Пропозиції щодо оптимізації роботи крона

1. Ні так не можна зробити, тому якщо ваші масові операції одночасно з хвилинним кроном щось будуть робити з одним і тим же контактом - ви отримаєте втрату даних 2. Різкі перерви крона - це теж буде проблема тому що ви очевидно не розумієте працює він зараз чи просто чекає 3. все залежить від того скільки пам'яті ви виділили кронам, можна дати стільки пам'яті, що їх вистачить і на обробку 200К записів

Дякую Ігорю. Зараз запустив масовою дією зміну етапу з 5500 процесів. За кілька хвилин бачу, що вже 500 процесів змінили етап, інші ще чекають на черги. Я бачу, що процес йде. Під час запуску масової зміни 120 000 карток клієнтів за 1,5 години не змінилося жодної картки. Крон просто зупинився. Тому смію робити висновок, що інколи справа не в очікуванні, а саме в збої через велику кількість завдань. З такої ситуації слід передбачити вихід. Зробити автоперевірку та перезапуск, якщо він завис (якщо ручний перезапуск відхиляєте. Або зробити захист, який би не дозволяв перевищувати ліміт можливостей). А так я роблю стандартну операцію та отримую зависання. Схоже на баг. 3. Виділення пам'яті відбувається вами? Чи мова про спільну пам'ять сервера? Скільки виділено зараз?

До речі, запустив у 5500 процесах змінив етап. На етапі виконую відправлення повідомлення у вайбер бот. Процедура зайняла годину. Хвилинний крон весь цей час висить. Виходить, що в робочий час я розсилку зробити не можу, тому що зупиняться інші процеси. Я згоден, що як Ви особливостей системи не знаю, то мої пропозиції можуть бути невірними. Але бачу проблематику. А яке рішення Ви бачите? Зміна ресурсів? Адже клієнти можуть бути з великими завданнями?

[quote] Пташкін Сергій Клієнт писав/ла: Тому смію робити висновок, що інколи справа не в очікуванні, а саме в збої через велику кількість завдань. З такої ситуації слід передбачити вихід. Зробити автоперевірку та перезапуск, якщо він завис (якщо ручний перезапуск відхиляєте. Або зробити захист, який би не дозволяв перевищувати ліміт можливостей). [/quote] Перезапуски та перевірки робляться налаштуваннями сервера а не системи, система не може зрозуміти працює крон або вилетів по пам'яті. Регулювання пам'яті це на стороні сервера. [quote] Пташкін Сергій Клієнт писав/ла: А так я роблю стандартну операцію та отримую зависання. Схоже на баг. [/quote] я вам описав причину чому так відбувається, так як система встановлюється на різних серверах з різною потужністю то я не праві обмежити кількість даних, що відправляються в крон [quote] Пташкін Сергій Клієнт писав/ла: 3. Виділення пам'яті відбувається вами? Чи мова про спільну пам'ять сервера? Скільки виділено зараз? [/quote] Пам'яті (memory_limit) виділяється на сервері для php скриптів, налаштовує системний адміністратор, в даному випадку у вас 512 мегабайт для запуску хвилинного крона [quote] Пташкін Сергій Клієнт писав/ла: До речі, запустив у 5500 процесах змінив етап. На етапі виконую відправлення повідомлення у вайбер бот. Процедура зайняла годину. Хвилинний крон весь цей час висить. Виходить, що в робочий час я розсилку зробити не можу, тому що зупиняться інші процеси. Я згоден, що як Ви особливостей системи не знаю, то мої пропозиції можуть бути невірними. Але бачу проблематику. А яке рішення Ви бачите? Зміна ресурсів? Адже клієнти можуть бути з великими завданнями? [/quote] рішення тут просто збільшення пам'яті

[/quote] рішення тут просто збільшення пам'яті [/quote] Дякую. Змінили на 4 гігабайти. Пробуємо

Ігорю, у нас не вдалося самостійно впоратися із завданням, прошу вашої допомоги. Вчора поміняли у файлі php.ini memory_limit = 512M на memory_limit = 4096M після чого перезавантажую апач Після цього хвилинний крон виконує завдання по 2 хвилини. Сьогодні на ранок файл php.ini був порожнім. І ви сказали, що ми припустилися помилки. Сьогодні відновили файл та все запрацювало. Повторно внесли зміни та проблема повторилася. Ігоре, я не наполягаю на тому, щоб ви займалися нашим навчанням. Ми готові довірити це завдання професіоналам. Можете оцінити це завдання і ми його сплатимо. Дякую

[quote] Пташкін Сергій Клієнт писав/ла: Ігорю, у нас не вдалося самостійно впоратися із завданням, прошу вашої допомоги. Вчора поміняли у файлі php.ini memory_limit = 512M на memory_limit = 4096M після чого перезавантажую апач Після цього хвилинний крон виконує завдання по 2 хвилини. Сьогодні на ранок файл php.ini був порожнім. І ви сказали, що ми припустилися помилки. Сьогодні відновили файл та все запрацювало. Повторно внесли зміни та проблема повторилася. Ігоре, я не наполягаю на тому, щоб ви займалися нашим навчанням. Ми готові довірити це завдання професіоналам. Можете оцінити це завдання і ми його сплатимо. Дякую [/quote] 1год

Ок. На балансі 9 годин доопрацювань. Можна запускати. Якщо не складно, напишіть у чому ми припустилися помилки.

Зараз у кроні часто висить процес ShopSupplier_Processor_Avail виконується 70 секунд Раніше такого не спостерігав. Чи не зрозумію причину.

Добрий день. Ігоре, завдання не термінове, але хотілося б уточнити дедлайн, щоб розуміти, що про завдання не забули. Дякую

Прошу також допомоги з вільним місцем на диску. Дайте рекомендації будь ласка. Чи потрібно збільшувати диск, чи потрібно щось почистити?

[quote] Пташкін Сергій Клієнт писав/ла: Ок. На балансі 9 годин доопрацювань. Можна запускати. Якщо не складно, напишіть у чому ми припустилися помилки. [/quote] налаштування я прописав, 1ч списав [quote] Пташкін Сергій Клієнт писав/ла: Зараз у кроні часто висить процес ShopSupplier_Processor_Avail виконується 70 секунд Раніше такого не спостерігав. Чи не зрозумію причину. [/quote] це перерахунок наявності товарів [quote] Пташкін Сергій Клієнт писав/ла: Прошу також допомоги з вільним місцем на диску. Дайте рекомендації будь ласка. Чи потрібно збільшувати диск, чи потрібно щось почистити? [/quote] я почистив логи на диску та сміття, пам'ять звільнилася

Дякую, Ігорю. Чи могли б ви запропонувати перелік робіт, які рекомендується робити на сервері з певною періодичністю. Щоб я розумів, що раз на місяць (або два) потрібно сплатити та провести ряд сервісних робіт. Відправляю 2000 повідомлень через турбосмс. Крон висне на годину. Побажання щодо оптимізації залишаються чинними, щоб у цей час не зупинялися хвилинні події. Може, ще щось придумаєте.