Ліміт процесів (nproc) на хостингу: коли процес не запускається, а памʼять вільна

Якщо сайт раптом почав огризатися помилкою «Resource temporarily unavailable», у логах промайнуло «cannot fork», а підтримка відповіла, що ви «вперлися в ліміт процесів», – найчастіше річ у nproc. Це обмеження не на памʼять і не на швидкість процесора, а на саме число процесів і потоків, які ваш акаунт може тримати запущеними в один момент. Поки в бюджеті є місце, все йде як зазвичай. Щойно він забитий, наступний процес просто не стартує: сторінка недомальовується, cron мовчки пропускає завдання, консоль відмовляється відкривати нову сесію.

Перевірити, чи в цьому причина, можна там само, де дивляться решту лімітів. У cPanel це розділ «Resource Usage», рядок із числом процесів (його підписують nproc або «Number of Processes»). Стоять навпроти faults, тобто спрацювання ліміту, і гадати більше нема про що. Відрізнити цю історію від упору в процесор найпростіше за однією ознакою: при нестачі CPU сайт зазвичай сповільнюється, але продовжує відповідати, а при упорі в nproc процес узагалі не створюється, і замість повільної сторінки ви отримуєте обірвану або помилку.

Нижче розберемо, чому ця стеля взагалі існує, чим відрізняється від двох сусідніх лімітів (їх постійно змішують в один), що її насправді забиває і чому підняти цифру допомагає не завжди.

Що таке nproc і чому це не про потужність

nproc – це лічильник, і рахує він не мегабайти й не відсотки ядра, а штуки: скільки окремих процесів і потоків крутиться під вашим акаунтом просто зараз. Така стеля є в кожного акаунта на віртуальному хостингу, навіть якщо в тарифі про неї ні слова. Універсального числа немає: сам CloudLinux у рекомендаціях для типового shared-акаунта ставить nproc=100, для потужнішого тарифу тримає те саме значення й лише розводить верхню планку за відвідувачами, а конкретний хостер виставляє своє, нерідко вище.

Ключове тут у тому, що в цей лічильник валиться все одразу, а не тільки «сайт». PHP збирає сторінку – це процеси. Відпрацював cron, плюс процес, а то й кілька. Зайшли по SSH, ще один. Поліз бекап архівувати базу, знову. Усі вони ділять один і той самий бюджет, і коли він закінчується, операційна система відповідає на спробу створити новий процес коротким відмовленням. На рівні PHP це обірвана генерація сторінки, на рівні консолі – те саме «-bash: fork: retry: Resource temporarily unavailable».

Звідки береться ця стеля і чому вона виглядає саме так, найпростіше зрозуміти через CloudLinux – систему, яка на більшості віртуальних хостингів ріже сервер на ізольовані частки й видає кожному акаунту свою квоту з памʼяті, процесора й числа процесів. nproc – одна з цих квот, сусідня з тими, що ви, можливо, вже зустрічали. Якщо потрібна загальна карта всіх лімітів акаунта і того, як вони повʼязані, вона зібрана в окремому розборі.

Збиває з пантелику тут одиниця виміру. Памʼять міряють у мегабайтах, це звично й наочно. А nproc рахує процеси, яких звичайний власник сайту не бачить і руками не створює: вони зʼявляються і зникають самі, десятками за секунду, і «скільки їх зараз» – це питання, на яке без панелі не відповісти.

Три стінки, які всі називають «процесами»

Ось місце, заради якого й варто було заводити окрему статтю. На віртуальному хостингу є три різні обмеження, і в розмові їх усі звуть «процесами» чи «навантаженням», через що в голові вони злипаються в одне. А влаштовані вони по-різному, поводяться по-різному й лікуються по-різному.

Перше – ліміт процесора. Він про швидкість: скільки процесорного часу вам дозволено спалити. Уперлися: застосунку дістається менше процесорного часу, і він починає відповідати повільніше; найчастіше сайт при цьому не падає, а гальмує. Симптом – затримки, що ростуть разом із відвідуваністю.

Друге – Entry Processes (EP). Він рахує входи у ваше ізольоване середовище: скільки запитів одночасно «зайшло» на обробку цієї миті. Зазвичай це вебзапити – майже кожне звернення до PHP-сторінки створює один такий вхід, але живе він частки секунди й одразу звільняється. Пробили цю стелю – сервер віддає 508 «Resource Limit Reached». Симптом – частина відвідувачів ловить 508 у момент напливу, решті нормально.

Третє – nproc, йому й присвячено текст. Він рахує не входи, а взагалі всі процеси й потоки всередині акаунта: і вебобробники, і те, що вони породжують уже всередині, і cron, і SSH-сесії, і потоки. Пробили – новий процес не створюється, fork не проходить, а відвідувач може отримати 500 або 503.

Різниця між EP і nproc тонка, і саме на ній міркування найчастіше звертає не туди. EP рахує лише входи ззовні: прийшов запит – плюс один вхід, відпрацював – мінус. А все, що процес запускає вже всередині акаунта (дамп бази, надсилання листа, звернення до MySQL), нового входу не створює, EP не росте, зате число процесів у nproc збільшується. Додайте сюди потоки, яких EP не бачить зовсім. Тому nproc на хостингу завжди ставлять вище за EP: CloudLinux прямо рекомендує тримати його щонайменше на 15 більшим. Із цього й народжується фірмова скарга: «по EP в панелі тиша, вільно, а процес усе одно не створюється». Отже, ви вперлися не в EP, а в загальний бюджет nproc, і набили його не вхідні відвідувачі, а те, що крутиться всередині. Зворотний випадок прикріший: підняли EP за порадою підтримки, а «cannot fork» нікуди не подівся, бо лікували не ту стінку.

До речі, у фонових завдань на кшталт cron і бекапів є прикра звичка ламатися мовчки. Вебзапит, якому не вистачило процесу, хоча б віддасть видиму помилку в браузер. А нічне завдання, що вперлося в ту саму стелю, просто не виконається, і ви дізнаєтеся про це не в момент збою, а коли одного разу полізете за бекапом і виявите, що за останній тиждень його немає.

Потоки рахуються так само, як процеси

Розділ короткий, але пропускати його не варто: про це майже ніхто не думає.

Лічильник nproc рахує не тільки процеси, а й потоки всередині них. Один процес, який усередині себе тримає двадцять потоків, здатен зайняти з бюджету не одиницю, а близько двадцяти: рахується кожен потік, реально запущений усередині акаунта. Для звичайного PHP це рідко проблема, але щойно на сайті зʼявиться щось багатопотокове (обробка картинок через ImageMagick, headless-браузер для генерації превʼю, тяжка бібліотека імпорту), і один такий запит здатен наодинці відʼїсти помітну частку ліміту.

Виглядає це оманливо. За числом процесів у звичному розумінні у вас усе скромно, пара десятків, а лічильник nproc чомусь повний. Причина рівно в тому, що за одним видимим процесом стоїть пучок потоків, і в бюджет іде кожен. Хостер при цьому бачить сплеск числа процесів там, де за логами сайту всього один тяжкий запит, і це збиває з пантелику вже обидві сторони.

Що на живому сайті забиває цей ліміт

Список винуватців із практики доволі короткий і від сайту до сайту повторюється.

Розігнаний wp-cron. На WordPress планувальник за замовчуванням спрацьовує на візитах, а не за годинником: настав час події, і її запускає перший-ліпший відвідувач. При хорошій відвідуваності таких запусків набігає багато, і в пік вони вміють забрати помітну частину бюджету. Не кожен візит плодить окремий паралельний процес, але при щільному трафіку й тяжких завданнях накладень вистачає.

Бекап – класика жанру, CloudLinux навіть наводить його як типовий приклад, коли число процесів раптово підскакує. Знімаючи копію, такий плагін зазвичай запускає додаткові й довгі фонові завдання – архівацію файлів, дамп бази, іноді вивантаження в хмару; скільки саме процесів і як вони влаштовані, залежить від конкретного плагіна. Ще й архівація дає шквал звернень до диска, а в диска свої окремі стелі: на число операцій за секунду (IOPS) і на швидкість читання-запису (bandwidth), тож тяжкий нічний бекап нерідко впирається одразу в кілька стінок. Поки копія знімається на живому сайті під трафіком, усе це лягає поверх звичайного навантаження. Спостереження, що спливає постійно: сайт «падає» щоночі в один і той самий час, а це не атака, а власний бекап за розкладом.

Фонові завдання і зовнішні інтеграції. Скрипт, який шле сповіщення або синхронізується зі стороннім API, нерідко робить це в кілька паралельних процесів, і на масовій розсилці це добре помітно. Сюди ж обірвана SSH-консоль, яка іноді лишає по собі завислий процес; джерело не головне, зате безкоштовне до перевірки.

Що обʼєднує весь список: майже все це фон, а не відвідувачі. Тому упор у nproc так часто трапляється в найтихіший за трафіком момент, глупої ночі, і власник насамперед думає на будь-що, тільки не на власні фонові завдання.

Як це виглядає і з чим плутають

Сигнатур у проблеми небагато, і впізнавати їх в обличчя корисно. У консолі – «fork: retry: Resource temporarily unavailable» або коротке «cannot fork». У логах PHP – обриви генерації, іноді гола 500-та без виразної причини в самому коді. У панелі – faults за рядком із числом процесів.

Варто тримати в голові, що «cannot fork» указує на упор у число процесів, але сам по собі стовідсотковим діагнозом не є: та сама помилка EAGAIN виникає й при вичерпанні загальносистемних стель, на кшталт максимуму потоків на всю машину. На віртуальному хостингу під CloudLinux це найчастіше саме ваш nproc, і вирішує справу не текст помилки, а faults у панелі.

Плутають це найчастіше з двома речами. Перша – нестача памʼяті, бо ззовні схоже: сторінка обірвалася, віддається 500-та або білий екран. Але памʼять, коли закінчується, лишає в логах виразний слід «Allowed memory size exhausted», а упор у nproc – слід про fork. Якщо за лічильником памʼяті до стелі далеко, а сторінки все одно рвуться, дивитися треба на число процесів.

Друга – 508-та. Це не персональний код EP, а загальний сигнал «досягнуто ліміт ресурсів» у LVE, тому за одним лише 508 причину не назвати. Розбиратися треба за faults: спрацювання за EP означають EP, за числом процесів – nproc, за CPU – процесор, за памʼяттю – PMEM. CloudLinux веде окремий лічильник на кожен ресурс, і саме він, а не код помилки в браузері, показує, в яку стінку ви вперлися. Докладніше про самі коди – у розборі відповідей HTTP.

Навіщо провайдер тримає nproc низьким

З боку клієнта низький ліміт на число процесів виглядає дрібʼязковою жадібністю: ну що провайдеру варто дозволити на сотню процесів більше. З боку сервера картина інша, і логіка тут жорстка.

Одне з практичних призначень цього ліміту – не дати одному акаунту безконтрольно плодити процеси; сам CloudLinux так і пояснює сенс nproc: щоб процес усередині акаунта не наплодив надто багато підпроцесів. Помилка в коді, кривий плагін, сусідній акаунт під зломом – будь-хто з них здатен почати розмножувати процеси по наростаючій. Не будь стелі, один такий акаунт ризикував би потягнути за собою ресурси всієї ноди, а на ній живуть ще десятки чужих сайтів. nproc – це запобіжник, який притримує один акаунт, щоб не постраждали інші.

Зі свого боку провайдер бачить те саме, що й ви, тільки раніше й у цифрах: на моніторингу акаунт упирається в стелю процесів, капають faults. «Оптимізуйте навантаження» для нього не відписка, а буквально те, що показує панель. По суті обидві сторони дивляться на один графік, просто з різних кінців.

І, як в історії з процесором, цифру nproc часто не виносять у тариф на видне місце. Причина прагматична, рівно та сама, з якої неохоче говорять про inode: покажеш параметр, якого немає в конкурентів, і половина звернень у підтримку буде про те, як його підняти, а не про те, чому він забився. Простіше не показувати.

Що з цим робити – і чому додати число допомагає не завжди

Далі починається місце, де хочеться простої відповіді «підніміть ліміт». Іноді це й справді рішення. Але частіше упор у nproc – не про те, що бюджету мало, а про те, що його хтось безконтрольно їсть, і тоді додача просто відсуває стелю на пару тижнів.

Почати варто з faults за числом процесів за тиждень, а не з миттєвої цифри; це, мабуть, головний діагностичний крок у всій історії. Миттєве значення майже завжди невисоке, ви ж дивитеся в спокійний момент. А от регулярні піки faults в одні й ті самі години, надто нічні, показують, що саме і коли забиває бюджет. Застереження важливе: faults=0 за сьогодні не означає, що сайт здоровий: можливо, ви просто не потрапили на вікно, коли відпрацьовує тяжке завдання.

Далі за спаданням частоти випадків. Перевести wp-cron на справжній серверний розклад: це знімає головне джерело накладень, завдання йдуть за годинником, а не товпляться на візитах. Побічних майже немає, допомагає майже завжди. Розібратися з бекапом: перенести знімання копії на серверний рівень або хоча б розвести його за часом із піками, замість того щоб архівувати живий сайт під трафіком; часто одне це прибирає нічні «падіння». Прибрати зависле: закриті, але не завершені SSH-сесії й підвислі процеси іноді займають відчутну частку бюджету, їх видно в панелі, і починати зручно з них, бо це нічого не коштує.

Підняти ліміт – законний хід, якщо сайту справді потрібно більше процесів, але тільки після того, як ви переконалися, що бюджет їсть діло, а не розігнаний плагін. Інакше це плата за те, щоб не розбиратися, і наступну стелю ви пробʼєте так само. І перш ніж доплачувати, корисно зрозуміти за що: наступний щабель тарифу не завжди дає пропорційно більше, а індекс цінності тарифу (TVI) якраз про те, скільки ресурсу припадає на кожну гривню. Піти на VPS має сенс сайту, якому реально тісно в межах спільного хостингу, але наче «там лімітів немає» – це міф: і на своєму сервері є свої стелі, від системного RLIMIT_NPROC й обмежень systemd із cgroups до pm.max_children у пулі PHP-FPM. Різниця в тому, що цими стелями керуєте ви, а ресурси машини виділені вам, а не діляться із сусідом. Чим VPS на практиці відрізняється від спільного хостингу й хмари, якщо дивитися не на рядки тарифу, розібрано в окремій статті.

Вільна памʼять при рваних сторінках сама по собі – уже половина діагнозу: раз памʼять ні до чого, значить, закінчилися не байти, а місця під процеси. І доїдає їх, як правило, не наплив відвідувачів, а щось своє, фонове, що працює за розкладом.

Джерела

• CloudLinux OS, розділ «Limits» – офіційна документація з лімітів LVE (NPROC, EP, PMEM, CPU), правило «NPROC має бути більшим за EP + 15» і поведінка при вичерпанні (500/503): docs.cloudlinux.com/cloudlinuxos/limits
• CloudLinux, «EP and NPROC limits – a look from inside» – чому вхідні процеси збільшують EP, а породжені всередині LVE й потоки йдуть лише в NPROC, через що NPROC ставлять вище за EP: cloudlinux.zendesk.com – EP and NPROC limits
• man7.org, fork(2) – системний виклик fork і помилка EAGAIN «Resource temporarily unavailable», зокрема при вичерпанні ліміту на число процесів: man7.org/linux/man-pages/man2/fork.2.html
• PHP, «FPM Configuration» – як менеджер процесів php-fpm (директиви pm, pm.max_children) тримає пул воркерів, що обслуговують запити: php.net/manual/en/install.fpm.configuration.php
• cPanel, «Resource Usage» – як відкрити розділ, читати графіки використання і знаходити faults за кожним ресурсом, зокрема числом процесів: kb.hosting.com/docs/latest-visitors-bandwidth-resource-usage

FAQ по nproc

Що означає помилка «cannot fork» або «Resource temporarily unavailable»?

Це означає, що акаунт уперся в ліміт на число процесів, nproc, і система відмовилася створювати новий процес. Памʼять і місце на диску тут ні до чого: закінчився бюджет на кількість одночасно запущених процесів і потоків. Поки він повний, будь-яка спроба запустити ще один процес, чи то PHP, cron чи консоль, відбивається цим відмовленням.

Чим ліміт nproc відрізняється від ліміту CPU?

CPU обмежує швидкість: скільки процесорного часу вам дають, а nproc – кількість процесів і потоків. При упорі в CPU сайт зазвичай сповільнюється, але продовжує відповідати, запити просто стають у чергу. При упорі в nproc новий процес не створюється зовсім, і замість повільної сторінки ви отримуєте обірвану або помилку. Це дві різні стінки, і впертися можна в будь-яку окремо.

Чим nproc відрізняється від EP (Entry Processes)?

EP рахує входи у ваше ізольоване середовище – скільки запитів одночасно на ньому обробляється. Nproc рахує взагалі всі процеси й потоки всередині, зокрема ті, що вже запущений процес породжує сам (дамп бази, надсилання пошти), і потоки, яких EP не бачить. Через це nproc завжди ставлять вище за EP, і впертися в нього можна, коли по EP ще є запас: тоді по EP в панелі тиша, а процес усе одно не створюється.

Чи рахуються потоки в ліміт процесів?

Так, nproc рахує і процеси, і потоки всередині них. Один процес із двадцятьма потоками здатен зайняти з бюджету близько двадцяти одиниць, а не одну. Тому щось багатопотокове, на кшталт обробки картинок через ImageMagick чи headless-браузера, може наодинці відʼїсти помітну частку ліміту, хоча «процес» начебто один.

Чому сайт віддає помилку, хоча памʼяті вистачає?

Тому що упор у nproc і нестача памʼяті – різні речі, а ззовні схожі: і там і там сторінка рветься або віддається 500-та. Різниця в логах: нестача памʼяті лишає слід «Allowed memory size exhausted», а упор у nproc – слід про fork. Якщо за лічильником памʼяті до стелі далеко, а сторінки все одно рвуться, дивитися треба на число процесів.

Що взагалі забиває nproc на звичайному сайті?

Найчастіше це фон, а не відвідувачі: розігнаний wp-cron, бекап, завислі SSH-сесії, поштова черга і синхронізація зі сторонніми API. Усі вони ділять один бюджет із генерацією сторінок. Тому упор у nproc нерідко трапляється в найтихіший за трафіком момент, уночі.

Чи рахуються cron і SSH-сесії в ліміт процесів?

Так, і те й інше рахується в nproc. Cron, що відпрацьовує вночі без жодного відвідувача, і відкрита SSH-сесія займають процеси із загального бюджету акаунта. При цьому вхідний лічильник EP вони, як правило, не збільшують, тому й виходить, що nproc набивається тим, чого по EP не видно.

Як перевірити, чи вперся акаунт у nproc?

У cPanel це розділ «Resource Usage», рядок із числом процесів (його підписують nproc або «Number of Processes»). Дивитися треба не на миттєву цифру, а на графік за тиждень із відмітками faults: регулярні спрацювання в одні й ті самі години і є діагноз. При цьому faults=0 за сьогодні ще не означає, що сайт здоровий – можливо, ви просто не потрапили на вікно тяжкого завдання.

Що таке faults за nproc і чи небезпечні вони?

Faults – це лічильник спрацювань ліміту: скільки разів система відмовила акаунту у створенні нового процесу. Поодинокі faults не страшні, а от регулярні піки в одні й ті самі години означають, що бюджету процесів комусь стабільно не вистачає. Відсутність faults за короткий відрізок гарантією здоровʼя не є: тяжке завдання могло просто не потрапити у вікно спостереження.

Чи допоможе підняти тариф, якщо сайт упирається в nproc?

Іноді так, але частіше упор у nproc – не про те, що бюджету мало, а про те, що його хтось безконтрольно їсть. Якщо підняти ліміт, не розібравшись із причиною, ви просто відсунете стелю на пару тижнів і заплатите за те, щоб не розбиратися. Спершу варто переконатися за faults, що процеси забиває діло, а не розігнаний плагін чи бекап.

Чому числа nproc немає в описі тарифу?

З тієї самої причини, з якої неохоче показують inode і ліміт CPU: параметр вітрину не прикрашає, а питань від клієнтів додає. Варто виставити цифру на видне місце, і половина звернень у підтримку буде про те, як її підняти. Ліміт при цьому нікуди не дівається – він просто живе на рівні сервера, а не у вашій панелі.

Як швидко розвантажити nproc, не змінюючи тариф?

Найрезультативніше – перевести wp-cron із запуску на візитах на справжній серверний розклад, щоб завдання не товпилися. Далі – розвести бекап за часом із піками або перенести його на серверний рівень, а не архівувати живий сайт під трафіком. І прибрати зависле: закриті, але не завершені SSH-сесії й підвислі процеси видно в панелі, і прибрати їх нічого не коштує.