How to determine what makes Drupal 6 hog all the memory and crash?
We have a site running Drupal 6 and a pretty standard set of modules such as Views, CCK and so on. The production site is running fine but after I created an SQL dump of the production server and imported the data to our local sandbox it stopped working.
To be more precise, after making a single request to the sandbox's Drupal instance such as loading the front page, 10-20 httpd processes suddenly start eating up all the CPU and memory on the machine. In a few seconds all the mysql handles have been used up and the site goes offline. The processes will keep doing whatever it is they're doing until I shut down the whole Apache httpd.
Since I can't get any output from the server, I can't think of a way to debug. Can there be some junk in the database that is causing infinite loops ore something similar?
Here's a snippet of the output of top
. These are all the result of one single page load.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
7690 apache 16 0 337m 52m 13m S 27.4 1.4 0:04.42 httpd
7715 apache 15 0 337m 52m 13m S 24.1 1.5 0:08.69 httpd
7777 apache 15 0 3开发者_JS百科37m 52m 13m R 20.8 1.4 0:09.94 httpd
7883 apache 16 0 337m 52m 13m S 19.5 1.5 0:12.39 httpd
7574 apache 16 0 337m 52m 13m R 17.2 1.4 0:06.30 httpd
7678 apache 15 0 337m 52m 13m S 16.2 1.4 0:02.26 httpd
7695 apache 15 0 337m 52m 13m S 15.5 1.4 0:10.29 httpd
7774 apache 15 0 337m 52m 13m S 15.5 1.4 0:04.62 httpd
748 mysql 15 0 364m 67m 5408 S 15.2 1.9 15:37.77 mysqld
7847 apache 15 0 337m 52m 13m S 14.9 1.4 0:07.10 httpd
7839 apache 16 0 337m 52m 13m S 14.2 1.4 0:02.85 httpd
7879 apache 15 0 337m 52m 13m S 13.9 1.5 0:12.65 httpd
7851 apache 16 0 337m 52m 13m R 12.5 1.4 0:06.77 httpd
7724 apache 16 0 337m 52m 13m S 12.2 1.4 0:06.62 httpd
7882 apache 16 0 337m 52m 13m S 11.6 1.5 0:09.04 httpd
8273 apache 16 0 337m 52m 13m S 9.2 1.4 0:07.30 httpd
7712 apache 15 0 337m 52m 13m R 8.9 1.4 0:08.13 httpd
7742 apache 16 0 337m 52m 13m S 8.9 1.4 0:06.74 httpd
7754 apache 15 0 337m 52m 13m S 8.6 1.4 0:04.16 httpd
7739 apache 16 0 337m 52m 13m S 8.3 1.4 0:04.51 httpd
7787 apache 15 0 337m 52m 13m S 8.3 1.4 0:07.44 httpd
7819 apache 16 0 337m 52m 13m S 7.6 1.4 0:02.03 httpd
7755 apache 16 0 337m 52m 13m S 7.3 1.4 0:05.89 httpd
7766 apache 16 0 337m 52m 13m R 7.3 1.4 0:01.12 httpd
7894 apache 16 0 337m 52m 13m S 7.3 1.4 0:09.49 httpd
7814 apache 15 0 337m 52m 13m S 5.9 1.4 0:03.88 httpd
7576 apache 15 0 337m 52m 13m S 5.6 1.4 0:03.63 httpd
7829 apache 15 0 337m 52m 13m S 5.3 1.4 0:04.17 httpd
7579 apache 15 0 337m 52m 13m S 5.0 1.4 0:04.43 httpd
7817 apache 15 0 337m 52m 13m S 4.0 1.4 0:04.60 httpd
7789 apache 15 0 337m 52m 13m S 2.0 1.4 0:04.41 httpd
7820 apache 15 0 337m 52m 13m S 1.0 1.4 0:01.57 httpd
First you should empty all cache tables if it's not done yet. Then try to consult the website without javascript enabled (this could prevent ajax calls). You could even try to access with lynx (the browser), maybe.
If the apache process creation does not come from javascript but from the internals... well that mean one PHP scipt is spawing apache processes and that would be a very bad behaviour for a PHP script, so I hope it's not that.
You could try a profiling module on Drupal, like this one. After the crash you'll maybe be able to query at least the report pages, all profiling data is saved in database and could report you interesting data (see screenshots), maybe you can try to check the MySQL tables containing the analysed data if you cannot access the module pages.
Else, you could try XDebug and exporting a kcachegrind file on your query, but this can be quite hard to read with Drupal requests.
EDIT
Try as well to check with firebug that you are not making all the request from the requested page (maybe because of empty images src for example if it's not javascript). And check apache log and Mysql log -- where you can activate request logging.
精彩评论