1. Главная
  2. Блоги
  3. Блог seaji

Быстрая диагностика зависания крона

Главные вкладки

Аватар пользователя seaji seaji 30 ноября 2007 в 1:08

Постоянно сталкивался с зависанием крона (http://drupal.ru/node/2293#comment-60504)
Вот некоторые рецепты.

Индексация

Уменьшите количество документов для индексирования за один запуск крона на стр. настройки поиска.
Лучше запускать крон несколько раз в день.

Рассылка

Если у вас стоит simple news то он может вызывать зависание при рассылке большого количества писем.

Не хватает времени

Попробуйте изменить файл cron.php следующим образом:
<?php
// If not in 'safe mode', increase the maximum execution time:
// if (!ini_get('safe_mode')) {
set_time_limit(1800);
// }
?>
т.е. закомментить эти строки.

Кто виноват?

Что бы выяснить какой модуль виноват в зависании крона сделайте следующее:
В файле includes/module.inc в самой последней функции function module_invoke_all() поменяйте строку 404-405

<?php
foreach (module_implements($hook) as $module) {
$function = $module .'_'. $hook;
?>
на
<?php
foreach (module_implements($hook) as $module) {
if ($hook == 'cron') {
watchdog('cron_runs', $module); }
$function = $module .'_'. $hook;
?>
Таким образом у вас появится новая категория "cron_runs" в журнале
В этой категории будет список модулей вызывавших крон.
Крайний последний модуль и будет виноват в его зависании.

После диагностики обязательно верните все файлы ядра в исходное состояние т.к. хакать ядро это как вступать в беспорядочные половые отношения.

Комментарии

Аватар пользователя seaji seaji 30 ноября 2007 в 1:24

Да, чуть не забыл.
Вы еще можете получать такое сообщение как у меня "Попытка перезапуска .... в то время как уже выполняется."
С чем это связано?
А связано это с тем, что wget может запрашивать cron.php до 20 раз подряд если не получает вразумительного ответа.
http://drupal.org/node/150972

Еще бывает полезно закрыть доступ к крону "извне" таким вот образом:
В файле .htaccess пишем:

<Files "cron.php">
Order deny,allow
Allow from xxx.xxx.xxx.xxx
Deny from all
</Files>

Вместо xxx.xxx.xxx.xxx пишете IP с которого разрешаете запуск крона.

Аватар пользователя Gedler Gedler 30 ноября 2007 в 11:17

респект!
решил глянуть, что у меня с кроном происходит и оказалось, что уже 3-й день на одном из сайтов не выполняется в полном объеме...
благодаря предложеному решению выяснил, что модуль update_status ведет себя не вполне корректно.
отключил, буду разбираться.

Аватар пользователя kpv_dnepr@drupal.org kpv_dnepr@drupal.org 3 мая 2010 в 19:55

Спасибо! Нашел кто виноват, это модуль search, только что с ним теперь делать, как то сайт без поиска - грустно! Уменьшал кол-во индексируемых строк, ничего, зависает. Что скажете?

Аватар пользователя IrinaStasuk@drupal.org IrinaStasuk@dru... 19 мая 2010 в 0:38

И у меня поиск вызывает зависание. Как только его отключаю, то крон выпоняется быстро. Поставила поиск Гугла, но он мне не совсем нравится - находит кучу ненужных страниц, где нужные теряются в общей массе. Да и почему-то при включеном гугловском поиске сайт начал подтормаживать.

Аватар пользователя seaji seaji 19 мая 2010 в 15:08

Посмотрите nid последнего индексированного материала. Потом откройте эту страницу и посмотрите в исходный код текста. У меня поиск зависал если в тексте были вордовские спец-теги, когда я копировал и вставлял из ворда.

Аватар пользователя IrinaStasuk@drupal.org IrinaStasuk@dru... 20 мая 2010 в 11:05

Сейчас задам глупый вопрос. А как посмотреть, какой был последний? Я облазила всю базу и не нашла... Хотя у меня такое ощущение, что просто база стала тяжелая для этого модуля - крон не просто зависает, а "кладет" сайт.

Аватар пользователя seaji seaji 21 мая 2010 в 1:53

переменная node_cron_last в таблице variable

а вообще Вам стоит произвести поиск по всей базе данных по условию LIKE %cron%

Аватар пользователя IrinaStasuk@drupal.org IrinaStasuk@dru... 21 мая 2010 в 11:07

Спасибо большое за ответ. Переменную я нашла. Все нормально. Но "родной" поиск убрала. Он давно уже не справляется с базой. Поставила Яндекс. Его выборка мне больше понравилась, чем гугловская - находит четко нужные страницы без лишнего мусора. А вот поиск у Гугла слишком уж подробный - находит все страницы, где упоминается нужное слово (даже в перекрестных ссылках), поэтому нужные страницы как-то теряются в этом объеме данных.

Но эксперимент продолжается...

Аватар пользователя MasterTrend MasterTrend 1 октября 2010 в 21:36

Доброе время суток!
Вот читаю:
"Таким образом у вас появится новая категория "cron_runs" в журнале
В этой категории будет список модулей вызывавших крон.
Крайний последний модуль и будет виноват в его зависании."
И не могу сообразить где этот журнал находится со списком модулей вызывавших крон.
Подсажите, если не трудно. Только подробней..

Аватар пользователя seaji seaji 24 ноября 2010 в 13:16

"<a href="mailto:kpv_dnepr@drupal.org">kpv_dnepr@drupal.org</a>" wrote:
s:10:"1251557656";
что это значит?

Это серелизованная переменная
s - string строка
10 - длина строки
1251557656 - значение переменной

это штамп времени последнего запуска крона

Аватар пользователя xom940k xom940k 1 февраля 2011 в 0:43

Добрый день. Прочел всю ветку. Прежде всего хочу сказать большое спасибо: пытался читать англоязычные решения - ничего подобно развернутого не нашел! Плюнул и довбил site:drupal.ru и вот Ваша тема.
Вот мое тупое телодвижение. Делал вот так
# /usr/bin/wget -O - -q -t 1 http://sitename.com/cron-php/cron.php
Я так понял это и вызвало ошибку, т.к. команда подвисла, а я ее Ctrl+C ...
Чтобы не возникало вопросов: там добавлена строка

<?php 
chdir('path/to/publick_html'); 
?>

На одном из клиентских сайтов такое решение работает (хостинг не мой, покупной). На моем хостинге попытался использовать wget - получил привет... Хочу добавить сразу, что Ваше решение с .htaccess конечно изящнее, поэтому я его и буду использовать в дальнейшем.
делал так:

SELECT *
FROM `variable`
WHERE name LIKE '%cron%'

получил вот:

cron_semaphore  i:1296505163;
cron_last       i:1296491634;

Потер семафор, который крон не успел потереть, когда я его Ctrl+C - все заработало!
Еще раз спасибо люди и автор!

Аватар пользователя xom940k xom940k 1 февраля 2011 в 0:44

Кстати на клиентском сайте все работает потому, что там

 
php /path/to/publick_html/cron-php/cron.php

wget в связи с этим не советую использовать...

Аватар пользователя edemus edemus 18 февраля 2011 в 11:19

13 * * * * /usr/bin/lynx -source http://ВАШ_САЙТ/cron.php > >/dev/null 2>&1
это через lynx (если у вас сервер и файл действительно в папке usr/bin)

Аватар пользователя Loac Loac 18 марта 2011 в 21:10

Еще крону могут мешать ноды с PHP кодом, в котором содержатся ошибки. При индексации, модуль Search попытается выполнить все PHP инструкции, вызываемые из ноды, и, если там ошибки, подвесит cron.

Если это ваш случай, то в таблице search_dataset можно посмотреть список индексируемых нод. При переинексации, следующая после последней ноды в этой таблице и будет с ошибкой.

Аватар пользователя _nikitA_ _nikitA_ 18 декабря 2011 в 20:26

Помогло решить эту проблему понижением кол страниц индексируемых за один запуск крона в search by page & search by node.
Спасибо ТС.