У понеділок хтось бачить, що готові завдання не розсмоктуються, і перша пропозиція — додати обробників. Іноді це справді треба купити. Часто ж те саме очікування просто копіюється на більшу кількість процесів. Черга — це кількість роботи, яка ще не закінчилась. Сама по собі вона не означає, що споживачів замало. Перш ніж додавати обробників, відокремте те, що чекає запуску, від того, що падає, від того, що висить на замку, і від того, що ніхто не бере, бо процеси, за які ви вже платите, не запущені.
Текст для людини, яка може відкрити чергу і машину з обробниками. Це не навала на кеш після закінчення ключа, не процес, який росте, доки машина його вбиває, не аргумент ставити Node поруч із Laravel і не читання журналу повільних запитів. Усе це окремі перевірки. Якщо пропустити розклад нижче, більший пул лише зробить не ту проблему гучнішою.
1. Розкладіть затор за станами, а не за рахунком
Рахуйте чотири купи, не один графік. Готові: їх вільний обробник може взяти зараз. Відкладені: вони мають почекати до часу, який ви самі задали. Зарезервовані: обробник уже взяв і ще не закінчив або не відпустив. Збійні: вони впали і або лежать окремо, або повернуться в готові за розкладом повтору. Одна «глибина» ховає, яка купа росте. Нові обробники вичерпують готову роботу. Вони не лікують збійну купу і не наближають відкладене завдання до його часу.
Запишіть числа разом із годинником. Подивіться ще раз через тихі десять хвилин, без деплою посередині. Якщо готових багато, а зарезервованих майже нуль, роботу ніхто не бере. Якщо зарезервовані тримаються високо, а готових мало, обробники зайняті або застрягли: додавати є сенс лише коли це жива робота, а не замок. Якщо збійні ростуть, а готові виглядають спокійно, це не нестача потужності. Це завдання, яке помиляється. І назвіть чергу. Спільна черга для листів, вивантажень і вебхуків покаже одну глибину на три різні роботи. Глибину краще читати за назвою черги або завдання. Ремонт застряглого вивантаження — не ремонт вебхука, який партнер відхиляє знову і знову.
2. Знайдіть назву завдання, якій належить глибина
Відкрийте вибірку готових і згрупуйте за типом. Одне вивантаження, одна перебудова зображень або один повтор вебхука часто тримає майже всі рядки. Решта продукту при цьому спокійна. Пропозиція подвоїти весь парк — це пропозиція масштабувати одне завдання, яке ще ніхто не прочитав.
Прочитайте одне корисне навантаження цього типу: який ідентифікатор воно несе, який обліковий запис, якщо він є, і який зовнішній виклик робить. Купа однакових повторів у один зламаний адрес — не навантаження, а одна помилка, повторена багато разів. Цей тип треба припаркувати або полагодити до нових обробників. Інакше кожен новий процес пристає до того самого повтору. Окремо подивіться вік найстаршого готового завдання, не лише лічильник. Тисяча завдань за останню хвилину — це сплеск. Сотня, з яких найстаршому шість годин, — це стік, який не встигає, або обробник, який зупинився. Сплеск може вимагати повільнішого виробника. Шестигодинний хвіст вимагає живого обробника або завдання, яке взагалі закінчується.
3. Подивіться на одне зарезервоване, не на середній процесор
Візьміть завдання, яке висить у резерві довше за свій звичний час, і подивіться, на чому воно чекає. Замок в іншого обробника. HTTP без тайм-ауту. Запит, який спершу треба було прочитати в журналі повільних, а не в розмові про кількість обробників. Файл на диску, який уже повний. Більше обробників множить очікування замка. Вони також множать виклики до партнера, який і так ріже частоту.
Тайм-аут входить у цей огляд. Завдання без межі може сидіти в резерві, доки процес уб’є щось інше. Черга й далі вважає його взятим. Нові обробники стартують, а застрягле тримає слот. Поставте межу під саму роботу і вирішіть, що означає тайм-аут: повтор чи збій із текстом, який людина прочитає. Повтор без межі — це як затор сам себе наповнює. Якщо очікування — це запит, зупиніться. Нові споживачі виконуватимуть його частіше. Сусідня перевірка — як читати журнал повільних запитів до рефакторингу. Якщо всередині одного процесу росте пам’ять, це інша форма, не затор черги. Обробників замість жодного з цих читань не купують.
4. Повтор вміє підробити нестачу потужності
Корисне навантаження, яке падає щоразу і повертається в готові, виглядає як глибина. Обробник зайнятий. Лічильник не падає. Помилка — той самий рядок. Це отруйне завдання. Більше обробників перетравлюють отруту швидше і все одно її не закінчують. Обмежте спроби. Після межі лишіть запис у сховищі збоїв, яке людина може відкрити, з останньою помилкою та ідентифікатором. У готові не повертайте, доки хтось не змінить дані або обробник.
На завданнях, які все ж закінчуються, подивіться лічильник спроб. Здорове закінчується з першого разу. Те, що часто потребує трьох, уже каже, що обробник або партнер нестабільний. Масштабувати процеси до цього читання — значить платити за повтори. І підвищувати шанс подвійного ефекту, якщо обробник небезпечно запускати двічі. Другий запуск, який знову списує, шле лист або вставляє рядок, гірший за затор. Мова виконання цієї безпеки не дає. Обробник має записати результат і зупинитися, коли та сама робота приходить знову. Збої, на які ніхто не дивиться, стають другою чергою. Якщо команда бачить лише готових, сховище збоїв може рости тиждень. Один погляд на збої ставте поруч із поглядом на готових. Якщо біль саме там, наступний найм — не обробник, а ремонт або рішення викинути тип, який ви не можете завершити.
5. Порахуйте обробників, які вже мають бути
Запитайте, скільки процесів має працювати, і порахуйте, скільки працює. Менеджер процесів може обіцяти чотири і мати нуль після деплою, падіння або машини, яка їх так і не підняла. Готових стає більше, бо до черги ніхто не підключений. П’ятий рядок у документі не запускає перші чотири. Перевірте машину, яка, на вашу думку, споживає чергу. Перевірте, що це те середовище, якому черга належить, а не забутий тестовий ящик, спрямований у той самий брокер.
У черги на базі даних є друга пастка. Обробники опитують. Якщо вони живі, але сплять за довгим розкладом, глибина готових лишається, хоча «обробники підняті». Інтервал сну скорочуйте лише після того, як зрозумієте, що заглядати в завдання дешево. Частіше опитувати купу отрути — все одно не означає її закінчити. Не плутайте це з навалою на кеш і з другим середовищем виконання. Ключ, який закінчився і який перераховує кожен запит, — це навала, а не затор завдань. Процес на Node поруч із вебом — рішення про межу, воно в матеріалі про чергу поза Laravel. Жодне з них не починається з фрази «додамо обробників» до купи, яку ви ще не назвали.
6. Коли нові обробники — чесна відповідь
Додавайте споживачів, коли перевірки вище нудні. Готових стабільно багато. Зарезервовані закінчуються у свій звичайний час. Збої тихі. Найстарше готове завдання старішає, а ті обробники, що є, справді зайняті корисною роботою. Обробник безпечно запускати двічі. Партнер витримує додаткові виклики, або частоту ви вже обмежили. Тоді більший пул скорочує очікування. Запишіть кількість готових, вік найстаршого і кількість обробників до і після, щоб наступна людина бачила, що додавання було зароблене.
Якщо виробник обганяє будь-який пул, який ви готові тримати, нові обробники лише відсувають розмову. Сповільніть виробника, зберіть роботу пакетами або відмовтесь від типу завдання. Затор без межі — це рішення продукту в костюмі інфраструктури.
Коли кликати допомогу
Розкласти готові, відкладені, зарезервовані і збійні можна за одне сидіння, і одне отруйне навантаження теж можна прочитати. Допомога потрібна, коли глибина справжня, обробники живі, а ви все одно не бачите, яка назва завдання тримає очікування. І тоді, коли повтор може двічі списати гроші або надіслати лист, а ніхто не довів, що обробник зупиняється. І тоді, коли дві машини можуть споживати одну чергу, і незрозуміло, яка з них жива. Робота в тому, щоб назвати купу до того, як платити за більший пул.
Послуги закривають таке читання на вже наявному Laravel або Node: яке завдання наповнює чергу, чому воно не закінчується і чи обробник тут взагалі ліки. Обрані роботи тримають кожне вимірювання біля своєї операції. Черга, що росте сама собою, не лікується додатковим обробником, тож завдання продуктивності та масштабованості тут конкретне: яка задача наповнює чергу, чому вона спиняється і скільки обробників справді потрібно. Якщо напишете, надішліть назву черги, чотири лічильники, тип, який домінує, і чи ті споживачі, на яких ви розраховуєте, справді запущені. Корисне навантаження клієнтів у перший лист не кладіть.
