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

Прислано: seaji

чт, 29/11/2007 - 22: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" в журнале
В этой категории будет список модулей вызывавших крон.
Крайний последний модуль и будет виноват в его зависании.

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

Комментарии


Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Применить"
Опубликовано VladSavitsky в чт, 29/11/2007 - 22:14.
VladSavitsky

Супер. В закладки.


Опубликовано seaji в чт, 29/11/2007 - 22:24.
seaji

Да, чуть не забыл.
Вы еще можете получать такое сообщение как у меня "Попытка перезапуска .... в то время как уже выполняется."
С чем это связано?
А связано это с тем, что 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 с которого разрешаете запуск крона.


Опубликовано seaji в чт, 29/11/2007 - 22:44.
seaji

Во, получил результаты, любуйтесь:


Опубликовано Gedler в пт, 30/11/2007 - 08:17.
Gedler

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


Опубликовано Valeratal в пт, 30/11/2007 - 20:51.
Valeratal

спасибо


Опубликовано VladSavitsky в вт, 13/05/2008 - 20:36.
VladSavitsky

Drupal CookBook - Готовить может каждый!Решение было сохранено на сайте DrupalCookBook.ru:
Быстрая диагностика зависания крона.
Авторы, предложившие решения, также указаны в сохранённой статье.


Опубликовано kiev1 в ср, 14/05/2008 - 03:14.
kiev1

спасибо, надо модуль написать


Опубликовано НовичОК в ср, 28/05/2008 - 19:02.
НовичОК

наверно полезно.


Опубликовано Goodboy в ср, 09/09/2009 - 11:31.
Goodboy

Спасибо, помогло!


Опубликовано kpv_dnepr@drupal.org в пн, 03/05/2010 - 15:55.
kpv_dnepr@drupal.org

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


Опубликовано IrinaStasuk@dru... в вт, 18/05/2010 - 20:38.
IrinaStasuk@drupal.org

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


Опубликовано seaji в ср, 19/05/2010 - 11:08.
seaji

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


Опубликовано IrinaStasuk@dru... в чт, 20/05/2010 - 07:05.
IrinaStasuk@drupal.org

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


Опубликовано seaji в чт, 20/05/2010 - 21:53.
seaji

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

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


Опубликовано IrinaStasuk@dru... в пт, 21/05/2010 - 07:07.
IrinaStasuk@drupal.org

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

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


Опубликовано MasterTrend в пт, 01/10/2010 - 17:36.
MasterTrend

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


Опубликовано kpv_dnepr@drupal.org в ср, 24/11/2010 - 09:13.
kpv_dnepr@drupal.org

В таблице node_cron_last вот такое значение,
s:10:"1251557656";
что это значит?


Опубликовано seaji в ср, 24/11/2010 - 10:16.
seaji

"kpv_dnepr@drupal.org" написал(а):

s:10:"1251557656";
что это значит?

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

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


Опубликовано xom940k в пн, 31/01/2011 - 21:43.
xom940k

Добрый день. Прочел всю ветку. Прежде всего хочу сказать большое спасибо: пытался читать англоязычные решения - ничего подобно развернутого не нашел! Плюнул и довбил 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 в пн, 31/01/2011 - 21:44.
xom940k

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

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

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


Опубликовано edemus в пт, 18/02/2011 - 08:19.
edemus

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


Опубликовано Loac в пт, 18/03/2011 - 18:10.
Loac

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

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


Опубликовано _nikitA_ в вс, 18/12/2011 - 16:26.
_nikitA_

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


Новое на сайте

Ссылки партнёров

Расходомер в Челябинске - спешите заказать!