Heutzutage werden Django-Anwendungen grundsätzlich mit uwsgi bereitgestellt. Ein Fehler ähnlich dem folgenden
listen queue of socket "127.0.0.1:9001" (fd: 3)
ist zweimal aufgetreten. Im Folgenden wird der Prozess zur Behebung dieser beiden Fehler beschrieben.
Fehlerszenario
Fehler Protokollabfang
<code><span>Tue</span><span>Jun</span><span>2</span><span>17</span>:<span>33</span>:<span>27</span><span>2015</span> - *** <span>uWSGI</span><span>listen</span><span>queue</span><span>of</span><span>socket</span><span>"127.0.0.1:9001"</span> (<span>fd</span>: <span>3</span>) <span>full</span><span>!</span><span>!</span><span>!</span> (<span>101</span>/<span>100</span>) *** <span>Tue</span><span>Jun</span><span>2</span><span>17</span>:<span>33</span>:<span>28</span><span>2015</span> - *** <span>uWSGI</span><span>listen</span><span>queue</span><span>of</span><span>socket</span><span>"127.0.0.1:9001"</span> (<span>fd</span>: <span>3</span>) <span>full</span><span>!</span><span>!</span><span>!</span> (<span>101</span>/<span>100</span>) ***</code>
Das erste Mal war, dass die Firewall im Computerraum von China Unicom falsch konfiguriert war, was die Serverausgabe einschränkte. Das heißt, es gab kein Problem mit dem Senden externer Pakete zum Server, aber der Server gab Pakete nach außen zurück. Es war sehr langsam und fast unbrauchbar. Zu diesem Zeitpunkt traten viele Fehler im uwsgi-Protokoll auf.
Das zweite Mal Dies geschah, nachdem die Parallelität stark anstieg und die Anzahl der aktiven Links bei etwa 6000 blieb. Dieser Fehler tritt in großer Zahl auf.
Analyse
Auf der Grundlage dieses Fehlers haben wir die relevanten Informationen überprüft. Es sollte ein Problem mit Parametern auf Systemebene vorliegen. Weitere Informationen finden Sie in der Linux-Manpage listen(2).
lzz Hinweis: Ein einfaches Verständnis ist, dass für jeden Listening-Socket die Länge des auf die Verarbeitung wartenden Sockets in der Warteschlange standardmäßig 128 beträgt Linux (zumindest in Centos6.6) Der Standardwert in meinem kompilierten uwsgi ist 100, was bedeutet, dass vor dem Anpassen der Systemparameter der höchste Wert 128 ist.
Wie können wir also die Länge der Warteschlange anpassen, um sie länger zu machen?
* Systemparameter müssen angepasst werden, damit sie wirksam sind
* Sie müssen die uwsgi-Konfiguration anpassen und dann die Anwendung neu starten
Vorgang
Systemparameter ändern
Die Konfigurationsdatei wird hier direkt geändert und ist nach dem Neustart weiterhin gültig .
Ändern Sie die Datei /etc/sysctl.conf und fügen Sie diese Parameterwerte hinzu oder ändern Sie sie.
<code><span>#对于一个经常处理新连接的高负载 web服务环境来说,默认的 128 太小了</span> net<span>.core</span><span>.somaxconn</span> = <span>262144</span> ?<span>#表示SYN<strong>队列</strong>的长度,默认为1024,加大<strong>队列</strong>长度为8192,可以容纳更多等待连接的网络连接数</span> net<span>.ipv</span>4<span>.tcp</span>_max_syn_backlog = <span>8192</span><span>#网卡设备将请求放入<strong>队列</strong>的长度</span> net<span>.core</span><span>.netdev</span>_max_backlog = <span>65536</span></code>
Nachdem die Änderung abgeschlossen ist, denken Sie daran, sysctl -p
die Parameter neu zu laden
uwsgi Passen Sie
an, ob es sich um die Konfiguration handelt, oder fügen Sie eine Option in der Befehlszeile hinzu. Fügen Sie beispielsweise die folgende Konfiguration
<code><span>listen</span>=<span>1024</span></code>
zur .ini-Datei hinzu und starten Sie dann die Anwendung und laden Sie die Konfiguration neu.
Zusammenfassung
Durch die Änderung der Konfiguration sind Fehler dieser Art fast nie aufgetreten und der Systemdurchsatz und die Parallelität wurden erheblich verbessert. Daher sind Systemeigenschaften und -optimierung sehr wichtig, um die Servicequalität insgesamt zu verbessern.
Referenz
Urheberrechtserklärung : Dieser Artikel ist ein Originalartikel von orangleliu (http://blog.csdn.net/orangleliu/). Bitte geben Sie beim Nachdruck den Artikel an.
Das Obige hat die Listen-Warteschlange der Socket-FD:3-Fehleranalyse vorgestellt, einschließlich der relevanten Aspekte. Ich hoffe, dass es für Freunde hilfreich sein wird, die sich für PHP-Tutorials interessieren.