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. После установки он показывает расход памяти и число запросов к базе внизу каждой страницы. Часто выясняется, что больше всего памяти ест вовсе не каталог или магазин, а давно забытый плагин, поставленный три года назад под один баннер. От этой цифры и считается всё остальное – и нередко оказывается, что менять тариф не нужно, достаточно выключить один плагин.