通過什么方法來排查是否linux服務(wù)器的負(fù)載過大？
通過top命令來查看服務(wù)器負(fù)載
再對此Linux服務(wù)器性能分析之前，先了解下Linux系統(tǒng)Load average負(fù)載的知識，負(fù)載均值在uptime 或者top 命令中可以看到，它們可能會顯示成這個樣子：load average: 0.15, 0.14, 0.11
很多人會這樣理解負(fù)載均值：三個數(shù)分別代表不同時間段的系統(tǒng)平均負(fù)載（一分鐘、五分鐘、以及十五分鐘），它們的數(shù)字當(dāng)然是越小越好。數(shù)字越高，說明服務(wù)器的負(fù)載越大,這也可能是服務(wù)器出現(xiàn)某種問題的信號。
一個單核的處理器可以形象得比喻成一條單車道。如果前面沒有車輛在等待，那么你可以告訴后面的司機(jī)通過。如果車輛眾多，那么需要告知他們可能需要稍等一會。
因此，需要些特定的代號表示目前的車流情況，例如：
0.00 表示目前橋面上沒有任何的車流。實際上這種情況與0.00 和1.00 之間是相同的，總而言之很通暢，過往的車輛可以絲毫不用等待的通過。
1.00 表示剛好是在這座橋的承受范圍內(nèi)。這種情況不算糟糕，只是車流會有些堵，不過這種情況可能會造成交通越來越慢。
超過1.00，那么說明這座橋已經(jīng)超出負(fù)荷，交通嚴(yán)重的擁堵。那么情況有多糟糕？例如2.00 的情況說明車流已經(jīng)超出了橋所能承受的一倍，那么將有多余過橋一倍的車輛正在焦急的等待。3.00 的話情況就更不妙了，說明這座橋基本上已經(jīng)快承受不了，還有超出橋負(fù)載兩倍多的車輛正在等待。
上面的情況和處理器的負(fù)載情況非常相似。一輛汽車的過橋時間就好比是處理器處理某線程的實際時間。Unix 系統(tǒng)定義的進(jìn)程運行時長為所有處理器內(nèi)核的處理時間加上線程在隊列中等待的時間。
和收過橋費的管理員一樣，你當(dāng)然希望你的汽車（操作）不會被焦急的等待。所以，理想狀態(tài)下，都希望負(fù)載平均值小于1.00 。當(dāng)然不排除部分峰值會超過1.00，但長此以往保持這個狀態(tài)，就說明會有問題，這時候你應(yīng)該會很焦急。
“所以你說的理想負(fù)荷為1.00 ？”
嗯，這種情況其實并不完全正確。負(fù)荷1.00 說明系統(tǒng)已經(jīng)沒有剩余的資源了。在實際情況中，有經(jīng)驗的系統(tǒng)管理員都會將這條線劃在0.70：
“需要進(jìn)行調(diào)查法則”：如果長期你的系統(tǒng)負(fù)載在0.70 上下，那么你需要在事情變得更糟糕之前，花些時間了解其原因。
“現(xiàn)在就要修復(fù)法則”：1.00 。如果你的服務(wù)器系統(tǒng)負(fù)載長期徘徊于1.00，那么就應(yīng)該馬上解決這個問題。否則，你將半夜接到你上司的電話，這可不是件令人愉快的事情。
“凌晨三點半鍛煉身體法則”：5.00。如果你的服務(wù)器負(fù)載超過了5.00 這個數(shù)字，那么你將失去你的睡眠，還得在會議中說明這情況發(fā)生的原因，總之千萬不要讓它發(fā)生。
那么多個處理器呢？我的均值是3.00，但是系統(tǒng)運行正常！哇喔，你有四個處理器的主機(jī)？那么它的負(fù)載均值在3.00 是很正常的。在多處理器系統(tǒng)中，負(fù)載均值是基于內(nèi)核的數(shù)量決定的。以100% 負(fù)載計算，1.00 表示單個處理器，而2.00 則說明有兩個雙處理器，那么4.00 就說明主機(jī)具有四個處理器。
回到我們上面有關(guān)車輛過橋的比喻。1.00 我說過是“一條單車道的道路”。那么在單車道1.00 情況中，說明這橋梁已經(jīng)被車塞滿了。而在雙處理器系統(tǒng)中，這意味著多出了一倍的負(fù)載，也就是說還有50% 的剩余系統(tǒng)資源- 因為還有另外條車道可以通行。
所以，單處理器已經(jīng)在負(fù)載的情況下，雙處理器的負(fù)載滿額的情況是2.00，它還有一倍的資源可以利用。
從上圖的top命令可以了解到，Linux服務(wù)器運行了5天23小時20分，在load average的數(shù)據(jù)來看，這臺快吧Linux無盤服務(wù)器可以說是壓力為零，運行十分流暢。
方法二：輸入iostat -x -k -t 說明：%util:一秒中有百分之多少的時間用于I/O操作，或者說一秒中有多少時間I/O隊列是非空的。
即delta(use)/s/1000 (因為use的單位為毫秒)
如果%util接近100%，說明產(chǎn)生的I/O請求太多，I/O系統(tǒng)已經(jīng)滿負(fù)荷，該磁盤可能存在瓶頸。
方法三：
如果玩游戲很卡，可以用hdparm –t /dev/磁盤名稱來測試磁盤性能是否達(dá)標(biāo)，下圖是單個希捷1T的盤測試的結(jié)果說明：sd表示硬盤是SATA，SCSI或者SAS，a表示串口的第一塊硬盤 本文轉(zhuǎn)摘自：http://www.flybaaa.com/help/69_1.html
一直以來以為通過top然后按數(shù)字1鍵，查到的cpu個數(shù)是服務(wù)器的物理cpu個數(shù)，今天在看服務(wù)器的硬件配置清單中發(fā)現(xiàn)一服務(wù)器的物理cpu個數(shù)是4個，我就奇怪了，這臺機(jī)子我的影響很深，明明是48啊，當(dāng)時通過top 1查看cpu信息還提示 “Sorry ,terminal is not big enough”。想當(dāng)初服務(wù)器只能識別到32個。還是重新編譯內(nèi)核搞定的。后來經(jīng)過查詢原來不是這樣滴，top 1查看的是邏輯cpu個數(shù)，一下為記。
查看Linux服務(wù)器的CPU詳細(xì)情況
判斷Linux服務(wù)器CPU情況的依據(jù)如下：
具有相同core id的CPU是同一個core的超線程。(Any cpu with the same core id are hyperthreads in the same core.)
具有相同physical id的CPU是同一個CPU封裝的線程或核心。(Any cpu with the same physical id are threads or cores in the same physical socket.)
下面舉例說明。
物理CPU個數(shù)如下：
[root@dbabc.net ～］# cat /proc/cpuinfo| grep "physical id"| sort| uniq| wc -l 4
每個物理CPU中core的個數(shù)(即核數(shù))如下：
[root@dbabc.net ～］# cat /proc/cpuinfo| grep "cpu cores"| uniq cpu cores : 12
邏輯CPU的個數(shù)如下：
［root@dbabc.net ～］#cat /proc/cpuinfo| grep "processor"| wc -l 48
按理說物理CPU個數(shù)×核數(shù)就應(yīng)該等于邏輯CPU的
Dbabc.Net [http://dbabc.net]
本文鏈接：http://dbabc.net/archives/2012/02/13/linux-cpu-info-count.shtml