云服务器如何选择 *** 作系统，带宽选择多大合适？

云服务器的 *** 作系统主要有两大类：Linux和Windows。

Linux *** 作系统，包括Ubuntu、Debian、CentOS等系统，这些都是非常优秀的开源系统，功能大同小异，界面和 *** 作方法略有不同，参照使用者对系统的熟悉程度和喜好即可。

Windows *** 作系统：

一般Windows *** 作系统常用的有Server2008和Server2012R2，其中又分为x86和x64两种。X86即32位，和x64(64位)最主要限制体现在内存上。由于32位本身的限制，最大可支持到4GB内存，如果您需要使用高于4GB的内存的需求，请使用64位 *** 作系统。选择选择2008版本还是选择2012呢建议版本越高越好，因为高版本漏洞更少，现在最高版本为2019。

一、根据开发语言选择：

网站开发语言为ASP、NET、HTML，选择Windows系统；

网站开发语言为PHP、HTML、WAP，选择Linux系统；

二、根据网站需要使用数据库来选择：

数据库为ACCESS、SQLServer，选择Windows系统。

数据库为MySQL、SQLite，选择Linux系统。

三、对 *** 作系统熟悉程度来选择：

如果平时没有接触过Linux下敲命令 *** 作系统（类似win下面的DOS），建议选择Windowssever系统。

如果熟悉Linux命令，那强烈建议使用Linux。

至于服务器的带宽则需要根据业务需求来具体计算，不同需求对带宽的要求也千差万别的。如果是公司主页，平时同时在线的访问人数也不会太大，几M的带宽应该是够用的了。但如果你是访问量非常大的论坛或视频下载网站，那就非常消耗带宽资源，几个G都有可能不够用。

1举例说明，如果你的站是公司网站，1M带宽就相当于200人左右在线。假如说是正常访问的话，那么就要看并发连接数目。最后用并发数目除以每个人所占用的带宽。

例如：2400人同时在线，2400人并发同时 *** 作，每个人的页面30KB，那么合算成带宽就是：2400/(30KB8)=10Mb

2举例说明，如果你的网站是视频网站

例如：网络环境是并发数目是1000，高清视频码率是2Mbps，标清码率是1Mbps。假如：1：2，单节点并发按600计算，那么它的总输出带宽是多少呢？

答：2002+4001=800Mbps

并发数和服务器的性能、带宽、网站页面大小各方面有着联系
mysql最大并发连接数设置

mysql 默认的最大并发连接为100,默认的连接数无法满足大量client 连接的请求
但是可以通过以下方式改变,使用root用户登录mysql 系统
引用
mysql > show variables like ’max_connections‘;
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| max_connections | 100 |
+-----------------+-------+
在不需要重启的情况下通过以下命令更改为300
引用
set global max_connections = 300;
为了保证mysql 重启能够生效,还需要编译 /myini (默认)
把
max_connections = 300
以上完成之后,下次重启就会使用新的参数。

1、公网带宽：是指服务器对外提供的网络带宽，即是通过互联网访问阿里云服务器的能力。而网络带宽是指在单位时间（一般指的是1秒钟）内能传输的数据量。网络和高速公路类似，带宽越大，就类似高速公路的车道越多，其通行能力越强。

2、阿里云服务器没有数据盘是没有关系的，服务器默认分配有系统盘，上面安装好了镜像 *** 作系统。如果对磁盘容量没有特别需求，用系统盘就可以了，日后可以升级扩充容量。

3、如果阿里云服务器没有公网带宽，就没有办法从外部（互联网）访问到这台服务器。只能通过阿里云的内部网络访问到服务器同一机房网络环境下的其他服务器。

扩展资料

1、公网带宽的计费方式

阿里云采用后付费方式，按实际使用流量收取ECS实例的公网带宽费用，不受ECS实例的计费方式和网络类型的限制，按小时计费。并且网络带宽价格因地域而不同。

2、公网带宽类型

（1）出网带宽：从ECS实例流出的带宽，比如您的ECS实例对外提供访问，或者从客户端FTP等工具下载ECS实例内部资源。

（2）入网带宽：流入ECS实例的带宽，比如您在ECS实例内部下载外部网络资源，或者从客户端FTP等工具上传资源到ECS实例。

3、购买公网带宽

根据访问公网的方式不同，可以采用不同的方式购买公网带宽：

（1）如果每个ECS实例均使用自己的公网IP地址访问公网，您需要在创建ECS实例时一起购买公网带宽。购买方法是：创建ECS实例时，设置公网带宽时，选择分配公网IP地址，并设置带宽峰值。

（2）对于VPC类型ECS实例，如果您想使用d性公网IP（EIP）地址访问公网，您只需要购买EIP服务即可。

参考资料来源：百度百科-网络带宽

是会影响的，因为网络的数据的传输的会经过很多的路由节点的，距离越远，速度就会越慢。比如：客户在国内用百兆独享机器，国内的服务器百兆独享肯定会快于美国的百兆独享的速度的。
带宽也有关系的，客户机与服务器的带宽对等的情况下，速度最快，如果一方的带宽小，取带宽小的一方的传输速度。
如果还不理解的话，可以查下海腾数据晋慧娟

有人删了千万级的数据，结果导致频繁的慢查询。

线上收到大量慢查询告警，于是检查慢查询的SQL，发现不是啥复杂SQL，这些SQL主要针对一个表，基本都是单行查询，看起来应该不会有慢查询。这种SQL基本上都是直接根据索引查找出来的，性能应该极高。

是否可能慢查询不是SQL问题，而是MySQL生产服务器的问题？特殊情况下，MySQL出现慢查询还真不是SQL问题，而是他自己生产服务器的负载太高，导致SQL语句执行慢。比如现在MySQL服务器的

磁盘I/O负载高，每秒执行大量高负载的随机I/O，但磁盘本身每秒能执行的随机I/O有限，导致正常SQL在磁盘执行时，若跑一些随机IO，你的磁盘太忙，顾不上你了，导致你本来很快的一个SQL，要等很久才能执行完毕，这时就可能导致正常SQL也变成慢查询。

也许网络负载高，导致你一个SQL语句要发到MySQL，光是等待获取一个和MySQL的连接，都很难，要等很久或MySQL自己网络负载太高，带宽打满，带宽打满后，你一个SQL也许执行很快，但其查出来的数据返回给你，网络都送不出去，也会变成慢查询。

若CPU负载过高，也会导致CPU过于繁忙去执行别的任务，没时间执行你的SQL。

所以慢查询不一定是SQL本身导致，若觉得SQL不应该会慢查询，结果他那个时间段跑这个SQL 就是慢，应排查当时MySQL服务器的负载，尤其看看磁盘、网络及 CPU 的负载，是否正常。

当某个离线作业瞬间大批量把数据往MySQL里灌入的时，他一瞬间服务器磁盘、网络以及CPU的负载会超高。

此时你一个正常SQL执行下去，短时间内一定会慢查询，类似问题，优化手段更多是控制你导致MySQL负载过高的那些行为，比如灌入大量数据，最好在业务低峰期灌入，别影响高峰期的线上系统运行。

但看了下MySQL服务器的磁盘、网络以及CPU负载，一切正常，似乎也不是这问题导致。看起来无解了？

慢 SQL 的头两步排查手段：

这两种办法都不奏效之后，第三步：用MySQL profilling工具去细致的分析SQL语句的执行过程和耗时。

这个工具可以对SQL语句的执行耗时进行非常深入和细致的分析

打开profiling，使用

接着MySQL就会自动记录查询语句的profiling信息。此时若执行show profiles，就会给你列出各种查询语句的profiling信息，会记录下来每个查询语句的query id，所以你要针对你需要分析的query找到对他的query id，我们当时就是针对慢查询的那个SQL语句找到了query id。

然后针对单个查询语句，看其profiling信息，使用show profile cpu, block io for query xx，这里的xx是数字，此时就可以看到具体的profile信息。

除了cpu以及block io以外，还能指定去看这个SQL语句执行时候的其他各项负载和耗时。

会给你展示出来SQL语句执行时候的各种耗时，比如磁盘IO的耗时，CPU等待耗时，发送数据耗时，拷贝数据到临时表的耗时等，SQL执行过程中的各种耗时都会展示。

检查该SQL语句的profiling信息后，发现问题，其Sending Data耗时最高，几乎使用1s，占据SQL执行耗时的99%！其他环节耗时低可以理解，毕竟这种简单SQL执行速度真的很快，基本就是10ms级别，结果跑成1s，那肯定Sending Data就是问题根源！

这Sending Data在干啥呢？

MySQL官方释义：为一个SELECT语句读取和处理数据行，同时发送数据给客户端的过程，简单来说就是为你的SELECT语句把数据读出来，同时发送给客户端。

但这过程为啥这么慢？profiling确实是提供给我们更多的线索了，但似乎还是没法解决问题。但已经捕获到异常关键点，就是Sending Data的耗时很高！

接着：

看innodb存储引擎的一些状态，此时发现一个奇怪的指标：history list length，值特别高，达到上万。

MVCC就是多个事务在对同一个数据， 有人写，有人读，此时可以有多种隔离级别，对一个数据有个多版本快照链条，才能实现MVCC和各种隔离级别。

所以当你有大量事务执行时，就会构建这种undo多版本快照链条，此时history list length就会很高。然后在事务提交后，会有一个多版本快照链条的自动purge清理机制，清理了，该值就会降低。一般该值不应过高，所以注意到第二个线索：history list length过高，即大量的undo多版本链条数据没有清理。推测可能有的事务长时间运行，所以其多版本快照不能被purge清理，进而导致history list length过高。

经过这俩线索推测，在大量简单SQL变成慢查询时，SQL因为Sending Data环节异常，耗时过高；同时此时出现一些长事务长时间运行，大量的频繁更新数据，导致有大量undo多版本快照链条，还无法purge清理。

因为发现有大量的更新语句在活跃，而且有那种长期活跃的长事务一直在跑而没有结束，问了下系统负责人，在后台跑了个定时任务：他居然开了一个事务，然后在一个事务里删除上千万数据，导致该事务一直在运行。

这种长事务的运行会导致你删除时，仅只是对数据加了一个删除标记，事实上并没有彻底删除。此时你若和长事务同时运行的其它事务里再查询，他在查询时可能会把那上千万被标记为删除的数据都扫描一遍。因为每次扫描到一批数据，都发现标记为删除了，接着就会再继续往下扫描，所以才导致一些查询语句很慢。

那为何你启动一个事务，在事务里查询，凭什么就要去扫描之前那个长事务标记为删除状态的上千万的垃圾数据？讲道理，那些数据都被删了，跟你没关系了呀，你可以不去扫描他们 嘛！

而问题症结在于，那个 删除千万级数据的事务是个长事务 ！即当你启动新事务查询时，那个删除千万级数据的长事务一直在运行，它是活跃的！结合MVCC的Read View机制，当你启动一个新事务查询时，会生成一个Read View。你的新事务查询时，会根据ReadView去判断哪些数据可见及可见的数据版本号，因为每个数据都有个版本链条，有时你能可见的仅是这个数据的一个 历史 版本。

所以正是因为该长事务一直在运行，还在删除大量数据，而且这些数据仅是逻辑删除，所以此时你新开事务的查询还是会读到所有逻辑删除数据，也就会出现千万级的数据扫描，导致了慢查询！

所以禁止在业务高峰期运行那种删除大量数据的语句，因为这可能导致一些正常的SQL都变慢查询，因为那些SQL也许会不断扫描你标记为删除的大量数据，好不容易扫描到一批数据，结果发现是标记为删除的，于是继续扫描下去，导致慢查询！

直接kill那个正在删除千万级数据的长事务，所有SQL很快恢复正常。此后，大量数据清理全部放在凌晨执行，那个时候就没什么人使用系统了，所以查询也很少。

这么大的表优化是很痛苦的，看你对数据的用途，如果不经常查询、而是频繁的增加，可以考虑定期（每周或者每日）把表中的数据复制到历史表中，清空工作表的数据，这样插入的效率能大大提高，但是查询的时候需要在两个表中进行查询。用于频繁插入数据的工作表要尽量少建索引，用于查询的历史表要多建索引。

---