一.如何增大service進程的max open files
ulimit -n 只能改小max open files，不能改大。需要按照以下步驟：
- 修改/etc/security/limits.conf文件，將"soft nofile 655360"和"hard nofile 655360"這兩行的655360改成期望的值
- 退出，重新ssh該機器（否則無效）
- 修改對service的啟動腳本，增加"ulimit -n 950000",其中950000是期望改變的值
- 重啟service進程（否則無效），通過"cat /proc/pid/limits"查看是否生效，其中pid是service的進程id
- 可以通過"cat /proc/sys/fs/file-max"查看系統允許的最大的max open files
二.如何修改系統的tcp端口限制
- 通過"cat /proc/sys/net/ipv4/ip_local_port_range"可以查看系統設置的可用端口
- 在/etc/sysctl.conf中增加"net.ipv4.ip_local_port_range = 1024 65000"這一行，執行"sysctl -p"，若不報錯則成功
- 再次通過"cat /proc/sys/net/ipv4/ip_local_port_range"可以查看系統設置的可用端口是否生效
三.測試方法
- 加強對測試系統的了解。例如：由於對系統的某些限制不了解造成測試方法錯誤，結果不可取。（同一級目錄下不允許創建百萬個文件）
- 復現問題，盡量模擬用戶的用法。例如：協程or物理線程。
- 打破常規假設：理論判斷不會走到的分支，則沒有測試，鏈接數異常，則可能是走到了理論判斷不會走到分支；
- Little's law法則：pthread_create並不是創建的線程越多越好，看測試重點，針對此問題，開幾個線程，每個線程多干活即可達到期望的高鏈接數；
N = X * E[T] ，N就是你的壓力器線程數，X是IOPS ，E[T]是平均處理時間
壓不上去兩個原因 1) N太小 2) E[T]太大 - 測試觀察項。期望壓力持續一個狀態，而非瞬間狀態，保證鏈接不復用且不釋放或釋放后立即重連。
- 測試性能結果，需要符合用戶的用法。例如：QPS、Latency等，不要提供給用戶一個用戶不需要的性能報告。
- 善用工具。例如：能復用盡量復用，減少重復的無用功。多積累學習一些工具，較少工作量。
用戶：我想要一輛跑得很快的馬車。
重點是“快”，而不是“馬車”。
參考：
Linux下高並發socket最大連接數