Viewing Running Status
Running php start.php status will display the running status of Workerman, similar to the following:
----------------------------------------------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]Explanation
GLOBAL STATUS
From this section, we can see:
The version of Workerman is version:3.5.13
The start time is 2018-02-03 11:48:20, running for run 112 days 2 hours
The server load is load average: 0, 0, 0, representing the system's average load in the last 1 minute, 5 minutes, and 15 minutes.
The I/O event library used is event-loop:\Workerman\Events\Event
There are 4 workers (3 types of processes, including ChatGateway, ChatBusinessWorker, Register processes, and WebServer processes)
There are 11 processes in total.
The fields include worker_name (worker process name)
exit_status (worker process exit status code)
exit_count (the number of exits with this status code)
Generally, an exit_status of 0 indicates normal exit. If it is any other value, it means the process exited abnormally, generating an error message similar to WORKER EXIT UNEXPECTED, and the error information will be recorded in the file specified by Worker::logFile.
Common exit_status and their meanings are as follows:
- 0: Indicates normal exit. A value of 0 can appear after a smooth restart through reload. This is normal. Note that calling exit or die in the program will also result in an exit code of 0 and produce a
WORKER EXIT UNEXPECTEDerror message. In workerman, calling exit or die statements in business code is not allowed. - 9: Indicates the process was killed by the SIGKILL signal. This exit code mainly occurs during stop and smooth restart. The reason for this exit code is that the child process did not respond to the main process's reload signal within the stipulated time (e.g., mysql, curl, etc., are blocking for a long time waiting or business logic is in a dead loop), and was forcibly killed by the main process using the SIGKILL signal. Note that sending the SIGKILL signal to the child process using the kill command in the Linux command line will also lead to this exit code.
- 11: Indicates that PHP has generated a core dump, usually caused by using unstable extensions. Please comment out the corresponding extension in php.ini; in addition, there are rare cases where it is a bug in PHP, and PHP needs to be upgraded.
- 65280: Indicates that the business code had a fatal error, such as calling a non-existent function or a syntax error, etc. The specific error information will be recorded in the file specified by Worker::logFile and can also be found in the file specified by php.ini in error_log (if specified).
- 64000: Indicates that the business code threw an exception, but the business did not catch this exception, causing the process to exit. If Workerman is running in debug mode, the exception call stack will be printed to the terminal; if running in daemon mode, the exception call stack will be recorded in the file specified by Worker::stdoutFile.
PROCESS STATUS
pid: Process PID
memory: The memory allocated by this process in PHP. This value does not account for the memory used by the PHP executable file, so the displayed value is less than the actual memory used by the process. For specifics, refer to memory_get_usage.
listening: The transport layer protocol and listening IP port. If no port is being listened to, it displays none. Refer to Worker class constructor
worker_name: The service name that this process runs, see Worker class name attribute
connections: The current number of TCP connection instances that this process has, including TcpConnection and AsyncTcpConnection instances. This value is real-time and not cumulative. Note: If the count does not decrease after a connection instance calls close, it may be because the business code is holding onto the $connection object, preventing the connection instance from being destroyed.
total_request: Indicates how many requests this process has received since startup. This request count includes not only requests from clients but also internal communication requests within Workerman, such as communication requests between Gateway and BusinessWorker in GatewayWorker architecture. This value is cumulative.
send_fail: The number of times this process failed to send data to the client, generally due to the client connection being closed. A non-zero value here usually indicates a normal state, see the reasons for send_fail in status. This value is cumulative.
timers: The number of active timers in this process (excluding deleted timers and one-time timers that have already run). Note: This feature requires Workerman version >=3.4.7. This value is real-time and not cumulative.
qps: The current number of network requests received by the process per second. Note: This option will only be counted if -d is added when running status; otherwise, it shows 0. This feature requires Workerman version >=3.5.2. This value is real-time and not cumulative.
status: The process status, where idle indicates it is idle, and busy indicates it is busy. Note: It is normal for a process to enter a short-term busy state; if a process remains in a busy state for an extended period, there may be a business blocking or business dead loop issue, and you need to troubleshoot according to the section on debugging busy processes. Note: This feature requires Workerman version >=3.5.0.
Principle
After the status script runs, the main process sends a SIGUSR2 signal to all worker processes, and then the status script enters a short sleep phase to wait for the state statistics from each worker process. At this time, idle worker processes receive the SIGUSR2 signal and immediately write their running status (connection count, request count, etc.) to a specific disk file, while worker processes that are processing business logic will wait until the business logic is completed before writing their status information. After a short sleep, the status script begins to read the status files from the disk and displays the results on the console.
Note
During status checking, it is possible to find that some processes display as busy. The reason for this is that the process is busy with business processing (such as the business logic being blocked for a long time on curl or database requests, or running a large loop) and cannot report the status, resulting in a busy display.
If this problem occurs, you need to check the business code to see where it causes long-term blocking and assess whether the blocking duration is within expectations. If it does not meet expectations, you need to diagnose the business code based on the section on debugging busy processes.