[Проблема] Не до конца отрабатывают крон задачи

08-22-2009, 01:41 PM

В общем сабж.
Есть некоторые крон задачи, которые отрабатывают не до конца, ни ошибок, ни предупреждений в логах нет.
Например, повышения пользователей. Каждый час отрабатывают повышения (судя по логам крона в админке) для 2 или 3 пользователей. но если запустить сразу после этого крон задачу из админки, то найдется еще 2 или 3 пользователя для которых повышение не отработало. Как следствие за день набирается около 20 пользователей для которых не отработало повышение.
Заметил что такие проблемы возникают для любых тяжелых крон задач (по cpu и по времени), но из админки ведь отрабатывает нормально, а по обычному крону нет...
В шаблонах крон везде есть (если бы не было - то не работал бы вообще).

Судя по форуму на vbulletin.org подобная проблема встречается на версиях 3.6, 3.7 и 3.8 (может и на более ранних, но на 3.6 - 3.8 точно), но вразумительного ответа так никто и не дал.

Может кто встречался с такой проблемой? Потому что похоже такая проблема была и здесь одно время - один знакомый сказал что его переносило по повышению с полмесяца в новую группу (может и не из-за крона, но все-таки очень похожий симптом).

Оффтоп

08-22-2009, 02:08 PM

Согласен vb 3.8.2 RSS импорт по крону не работает. Приходится в ручную запускать

08-23-2009, 10:19 PM

Да... Видать мало крупных форумов (на небольших такая проблема не проявляется)
Придется переписывать крон, сравнивать с тем как задачи из админки запускаются...

08-24-2009, 12:53 AM

Переписывайте. Но этой проблемы на крупных форумах нет.

08-25-2009, 02:56 PM

Quote:

Originally Posted by netwind

Переписывайте. Но этой проблемы на крупных форумах нет.

Видать не так выразился... Это плавающая проблема - и на небольшом форуме ее 100% не будет. На крупных появляется и то редко, просто на офф.форуме vbulletin у тех у кого она появляется, никто не описал конфиг сервера, поэтому нельзя выявить хоть какую либо зависимость.

Yoskaldyr добавил 25.08.2009 в 15:32
Как я и предполагал ошибка в коде (иногда просто удивляюсь как разрабы желсофта гонят)

Типичная логическая ошибка разработки программы и как оказалось не в самом кроне а файле повышений пользователей promotion.php. Этот код будет правильно работать только если крон булки прикрепить к системному крону и то будет очень небольшая вероятность что не отработают некоторые пользователи.

PHP Code:


			
$promotions = $vbulletin->db->query_read("
    SELECT user.joindate, user.userid, user.membergroupids, user.posts, user.reputation,
        user.usergroupid, user.displaygroupid, user.customtitle, user.username, user.ipoints,
        userpromotion.joinusergroupid, userpromotion.reputation AS jumpreputation, userpromotion.posts AS jumpposts,
        userpromotion.date AS jumpdate, userpromotion.type, userpromotion.strategy,
        usergroup.title, usergroup.usertitle AS ug_usertitle,
        usertextfield.rank
    FROM " . TABLE_PREFIX . "user AS user
    INNER JOIN " . TABLE_PREFIX . "userpromotion AS userpromotion ON (user.usergroupid = userpromotion.usergroupid)
    LEFT JOIN " . TABLE_PREFIX . "usergroup AS usergroup ON (userpromotion.joinusergroupid = usergroup.usergroupid)
    LEFT JOIN " . TABLE_PREFIX . "usertextfield AS usertextfield ON (usertextfield.userid = user.userid)
    " . iif(VB_AREA != 'AdminCP', "WHERE user.lastactivity >= " . (TIMENOW - ($nextrun - TIMENOW)))
);

просто поражает конструкция

PHP Code:


			
user.lastactivity >= " . (TIMENOW - ($nextrun - TIMENOW)))

Конечно понятно, что не удобно из логов крона брать точное время предыдущей успешной отработки данной задачи, но так точно рассчитывать и без минимальной погрешности... А если еще время задач будет изменено на не равные интервалы времени (а не как по умолчанию раз в час), то тогда вообще может у больше половины пользователей не отработают повышения.
более детально в данный момент смотреть код и базу не хочу, решение ниже, сделанное на коленке - просто добавление небольшого запаса по точности, последние строчки будут выглядеть так:

PHP Code:


			
    " . iif(VB_AREA != 'AdminCP', "WHERE user.lastactivity >= " . (TIMENOW - intval(1.1*($nextrun - TIMENOW))))
);

Значение 1.1 можно увеличить при низкой посещаемости форума до 1.5
P.S. Понятно что это немного утяжелит задание, но зато все повышения пройдут и не надо вручную запускать в админке

Yoskaldyr добавил 25.08.2009 в 15:38
Раз есть ошибка в повышениях пользователей, то и в других крон задачах могут быть подобные косяки

-------------
И еще:
строку

PHP Code:


			
 "WHERE user.lastactivity >= " . (TIMENOW - intval(1.1*($nextrun - TIMENOW))))

не стоит понимать буквально, смысл выражения TIMENOW - intval(1.1*($nextrun - TIMENOW))) в том чтобы гарантированно захватить период прошлого успешного запуска данной задачи и это должен решать сам админ исходя из посещаемости форума и частоты отработки крона (например, крон не всегда может отработать из-за неправильной обработки заголовков No-Cache браузером или проксей), также крон не отработает при каких либо ajax функциях (но отработает lastactivity для пользователя) - так как нет обновления страницы и как результат нет обращения к cron.php. Более точно частоту обращений к cron.php нужно смотреть по логам вебсервера. Т.е. условие в некоторых частных случаях может выглядеть и так:

PHP Code:


			
 "WHERE user.lastactivity >= " . (TIMENOW - 300 - ($nextrun - TIMENOW)))

т.е. добавлен запас точности в 5 минут.

08-26-2009, 01:08 AM

Quote:

Originally Posted by Yoskaldyr

А если еще время задач будет изменено на не равные интервалы времени (а не как по умолчанию раз в час)

все ясно. в багтрекере обычно такое кончается вердиктом "work as designed" (переводиться обычно как "сам дурак").
попробуй запостить ради интереса.

08-26-2009, 01:33 AM

Quote:

Originally Posted by netwind

все ясно. в багтрекере обычно такое кончается вердиктом "work as designed" (переводиться обычно как "сам дурак").
попробуй запостить ради интереса.

Да я и не собираюсь - нафиг мне это надо

И я понимаю что они так специально сделали (не зря стоит проверка на то что задача запускается из админки - явно как раз для того чтобы запускать повышения для таких неотработанных пользователей), но хоть где-нибудь бы написали что именно так оно должно работать. И сделали бы нормальную документацию как привязать крон булки к системному крону через cli php или вообще убрали бы из кода проверку на системный крон и cli режим...

08-26-2009, 01:47 AM

Проверка на запуск из админки нужна чтобы нельзя было просто перейти по урл задачи и запустить ее как скрипт. Никакой нормальной документации на левые трюки не будет. Зачем фирме нужен гемморой по их поддержке?

08-26-2009, 01:32 PM

Quote:

Originally Posted by netwind

Проверка на запуск из админки нужна чтобы нельзя было просто перейти по урл задачи и запустить ее как скрипт.

Я говорил об этой проверке:

PHP Code:


			
iif(VB_AREA != 'AdminCP', "WHERE user.lastactivity >= " . (TIMENOW - ($nextrun - TIMENOW)))

а проверка что бы нельзя было запустить напрямую php скрипт вот это

PHP Code:


			
error_reporting(E_ALL & ~E_NOTICE);
if (!is_object($vbulletin->db))
{
    exit;
}

и именно здесь нет никакой привязки к админке.
Дальше обсуждать тему не вижу смысла, т.к. свою проблему я решил и надеюсь если у кого возникнет похожая ситуация это хоть немного поможет.
Оффтоп

Yoskaldyr добавил 26.08.2009 в 13:48
Добавил описание проблемы и ее решения в этом посте

08-26-2009, 02:28 PM

Yoskaldyr, так и не понял. в типичном случае, если не изменять время запуска и запускать крон как и было задумано, проблема возникает?
Вообще не понимаю в чем претензия. Весь интервал разделен на равные промежутки времени. Любой пользователь попадет в тот или иной промежуток. Если пользователь на форуме не появляется - нахрен он не нужен крону и его данные обрабатываться не будут.
Что по-твоему не так? Откуда ты придумал погрешность?