今天研發同事找我配合進行系統的壓力測試，目前的測試結果是併發500無限循環，tps 300，怎麼也上不去，懷疑壓力在oracle數據庫。
測試中發現數據庫的系統壓力在cpu上，雖然是64核的系統，但是vmstat的r列已經是80多了，大部分cpu的壓力也很高（sar -P ALL）,等待事件是latch: cache buffers chains。awr上顯示平均等待40ms左右，可能問題
（1）sql問題，邏輯讀過多 --> 優化sql爲主
（2）熱點塊 --> 主要考慮打散表中數據（調整pctfree或者分區）
抓邏輯讀過多的sql，果然部分走的是全表掃描。
加索引後情況大爲好轉，ash顯示主要事件集中在insert的cpu上了，再看看數據庫的系統壓力，沒有，問題是併發測試還在300左右，現在初步判斷瓶頸應該不在數據庫上。本來與我無事了，看同事毫無思路，也跟着一起分析。
捨去併發，1個併發1個事物，響應時間在37ms（一秒鐘一個併發能響應1000/37~=27個），那併發11個就能達到300個的瓶頸了（11*27~=297個），但是前提是每個併發響應時間不衰減。
測試（jmeter）15個併發，tps --> 200不到，說明整個系統的性能下降了不少了。
因爲我們測試是通過nginx的，查看nginx日誌，大量響應碼499，好吧，添加proxy_ignore_client_abort on參數，百度說是連續post，nginx拒絕。
修改後測試，
，老樣子。但是ngixn的日誌中的響應時間顯示測試開始響應在10ms左右，但是隨着壓力增大，響應時間慢慢增大，最後到了4s左右。
客戶端問題？？本來是一臺linux跑的jmeter，現在加一個分佈式節點，如果真是jmeter問題，兩臺一起跑應該會好很多，結果是一臺tps --> 170,另外一臺 --> 130,排除這個問題。
網絡瓶頸或者容器設置問題？？不太會，網絡延時並不大，而且如果是這兩樣的話不應該前後的響應時間差別太大（測試時間10分鐘），猜測是某個java容器隨着壓力慢慢到了資源極限，可能是cpu，也可能是mem，磁盤不太會畢竟容器跟磁盤交互還是比較少的。另提一點，壓力測試中，小包爲主考慮網絡間的發送接受能力（類似於磁盤的iops，需要考慮長連接問題，網絡延時問題，可以簡單的用ab [-k] -n -c 測試），如果以大包爲主考慮帶寬問題，當然部分機器還有網卡問題，記得DELL R720的網卡，redhat 5.4系統，流量一大網卡就會出問題，還要打補丁，唉，壓力測試前網絡和硬件測試還是很必要的。
top命令監控所有java容器的主機，之前研發說系統壓力沒問題的，結果發現一個java進程cpu 330%，還有幾個java是100%左右，這也叫系統壓力沒問題啊，我擦，問題的容器再加一個節點（nginx配置轉發），tps --> 600,問題發現了，還是容器的問題，優化代碼或者堆機器加節點吧。
最後併發輕鬆到了1000，鬆了口氣，再解決不了就打算tcpdump抓包分析了（這種方法很容易能發現事務各個節點的處理能力問題，當然如果研發能把測試腳本分開測試更直觀，-個事務分割成n個，分別測試），同事很高興的立即去跟領導回報說自己已經解決了系統壓力問題，我也是醉了，跟我又沒關係了，關機回家吧。
案例很簡單，測力能力有限，只是記錄一下自己的思路，希望對別人有幫助，能夠及時發現問題。
建議：
（1）非專業人員測試的話（比如研發），最好能找來系統和數據庫工程師一起看看，集思廣益麼
（2）一開始就應該從系統壓力入手，監控單個進程 top -p xxx 更有效（既能看到整體壓力，又能看到單個進程的佔用資源），io的話 iostat -xk xx xx基本就夠了，當然習慣用nmon或者htop看個人了
（3）如果是網絡或者容器配置問題，測試中各個階段性能變化應該不大