PHP memory_limit і PMEM (виділена оперативна пам’ять)

Якщо ваш сайт впав з помилкою про нестачу пам’яті або ви просто вибираєте тариф і не розумієте, що означає «1 ГБ RAM» у таблиці специфікацій хостингу, – давайте розбиратися детально.

Можливо, для багатьох це буде відкриттям, але на хостингу є дві різні пам’яті, і їх постійно плутають.

Перша – це пам’ять на одну сторінку. Точніше, на один скрипт: щоб показати відвідувачу сторінку, сервер запускає програму на PHP, і пам’яті на неї йде якась кількість. Часто скрипт і сторінка – одне й те саме, але буває, що одна сторінка запускає одразу кілька скриптів. Є налаштування, яке каже: більше ось цього один такий скрипт зайняти не може. Називається воно memory_limit, і ви зазвичай можете міняти його самі.

Друга – це пам’ять на весь акаунт цілком. Усі сторінки, які готуються просто зараз, усі завдання за розкладом, резервне копіювання – усе це разом не може зайняти більше, ніж відведено вашому тарифу. Цю пам’ять ви купуєте разом із тарифом і самі не міняєте. У панелях і документації її часто позначають як PMEM.

Перше налаштування відповідає за одну сторінку. Друге – за все одразу. Далі вся стаття, по суті, про те, як ці дві цифри уживаються одна з одною.

Якщо потрібна готова відповідь просто зараз: для звичайного сайту на WordPress з парою десятків плагінів поставте memory_limit у 256 мегабайтів, а тариф беріть із пам’яттю акаунта від гігабайта. Зовсім простому блогу вистачить і 128 мегабайтів, але 256 зайвими не будуть майже ніколи. І ось чого точно не робіть: не піднімайте memory_limit до розміру всієї пам’яті акаунта, навіть коли дуже хочеться, – це не допомагає, а шкодить, і нижче я докладно поясню чому.

Усе інше в статті – про те, звідки беруться ці цифри і що робити, коли вони не сходяться.

Дві пам’яті, які часто плутають

Для простішого розуміння питання уявіть бак з водою. На весь ваш будинок – один бак, і це вся пам’ять вашого акаунта: скільки налито, стільки на день і є. Від бака йдуть крани, по одному на кожного члена сім’ї, і на кожному крані стоїть обмежувач – більше стільки-то літрів за раз кран не дасть. Ось цей обмежувач на крані й є memory_limit, стеля на одну сторінку.

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

З пам’яттю відбувається рівно те саме.

Коли сторінка впирається в memory_limit, її зупиняє сам PHP. У журнал помилок потрапляє зрозуміле повідомлення із зазначенням файлу й рядка, решта сайту продовжує працювати – впала одна сторінка. Коли акаунт упирається у свою пам’ять, втручається операційна система сервера: вона вбиває частину ваших процесів, щоб не постраждали сусіди. Відвідувачі бачать помилку 500 або 503, а в логах PHP – порожнеча. Тут плутаються найчастіше.

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

Що бачить хостер, коли у вас закінчується пам’ять

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

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

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

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

До речі, саме з цієї логіки росте відповідь на питання, чому підтримка так часто відповідає шаблонами. З їхнього боку видно лише факт: акаунт перевищив ліміт, процеси вбиті, лічильник збоїв виріс. Що саме ви там запустили, провайдер не знає й знати не зобов’язаний – усередину вашого сайту він не дивиться. Розбиратися доводиться вам, і половина цієї статті якраз про те, як це робити.

Провайдери з гарними значеннями PMEM та Memory Limit

Серед українських хостинг-провайдерів, представлених у нашому рейтингу хостингів, є декілька, у яких ситуація з пам’яттю на обліковий запис помітно краща за середню. Ми відібрали тарифи, де значення PMEM і memory_limit не доводиться випитувати у служби підтримки, – вони заявлені чесно і з запасом, якого вистачає реальному сайту під навантаженням, а не лише на папері. Ось ці варіанти.

Число в лівому верхньому куті картки провайдера відображає місце провайдера в рейтингу.

Чому цифра в помилці не сходиться з реальністю

Тут є несподіваний момент, через який розрахунки зазвичай і роз’їжджаються. PHP бере пам’ять оптом. Не по шматочку під кожне слово на сторінці, а одразу великими блоками, і вже з них роздає під текст, списки товарів, картинки. Лічильник memory_limit бачить тільки те, що було роздано з цих блоків – сам рушій, підключені до нього модулі й службові буфери в рахунок не йдуть.

На практиці це означає, що справжній апетит однієї сторінки приблизно втричі більший за той, що показує PHP. Тридцять мегабайтів за лічильником – це близько ста мегабайтів реально зайнятої пам’яті сервера.

Звідси неочевидний наслідок, який знадобиться далі при розрахунках. Пам’ять акаунта треба рахувати за більшою, реальною цифрою – саме її бачить хостинг, коли вирішує, вбивати ваші процеси чи ні. А memory_limit ставиться за тією, що показує PHP, – за меншою. Через це ліміт на сторінку й має скромніший вигляд за реальні витрати: memory_limit у 256 мегабайтів спокійно уживається зі сторінкою, яка насправді займає під сотню, тому що рахують вони різне. Тримайте це в голові, коли дійдемо до таблиці: рядок «сторінка займає» в ній – про реальну пам’ять, а рядок memory_limit – про лічильник PHP.

Деякі речі проходять повз лічильник узагалі. Обробка великої фотографії здатна з’їсти гігабайт, і PHP її не зупинить – зупинить хостинг, просто вбивши процес. Різниця відчутна: коли ліміт ловить сам PHP, у вас є зрозуміле повідомлення про помилку з номером рядка; коли процес убиває хостинг, сайт просто мовчки падає, і шукати причину нема чим.

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

Межа проста: поки дані лежать у базі – вони не ваші, щойно скрипт їх забрав – ваші.

Чому «поставлю пам’яті побільше» робить тільки гірше

Найчастіша реакція на помилку пам’яті зрозуміла: відкрити налаштування й викрутити ліміт на максимум. Хай бере скільки треба.

Дивіться, що відбувається далі. Наприклад, тариф із гігабайтом пам’яті, власник бачить помилку при імпорті товарів і ставить memory_limit у той самий гігабайт. Приходить пошуковий робот і відкриває шість сторінок одночасно. Кожна з шести тепер має право зайняти гігабайт. Зазвичай їм вистачає й сотні мегабайтів, але одна натрапила на важке вивантаження й почала розростатися. За кілька секунд пам’ять акаунта закінчується, система вбиває процеси, і лежить уже весь сайт, а не одна сторінка.

При ліміті в 256 мегабайтів та сама сторінка впала б наодинці. Решта відвідувачів нічого б не помітили.

memory_limit – це ще й запобіжник. Він тримає аварію в межах однієї сторінки, і що вище ви його викручуєте, то ширшою стає зона ураження. Правило про чверть від пам’яті акаунта з’явилося саме з цього міркування: при гігабайті розумна стеля – 256 мегабайтів, при двох гігабайтах – 384 або 512.

Чому цю цифру рідко пишуть у тарифі

Зверніть увагу, як зазвичай влаштовані тарифні таблиці в більшості провайдерів: місце на диску, кількість сайтів, база даних, SSL – усе на вітрині, а розмір пам’яті акаунта або найдрібнішим шрифтом, або в довідці, або ніде.

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

Скільки пам’яті потрібно саме вам

Прикинути це нескладно, і краще зробити це до покупки, а не після третього падіння. Берете, скільки займає одна сторінка вашого сайту. Множите на те, скільки сторінок готується одночасно в годину пік. Додаєте відсотків тридцять запасу і ще мегабайтів двісті на фонові завдання – резервні копії, оновлення, пошту.

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

Розсилка чи реклама дають стрибок у рази за лічені хвилини – трафік приходить не рівним струмочком, а хвилями. Пошукові роботи ходять пачками по десять-двадцять з’єднань одразу і, на відміну від людей, нічого не кешують; на клієнтських серверах бот нерідко створює більше одночасних запитів, ніж живі відвідувачі. І один перегляд сторінки магазину – це зазвичай три-п’ять звернень до сервера: сама сторінка, кошик, підказка в пошуку, лічильник аналітики.

Тому для скромного сайту закладають три-п’ять одночасних сторінок, для активного магазину – вісім-п’ятнадцять. У цифрах виходить так:

	Блог	Магазин	Великий портал
Одна сторінка займає	60 МБ	130 МБ	150 МБ
Одночасно в пік	3	8	15
Разом за формулою	~430 МБ	~1,5 ГБ	~3 ГБ
Тариф, який беремо	512 МБ	2 ГБ	4 ГБ
Розумний memory_limit	128M	256M	384M

Рядок «разом» – це якраз перемноження з формули вище: пік сторінки на число одночасних, плюс запас і фон. А беремо ми завжди наступний тариф вгору, тому що пам’яті рівно «впритул» не буває – провайдери продають її сходинками 512 МБ, 1 ГБ, 2 ГБ, і брати треба ту сходинку, яка ваш розрахунок покриває із запасом, а не впритул.

Подивіться на два останні рядки. Пам’ять акаунта росте швидко, а ліміт на сторінку – повільно. Так і задумано: пам’ять акаунта потрібна, щоб обслуговувати багато відвідувачів одразу, а не щоб одна сторінка могла забрати все.

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

Швидкий сайт потребує менше пам’яті, ніж повільний

Це, на диво, найкорисніший наслідок усієї арифметики, і в обговореннях тарифів його майже не зустрінеш.

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

Звідси випливає доволі приємна річ: прискорення сайту економить гроші на тарифі. Кешування сторінок узагалі не запускає PHP – готова сторінка віддається з файлу й майже нічого не коштує. Це єдине налаштування, яке знімає навантаження одразу з пам’яті, з процесора і з обмеження на число одночасних відвідувачів. Про те, як виміряти швидкість відповіді сервера, у нас є окремий розбір про TTFB.

Що означають різні помилки

Allowed memory size of 268435456 bytes exhausted – ліміт сторінки. У повідомленні зазначені файл і рядок, де пам’ять закінчилася, і за ними зазвичай одразу видно винуватця. Додати пам’яті тут можна, але правильніше подивитися, що саме її з’їло.

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

508 Resource Limit Is Reached – це вже не про пам’ять, хоча приймають цю сторінку за нестачу пам’яті постійно. Вісімка означає, що перевищено число одночасних звернень. Причина зазвичай у швидкості: сторінки робляться повільно, запити накопичуються, ліміт переповнюється. Купівля пам’яті тут не допоможе взагалі.

504 – сервер не дочекався відповіді. Може бути й від пам’яті: якщо процес убили, відповідати вже нема кому.

Окремий сюжет – сайт, який падає за розкладом, найчастіше вночі. Майже завжди це резервне копіювання, синхронізація з обліковою системою чи оновлення каталогу, запущені одночасно. Кожне завдання черпає з тієї самої спільної пам’яті акаунта, що й звичайні відвідувачі, – а вночі здається, ніби сайт вільний.

Щоб не гадати, скільки займає ваша сторінка, є безкоштовний спосіб. Цікавий факт – після встановлення на сайт Query Monitor багато хто виявляє, що найбільше пам’яті їсть зовсім не магазин і не каталог, а давно забутий конструктор сторінок чи галерея, яку поставили під один банер три роки тому.

Три випадки, які повторюються рік у рік

Перший – білий екран при оновленні великого плагіна. Спершу всі думають на пам’ять акаунта, тому що тариф скромний. А в лозі виявляється звичайна помилка нестачі пам’яті на розпакуванні архіву: ліміт сторінки стояв 128 мегабайтів, і його вистачило на все, крім оновлення. Допомогло разове підняття ліміту для адмінки, тариф залишився тим самим – у момент оновлення на сайті все одно майже нікого нема, і пам’ять акаунта простоює.

Другий – магазин, який лягає строго ночами, раз на тиждень. Тут діагностика буксує найдовше, тому що логи чисті: процеси вбиває система, а вона пояснювальних не пише. Розгадка зазвичай в обміні з обліковою системою, який тягне весь прайс одним шматком, та ще й збігається за часом із резервним копіюванням – два важкі завдання разом вибирають усю пам’ять акаунта. Лікується рознесенням завдань за часом і розбивкою обміну на порції. Найнеочевидніше в таких випадках – що memory_limit при цьому нерідко доводиться не піднімати, а знижувати: хай обмін падає сам, якщо знову почне розростатися, замість того щоб тягти за собою весь сайт.

Третій трапляється після переїздів. Сайт почав падати на новому хостингу, хоча тариф узяли дорожчий. Причина – старий хостинг читав налаштування з файлу .htaccess, а новий цю схему не підтримує. Файл на місці, рядок у ньому є, виглядає все правильно, але не працює нічого, і PHP тихо повернувся до стандартних 128 мегабайтів. Такі звернення до нас ішли валом років три-чотири тому, коли хостери масово переїжджали на LiteSpeed.

Де змінюється налаштування й чому воно часто не спрацьовує

Місць, де задається memory_limit, кілька, і вони перебивають одне одного. Найпростіше користуватися панеллю: у cPanel це «Select PHP Version» або «MultiPHP INI Editor», в ISPmanager – налаштування PHP у конкретного домену, у Plesk – «Налаштування PHP» у розділі сайтів. Другий робочий варіант – файл .user.ini в корені сайту з рядком memory_limit = 256M.

Не спрацьовує налаштування зазвичай з трьох причин.

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

Зміни не підхопилися. Файл .user.ini перечитується не миттєво, а раз на п’ять хвилин. Відредагували, оновили сторінку, нічого не змінилося – зачекайте.

Хостинг не дозволяє. На багатьох тарифах стеля задана жорстко, і підняти її зі своїх файлів не можна в принципі. Це не жадібність, а той самий захист сусідів по серверу.

Перевірити, яке значення працює насправді, можна так: створіть у корені сайту файл з єдиним рядком <?php phpinfo();, відкрийте його в браузері й знайдіть рядок memory_limit. Потім файл обов’язково видаліть – він показує стороннім забагато про ваш сервер.

Окремо про WordPress

У рушія свої налаштування поверх хостингових, і плутанини вони додають неабияк.

У файлі wp-config.php живуть дві константи. WP_MEMORY_LIMIT відповідає за публічну частину сайту, за замовчуванням це скромні 40 мегабайтів. WP_MAX_MEMORY_LIMIT діє в адмінці й фонових завданнях, за замовчуванням 256.

Розділення зроблено не на порожньому місці: адмінка важча за публічну сторінку у два-три рази – там перевіряються оновлення, будуються списки, працюють звіти плагінів. Тримати заради неї підвищений ліміт на всьому сайті невигідно. Якщо у вас падає імпорт чи оновлення, а сам сайт при цьому працює, піднімати треба другу константу.

Тонкість, на якій спотикаються: ці константи вміють лише піднімати ліміт у межах дозволеного хостингом. Написали в конфізі 512 мегабайтів, а хостинг дає 128 – залишиться 128, і жодного повідомлення про це ви не побачите.

Подивитися, що вийшло в підсумку, можна без плагінів: «Інструменти» → «Стан сайту» → «Інформація», розділи «Сервер» і «Константи WordPress».

Що зробити до того, як платити більше

Зазвичай двох-трьох кроків вистачає, щоб питання закрилося без зміни тарифу. Увімкніть кешування сторінок. Повторю, тому що це справді найрезультативніше: сторінка з кешу не запускає PHP і пам’яті не витрачає зовсім.

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

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

Оновіть PHP. Перехід із 7.4 на 8.2 і вище дає і швидкість, і менші витрати пам’яті на тому самому сайті. Робиться однією кнопкою в панелі, але перед цим зніміть резервну копію: старі плагіни іноді оновлення не переживають.

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

Чого від пам’яті чекати не треба

Більше пам’яті – не швидше. Пам’ять не прискорює роботу коду, вона дозволяє сторінці не впасти. Відчуття «стало швидше» виникає лише там, де раніше сторінка не відкривалася взагалі.

Більше пам’яті на сторінку – не більше відвідувачів. Радше навпаки: при тому самому тарифі високий ліміт означає, що одночасно поміститься менше сторінок.

Помилка пам’яті зазвичай не означає, що сайт виріс. Частіше вона означає, що з’явився новий плагін або хтось запустив вивантаження. Зростання відвідуваності проявляється інакше – повільним завантаженням і тією самою 508-ю.

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

Як читати тариф

Пам’ять майже ніколи не закінчується наодинці. Разом із нею тариф обмежує частку процесора, число одночасних відвідувачів, швидкість роботи з диском і кількість файлів. Тариф із чотирма гігабайтами пам’яті й жорстким лімітом на одночасні звернення видаватиме 508-у при першому ж сплеску трафіку, і гігабайти тут ні до чого.

Три формулювання, які варто вміти перекладати.

«До 4 ГБ» означає, що постійний ліміт нижчий, а підвищений доступний короткими сплесками або на запит у підтримку. Уточнюйте, скільки дається у звичайному режимі.

«Необмежена пам’ять» означає, що ліміт є, просто вам його не називають. Дізнаєтеся про нього з листа про перевищення допустимого навантаження.

А найнеприємніше – коли провайдер зазначає в описі тарифу memory_limit, називаючи його оперативною пам’яттю. Формально не обман. Фактично 512 мегабайтів такої «пам’яті» означають, що одна сторінка здатна вичерпати весь ваш акаунт цілком.

Три питання в підтримку перед покупкою знімають майже всю неясність: скільки пам’яті на акаунт, який ліміт одночасних звернень і чи можна самому міняти memory_limit. Відповіді скажуть про тариф більше, ніж сторінка з цінами. З тієї ж причини при порівнянні хостингів України варто дивитися не на красиві цифри з реклами, а на те, що акаунт реально видає під навантаженням.

Якщо у вас віртуальний сервер

Звичних лімітів там немає – є просто оперативна пам’ять машини, яку ви ділите між PHP, базою даних і системою. Обмеження задається числом одночасно працюючих процесів PHP у налаштуваннях сервера, і рахується так само: вільна пам’ять мінус потреби бази, поділена на середній розмір процесу.

Помилитися тут неприємніше, ніж на віртуальному хостингу. Там вас просто обмежать, а тут при нестачі пам’яті система почне вибирати, кого вимкнути, і дуже часто вибирає базу даних – як найбільший застосунок. Сайт після цього не працює взагалі, поки базу не піднімуть руками.

Підсумок

Дві пам’яті на хостингу – не дві назви одного й того самого. Одна захищає сайт від єдиної збійної сторінки, інша захищає сервер від вашого акаунта цілком. Перша налаштовується, друга купується.

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

І, якщо робити всього одну дію, – поставте Query Monitor і подивіться, скільки займає ваша головна сторінка. Усе інше рахується від цієї цифри, і доволі часто з’ясовується, що міняти тариф не потрібно зовсім, достатньо вимкнути один плагін.

---

Джерела

1. Офіційне керівництво PHP – опис директиви memory_limit: https://www.php.net/manual/ru/ini.core.php
2. Офіційне керівництво PHP – функція memory_get_peak_usage(): https://www.php.net/manual/ru/function.memory-get-peak-usage.php
3. Документація CloudLinux – ліміти хостинг-акаунта, включно з пам’яттю та числом одночасних звернень: https://docs.cloudlinux.com/cloudlinuxos/limits/
4. База знань CloudLinux – на що впливає ліміт пам’яті акаунта: https://cloudlinux.zendesk.com/hc/en-us/articles/5503038402844-What-does-the-PMEM-LVE-limit-affect
5. База знань CloudLinux – значення лімітів за замовчуванням і рекомендовані: https://cloudlinux.zendesk.com/hc/en-us/articles/9299899421084-LVE-limits-default-values-and-recommended-values
6. WordPress Developer Resources – налаштування wp-config.php, константи WP_MEMORY_LIMIT і WP_MAX_MEMORY_LIMIT: https://developer.wordpress.org/advanced-administration/wordpress/wp-config/
7. WP Engine – розбір помилок «Allowed memory size»: https://wpengine.com/support/resolving-allowed-memory-size-errors/

Часті запитання про пам’ять сайту та хостинг-акаунта

Чим memory_limit відрізняється від пам’яті акаунта?

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

Який memory_limit поставити для WordPress?

Для звичайного сайту з парою десятків плагінів – 256 мегабайтів. Зовсім простому блогу вистачить і 128. Магазину з важким каталогом іноді потрібно 384–512. Головне правило: не піднімайте memory_limit до розміру всієї пам’яті акаунта, тримайте його приблизно в межах чверті. При гігабайті пам’яті акаунта розумна стеля – 256 мегабайтів.

Чому не можна просто поставити memory_limit побільше?

Тому що це знімає запобіжник. memory_limit тримає аварію в межах однієї сторінки: якщо одна сторінка розрослася й упёрлася в ліміт, падає лише вона. Якщо поставити ліміт рівним усій пам’яті акаунта, одна важка сторінка зможе виїсти пам’ять цілком – і тоді впаде весь сайт, а не одна сторінка. Що вищий ліміт, то ширша зона ураження.

Сайт видає помилку пам’яті, але в логах порожньо. Чому?

Це ознака того, що ви впёрлися в ліміт акаунта, а не в ліміт сторінки. Коли сторінка перевищує memory_limit, її зупиняє сам PHP і пише в лог зрозумілу помилку з номером рядка. Коли переповнюється пам’ять усього акаунта, процеси вбиває операційна система сервера – мовчки, без запису в лог PHP. Дивитися тут треба не логи, а статистику використання ресурсів у панелі хостингу.

Як розрізнити помилку сторінки та помилку акаунта?

За логами. Є зрозуміла помилка про нестачу пам’яті із зазначенням файлу й рядка – це ліміт сторінки, ви впёрлися в нього самі, і додавання пам’яті або правка коду допоможе. Сайт мовчки віддає 500 або 503, а логи чисті – це ліміт акаунта, вас зупинив хостинг, і лікується це вже інакше: оптимізацією чи зміною тарифу.

Чи рахується база даних у пам’ять мого акаунта?

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

Скільки пам’яті акаунта мені реально потрібно?

Візьміть, скільки займає одна сторінка вашого сайту, помножте на число сторінок, які готуються одночасно в годину пік, додайте приблизно 30% запасу і ще близько 200 мегабайтів на фонові завдання. Для скромного сайту закладають три-п’ять одночасних сторінок, для активного магазину – вісім-п’ятнадцять. За цією прикидкою блогу зазвичай вистачає 512 мегабайтів, магазину – 2 гігабайти, великому порталу – 4. Тариф беруть на сходинку вище розрахунку, тому що пам’яті впритул не продають.

Чому справжні витрати пам’яті більші, ніж показує PHP?

PHP рахує лише те, що роздав під ваші дані, а сам рушій, підключені модулі й службові буфери в лічильник не потрапляють. На практиці реально зайнята пам’ять приблизно втричі більша за показану: 30 мегабайтів за лічильником – це близько 100 мегабайтів пам’яті сервера. Тому пам’ять акаунта планують за більшою, реальною цифрою, а memory_limit ставлять за меншою, яку показує PHP.

Чому швидкий сайт потребує менше пам’яті?

Тому що час генерації сторінки входить у розрахунок напряму. Сторінка, яка готується три секунди замість пів секунди, при тій самій відвідуваності дає в шість разів більше одночасних процесів – вони довше живуть і накладаються один на одного. Отже, і пам’яті потрібно у стільки ж разів більше. Прискорення сайту, особливо кешування сторінок, знижує потребу в пам’яті й часто позбавляє необхідності міняти тариф.

Що означає помилка 508 Resource Limit Is Reached?

Це не про пам’ять, хоча її постійно приймають за нестачу пам’яті. 508 означає, що перевищено число одночасних звернень до сайту. Причина зазвичай у швидкості: сторінки готуються повільно, запити накопичуються, ліміт переповнюється. Купівля пам’яті тут не допомагає – допомагає кешування й прискорення сайту.

Де змінюється memory_limit?

Найпростіше через панель хостингу: у cPanel це «Select PHP Version» або «MultiPHP INI Editor», в ISPmanager – налаштування PHP у конкретного домену, у Plesk – «Налаштування PHP» у розділі сайтів. Другий робочий спосіб – файл .user.ini в корені сайту з рядком memory_limit = 256M. Порада «прописати в .htaccess» застаріла: на сучасному хостингу такий рядок найчастіше ігнорується або роняє сайт у помилку 500.

Я змінив memory_limit, а він не застосувався. Чому?

Три часті причини. Застарілий спосіб – правка через .htaccess, яка на сучасному хостингу не працює. Кеш – файл .user.ini перечитується не миттєво, а приблизно раз на п’ять хвилин, треба зачекати. І заборона хостингу – на багатьох тарифах стеля задана жорстко, і підняти її зі своїх файлів не можна. Перевірити фактичне значення можна так: створіть у корені сайту файл із рядком phpinfo(), відкрийте в браузері, знайдіть memory_limit, а потім обов’язково видаліть цей файл.

Чим WP_MEMORY_LIMIT відрізняється від WP_MAX_MEMORY_LIMIT?

Це дві константи у файлі wp-config.php. WP_MEMORY_LIMIT відповідає за публічну частину сайту, за замовчуванням 40 мегабайтів. WP_MAX_MEMORY_LIMIT діє в адмінці й фонових завданнях, за замовчуванням 256, тому що адмінка важча у два-три рази. Якщо у вас падає імпорт чи оновлення, а сам сайт працює, піднімати треба другу константу. Важливо: обидві вміють лише піднімати ліміт у межах дозволеного хостингом – стрибнути вище хостингової стелі через них не можна.

Що зробити, якщо не вистачає пам’яті, крім зміни тарифу?

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

Як зрозуміти, скільки пам’яті займає мій сайт?

Найпростіший спосіб для WordPress – плагін Query Monitor. Після встановлення він показує витрати пам’яті й число запитів до бази внизу кожної сторінки. Часто з’ясовується, що найбільше пам’яті їсть зовсім не каталог чи магазин, а давно забутий плагін, поставлений три роки тому під один банер. Від цієї цифри й рахується все інше – і нерідко виявляється, що міняти тариф не потрібно, достатньо вимкнути один плагін.