如今django的應用基本都是使用uWSGI來部署,相似下面 listen queue of socket "127.0.0.1:9001" (fd: 3)
的錯誤說下此次錯誤出現的解決的過程。linux
錯誤日誌截取nginx
*** uWSGI listen queue of socket "127.0.0.1:9001" (fd: 3) full !!! (101/100) *** Tue Jun 2 17:33:28 2015 - *** uWSGI listen queue of socket "127.0.0.1:9001" (fd: 3) full !!! (101/100) ***
第一次是由於聯通機房防火牆配置錯了,限制了服務器output,也就是外部發包給服務器沒有問題,可是服務器返回包給外部的時候很是慢,幾乎不可用,這個時候uwsgi日誌中就出現了大量的錯誤django
第二次是併發量劇增以後,活動連接保持在6000左右的時候,大量出現這個錯誤。centos
以這個錯誤爲基礎,查詢了下相關資料,應該是系統級別參數的問題,具體能夠參考 linux man page listen(2).服務器
簡單的理解就是每一個監聽的socket,在沒有accept以前,等待處理的socket隊列長度,linux(至少在centos6.6中)默認是128,在我這個編譯的uwsgi中默認是100,也就是說沒有調整系統參數以前,最高也就是128。網絡
那麼怎樣才能把隊列的長度調整變長呢?
* 必須調整系統參數,使其生效
* 必須調整uwsgi配置,而後重啓應用併發
這裏直接修改配置文件了,重啓後仍然有效。socket
修改/etc/sysctl.conf文件,添加或者修改這幾個參數值大數據
# 用於設置內核沒法及時處理網絡接口收到的數據包時容許發送到隊列的最大數據包數目,默認爲128。也就是每一個監聽的socket,在沒有accept以前,等待處理的socket隊列長度 net.core.somaxconn = 20480
修改完成以後要記得 sysctl -p
從新加載參數atom
無論是配置,仍是命令行加一個選項,例如 uwsgi.ini 文件中在socket= 127.0.0.1:9001下面添加以下配置
listen=10240
以後重啓應用,從新加載配置。
1. 當sysctl -p從新加載參數時報錯「sysctl: setting key ‘net.core.somaxconn’: Invalid argument」 無效的參數,
緣由:net.core.somaxconn 的值設置的大於USHRT_MAX(Maximum value of a type unsigned short int. 無符號短整型最大值65535,也能夠用命令:getconf USHRT_MAX 查看)
修改:net.core.somaxconn的值設置的小於USHRT_MAX就能夠了,如10240
經過修改配置,這種錯誤基本沒有出現過了,系統的吞吐量和併發數都大大提升了。因此係統特性和調優對於提升整個服務質量很是重要。