Voir l'état d'exécution
Exécuter php start.php status
vous permet de consulter l'état d'exécution de Workerman, ressemblant à ceci :
----------------------------------------------ÉTAT GLOBAL----------------------------------------------------
Version de Workerman : 3.5.13 Version de PHP : 5.5.9-1ubuntu4.24
Heure de démarrage : 2018-02-03 11:48:20 en cours d'exécution depuis 112 jours 2 heures
Charge moyenne : 0, 0, 0 boucle d'événements : \Workerman\Events\Event
4 travailleurs 11 processus
nom_du_travailleur statut_de_sortie nombre_de_sortie
ChatBusinessWorker 0 0
ChatGateway 0 0
Register 0 0
WebServer 0 0
----------------------------------------------ÉTAT DU PROCESSUS---------------------------------------------------
pid mémoire écoute nom_du_travailleur connexions envoi_échec minuteries total_des_requêtes qps statut
18306 2.25M aucun ChatBusinessWorker 5 0 0 11 0 [inactif]
18307 2.25M aucun ChatBusinessWorker 5 0 0 8 0 [inactif]
18308 2.25M aucun ChatBusinessWorker 5 0 0 3 0 [inactif]
18309 2.25M aucun ChatBusinessWorker 5 0 0 14 0 [inactif]
18310 2M websocket://0.0.0.0:7272 ChatGateway 8 0 1 31 0 [inactif]
18311 2M websocket://0.0.0.0:7272 ChatGateway 7 0 1 26 0 [inactif]
18312 2M websocket://0.0.0.0:7272 ChatGateway 6 0 1 21 0 [inactif]
18313 1.75M websocket://0.0.0.0:7272 ChatGateway 5 0 1 16 0 [inactif]
18314 1.75M text://0.0.0.0:1236 Register 8 0 0 8 0 [inactif]
18315 1.5M http://0.0.0.0:55151 WebServer 0 0 0 0 0 [inactif]
18316 1.5M http://0.0.0.0:55151 WebServer 0 0 0 0 0 [inactif]
----------------------------------------------ÉTAT DU PROCESSUS---------------------------------------------------
Résumé 18M - - 54 0 4 138 0 [Résumé]Description
ÉTAT GLOBAL
À partir de cette section, nous pouvons voir
La version de Workerman version:3.5.13
L'heure de démarrage 2018-02-03 11:48:20, fonctionne depuis run 112 days 2 hours
La charge du serveur load average: 0, 0, 0, qui représente respectivement la charge moyenne du système au cours de la dernière minute, de 5 minutes et de 15 minutes.
La bibliothèque d'événements IO utilisée, event-loop:\Workerman\Events\Event
4 workers (3 types de processus, y compris ChatGateway, ChatBusinessWorker, Register, processus WebServer)
11 processes (total de 11 processus)
worker_name (nom du processus worker)
exit_status (code d'état de sortie du processus worker)
exit_count (nombre de sorties avec ce code d'état)
En général, un exit_status de 0 indique une sortie normale ; s'il a une autre valeur, cela signifie que le processus a quitté de manière anormale, produisant un message d'erreur similaire à WORKER EXIT UNEXPECTED. Les informations d'erreur seront enregistrées dans le fichier spécifié par Worker::logFile.
Les codes d'état de sortie courants et leur signification sont les suivants :
- 0 : indique une sortie normale ; le code de sortie 0 apparaît après un rechargement en douceur, ce qui est normal. Notez que l'appel à exit ou die dans le programme entraînera également un code de sortie de 0 et produira un message d'erreur
WORKER EXIT UNEXPECTED, et l'utilisation des déclarations exit ou die dans le code d'affaires n'est pas autorisée dans Workerman. - 9 : indique que le processus a été tué par le signal SIGKILL. Ce code de sortie se produit principalement lors de l'arrêt ou du rechargement, la raison en étant que le sous-processus n'a pas répondu au signal reload du processus principal dans le délai imparti (par exemple, en raison de mysql, curl, etc., en attente bloquante prolongée ou d'une boucle d'affaires), étant donc tué par le signal SIGKILL envoyé par le processus principal. Notez qu'envoyer un signal SIGKILL au sous-processus à l'aide de la commande kill dans la ligne de commande linux provoquera également ce code de sortie.
- 11 : indique qu'un core dump s'est produit, généralement en raison d'une extension instable ; veuillez commenter l'extension correspondante dans php.ini ; dans certains cas, cela pourrait être un bug de PHP, et une mise à niveau de PHP est nécessaire.
- 65280 : ce code de sortie est causé par une erreur fatale dans le code d'affaires, par exemple, l'appel d'une fonction inexistante, une erreur de syntaxe, etc. Les informations d'erreur spécifiques seront enregistrées dans le fichier spécifié par Worker::logFile ou dans le fichier indiqué par error_log dans php.ini (si spécifié).
- 64000 : ce code de sortie est causé par une exception non capturée lancée par le code d'affaires, entraînant la sortie du processus. Si Workerman fonctionne en mode debug, la pile d'appels de l'exception sera imprimée dans le terminal ; si en mode daemon, la pile d'appels sera enregistrée dans le fichier spécifié par Worker::stdoutFile.
ÉTAT DU PROCESSUS
pid : identifiant du processus
mémoire : mémoire demandée par ce processus PHP. Cette valeur n'inclut pas la mémoire utilisée par l'exécutable PHP, donc la valeur affichée sera inférieure à la mémoire réellement utilisée par le processus, voir memory_get_usage.
écoute : protocole de couche de transport et adresse IP du port d'écoute. Si aucun port n'est à l'écoute, cela affichera "aucun". Voir Constructeur de la classe Worker.
nom_du_travailleur : nom du service que ce processus exécute, voir propriété name de la classe Worker.
connexions : le nombre de instances de connexion TCP actuelles que possède ce processus ; les instances de connexion incluent TcpConnection et AsyncTcpConnection. Cette valeur est à jour et non cumulative. Notez que lorsque l'instance de connexion appelle close, si le comptage correspondant ne diminue pas, cela pourrait être dû à ce que le code d'affaires a sauvegardé l'objet $connection, rendant l'instance de connexion impossible à détruire.
total_des_requêtes : indique le nombre total de requêtes reçues par ce processus depuis son lancement. Ce nombre inclut non seulement les requêtes envoyées par les clients, mais également les requêtes de communication internes de Workerman, par exemple les requêtes de communication entre Gateway et BusinessWorker dans l'architecture GatewayWorker. Cette valeur est cumulative.
envoi_échec : le nombre de fois que ce processus a échoué à envoyer des données au client ; la raison d'un échec est généralement que la connexion du client a été interrompue. Une valeur différente de 0 est généralement une condition normale, voir les raisons de send_fail dans status. Cette valeur est cumulative.
minuteries : le nombre de minuteries actives pour ce processus (sans compter les minuteries supprimées et les minuteries à exécution unique déjà exécutées). Notez que cette fonctionnalité nécessite Workerman version >= 3.4.7. Cette valeur est à jour et non cumulative.
qps : le nombre de requêtes réseau reçues par le processus actuel par seconde ; notez que "status" doit être exécuté avec -d pour que cette option soit comptée, sinon elle affichera 0. Cette fonctionnalité nécessite Workerman version >= 3.5.2. Cette valeur est à jour et non cumulative.
statut : état du processus ; s'il est inactif, cela signifie oqu'il est libre, et s'il est occupé, cela signifie qu'il est chargé. Notez que si le processus entre brièvement dans un état occupé, c'est normal ; si le processus reste constamment occupé, cela pourrait indiquer un blocage des affaires ou une boucle infinie d'affaires, auquel cas vous devrez vérifier la section Déboguer un processus occupé. Notez que cette fonctionnalité nécessite Workerman version >= 3.5.0.
Principe
Lorsque le script de statut est exécuté, le processus principal envoie un signal SIGUSR2 à tous les processus worker, puis le script de statut entre dans une courte phase de sommeil pour attendre les résultats de statistique d'état des processus worker. À ce moment-là, les processus worker inactifs, après avoir reçu le signal SIGUSR2, écriront immédiatement leur état d'exécution (nombre de connexions, nombre de requêtes, etc.) dans un fichier sur le disque. Pendant ce temps, les processus worker traitant la logique d'affaires attendront que cette logique soit terminée pour écrire leur état. Après une courte période de sommeil, le script de statut commence à lire le fichier d'état sur le disque et à afficher les résultats dans la console.
Remarque
Lors de l'état, vous pourriez constater que certains processus affichent "occupé", la raison étant que le processus est occupé à traiter des affaires (par exemple, la logique d'affaires bloquant longuement sur curl ou une requête de base de données, ou exécutant une grande boucle), ce qui empêche le rapport d'état, conduisant à l'affichage "occupé".
En cas de problèmes de ce type, il est nécessaire de examiner le code d'affaires pour identifier où il pourrait y avoir des blocages prolongés, et évaluer si la durée de blocage est conforme aux attentes ; si ce n'est pas le cas, les vérifications doivent être effectuées selon la section Déboguer un processus occupé.