近幾天在性能測試過程中，發現loadrunner Controller經常報 Server “**” has shut down the connection prematurely 。概率很高，現象很奇怪。網上有很多說法，各有不同，但貌似都不正確，只能靠自己追蹤。
根據經驗仔細分析，發現可能跟下列因素有關：
（1）loadrunner客戶端服務器網卡資源不足；
（2）tcp/ip或者http connection keepalive連接超時時間設置太長，造成無連接可用；
（3）應用服務端有問題。
一、用事實做詳細的對比：
分析：從對比結果來看，shut down的比例跟loadrunner客戶端確實有關系，但無論客戶端怎樣改變，還是該現象出現，而且比例始終超過萬分之1。
| loadrunner服務器數量 |
TcpTimedWaitDelay鍵值 |
並發用戶數 |
平均TPS |
shut down比例 |
| 1台 |
30s |
13 |
76.195 |
萬分之18.4 |
| 1台 |
10s |
7 |
66.49 |
萬分之10.8 |
| 2台 |
10s |
7 |
85.994 |
萬分之1.39 |
| 2台 |
10s |
2 |
33.544 |
萬分之1.23 |
至此，可以排除loadrunner客戶端的原因。
二、轉向服務端，在dpm服務器上，發現apache占用很大的資源，而且有報錯：
（1）在壓力情況下，apache（httpd進程）占用的物理內存，平均每秒增漲4M，非常恐怖；
（2）Apache日志中有三類報錯信息：
a、 [Tue Jun 30 18:54:37 2009] [error] [client 192.168.**.**] unable to init Zlib: deflateInit2 returned -4: URL /distributor/product/my_product_list.htm
b、 [Tue Jun 30 18:54:38 2009] [notice] child pid 28699 exit signal Segmentation fault (11)
c、Memory allocation failed.
分析：經過觀察，推論出httpd進程占用物理內存狂增，導致服務器沒有剩余資源分配給它，造成memory allocation failed。
三、修改和屏蔽一些apache配置項，例如減少SendBufferSize所占空間、屏蔽CustomLog日志。都無濟於事。
問題到底出在哪？ 欲知后事如何，敬請關注該主題的下一篇blog。
上一篇Blog講到，性能測試過程中發現server shut down現象，經過追蹤，定位到是apache子進程狂吃內存。
根據經驗，判斷問題可能出在apche加載某個/某些模塊上。於是，使用“拆分問題，隔離分析”的分析方法。先隔離出apache加載的所有模塊。再采取注釋、重啟、驗證的方式，逐步縮小隔離范圍。最終定位出瓶頸點。
系apache在加載一個Taobao**_module時，每秒消耗4M內存，導致apache占用的物理內存不斷增漲，當漲至操作系統能分配給apache的最大內存時，apache子進程死掉。在老的子進程死亡和新的子進程創建的時間間隔，有請求過來，系統自然沒有響應，從loadrunner那端看，就是server shut down。
真相得以大明。接下來就是對這個模塊進行優化了。
一個 1.84/千 ，背后竟然隱含如此巨大的性能問題。如果不深究，問題很快就被忽視了，系統上線之后，不被上帝眷顧的用戶很有可能就打不開網頁了。整個瓶頸查找的過程，我想可以讓我們想到以下幾點：
1. 性能測試工程師需要具備敏銳的觀察力，再小的概率，只要出錯，必定深究；
2. 性能測試工程師需要有清晰的思路，先查什么，后查什么，要設計得很明確；
3. 除了注重jboss和java程序，apache也應當重點關注，特別是出現error的時候；
4. “拆分問題，隔離分析”的方法確實很實用；
5. 盡信書不如無書，遇到具體問題要具體分析。