Cause Analysis and Solution steps of excessive CPU resources used by the PHP-CGI process

Cause Analysis and Solution steps of excessive CPU resources used by the PHP-CGI process

Blog type: 
• Linux Study Notes

Phpcgilinuxnginxredhat

Server Environment: RedHat Linux 5.5, nginx, phpfastcgi

 

In this environment, PHP-CGI generally runs very stably, but it has encountered that PHP-CGI occupies too many CPU resources, resulting in slow server response, the reasons why the PHP-CGI process occupies too many CPU resources are as follows:

 

1. some PHP extensions and PHP versions are compatible. Practice has proved that eaccelerater is compatible with some PHP versions. When the PHP-CGI process is started, it runs for more than 10 minutes, which is extremely slow, however, static resources are accessed quickly, and the server load is normal (indicating that nginx is not a problem, but the PHP-CGI process is a problem). The solution is from PHP. disable the eaccelerater module in ini and restart the PHP-CGI process.

 

2. There may be an endless loop in the program, resulting in extremely high server load (using the TOP command to view the load as high as 100 +), you need to find the specific problem program using the Linux proc Virtual File System

 

3. the PHP program improperly uses the session, which occurs in the open-source Weibo notebook dog program. The actual performance is that there are a small number of PHP-CGI processes (no more than 10) with a CPU usage rate of more than 98%, the server load is between 4-8. To solve this problem, you still need to use the Linux proc file system to find out the cause.

 

4. Operations in the program that are too time-consuming and impossible to complete (or program problems), such as discuz x 1.5's attachment download function: definitions in source/module/FORUM/forum_attachement.php

 

Function getremotefile ($ file ){
Global $ _ g;
@ Set_time_limit (0 );
If (! @ Readfile ($ _ g ['setting'] ['ftp '] ['attachurl']. 'Forum/'. $ file )){
$ FTP = ftpcmd ('object ');
$ Tmpfile = @ tempnam ($ _ g ['setting'] ['attachdir'], '');
If ($ FTP-> ftp_get ($ tmpfile, 'Forum/'. $ file, ftp_binary )){
@ Readfile ($ tmpfile );
@ Unlink ($ tmpfile );
} Else {
@ Unlink ($ tmpfile );
Return false;
}
}
Return true;
}

 

No preliminary check is performed on the input parameters, and the setting never times out. If you use readfile to read a large file at a time, the following problems may occur:
A. excessive time consumption for reading remote attachments via HTTP

B. How can I report errors in a timely manner when FTP cannot be connected?

C. readfile is a one-time read of files loaded into the memory and output. When the file is too large, the memory consumption is astonishing.

According to the experiment, we found that using readfile for one-time reading will significantly increase the memory consumption, but the CPU utilization will decrease a lot. If the multipart read method is used, the memory consumption decreases slightly, while the CPU usage increases significantly.

 

A better solution to the bug of discuz x 1.5 is to reset the remote attachment parameters in the background.

 

The Troubleshooting steps are as follows:

1. Obtain the PID (process ID) of the PHP-CGI process that occupies too many CPU resources. Use the TOP command, for example:

 

After that, we found that the CPU usage of two PHP-CGI processes was too high, and the PID was 10059,11570, which was generally caused by insufficient program optimization. How to locate the problematic PHP program location?

 

2. Find the files used by the Process

/Proc/the file system is stored in the memory, mainly to save the status of the system, key configurations, and so on. The/proc/directory contains many digital directories, which are process-related information, such, let's see what files are being used by process 10059?

Obviously, the/home/tmp/SESS _ * file is used, which is obviously a PHP session file. We can view the content of this session file as follows: view_time | 123333312412

 

We can already suspect that the PHP program has written a session item called view_time, so the remaining event is to check all PHP files containing view_time, then modify it (for example, use a cookie). To tell the truth, this view_time is not sensitive data and only records the last access time of the user. It is really unnecessary to use a session with a huge cost, instead, use a cookie.

 

3. Find the problematic program and modify it.

Use VI to edit the following shell program (assuming that the website program is in the/WWW directory)

 

#! /Bin/bash
Find/www/-name "*. php"> list.txt
 
F = 'cat./list.txt'
 
For N in $ F
Do
R = 'egrep 'view _ time' $ N'
If [! "$ R" = ""]; then
Echo $ n
Fi
Done

 

Run this shell program and output a file containing view_time. the problem caused by the system is in the modules/topic. Mod. Class file.