Visualizza lo stato di esecuzione
Esegui php start.php status
per visualizzare lo stato di esecuzione di Workerman, simile al seguente:
----------------------------------------------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]Descrizione
GLOBAL STATUS
Da questa sezione possiamo vedere
La versione di Workerman version:3.5.13
L'orario di avvio 2018-02-03 11:48:20, in esecuzione per run 112 days 2 hours
Il carico del server load average: 0, 0, 0, che rappresenta il carico medio del sistema negli ultimi 1 minuto, 5 minuti e 15 minuti.
La libreria di eventi IO utilizzata, event-loop:\Workerman\Events\Event
4 workers (3 tipi di processi, inclusi i processi ChatGateway, ChatBusinessWorker, Register e WebServer)
11 processes (totale di 11 processi)
worker_name (nome del processo worker)
exit_status (codice di stato di uscita del processo worker)
exit_count (numero di uscite con quel codice di stato)
In generale, exit_status pari a 0 indica un'uscita normale, mentre valori diversi indicano che il processo è stato terminato in modo anomalo, generando un messaggio di errore simile a WORKER EXIT UNEXPECTED. Le informazioni sugli errori verranno registrate nel file specificato da Worker::logFile.
I codici di exit_status comuni e i loro significati sono i seguenti:
- 0: indica un'uscita normale. Dopo un'esecuzione di reload senza problemi, si visualizzerà un codice di uscita pari a 0, il che è normale. Nota che la chiamata a exit o die nel programma porterà a un codice di uscita pari a 0 e genererà un messaggio di errore
WORKER EXIT UNEXPECTED. In workerman, non è consentito chiamare le istruzioni exit o die nel codice aziendale. - 9: indica che il processo è stato ucciso con un segnale SIGKILL. Questo codice di uscita si verifica principalmente durante lo stop e il reload, principalmente a causa di subprocessi che non rispondono al segnale di reload del processo principale entro il tempo stabilito (ad esempio, mysql, curl, ecc. in attesa di un lungo blocco o loop infinito dell'attività aziendale), costringendo il processo principale a terminare il processo figlio con un segnale SIGKILL. Nota che l'uso del comando kill da riga di comando di Linux per inviare un segnale SIGKILL al processo figlio porterà anche a questo codice di uscita.
- 11: indica che si è verificato un coredump di php, di solito causato dall'uso di estensioni instabili. Si prega di commentare l'estensione corrispondente nel php.ini; inoltre, in rari casi, potrebbe essere un bug di php ed è necessario aggiornare php.
- 65280: questo codice di uscita è causato da errori fatali nel codice aziendale, ad esempio chiamando funzioni inesistenti o errori di sintassi; le informazioni sugli errori specifici verranno registrate nel file specificato da Worker::logFile. Puoi trovare anche nel file specificato in php.ini per error_log (se specificato).
- 64000: questo codice di uscita è causato dal lancio di un'eccezione nel codice aziendale che non viene catturata, causando l'uscita del processo. Se workerman è in esecuzione in modalità debug, lo stack di chiamate dell'eccezione verrà stampato nel terminale. Quando è in esecuzione in modalità daemon, lo stack di chiamate dell'eccezione verrà registrato nel file specificato da Worker::stdoutFile.
PROCESS STATUS
pid：pid del processo
memory：la memoria richiesta da questo processo PHP. Questo valore non tiene conto della memoria occupata da file eseguibili PHP, quindi il valore visualizzato è inferiore alla memoria effettivamente occupata dal processo; per ulteriori dettagli, vedere memory_get_usage.
listening：protocollo di trasporto e IP/porta di ascolto. Se non si ascolta alcuna porta, verrà visualizzato "none". Fare riferimento al costruttore della classe Worker
worker_name：il nome del servizio in esecuzione per questo processo, vedere l'attributo name della classe Worker.
connections：il numero corrente di istanze di connessione TCP per questo processo, dove le istanze di connessione includono sia TcpConnection sia AsyncTcpConnection. Questo valore è in tempo reale e non è un valore cumulativo. Nota: quando un'istanza di connessione chiama close e il conteggio corrispondente non diminuisce, potrebbe essere che il codice aziendale ha mantenuto l'oggetto $connection, impedendo l'eliminazione di quest'istanza di connessione.
total_request：indica il numero totale di richieste ricevute da questo processo dall'avvio fino ad ora. Questo conteggio delle richieste include non solo le richieste inviate dai client, ma anche le richieste di comunicazione interne di Workerman, come quelle tra Gateway e BusinessWorker nell'architettura GatewayWorker. Questo valore è cumulativo.
send_fail：numero di volte in cui il processo ha fallito nell'inviare dati al client; le ragioni del fallimento sono generalmente dovute alla disconnessione del client. Se questo campo non è pari a zero, si considera generalmente uno stato normale. Per ulteriori informazioni, vedere le ragioni per send_fail nello stato. Questo valore è cumulativo.
timers：numero di timer attivi in questo processo (non includendo timer eliminati o timer one-shot già eseguiti). Nota: questa funzionalità richiede workerman versione >=3.4.7. Questo valore è in tempo reale e non è un valore cumulativo.
qps：numero di richieste ricevute dalla rete per secondo dal processo corrente; nota: solo quando si aggiunge -d a status verrà conteggiato questo elemento, altrimenti mostrerà 0. Questa funzionalità richiede workerman versione >=3.5.2. Questo valore è in tempo reale e non è un valore cumulativo.
status: stato del processo; se è idle, indica inattivo, mentre se è busy indica che è occupato. Nota: se un processo entra in uno stato di breve occupazione è normale; se il processo rimane sempre in stato occupato, è possibile che ci sia un blocco dell'attività aziendale o un ciclo infinito, quindi bisogna esaminare la sezione debugging del processo busy. Nota: questa funzionalità richiede workerman versione >=3.5.0.
Principio
Dopo l'esecuzione dello script di stato, il processo principale invierà un segnale SIGUSR2 a tutti i processi worker, quindi lo script di stato entrerà in una breve fase di sonno per attendere i risultati della statistica di stato dai vari processi worker. In questo momento, i processi worker inattivi che ricevono il segnale SIGUSR2 scriveranno immediatamente il proprio stato di esecuzione (numero di connessioni, numero di richieste, ecc.) in un file su disco specifico, mentre i processi worker che stanno eseguendo la logica aziendale attenderanno che la logica aziendale venga completata prima di scrivere le proprie informazioni di stato. Dopo un breve sonno, lo script di stato inizierà a leggere i file di stato su disco e mostrerà i risultati sulla console.
Nota
Quando si esegue lo stato, potrebbe capitare che alcuni processi mostrino busy, poiché i processi sono occupati a gestire attività aziendali (ad esempio, se la logica aziendale è bloccata per lungo tempo su richieste curl o di database, o durante l'esecuzione di grandi cicli), non possono riportare lo stato, risultando quindi busy.
Se si verifica questo problema, è necessario esaminare il codice aziendale per vedere dove si verifica il lungo blocco e valutare se il tempo di blocco è entro le aspettative; Se non è conforme alle aspettative, è necessario esaminare il codice aziendale secondo la sezione debugging del processo busy.