集群的最主要瓶颈是什么？
发布时间：2024-04-21 点击：77
集群的最主要瓶颈是：磁盘。当我们面临集群作战的时候，我们所希望的是即读即得。可是面对大数据，读取数据需要经过磁盘io，这里可以把io理解为水的管道。管道越大越强，我们对于t级的数据读取就越快。所以io的好坏，直接影响了集群对于数据的处理。
集群的瓶颈提出多种看法，其中网络和磁盘io的争议比较大。这里需要说明的是网络是一种稀缺资源，而不是瓶颈。
对于磁盘io：（磁盘io：磁盘输出输出）
当我们面临集群作战的时候，我们所希望的是即读即得。可是面对大数据，读取数据需要经过io，这里可以把io理解为水的管道。管道越大越强，我们对于t级的数据读取就越快。所以io的好坏，直接影响了集群对于数据的处理。
这里举几个例子，让大家来参考一下。
案例一
自从使用阿里云以来，我们遇到了三次故障（一、二、三），这三次故障都与磁盘io高有关。
第一次故障发生在跑zzk.cnblogs.com索引服务的云
服务器上，当时的avg.disk read queue
length高达200多；
第二次故障发生在跑images.cnblogs.com静态文件的云服务器上，当时的avg.disk read
queue length在2左右（后来分析，对于图片站点这样的直接读文件进行响应的应用，disk read queue
length达到这个值会明显影响响应速度）；
第三次故障发生在跑数据库服务的云服务器上，当时的avg. disk write queue
length达到4~5，造成很多的数据库写入操作超时。
（这里既提到“硬盘”，又提到“磁盘”，我们这样界定的：在云服务器中看到的硬盘叫磁盘[虚拟出来的硬盘]，在集群中的物理硬盘叫硬盘）
这三次的磁盘io高都不是我们云服务器内的应用引起的，最直接的证据就是将云服务迁移至另一个集群之后，问题立即解决。也就是说云服务器的磁盘io高是因
为它所在的集群的硬盘io高。
集群的硬盘io是集群内所有云服务器的磁盘io的累加，集群的硬盘io高是因为集群中某些云服务器的磁盘io过高。而我们自
己的云服务器内的应用产生的磁盘io在正常范围，问题出在其他用户的云服务器产生过多的磁盘io，造成整个集群硬盘io高，从而影响了我们。
为什么其他云服务器引起的硬盘io问题会影响到我们？问题的根源就在于集群的硬盘io被集群中的所有云服务器所共享，而且这种共享没有被有效的限制、没有
被有效的隔离，大家都在争抢这个资源，同时争抢的人太多，就会排长多。
而且对于每个云服务器来说，也不知道有多少台云服务器在争抢，从云服务器使用者的角
度根本无法躲开这个争抢；就像在世博会期间，你起再早去排队，也得排超长的队。
如果每个云服务器使用的硬盘io资源是被限制或隔离的，其他云服务器产生再
多的磁盘io也不会影响到我们的云服务器；就像在一个小区，你一个人租了一套房子，其他的一套房子即使住了100人，也不会影响到你。
你可以买到cpu、内存、带宽、硬盘空间，你却买不到一心一意为你服务的硬盘io，这就是当前阿里云虚拟化平台设计时未考虑到的一个重要问题。
经过与阿里云技术人员的沟通，得知他们已经意识到这个问题，希望这个问题能早日得到解决。
—————————————————————————————————————————————
案例2
云计算之路-迁入阿里云后：20130314云服务器故障经过
首先向大家致歉，这次云服务器故障发现于17:30左右，18:30左右恢复正常，给大家带来了麻烦，请大家谅解！
故障的原因是云服务器所在的集群负载过高，磁盘写入性能急剧下降，造成很多数据库写入操作超时。后来恢复正常的解决方法是将云服务器迁移至另一个集群。
下面是故障发生的主要经过：
今天上午9:15左右一位园友通过邮件反馈在访问园子时遇到502 bad gateway错误.
这是由阿里云负载均衡器返回的错误，tegine是由阿里巴巴开发的开源web服务器。我们猜测阿里云提供的负载均衡服务可能是通过tegine反向代理实现的。
这个错误页面表示负载均衡器检测到负载均衡中的云服务器返回了无效的响应，比如500系列错误。
我们将这个情况通过工单反馈给了阿里云，得到的处理反馈是继续观察，可能是这位用户的网络线路的临时问题导致。
由于我们在这个时间段没遇到这个问题，也没有其他用户反馈这个问题，我们也认可了继续观察的处理方式。
（根据我们后来的分析，出现502 bad gateway错误可能是集群出现了瞬时负载高的情况）
下午17:20左右，我们自己也遇到了502 bad gateway错误，持续了大约1-2分钟。见下图：
出问题期间，我们赶紧登录到两台云服务器查看情况，发现iis并发连接数增长至原来的30多倍，而bytes
send/sec为0，而且两台云服务器都是同样的情况。我们当时推断，这两台云服务器本身应该没有问题，问题可能出在它们与数据库服务器之间的网络通
信。我们继续将这个情况通过工单反馈给阿里云。
刚把工单填好，我们就接到园友的电话反馈说博客后台不能发布文章，我们一测试，果然不能发布，报数据库超时错误，见下图：
但打开现有的文章速度很快，也就是说读正常，写有问题。赶紧登录数据库服务器通过性能监视器查看磁盘io情况，果然磁盘写入性能有问题，见下图：
avg. disk write queue length超过1就说明有问题了，现在平均已经到了4~5。进入阿里云网站上的管理控制台一看，磁盘io问题就更明显了，见下图：
继续向阿里云反馈情况，得到的反馈是这台云服务器iops太高了，见下图：
于是，阿里云工作人员将这台云服务器迁移至另一个集群，问题立刻解决。
—————————————————————————————————————————————-
案例三
14:17左右，我们看到了这条闪存。立即进入博客后台测试，发现提交时会出现如下的错误：
"timeout expired. the timeout period elapsed prior to completion of the operation or the server is not responding."
这是数据库写入超时的错误，对这个错误信息我们记忆犹新。之前遇到过两次（3月14日、4月2日），都是数据库服务器所在的云服务器磁盘io问题引起的。
登上云服务器，查看windows性能监视器，发现日志文件所在的磁盘的io监测数据avg.disk write queue
length平均值在5以上。性能监视器中这个值的纵坐标最高值是1，可想而知5是多么高的一个值。性能监视器中的走势图几乎是一条直线。见下图（最高值
竟然达到了20，真恐怖）：
（为什么数据库写入超时会表现于日志文件所在的磁盘io高？因为数据库恢复模式用的是full，对数据库的数据写入，会先在日志中进行写入操作。）
这次问题与3月14日磁盘io问题的表现是一样的，所以我们断定这次也是同样的原因，是云服务器所在集群的磁盘io负载高引起的。
14:19，我们向阿里云提交了工单，特地在标题中加了“紧急”；
14:23，阿里云客服回复说正在核实我们提交的问题；
14:31，阿里云客服回复说已反馈给相关部门检查；
14:42，没有阿里云客服的进一步消息，我们就回复说“如果短时间内解决不了，希望尽快进行集群迁移”（3月14日就是通过集群迁移解决这个问题的，阿里云的技术人员也说过对于集群负载高引起的磁盘io问题，目前唯一的解决办法就是集群迁移）；
14:47，阿里云客服只回复说正在处理；
14:59，还是没消息，我们心急如焚（40分钟过去了，连个说法都没有），在工单中说：“能不能先做集群迁移？”；
然后，接到阿里云客服的电话，说集群中其他云服务器占用的磁盘io高影响了我们，他们正在处理。。。
过了会，阿里云客服又打电话
为什么说云原生是企业数字化转型的通关密码？
阿里云服务器硬盘容量多大
租赁云端服务器的价格组成
给初级seo的建议 如何端正自己对seo的态度
传统服务器和云计算的区别
北京云服务器怎么购买虚拟主机
数据库内容空白-虚拟主机/数据库问题
阿里云服务器配置教程超级vps管理器
集群的瓶颈提出多种看法，其中网络和磁盘io的争议比较大。这里需要说明的是网络是一种稀缺资源，而不是瓶颈。
对于磁盘io：（磁盘io：磁盘输出输出）
当我们面临集群作战的时候，我们所希望的是即读即得。可是面对大数据，读取数据需要经过io，这里可以把io理解为水的管道。管道越大越强，我们对于t级的数据读取就越快。所以io的好坏，直接影响了集群对于数据的处理。
这里举几个例子，让大家来参考一下。
案例一
自从使用阿里云以来，我们遇到了三次故障（一、二、三），这三次故障都与磁盘io高有关。
第一次故障发生在跑zzk.cnblogs.com索引服务的云
服务器上，当时的avg.disk read queue
length高达200多；
第二次故障发生在跑images.cnblogs.com静态文件的云服务器上，当时的avg.disk read
queue length在2左右（后来分析，对于图片站点这样的直接读文件进行响应的应用，disk read queue
length达到这个值会明显影响响应速度）；
第三次故障发生在跑数据库服务的云服务器上，当时的avg. disk write queue
length达到4~5，造成很多的数据库写入操作超时。
（这里既提到“硬盘”，又提到“磁盘”，我们这样界定的：在云服务器中看到的硬盘叫磁盘[虚拟出来的硬盘]，在集群中的物理硬盘叫硬盘）
这三次的磁盘io高都不是我们云服务器内的应用引起的，最直接的证据就是将云服务迁移至另一个集群之后，问题立即解决。也就是说云服务器的磁盘io高是因
为它所在的集群的硬盘io高。
集群的硬盘io是集群内所有云服务器的磁盘io的累加，集群的硬盘io高是因为集群中某些云服务器的磁盘io过高。而我们自
己的云服务器内的应用产生的磁盘io在正常范围，问题出在其他用户的云服务器产生过多的磁盘io，造成整个集群硬盘io高，从而影响了我们。
为什么其他云服务器引起的硬盘io问题会影响到我们？问题的根源就在于集群的硬盘io被集群中的所有云服务器所共享，而且这种共享没有被有效的限制、没有
被有效的隔离，大家都在争抢这个资源，同时争抢的人太多，就会排长多。
而且对于每个云服务器来说，也不知道有多少台云服务器在争抢，从云服务器使用者的角
度根本无法躲开这个争抢；就像在世博会期间，你起再早去排队，也得排超长的队。
如果每个云服务器使用的硬盘io资源是被限制或隔离的，其他云服务器产生再
多的磁盘io也不会影响到我们的云服务器；就像在一个小区，你一个人租了一套房子，其他的一套房子即使住了100人，也不会影响到你。
你可以买到cpu、内存、带宽、硬盘空间，你却买不到一心一意为你服务的硬盘io，这就是当前阿里云虚拟化平台设计时未考虑到的一个重要问题。
经过与阿里云技术人员的沟通，得知他们已经意识到这个问题，希望这个问题能早日得到解决。
—————————————————————————————————————————————
案例2
云计算之路-迁入阿里云后：20130314云服务器故障经过
首先向大家致歉，这次云服务器故障发现于17:30左右，18:30左右恢复正常，给大家带来了麻烦，请大家谅解！
故障的原因是云服务器所在的集群负载过高，磁盘写入性能急剧下降，造成很多数据库写入操作超时。后来恢复正常的解决方法是将云服务器迁移至另一个集群。
下面是故障发生的主要经过：
今天上午9:15左右一位园友通过邮件反馈在访问园子时遇到502 bad gateway错误.
这是由阿里云负载均衡器返回的错误，tegine是由阿里巴巴开发的开源web服务器。我们猜测阿里云提供的负载均衡服务可能是通过tegine反向代理实现的。
这个错误页面表示负载均衡器检测到负载均衡中的云服务器返回了无效的响应，比如500系列错误。
我们将这个情况通过工单反馈给了阿里云，得到的处理反馈是继续观察，可能是这位用户的网络线路的临时问题导致。
由于我们在这个时间段没遇到这个问题，也没有其他用户反馈这个问题，我们也认可了继续观察的处理方式。
（根据我们后来的分析，出现502 bad gateway错误可能是集群出现了瞬时负载高的情况）
下午17:20左右，我们自己也遇到了502 bad gateway错误，持续了大约1-2分钟。见下图：
出问题期间，我们赶紧登录到两台云服务器查看情况，发现iis并发连接数增长至原来的30多倍，而bytes
send/sec为0，而且两台云服务器都是同样的情况。我们当时推断，这两台云服务器本身应该没有问题，问题可能出在它们与数据库服务器之间的网络通
信。我们继续将这个情况通过工单反馈给阿里云。
刚把工单填好，我们就接到园友的电话反馈说博客后台不能发布文章，我们一测试，果然不能发布，报数据库超时错误，见下图：
但打开现有的文章速度很快，也就是说读正常，写有问题。赶紧登录数据库服务器通过性能监视器查看磁盘io情况，果然磁盘写入性能有问题，见下图：
avg. disk write queue length超过1就说明有问题了，现在平均已经到了4~5。进入阿里云网站上的管理控制台一看，磁盘io问题就更明显了，见下图：
继续向阿里云反馈情况，得到的反馈是这台云服务器iops太高了，见下图：
于是，阿里云工作人员将这台云服务器迁移至另一个集群，问题立刻解决。
—————————————————————————————————————————————-
案例三
14:17左右，我们看到了这条闪存。立即进入博客后台测试，发现提交时会出现如下的错误：
"timeout expired. the timeout period elapsed prior to completion of the operation or the server is not responding."
这是数据库写入超时的错误，对这个错误信息我们记忆犹新。之前遇到过两次（3月14日、4月2日），都是数据库服务器所在的云服务器磁盘io问题引起的。
登上云服务器，查看windows性能监视器，发现日志文件所在的磁盘的io监测数据avg.disk write queue
length平均值在5以上。性能监视器中这个值的纵坐标最高值是1，可想而知5是多么高的一个值。性能监视器中的走势图几乎是一条直线。见下图（最高值
竟然达到了20，真恐怖）：
（为什么数据库写入超时会表现于日志文件所在的磁盘io高？因为数据库恢复模式用的是full，对数据库的数据写入，会先在日志中进行写入操作。）
这次问题与3月14日磁盘io问题的表现是一样的，所以我们断定这次也是同样的原因，是云服务器所在集群的磁盘io负载高引起的。
14:19，我们向阿里云提交了工单，特地在标题中加了“紧急”；
14:23，阿里云客服回复说正在核实我们提交的问题；
14:31，阿里云客服回复说已反馈给相关部门检查；
14:42，没有阿里云客服的进一步消息，我们就回复说“如果短时间内解决不了，希望尽快进行集群迁移”（3月14日就是通过集群迁移解决这个问题的，阿里云的技术人员也说过对于集群负载高引起的磁盘io问题，目前唯一的解决办法就是集群迁移）；
14:47，阿里云客服只回复说正在处理；
14:59，还是没消息，我们心急如焚（40分钟过去了，连个说法都没有），在工单中说：“能不能先做集群迁移？”；
然后，接到阿里云客服的电话，说集群中其他云服务器占用的磁盘io高影响了我们，他们正在处理。。。
过了会，阿里云客服又打电话
为什么说云原生是企业数字化转型的通关密码？
阿里云服务器硬盘容量多大
租赁云端服务器的价格组成
给初级seo的建议 如何端正自己对seo的态度
传统服务器和云计算的区别
北京云服务器怎么购买虚拟主机
数据库内容空白-虚拟主机/数据库问题
阿里云服务器配置教程超级vps管理器
上一篇：国外虚拟主机哪里买