這邊的高流量,絕對不是即時在線人數幾百人這種小數字,而是多達萬以上,當網站的即時在線人數多達萬人以上,要面對的就不是單純想著把 Apache 換成 Nginx 就可以應付高流量,或是快取有沒有上好上滿的問題。

最容易被忽視但是會導致高流量死亡原因:最大開啟檔案數、Conntrack 沒有調整。

如果只是幾百人在線上可能偶爾會遇到但不常見,不過當網站線上人數夠多時就會發現一些狀況,明明機器附載還是很低 0.xx 而以,可是伺服器一直有 500 錯誤,此時看了 Nginx Log 如果看到 Too many open files
,這時候你就是遇到了第一個問題,沒有調整最大開啟檔案數。
Linux 預設下每個 user 都可以開啟 1024 個檔案,如果沒有調整,就算 Nginx 可以負荷 100 萬個連線,也會先受限於只能開啟 1024 個檔案數而導致出現錯誤。
解決方法:
Nginx: 24: Too Many Open Files Error And Solution
Nginx Connection 不夠用 的參數調整
如果主機有 iptables 或是其他會使用到 nf_conntrack 的東西時,也可能會踩到相關的雷,如果在 dmesg 或是 /var/log/messages 中看到 kernel: nf_conntrack: table full, dropping packet.
那就是踩到第二個雷,Conntrack 沒有調整。
踩到這個雷時,你的連線甚至連 Nginx 都碰不到,就先說再見了,因此可以透過把 nf_conntrack_max 值調大,與降低 timeout 時間讓他清除得快點來解決。
解決方法:
Conntrack tuning
nf_conntrack连接跟踪模块
系統調得好,再加上一些黑魔法(X,就算是萬人在線附載也能很低。

