开发者

How to determine what makes Drupal 6 hog all the memory and crash?

开发者 https://www.devze.com 2023-03-02 17:25 出处:网络
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 impo

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.

0

精彩评论

暂无评论...
验证码 换一张
取 消