博客原文
安利一篇我翻譯的國外大牛的神經網絡入門文章
在雲計算領域，採用容器部署web服務越來越普遍，具有部署速度快，動態伸縮簡單的特點。
最近參與了一次公司採用docker容器技術部署web服務的一次實踐，在壓測過程遇到了一個性能問題，記錄下來作爲以後開發的一個積累。
問題描述
測試環境
單臺物理機，24核，120G內存
部署場景
採用docker容器，容器內部跑web應用。
壓測過程
併發500訪問。
1.啓動一個容器，進行壓測
2.啓動四個容器，進行壓測
問題現象
單容器場景下，沒發現問題，跟物理部署單tomcat場景比，tps接近(均達到了17k)。
四個容器的場景下，發現tps只到23k，並且cpu佔用只在50%左右。
後來我們把容器數量加到6個，發現依然沒有改善，tps並沒有上升。cpu佔用率也沒有提升。
問題分析
這個場景下很顯然是有資源在cpu之前先到達了瓶頸。從而導致即使增加容器實例部署，也無法使cpu利用率上升。但通過對內存，network-io，disk-io監控，都沒有發現有瓶頸出現，並且看了tomcat的線程數，即使全達到最大，也不會超出物理機的線程數限制。而在另外一個物理機上，這個tomcat的配置，4個實例是幾乎可以將cpu打滿。
問題定位解決過程
因爲單容器時候沒發現問題，因此我們重點懷疑是物理機的配置導致的。因此在我們這個啓動容器的物理機上也部署了4個tomcat實例，壓測發現果然跟4個容器一樣，cpu無法打滿，tps上不去。
這時候開發人員給了一個提示，懷疑是有cpu的軟中斷處理不過來了。
於是在又一次的壓測過程，採用下面的命令進行監控
mpstat -P ALL 1果然發現有個別cpu一直處於忙碌當中(idel列一直爲0)
於是開發懷疑是物理的RPS沒開，後來設置RPS之後就好了。
關於RPS/RFS的一些理解
參考
http://blog.csdn.net/yy405145590/article/details/9837839
http://www.linuxidc.com/Linux/2015-07/119424.htm
- RPS全稱是 Receive Packet Steering, 這是Google工程師 Tom Herbert ([email protected] )提交的內核補丁, 在2.6.35進入Linux內核. 這個patch採用軟件模擬的方式，實現了多隊列網卡所提供的功能，分散了在多CPU系統上數據接收時的負載, 把軟中斷分到各個CPU處理，而不需要硬件支持，大大提高了網絡性能。
- RFS 全稱是 Receive Flow Steering, 這也是Tom提交的內核補丁，它是用來配合RPS補丁使用的，是RPS補丁的擴展補丁，它把接收的數據包送達應用所在的CPU上，提高cache的命中率。
- 這兩個補丁往往都是一起設置，來達到最好的優化效果, 主要是針對單隊列網卡多CPU環境(多隊列多重中斷的網卡也可以使用該補丁的功能，但多隊列多重中斷網卡有更好的選擇:SMP IRQ affinity)
簡單原理
RPS實現了數據流的hash歸類，並把軟中斷的負載均衡分到各個cpu，實現了類似多隊列網卡的功能。由於RPS只是單純的把同一流的數據包分發給同一個CPU核來處理了，但是有可能出現這樣的情況，即給該數據流分發的CPU核和執行處理該數據流的應用程序的CPU核不是同一個：數據包均衡到不同的cpu，這個時候如果應用程序所在的cpu和軟中斷處理的cpu不是同一個，此時對於cpu cache的影響會很大。那麼RFS補丁就是用來確保應用程序處理的cpu跟軟中斷處理的cpu是同一個，這樣就充分利用cpu的cache。
- 應用RPS之前: 所有數據流被分到某個CPU, 多CPU沒有被合理利用， 造成瓶頸
- 應用RPS之後: 同一流的數據包被分到同個CPU核來處理，但可能出現cpu cache遷躍
- 應用RPS+RFS之後: 同一流的數據包被分到應用所在的CPU核
必要條件
使用RPS和RFS功能，需要有大於等於2.6.35版本的Linux kernel
看完支付寶掃個紅包吧 :)
