Überprüfen des Betriebsstatus
Führen Sie php start.php status aus, um den Betriebsstatus von Workerman anzuzeigen, ähnlich wie folgt:
----------------------------------------------GLOBAL STATUS----------------------------------------------------
Workerman version:3.5.13 PHP version:5.5.9-1ubuntu4.24
start time:2018-02-03 11:48:20 run 112 days 2 hours
load average: 0, 0, 0 event-loop:\Workerman\Events\Event
4 workers 11 processes
worker_name exit_status exit_count
ChatBusinessWorker 0 0
ChatGateway 0 0
Register 0 0
WebServer 0 0
----------------------------------------------PROCESS STATUS---------------------------------------------------
pid memory listening worker_name connections send_fail timers total_request qps status
18306 2.25M none ChatBusinessWorker 5 0 0 11 0 [idle]
18307 2.25M none ChatBusinessWorker 5 0 0 8 0 [idle]
18308 2.25M none ChatBusinessWorker 5 0 0 3 0 [idle]
18309 2.25M none ChatBusinessWorker 5 0 0 14 0 [idle]
18310 2M websocket://0.0.0.0:7272 ChatGateway 8 0 1 31 0 [idle]
18311 2M websocket://0.0.0.0:7272 ChatGateway 7 0 1 26 0 [idle]
18312 2M websocket://0.0.0.0:7272 ChatGateway 6 0 1 21 0 [idle]
18313 1.75M websocket://0.0.0.0:7272 ChatGateway 5 0 1 16 0 [idle]
18314 1.75M text://0.0.0.0:1236 Register 8 0 0 8 0 [idle]
18315 1.5M http://0.0.0.0:55151 WebServer 0 0 0 0 0 [idle]
18316 1.5M http://0.0.0.0:55151 WebServer 0 0 0 0 0 [idle]
----------------------------------------------PROCESS STATUS---------------------------------------------------
Summary 18M - - 54 0 4 138 0 [Summary]Erklärung
GLOBAL STATUS
Aus dieser Leiste können wir sehen:
Die Version von Workerman ist version:3.5.13
Die Startzeit ist 2018-02-03 11:48:20 und ist seitdem run 112 days 2 hours
Die Serverlast ist load average: 0, 0, 0, was die durchschnittliche Last des Systems in den letzten 1, 5 und 15 Minuten darstellt.
Die verwendete IO-Ereignisbibliothek ist event-loop:\Workerman\Events\Event
4 workers (3 Arten von Prozessen, einschließlich ChatGateway, ChatBusinessWorker, Register Prozess, WebServer Prozess)
11 processes (insgesamt 11 Prozesse)
worker_name (Name des Worker-Prozesses)
exit_status (Exit-Status-Code des Worker-Prozesses)
exit_count (Anzahl der Austritte mit diesem Statuscode)
Im Allgemeinen bedeutet ein exit_status von 0 einen normalen Austritt. Wenn es einen anderen Wert hat, bedeutet dies, dass der Prozess abnormal beendet wurde, was eine ähnliche Fehlermeldung wie WORKER EXIT UNEXPECTED erzeugt. Diese Fehlermeldung wird in der Datei aufgezeichnet, die in Worker::logFile angegeben ist.
Die häufigsten exit_status und ihre Bedeutungen sind wie folgt:
- 0: bedeutet normalen Austritt. Nach einem reibungslosen Neustart mit reload kann der Rückgabewert 0 sein, was normal ist. Beachten Sie, dass ein Aufruf von exit oder die Anweisung die auch zu einem Exit-Code 0 führt, eine Fehlermeldung wie
WORKER EXIT UNEXPECTEDerzeugt. In Workerman darf der Geschäftscode exit oder die Anweisung nicht aufrufen. - 9: bedeutet, dass der Prozess durch das SIGKILL-Signal beendet wurde. Dieser Exit-Code tritt hauptsächlich beim Stoppen oder reibungslosen Neustart auf; der Grund für diesen Exit-Code ist, dass der Unterprozess nicht innerhalb der vorgeschriebenen Zeit auf das Reload-Signal des Hauptprozesses reagiert hat (z. B. mysql, curl usw., die lange blockiert sind oder eine Endlosschleife im Geschäft), und vom Hauptprozess zwangsweise mit dem SIGKILL-Signal beendet wurde. Beachten Sie, dass auch das Senden eines SIGKILL-Signals an den Unterprozess mit dem kill-Befehl in der Linux-Konsole zu diesem Exit-Code führen kann.
- 11: bedeutet, dass php einen Coredump erzeugt hat, normalerweise verursacht durch die Verwendung von instabilen Erweiterungen; bitte kommentieren Sie die entsprechenden Erweiterungen in php.ini aus. In einigen Fällen könnte es sich auch um einen Fehler von php handeln, in diesem Fall muss php aktualisiert werden.
- 65280: Der Grund für diesen Exit-Code liegt darin, dass der Geschäftscode einen schweren Fehler hat, z. B. einen nicht existierenden Funktionsaufruf, einen Syntaxfehler usw.; spezifische Fehlermeldungen werden in der Datei Worker::logFile protokolliert, oder in der php.ini kann das error_log angegebene Dateiformat gefunden werden (wenn angegeben).
- 64000: Der Grund für diesen Exit-Code ist, dass der Geschäftscode eine Ausnahme ausgelöst hat, die jedoch nicht erfasst wurde, was zu einem Prozessabbruch führt. Wenn Workerman im Debugmodus läuft, wird der Ausnahme-Stacktrace im Terminal ausgegeben; wenn es im Daemon-Modus läuft, wird der Stacktrace in der in Worker::stdoutFile angegebenen Datei protokolliert.
PROCESS STATUS
pid: Prozesspid
memory: Der vom Prozess angeforderte Speicher in PHP. Dieser Wert zählt den Speicher von ausführbaren PHP-Dateien usw. nicht, sodass der angezeigte Wert kleiner sein muss als der tatsächliche Speicherverbrauch des Prozesses. Bitte beachten Sie memory_get_usage.
listening: Transport-Protokoll und hörende IP-Adresse / Port. Wenn kein Port abgehört wird, wird none angezeigt. Siehe Konstruktor der Worker-Klasse
worker_name: Der Name des Dienstes, den dieser Prozess ausführt, siehe name-Eigenschaft der Worker-Klasse
connections: Die Anzahl der aktuellen TCP-Verbindungseinträge, die dieser Prozess hat. Verbindungseinträge umfassen TcpConnection und AsyncTcpConnection Instanzen. Dieser Wert ist ein Echtzeitwert und kein kumulativwert. Beachten Sie: Wenn die Verbindungseinträge close aufrufen, aber die entsprechende Zählung nicht entsprechend reduziert wird, könnte dies darauf hinweisen, dass der Geschäftscode das $connection-Objekt gespeichert hat, was dazu führt, dass dieses Verbindungseintrag nicht zerstört werden kann.
total_request: Gibt an, wie viele Anfragen dieser Prozess seit seiner Startzeit bis jetzt erhalten hat. Diese Anzahl umfasst nicht nur die von Clients gesendeten Anfragen, sondern auch interne Kommunikationsanfragen von Workerman, wie z.B. die Kommunikationsanfragen zwischen Gateway und BusinessWorker in der GatewayWorker-Architektur. Dieser Wert ist kumulativ.
send_fail: Die Anzahl der gescheiterten Datenübertragungen an den Client. Der Hauptgrund für das Scheitern ist, dass die Verbindung des Clients abgebrochen wurde. Null beträgt in diesem Fall normalerweise den normalen Status, siehe Ursachen für send_fail im Status. Dieser Wert ist kumulativ.
timers: Die Anzahl der aktiven Timer, die der Prozess hat (einschließlich der nicht gelöschten Timer sowie der bereits einmal ausgeführten Timer). Beachten Sie, dass diese Funktion Workerman-Versionen >=3.4.7 benötigt. Dieser Wert ist ein Echtzeitwert und kein kumulativwert.
qps: Die Anzahl der Netzwerkanfragen, die der aktuelle Prozess pro Sekunde erhält. Beachten Sie: Mit -d wird nur der Status gemessen, andernfalls wird 0 angezeigt. Diese Funktion ist in Workerman-Versionen >=3.5.2 verfügbar. Dieser Wert ist ein Echtzeitwert und kein kumulativwert.
status: Prozessstatus. Wenn er idle ist, bedeutet dies, dass der Prozess inaktiv ist; wenn er busy ist, bedeutet dies, dass er beschäftigt ist. Beachten Sie: Wenn ein Prozess kurzfristig beschäftigt ist, ist dies normal, wenn er jedoch ständig beschäftigt ist, kann dies auf Geschäftsblockierung oder eine Endlosschleife hinweisen. In diesem Fall müssen Sie die Fehlerbehebung bei beschäftigten Prozessen überprüfen. Beachten Sie, dass diese Funktion in Workerman-Versionen >=3.5.0 benötigt wird.
Prinzip
Nach dem Ausführen des Status-Skripts sendet der Hauptprozess ein SIGUSR2-Signal an alle Worker-Prozesse, gefolgt davon, dass das Status-Skript eine kurze Schlafphase eintritt, um auf die Statusstatistiken der verschiedenen Worker-Prozesse zu warten. In diesem Moment wird der inaktive Worker-Prozess, der das SIGUSR2-Signal erhält, sofort seinen Betriebsstatus (Anzahl der Verbindungen, Anzahl der Anfragen usw.) in eine bestimmte Datei auf der Festplatte schreiben, während Prozesse, die Geschäftslogik verarbeiten, erst dann ihren Status schreiben, wenn die Verarbeitung der Geschäftslogik abgeschlossen ist. Nach einer kurzen Schlafphase beginnt das Status-Skript, die Statusdatei auf der Festplatte zu lesen und die Ergebnisse auf der Konsole anzuzeigen.
Hinweis
Beim Status kann es vorkommen, dass einige Prozesse als busy angezeigt werden. Der Grund dafür ist, dass die Prozesse mit der Verarbeitung von Geschäftslogik beschäftigt sind (z. B. ist die Geschäftslogik lange in curl oder Datenbankanfragen blockiert oder läuft in einer großen Schleife), und sie nicht in der Lage sind, ihren Status zu melden, was zu einer Anzeige von busy führt.
In einem solchen Fall muss der Geschäftscode überprüft werden, um festzustellen, wo die Geschäftslogik lange blockiert ist, und es sollte bewertet werden, ob die Blockierungszeit im erwarteten Rahmen liegt. Wenn dies nicht dem erwarteten Rahmen entspricht, sollte die Fehlerbehebung bei beschäftigten Prozessen überprüft werden.