如何确定是什么导致 Drupal 6 占用所有内存并崩溃？
我们有一个运行 Drupal 6 的站点和一组非常标准的模块，例如视图、CCK 等。生产站点运行良好，但在我创建生产服务器的 SQL 转储并将数据导入到本地沙箱后，它停止工作。
更准确地说，在向沙箱的 Drupal 实例发出单个请求（例如加载首页）后，10-20 个 httpd 进程突然开始耗尽计算机上的所有 CPU 和内存。几秒钟后，所有 mysql 句柄都已用完，站点离线。这些进程将继续执行它们正在执行的操作，直到我关闭整个 Apache httpd。
由于我无法从服务器获得任何输出，因此我想不出调试的方法。数据库中是否有一些垃圾导致无限循环或类似的东西？
这是 top 输出的片段。这些都是单页加载的结果。
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 337m 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
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 337m 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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
首先，如果尚未完成，您应该清空所有缓存表。
然后尝试在未启用 javascript 的情况下访问该网站（这可能会阻止 ajax 调用）。
也许您甚至可以尝试使用 lynx（浏览器）进行访问。
如果 apache 进程创建不是来自 javascript 而是来自内部......那么这意味着一个 PHP scipt 正在生成 apache 进程，这对于 PHP 脚本来说是一种非常糟糕的行为，所以我希望不是这样。
您可以尝试 Drupal 上的分析模块，例如这个。崩溃后，您也许至少能够查询报告页面，所有分析数据都保存在数据库中，并且可以向您报告有趣的数据（参见屏幕截图），也许您可以尝试检查包含分析数据的 MySQL 表，如果您无法访问模块页面。
另外，您可以尝试 XDebug 并在查询中导出 kcachegrind 文件，但这对于 Drupal 请求来说可能很难读取。
编辑
还请尝试使用 firebug 检查您是否没有从所请求的页面发出所有请求（可能是因为图像 src 为空，例如，如果它不是 javascript）。并检查 apache 日志和 Mysql 日志——您可以在其中激活请求日志记录。
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.