效能指標之資源指標-網路IO-關注指標
有時系統性能的低下是由於網路頻寬不足、網路抖動或者伺服器端的相關引數配置導致的。本節介紹網路IO的相關指標。
一、 配置
1.1 最大頻寬
LPAR能夠佔用的最大頻寬是有網路管理員/運營商配置決定的。如果需要了解某個LPAR的最大頻寬或者某N個LPAR共同佔用的最大頻寬，需諮詢網路管理員。
需要提醒一點，網路是有損耗的，比如控制包等因素，實際的頻寬佔用達不到100%，例如ATM網路達到85~90%就基本達到網路頻寬瓶頸了。
1.2 作業系統配置
事實上，網路相關的引數配置很少會被關注，一般均採用作業系統及中介軟體的預設配置。因為網路相關引數很少會明顯影響到系統的效能表現，也就是說，很少會被使用者感知到。本章僅做簡單介紹。
1. 獲取來源
NMON BBBP SHEET
命令列no –F –L
2. 詳細解釋
引數之多無法直視。可以參考man no，或者最新版本（比如AIX Version 7.2）的《Networks and communication management》，
http://public.dhe.ibm.com/systems/power/docs/aix/72/commadmndita_pdf.pdf
這裡簡單介紹幾個常見的、可能會被修改的引數
1）Socket的傳送/接收緩衝區的尺寸（sb_max、tcp_recvspace、tcp_sendspace、udp_recvspace、udp_sendspace）
2）啟用 TCP 優化，設定 RFC 1323（TCP 擴充套件到高效能）。rfc1323值為 1 表示 tcp_sendspace and tcp_recvspace 可以超過 64 KB。
3）tcp_nodelayack禁用延遲的應答
通常情況下，在伺服器之間收發資料包，依據 TCP 協議，節點 A 向節點 B 傳送一個數據報文 , 節點 B 收到這個資料報文以後，會向節點 A 返回一個 acknowledge 資訊。延遲 ACK 機制：TCP 在接收到資料時不立即向傳送方返回ACK，而是延遲傳送。一般延遲時間是 200ms。在等待發送ACK 期間，TCP收集需要往另一端傳送的資料，直到收集的資料大小超過 MSS 的定義或者延遲時間超時，TCP才將ACK資訊和需要傳送的資料合併成一個報文一起傳送。這樣有利於減少網路中的資料包，避免網路擁塞
針對tcp_nodelayack的實驗
在一個“報文從起點出發 -> 報文傳輸 -> 伺服器A處理轉發 -> 報文傳輸 -> 伺服器B處理轉發 -> 報文傳輸 -> 報文回到起點”的驗證系統中，針對4KB小報文和1.2 MB大報文分別進行測試，觀察tcp_nodelayack=1的效果。
在處理4KB小報文時，當設定tcp_nodelayack=1 禁用延遲的應答後，報文流轉全流程時間減少13.8毫秒或16.3%，網路頻寬佔用增加26.4 KB/s或1.4%。
在處理1.2MB大報文時，當設定tcp_nodelayack=1 禁用延遲的應答後，報文流轉全流程時間減少41.2毫秒或1.9%，網路頻寬佔用增加221.6 KB/s或2.1%。
禁用延遲的應答對小報文的傳輸效率提升較為明顯，對大報文傳輸效率提升不明顯（百分比較小）。如果排除掉伺服器的處理轉發時間（這個時間是固定的），那麼時間縮短的百分比會更大。
1.3 傳輸中介軟體配置
以MQ為例，MQ作為傳輸中介軟體，qm.ini中也有相關的引數會影響到傳輸的效率，qm.ini示例如下，這裡介紹幾個典型的引數。
1）Buffer
Buffer相關的引數，如果=0，則交由作業系統的TCP/IP管理buffer大小，如果是非0，則MQ覆蓋作業系統的配置。
SndBuffSize：通道的傳送端傳送buffer，可被特殊型別通道的引數（如RcvSndBuffSize）覆蓋
RcvBuffSize：通道的接收端接收buffer，可被特殊型別通道的引數（如RcvRcvBuffSize）覆蓋
RcvSndBuffSize：接收通道的傳送端的傳送buffer
RcvRcvBuffSize：接收通道的接收端的接收buffer
ClntSndBuffSize：客戶端伺服器模式下的客戶端的傳送buffer
ClntRcvBuffSize：客戶端伺服器模式下的客戶端的接收buffer
SvrSndBuffSize：客戶端伺服器模式下的伺服器端的傳送buffer
SvrRcvBuffSize: 客戶端伺服器模式下的伺服器端的接收buffer
聽起來很繁瑣，我們還是來個例項驗證。
將Buffer（SndBuffSize、RcvRcvBuffSize）由32K調整成64K，對比4K小報文和1.2 MB大報文的影響。這裡還是採用“報文從起點出發 -> 報文傳輸 -> 伺服器A處理轉發 -> 報文傳輸 -> 伺服器B處理轉發 -> 報文傳輸 -> 報文回到起點”的驗證系統。
在處理大報文時，將MQBuffer由32K調整成64K，報文流轉全流程時間減少32149.2毫秒或24.3%。
在處理小報文時，將MQBuffer由32K調整成64K，報文流轉全流程時間較少4.9毫秒或5.8%。
增大TCP/IP的Buffer對於大報文的傳輸效率提升較為明顯，對於小報文的傳輸效率提升不太明顯。
2）通道壓縮
針對某個通道，將其傳輸的報文進行壓縮，對大報文來說，不但減少頻寬的佔用，而且提高了傳輸成功率。
alter chl(通道名) chltype(SDR) compmsg(ZLIBHIGH)
alter chl(通道名) chltype(RCVR) compmsg(ZLIBHIGH)
繼續例項驗證
在傳輸1.2M大報文時，開啟MQ通道壓縮後，網路頻寬佔用減少為原來的1/12，報文流轉總時間減少255.0毫秒或11.9%。
在傳輸4K小報文時，開啟MQ通道壓縮後，網路頻寬佔用減少為原來的1/2（壓縮比為2:1），報文流轉總時間減少2.8毫秒或3.3%。
並且，伺服器的CPU利用率增加非常小（例如：從16%增加到17.5%）。
3）通道批次BATCHSZ
由於MQ按照批次（BATCHSZ）的值進行提交和回滾確認(驗證這一個批次是否都傳輸成功)，在傳輸過程中一旦出現問題，這個批次所有的報文都要重新傳輸。所以在網路不穩定的情況下(傳輸資料有丟失)，BATCHSZ設定的值越大，一個批次中有資料出錯的概率就越大，重新提交傳輸的訊息就越多，在有些情況下（尤其是大報文場景），甚至長時間不能完成一個批次的傳輸。
此時可以將每個傳輸批次改小，傳輸成功一個就確認一個，減少重傳概率。
某大報文（1.2M）傳輸場景中，當傳輸批次=50時，傳輸效果如下，通道經常中斷
將批次改為1之後的Network圖形如下
二、 關注指標
2.1 LPAR佔用的頻寬
1. 獲取來源
從網路裝置上讀取的頻寬佔用最準確，但網路裝置往往連線多個主機，因此，從LPAR上讀取自身佔用的網路頻寬是一個比較適用的方法。
Nmon：NET Sheet
命令列topas：Network：BPS、B-In、B-Out
2. 詳細解釋
Nmon NET Sheet中找到實際對外通訊的網絡卡（例如en1），讀取對應的en1-write（本機向外傳送）、en1-read（本機收到）、en1-total。讀數均為計算機的單位Byte，若轉換為網路bps，需乘以8。
3. 觀察頻寬佔用的意義
觀察頻寬佔用情況，並結合CPU利用率等情況，可以幫助判斷問題的原因出自哪裡。如果懷疑到網路方面的原因，可以抓取tcpdump或者其他抓包工具進行深入分析，並檢查相關網路裝置。
假設系統的吞吐量下降了，或者吞吐量忽高忽低的抖動。
如果頻寬佔用中read下降，那麼有可能是傳送方沒有將足夠量的報文傳送到本伺服器。或者因為網路擁塞、通道異常等網路原因引起的接收報文吞吐量下降。
如果頻寬佔用中read基本沒有變化，而write降低，那麼有可能是本伺服器處理報文的能力下降了，或者本伺服器希望將報文發出去，但接收節點沒有能力接收。
以下圖為例，圖中的網路流量有幾個問題，1）有很多網路頻寬佔用率幾乎為0的情況，2）有小部分時間段收到了報文資料，但並沒有將他們處理後發出去，3）收到報文後並沒有及時處理並將之發出，而是有一小段時間的延遲。
結合對應的CPU利用率的圖形，可以推測
問題1）有很多網路頻寬佔用率幾乎為0的情況
此時業務處理的吞吐量下降肯定不是有應用程式造成的，而是可能由於傳送方沒有將足夠量的報文傳送到本伺服器。或者因為網路擁塞、通道異常等網路原因。
本案中進一步檢視傳送方，傳送方有大量報文堆積在傳送佇列，那麼，說明是網路方面原因。進一步檢查網路，ping包是沒有問題的，而且兩臺伺服器之間的探測是通暢的，而傳送方與接收方之間的傳輸通道卻異常中斷。
本案中進一步分析通道中斷的原因。發現傳輸大報文（比如1MB）的時候，非常容易復現本問題，而傳輸小報文則沒有遇到過本問題。懷疑是因為MQ傳輸的批次太大並且報文也太大，疊加效果就是隻要一個傳輸失敗就觸發了MQ的某個bug。
解決：將通道批次由50改為1，問題得到明顯緩解。
問題2）有小部分時間段收到了報文資料，但並沒有將他們處理後發出去。
可能是本伺服器沒有處理報文，或者本伺服器已經處理，但傳送時，對端節點不接收。
本案中檢視傳送通道、對端節點均沒有異常，斷定是應用程式沒有正常處理報文。
問題3）收到報文後並沒有及時處理並將之發出，而是有一小段時間的延遲。
在傳送通道正常的情況下，這種情況幾乎可以斷定是本機應用程式的問題。
2.2 網路響應時間
多個系統互動共同完成一個交易時，交易的響應時間必然包含的網路傳輸時間。有時網路的傳輸效率低下或者不穩定，不僅降低交易的處理效率，有時甚至會導致交易的失敗（很多交易有超時機制）。
檢視網路是否正常，通常採用ping命令檢視ping的延時是否在合理範圍，是否有丟包現象。
在區域網當中，ping延時0~1ms為正常，超過10ms時需要關注網路問題。
在廣域網中，ping延時30ms內為正常。
有些交換機對ping命令設定了較低的優先順序，可能在回覆、轉發ping包的時候有延遲，因此ping的結果不一定能反映真實情況。如果需要更為精確的測量可以探針捕獲從某伺服器建立TCP連線時傳送的SYN包後開始計時起，到其收到對端發回的TCP SYNACK後的時間差。
如果採用專業的網路裝置進行捕獲，不但不影響伺服器本身的效能，並且可以區分出哪一段網路延時較大。
