Предотвратить одновременный ран одного и того же крона

[xawm]

На одном из серверов было как-то у нам замечено неимоверное колличество одновременно ранающихся кронов (400 штук), при имеющихся всего 150 сайтов. Расследование показало что виноват в этом оказался тупивший MySQL, но посетила следующая идея, которая на самом деле когда-то была замечена в StreamRotator. Так вот:
Не стоит выполнять какую-либо работу скрипту крона (cron.php или rot.php) если вторая копия его счас ранается. Реализовать это лучше всего без привязки к какой-либо и сложных систем типа Redis или MySQL, а прсото создавать tmp файлик, которому просто делать touch и сверять дату модификации его, и если прошло меньше минуты то просто делать die();

Я понимаю что виноват не Смарт в том что растёт нагрузка или медленно отвечает мускуль, но этот способ поможет просто предотвратить развитие снежного кома нагрузки и неминуемого падения сервера в перспективе.

Я это всё к чему и о чём. Вот такие раны крона могут убивать сервак на 1 2 3:

Code: Select all

2014-02-05 22:43 Process clicks (68.443552970886, 41.398777008057) 
2014-02-05 22:43 Updating Gal CTR 1 (100.31895518303, 31.875402212143) 
2014-02-05 22:43 Set Best thumb (select) (100.35532903671, 0.036373853683472) 
2014-02-05 22:43 Set Best thumb (set) (100.35839915276, 0.0030701160430908) 
2014-02-05 22:43 Updating done (100.36229515076, 0.0038959980010986) 
2014-02-05 22:43 Check shift point (103.96987199783, 3.6075768470764) 
2014-02-05 22:43 Check if we have to create Rotation - Pages (103.97061109543, 0.00073909759521484) 
2014-02-05 22:44 Processing preload ... (163.79452705383, 59.823915958405) 
2014-02-05 22:44 Preload Total: 0 (164.60411810875, 0.80959105491638) 
2014-02-05 22:44 Checking galleries (168.63985800743, 4.0357398986816) 

или вот:

Code: Select all

2014-02-07 01:13 Rotation Started (11.650386095047, 11.650386095047)
2014-02-07 01:13 Rot Cron Load?: Started at 2014-02-07 01:02:05 but not finished yet at 2014-02-07 01:13:09 (14.444875001907, 2.7944889068604)
2014-02-07 01:13 Rotation Started (29.41756606102, 29.41756606102)
2014-02-07 01:13 Rot Cron Load?: Started at 2014-02-07 01:02:05 but not finished yet at 2014-02-07 01:13:49 (43.530824184418, 14.113258123398)
2014-02-07 01:13 Process clicks (61.206432104111, 46.761557102203)
2014-02-07 01:14 Rotation Started (33.273573875427, 33.273573875427)
2014-02-07 01:14 Process clicks (57.463672161102, 13.932847976685)
2014-02-07 01:14 Old copy still running from 01:13:55 (35.061989068985, 1.7884151935577)
2014-02-07 01:16 Updating Gal CTR 1 (186.51320314407, 129.04953098297)
2014-02-07 01:16 Set Best thumb (select) (186.53045201302, 0.017248868942261)
2014-02-07 01:16 Set Best thumb (set) (187.15224814415, 0.62179613113403)
2014-02-07 01:21 Check shift point (496.81702208519, 435.61058998108)
2014-02-07 01:21 Check if we have to create Rotation - Pages (497.83533811569, 1.0183160305023)
2014-02-07 01:22 Updating done (538.6503970623, 351.49814891815)
2014-02-07 01:22 Clean rot_page_items (551.30008602142, 53.464747905731)
2014-02-07 01:22 Check shift point (539.91923117638, 1.2688341140747)
2014-02-07 01:22 Create cat0 periodical (552.6507461071, 1.3506600856781)
2014-02-07 01:22 Check if we have to create Rotation - Pages (541.26916003227, 1.349928855896)
2014-02-07 01:22 Clean rot_page_items (541.31787919998, 0.048719167709351)
2014-02-07 01:22 Create cat0 periodical (541.91770815849, 0.59982895851135)
2014-02-07 01:22 Updating Cat0 (0) (542.14934015274, 0.23163199424744)
2014-02-07 01:22 Updating Cat0 start (542.14977812767, 0.00043797492980957)
2014-02-07 01:22 Count sponsor galleries (542.15678501129, 0.0070068836212158)
2014-02-07 01:22 Set cache sponsors 0 (542.4931781292, 0.33639311790466)
2014-02-07 01:22 Updating Cat0 (0) (554.30164408684, 1.6508979797363)
2014-02-07 01:22 Updating Cat0 start (554.30361795425, 0.0019738674163818)
2014-02-07 01:22 Count sponsor galleries (554.31332015991, 0.009702205657959)
2014-02-07 01:22 Set cache sponsors 0 (554.34064102173, 0.027320861816406)
2014-02-07 01:22 Count model galleries (543.80517101288, 1.3119928836823)
2014-02-07 01:22 Set cache models 0 : 6 (543.80672812462, 0.0015571117401123)
2014-02-07 01:22 Create tag cloud (543.84141016006, 0.034682035446167)
2014-02-07 01:22 Count model galleries (555.74448013306, 1.4038391113281)
2014-02-07 01:22 Set cache models 0 : 6 (555.7495059967, 0.0050258636474609)
2014-02-07 01:22 Create tag cloud (555.7694029808, 0.019896984100342)
2014-02-07 01:22 Delete thumbs marked for deletion (545.17578721046, 1.3343770503998)
2014-02-07 01:22 Delete thumbs marked for deletion (558.97172212601, 3.2023191452026)
2014-02-07 01:22 Processing preload ... (550.01849722862, 4.842710018158)
2014-02-07 01:22 Preload Total:  (550.01883220673, 0.0003349781036377)
2014-02-07 01:22 Processing preload ... (561.77477407455, 2.8030519485474)
2014-02-07 01:22 Preload Total:  (561.7751660347, 0.00039196014404297)

[admin]

Так и есть, оно проверяет в мускле и дает 10 минут прежде чем запустить следующий.
Потом считает что по какой-то причине предыдущий процесс видимо sk прибит и потому не изменил значение в базе и запускается снова.

[xawm]

Почти хорошо, только вот не в Мускуле можно бы проверять.

[darkover]

Почти хорошо, только вот не в Мускуле можно бы проверять.

Напиши bash скрипт, или закажи, там цена вопрос 10 баксов и 20 минут времени, и запускай из него оба крона, но при запуске крона отвечающего за ротацию - сверяй, работает он или нет, а крон отвечающий за трейд - запускай всегда, с него нагрузки почти нет. На ротации это сильно не отразится, а сервак разгрузит.

У меня сейчас 70 ресов на сервере, пока досточно разноса только через sleep
мастера с большим слипом, слейвы с меньшим.

[admin]

Почти хорошо, только вот не в Мускуле можно бы проверять.

Мне кажется разницы особо нет, но можете заюзать flock например

[xawm]

Продолжу тему ибо "снежный ком" стал довольно актуален на сервере с большими базами (300к+ галлер).
Если я правильно понимаю то крон ставит отметку о своём выполнении только в конце своего запуска. То есть скрипт перед запуском проверяет:
а) Статус крона (ранаюсь, закончил)
б) а были ли успешные запуски менее чем 10 минут назад.

Если так то, из-за этого снежный ком собирается в нескольких случаях:
1. По какой-то причине мы долго не ранали крон и накопилось много работы (падение, переезд). Далее сценарий такой:
- Крон стартует и работает долго
- второй крон стартует невидит отметки о запуске и тоже стартует делать работу.
= Снежный ком.

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

Предложение:

Живой, ранающийся Крон должен делать отметки в базе о том что он живой и вновь стартующий крон должен смотреть что если:
а) статус крона ранается
б) он отмечался как живой менее 5 минут назад
= не стартавать, а прсото завершать работу.

Если не было отметок 5 минут, то окей, стартуем.

хотя можно попробовать доработать алгоритм или вообще на локах файлов сделать его. Ибо если например процесс был убит, то лок же отпустится.

PS: пишу не просто так, а потому что испытываем действительно серьёзные проблемы с мощным сервером и большими базами. порядка 40 баз по 300к+ галер.

[admin]

Примернго так и едлает
Запустили - поставить timestamp
работает
если в это время запстился еще один и видит что стоит timestamp - проверяем сколько времени прошло. Если больше 5ти минут - есть вероятность что первый запуск был прибит системой например или что-то в этом роде, в любом случае он не дошел до момента когда убирается timestamp. В этом случае скрипт продолжает работу. Если со времени timestamp прошло менее 5ти минут - выходит.

А вы flock пробовали ?

[xawm]

Похоже этот алгоритм никак не спасает от сценария описанного в пункте 1.

timestamp засетывается 1 раз за всё время рана крона? В начале сетается и в конце снимается? Если так, то я предлагаю по ходу выполнения крона этот timestamp обновлять, по мере выполнения задач крона. Сделать это как минимум как минимум для rot.php.

flock пока не пробовал, если это единственный способ то буду пробоувать.

[admin]

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

[xawm]

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