叢集最主要的瓶頸是：磁碟。當我們面對集群作戰的時候，我們所希望的是即讀即得。但面對大數據，讀取資料需要經過磁碟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狀況，果然磁碟寫入效能有問題，請見下圖：
----------------------------------------------- -------------------------------------------------- ---------------------------------------
案例三
這是資料庫寫入超時的錯誤，對這個錯誤訊息我們記憶猶新。之前遇到過兩次（3月14日、4月2日），都是資料庫伺服器所在的雲端伺服器磁碟IO問題引起的。
14:19，我們向阿里雲提交了工單，特地在標題中加了「緊急」；
14:42，沒有阿里雲客服的進一步訊息，我們就回覆說「如果短時間內解決不了，希望盡快進行集群遷移」（3月14日就是透過集群遷移解決這個問題的，阿里雲的技術人員也說過對於叢集負載高造成的磁碟IO問題，目前唯一的解決辦法就是叢集遷移）；
14:47，阿里雲客服只回覆說正在處理；
14:59，還是沒消息，我們心急如焚（40分鐘過去了，連個說法都沒有），在工單中說：「能不能先做集群遷移？」；
然後，接到阿里雲端客服的電話，說叢集中其他雲端伺服器佔用的磁碟IO高影響了我們，他們正在處理。 。 。
過了會，阿里雲客服又打電話過來說可能是我們雲端伺服器中的系統或應用程式導致伺服器磁碟寫入卡死，讓我們重新啟動雲端伺服器。 （這樣的考慮可能是因為這時叢集的負載已經降下來，但我們的雲端伺服器磁碟IO還是高。）
15:23左右，我們重啟了資料庫伺服器，但問題依舊。
15:30，阿里雲客服終於決定進行叢集遷移（從提交工單到決定叢集遷移耗時1小10分鐘）
15:45，完成叢集遷移（上次遷移5分鐘不到，這次花了15分鐘，這也是阿里雲客服所說的進行集群遷移所需的最長時間）
遷移之後，傻眼了，磁碟IO（Avg.Disk Write Queue Length）還是那麼高！
為什麼這次叢集遷移不能像上次那樣立即解決問題？我們猜測有兩個可能的原因：
1、遷移後所在的叢集磁碟IO負載依然高；
2、 雲端伺服器上出現磁碟IO很高的這個分割區放的都是資料庫日誌文件，可能這個時間段日誌寫入操作比平常頻繁（但暴增幾乎沒有可能）而且所有日誌文件在同一個分 區，超過了雲端伺服器磁碟IO的某個極限，造成磁碟IO效能驟降（可能性比較大，依據是雲端運算之路-入阿里雲後：解決images.cnblogs.com 響應速度慢的詭異問題）。雖然之前使用實體伺服器時，日誌檔案也是放在同一個分割區，從未出現過這個問題，但現在雲端伺服器的磁碟IO能力無法與實體伺服器相 比，而且磁碟IO會被集群上其他雲端伺服器爭搶（詳見雲端運算之路-遷入阿里雲後：問題的根源——買到她的“人”，卻買不到她的“心” ）。
不管是哪一個原因，要解決問題只有一招也是最後一招－減輕日誌檔案所在的磁碟分割的IO壓力。
怎麼減壓呢？根據“遷入阿里雲後的一些心得”一文中的“提高整體磁碟IO性能的小偏方”，另外購買一塊磁碟空間，然後將存放博文內容的資料庫CNBlogsText（大文本資料寫入，對磁碟IO產生的壓力很大）的日誌檔案移至獨立的磁碟分割。
在SQL Server中，無法線上完成將資料庫日誌檔案從一個磁碟分割區移至另一個磁碟分割區。需要先detach資料庫，然後將日誌檔案複製到目標分割區，然後再attach這個資料庫；在attach時，將日誌檔案的位置修改為新的路徑。
於是，在別無選擇的情況下，我們CNBlogsText資料庫進行detach操作，並且選擇了drop connections，哪知在detach的過程中悲劇發生了，detach失敗了，錯誤是：
Transaction (Process ID 124) was deadlocked on lock resources with another process and 有 been chosen as the deadlock victim. Rerun the transaction.
在 detach的過程中竟然發生了死鎖，然後「被犧牲」了。讓人困惑的是，不是drop connections嗎，怎麼還會發生死鎖？可能drop connections是在detach操作正式開始前，在detach的過程中，還會發生資料庫寫入操作，這時的寫入操作引發了deadlock。為什 麼偏偏要讓detach犧牲？不合情理。
detach失敗後，CNBlogsText資料庫就處於Single User狀態。繼續detach，同樣的錯誤，同樣的「被犧牲」。
於是，重啟了一下SQL Server服務。重啟之後，CNBlogsText資料庫的狀態變成了In Recovery。
這時時間已經到了16:45。
這樣的In Recovery狀態以前沒遇過，不知如何處理，也不敢輕舉妄動。
過了一段時間，刷新了一下SQL Server的Databases列表，CNBlogsText資料庫又顯示為之前的Single User狀態。 （原來重開SQL Server之後，會自動先進入In Recovery狀態，再進入到Single User狀態）
針對Single User狀態問題，在工單中諮詢了阿里雲客服，阿里雲客服聯絡了資料庫工程師，得到的建議是進行這樣的操作：alter database $db_name SET multi_user
於是，執行了這樣的SQL：
exec sp_dboption 'CNBlogsText', N'single', N'false'
出現錯誤提示：
Database 'CNBlogsText' is already open and can only have one user at a time.
Single User狀態依舊，出現這個錯誤可能是因為這個資料庫不斷有寫入操作，而搶佔Single User狀態下只允許唯一的資料庫連線。
（更新：后来从阿里云DBA那学习到解决这个问题的方法：
select spid from sys.sysprocesses where dbid=DB_ID('dbname'); --得到当前占用数据库的进程id kill [spid] go alter login [username] disable --禁用新的访问 go use cnblogstext go alter database cnblogstext set multi_user with rollback immediate go
）
当时的情形下，我们不够冷静，急着想完成detach操作。觉得屏蔽CNBlogsText数据库的所有写入操作可能需要禁止这台服务器的所有数据库连接，这样会影响整站的正常访问，所以没从这个角度下手。
这时时间已经到了17:08。
我们也准备了最最后一招，假如实在detach不了，假如日志文件也出了问题，我们可以通过数据文件恢复这个数据库。这个场景我们遇到过，也实际成功操作过，详见：SQL Server 2005数据库日志文件损坏的情况下如何恢复数据库。所需的SQL语句如下：
use master alter database dbname set emergency declare @databasename varchar(255) set @databasename='dbname' exec sp_dboption @databasename, N'single', N'true' --将目标数据库置为单用户状态 dbcc checkdb(@databasename,REPAIR_ALLOW_DATA_LOSS) dbcc checkdb(@databasename,REPAIR_REBUILD) exec sp_dboption @databasename, N'single', N'false'--将目标数据库置为多用户状态
即使最最后一招也失败了，我们在另外一台云服务器上有备份，在异地也有备份，都有办法恢复，只不过需要的恢复时间更长一些。
想到这些，内心平静了一些，认识到当前最重要的是抛开内疚、紧张、着急，冷静面对。
我们在工单中继续咨询阿里云客服，阿里云客服联系了数据库工程师，让我们加一下这位工程师的阿里旺旺。
我们的电脑上没装阿里旺旺，于是打算自己再试试，如果还是解决不了，再求助阿里云的数据库工程师。
在网上找了一个方法：SET DEADLOCK_PRIORITY NORMAL（来源），没有效果。
时间已经到了17:38。
这时，我们冷静地分析一下：detach时，因为死锁“被牺牲”；从单用户改为多用户时，提示“Database 'CNBlogsText' is already open and can only have one user at a time.”。可能都是因为程序中不断地对这个数据库有写入操作。试试修改一下程序，看看能不能屏蔽所有对这个数据库的写入操作，然后再将数据库恢复为多 用户状态。
修改好程序，18:00之后进行了更新。没想到更新之后，将单用户改为多用户的SQL就能执行了：
exec sp_dboption 'CNBlogsText', N'single', N'false'
于是，Single User状态消失，CNBlogsText数据库恢复了正常状态，然后尝试detach，一次成功。
接着将日志文件复制到新购的磁盘分区中，以新的日志路径attach数据库。attach成功之后，CNBlogsText数据库恢复正常，博客后台可以正常发布博文，CNBlogsText数据库日志文件所在分区的磁盘IO（单独的磁盘分区）也正常。问题就这么解决了。
当全部恢复正常，如释重负的时候，时间已经到了18:35。
原以为可以用更多的内存弥补云服务器磁盘IO性能低的不足。但万万没想到，云服务器的硬伤不是在磁盘IO性能低，而是在磁盘IO不稳定。
更多相关知识，请访问：PHP中文网！
以上是群集最主要的瓶頸是什麼？的詳細內容。更多資訊請關注PHP中文網其他相關文章！
