Как определить, что заставляет Drupal 6 перегружать всю память и вылетать? - PullRequest
Новая
       52

Как определить, что заставляет Drupal 6 перегружать всю память и вылетать?

1 голос
/ 03 мая 2011

У нас есть сайт с Drupal 6 и довольно стандартный набор модулей, таких как Views, CCK и так далее. Рабочий сайт работает нормально, но после того, как я создал дамп SQL рабочего сервера и импортировал данные в нашу локальную песочницу, он перестал работать.

Точнее, после одного запроса к экземпляру песочницы Drupal, такого как загрузка главной страницы, 10-20 процессов httpd внезапно начинают поглощать весь процессор и память на машине. Через несколько секунд все дескрипторы 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

1 Ответ

1 голос
/ 04 мая 2011

Сначала вы должны очистить все таблицы кеша, если это еще не сделано. Затем попробуйте просмотреть веб-сайт без включенного JavaScript (это может предотвратить вызовы AJAX). Вы можете даже попытаться получить доступ через lynx (браузер), возможно.

Если создание процесса apache происходит не из javascript, а из внутренних компонентов ... это означает, что один PHP-сценарий порождает процессы apache, и это было бы очень плохо для PHP-скрипта, поэтому я надеюсь, что это не так.

Вы можете попробовать модуль профилирования на Drupal, например этот . После сбоя вы, возможно, сможете запрашивать хотя бы страницы отчета, все данные профилирования сохраняются в базе данных и могут сообщать вам интересные данные (см. Скриншоты), возможно, вы можете попробовать проверить таблицы MySQL, содержащие проанализированные данные, если вы не может получить доступ к страницам модуля.

Иначе, вы можете попробовать XDebug и экспортировать файл kcachegrind по вашему запросу, но это может быть довольно сложно для чтения с запросами Drupal.

EDIT

Попытайтесь также проверить с помощью firebug, что вы не выполняете все запросы с запрошенной страницы (возможно, из-за пустых изображений src, например, если это не javascript). И проверьте журнал apache и журнал Mysql - где вы можете активировать ведение журнала запросов.

...