Вы купили тариф, где крупно написано «512 МБ памяти», и держите в голове одну цифру: вот мой потолок. Потолок у аккаунта не один. Их с десяток, каждый проверяется сам по себе, и тормозит или падает сайт обычно от того лимита, за которым вы как раз не следили.
Если вы пришли с конкретной бедой – сайт то и дело отдаёт ошибку, тормозит на ровном месте, «резко кончилось место» при полупустом диске, листайте сразу к таблице ниже: там симптом и то, куда смотреть. Всем остальным стоит потратить пять минут на общую карту. Второй раз вы упрётесь уже в другой забор, и знать заранее, где он стоит, дешевле, чем выяснять по аварии.
Откуда лимиты берутся вообще, разобрано в тексте про CloudLinux – систему, которая на большинстве виртуальных хостингов делит один сервер между сотнями аккаунтов. Здесь важно другое: лимитов много не потому, что хостер жадный, а потому что ресурс не один, и каждый приходится сторожить отдельно.
Почему заборов (лимитов) так много
Со стороны провайдера картина простая. На одной машине живут сотни чужих сайтов, и любой из них может однажды сойти с ума, например, зациклившийся скрипт, кривой плагин, ночной бэкап, который читает диск без остановки. Если ничем это не огородить, один такой сосед кладёт всех. Поэтому каждому аккаунту ставят забор.
Забор нужен не один. Скрипт может почти не есть память, но насмерть загрузить диск мелкими чтениями; может быть лёгким по диску, но сжирать процессор; может спокойно работать в одиночку и захлебнуться, когда на сайт разом зашли двести человек. Один счётчик все эти случаи не покроет, т.к. под каждый тип нагрузки нужен свой. Так их и набирается сразу несколько: процессорное время, память, число одновременных процессов, место на диске, количество файлов, скорость и частота обращений к диску. Полдюжины независимых лимитов, и это ещё скромный набор.
Что стоит понять с самого начала: провайдеру обычно нет смысла занижать лимиты искусственно, ведь ограничения нужны прежде всего, чтобы держать нагрузку под контролем и защищать остальные аккаунты. Тикет в поддержку к тому же обходится ему дороже, чем процессорные секунды, которые вы могли бы потратить. Забор он ставит не в наказание вам, а в защиту вашего соседа, ну и вас от соседа. На большинстве нормальных хостингов лимиты выставлены с запасом, и упираются в них не «тяжёлые» сайты, а сайты с проблемой, о которой владелец не знает.
У самих цифр лимита логика тоже провайдерская. Сервер на shared-хостинге по умолчанию рассчитан на то, что аккаунты не станут одновременно выбирать свои лимиты на максимум. Так чаще всего и есть: пики у сайтов не совпадают, и запаса хватает на всех. Лимит на аккаунт – это страховка на случай, когда расчёт не сходится: он не даёт одному сайту забрать долю, отложенную под соседей. Оттого одинаковый на бумаге тариф на пустом сервере и на плотно набитом ощущается по-разному, хотя цифры в панели те же.
Кто здесь живёт
Проще всего разложить лимиты по тому, что каждый из них сторожит.
Процессорное время
Это не «насколько быстрый у вас сервер», а какую долю ядра вам разрешено занимать. Считается в процентах, где 100% – это одно целое ядро. Когда вы упираетесь, сервер не выдаёт ошибку, он вас притормаживает: запросы встают в очередь, страница собирается не за триста миллисекунд, а за две секунды. Оттого CPU-лимит и трудно поймать: сайт не лежит, просто становится вязким. Подробно этот случай, «памяти вагон, а сайт еле шевелится», разобран в отдельном тексте про лимит процессора.
Память
Тут живёт самая застарелая путаница на всём хостинге. В настройках PHP есть memory_limit – сколько оперативки разрешено одному скрипту. А есть PMEM – сколько памяти вообще отведено всему аккаунту. Человек поднимает memory_limit до 512 МБ, считает, что теперь у него полгигабайта, и всё равно ловит белый экран, потому что реальный забор, PMEM, стоит ниже, а memory_limit в PHP всё равно не отражает весь расход памяти аккаунта. Разницу и то, по какой цифре считать на самом деле, я разбирал в тексте про memory_limit и PMEM.
Одновременность
Здесь два лимита, которых постоянно путают. EP (entry processes) – сколько запросов одновременно вошло внутрь изоляции аккаунта (LVE) и заняло этот лимит. Для сайта это прежде всего параллельные обращения к динамическим скриптам, но туда же могут попадать cron и SSH. Не сколько человек на сайте, а сколько прямо в эту секунду что-то считается на сервере. Обычный тариф даёт около двадцати таких входов, тариф подороже – сорок. Исчерпали – и на Apache сервер сразу отдаёт 508-ю ошибку. Второй, NPROC, – это общее число процессов аккаунта, куда входят не только веб-запросы, но и cron с SSH. NPROC обычно ставят выше EP, т.к. он ограничивает уже общее число процессов внутри изоляции, и упираются в него реже, но симптом другой, поэтому лимиту процессов отведён свой разбор.
Кстати, тонкость, из-за которой EP пугает сильнее, чем стоило бы: EP не считает каждый дочерний процесс отдельно. Скрипт вызвал базу, отправку письма, внешнюю команду, но для EP это по-прежнему один вход. Так что двадцать EP – это не про число посетителей. Это двадцать запросов, которые выполняются в один момент, и для среднего сайта такой запас обычно не мал.
Диск
Тоже два разных забора. Первый – место в мегабайтах, он понятен. Второй – число файлов, inode, и вот он ловит людей врасплох: сайт пишет «No space left on device», а по диску занято процентов шестьдесят. Просто файлов уже больше, чем разрешено, а весят они копейки: тысячи мелких файлов кэша, старая почта, сессии. Куда именно утекает квота, когда цифры не сходятся, – тема отдельного текста про скрытый расход места.
Ввод-вывод
Самый тихий и самый недооценённый лимит. Их снова два: полоса – сколько мегабайт в секунду вам разрешено читать и писать (типовое значение около одного, на быстрых тарифах до четырёх), и IOPS – сколько отдельных операций с диском в секунду. Сайт с кучей свободной памяти и незагруженным процессором может тормозить именно тут, и догадаться сложно, потому что в тарифе этих цифр обычно нет вовсе. Что происходит, когда упираешься в полосу и когда в число операций, разнесено по двум текстам – про полосу дискового I/O и про лимит IOPS.
Разница между полосой и числом операций важнее, чем кажется. Большой файл – видео, архив бэкапа – упирается в полосу: данных много, а операций мало. Галерея из сотен мелких превью наоборот: каждого килобайта чуть, но обращений к диску тысячи, и первым кончается IOPS. Поэтому сайт с одной тяжёлой картинкой и сайт с горой мелких файлов тормозят по разным лимитам, хотя на словах и там, и там «диск не тянет».
Одна деталь, которая экономит часы диагностики: обращения к дисковому кэшу в лимит I/O не засчитываются. Файл, который сервер уже держит в памяти, можно читать хоть тысячу раз бесплатно. Поэтому два одинаковых с виду сайта ведут себя по-разному: у одного горячие данные лежат в кэше, у другого каждый запрос лезет на реальный диск.
Статья длинная. Предлагаем сделать паузу и ознакомиться с лучшими украинскими хостинг-провайдерами из нашего рейтинга. По каждому есть подробный разбор: как тестировали, что с аптаймом, скоростью и поддержкой, где сильные и слабые стороны. Загляните в обзоры тех, кто вам интересен, почитайте отзывы клиентов.
Почему чинить приходится по кругу
Лимиты независимы, и это выходит боком при ремонте. Вы находите утечку памяти, сайт перестаёт выдавать белый экран, а через неделю начинает тормозить, потому что тот же тяжёлый плагин, что ел память, не легче и по процессору. Разбираетесь с процессором, и в потолок упираются ночные бэкапы, теперь уже по вводу-выводу. И так по кругу… Каждый забор стоит сам по себе, поэтому, разгрузив один ресурс, вы просто передвигаете нагрузку на следующий. «Добавьте памяти» почти никогда не закрывает вопрос целиком, т.е. лечит один симптом из нескольких.
Поставив монитор запросов, владельцы магазина нередко обнаруживают, что тяжелее всего у них не каталог и не корзина, а давно заброшенный конструктор страниц, который грузит и память, и процессор, и диск разом. Убрали его – и отпустило по всем трём лимитам сразу. Такие находки со стороны видно куда чаще, чем кажется: настоящий пожиратель ресурсов обычно не тот, на кого думают в первую очередь.
Кто вас ограничил
Если сайт уже ведёт себя странно, а копаться в теории некогда, держите короткую сводку: симптом слева, вероятный виновник справа. Она не заменяет диагностику, но сокращает круг подозреваемых.
| Симптом | Скорее всего это | Куда смотреть |
|---|---|---|
| 508 или «resource limit is reached» | достигнут LVE-лимит, чаще всего EP (Apache) | Resource Usage → faults по лимитам |
| Белый экран после обновления плагина или темы | память: PMEM или memory_limit | лог ошибок, график PMEM |
| Тормозит, при этом память и процессор свободны | полоса I/O или IOPS | графики I/O и faults по ним |
| Тормозит под нагрузкой, память в норме | CPU-лимит, идёт троттлинг | график CPU, faults по CPU |
| «No space left on device», а диск не полный | закончились inode | число файлов: кэш, почта, сессии |
| 503 время от времени на LiteSpeed | не обязательно EP | конфигурация PHP, лог – шире |
| cron не доходит до конца | NPROC или CPU в момент запуска | список процессов, время старта задач |
Отдельно про предпоследнюю строку. На Apache исчерпание EP обычно даёт именно 508, и это хороший первый ориентир. На LiteSpeed EP устроен иначе, и периодическая 503 там прилетает по самым разным причинам, вешать её на лимит процессов не стоит, пока не посмотрели логи. Что вообще означают эти коды и чем 508 отличается от 503 и 504, собрано в тексте про коды ответа HTTP.
Мягкий лимит и жёсткий
Лимиты гасят нагрузку по-разному, и от этого зависит, переживёте вы всплеск или нет. Мягкий лимит вас притормаживает: очередь, задержка, но сайт работает. Жёсткий – обрубает сразу. CPU обычно мягкий: упёрлись в потолок – вас придерживают, отпустило – поехали дальше. EP жёсткий: если все двадцать входов заняты, следующий запрос, которому нужен новый вход, получает 508 без разговоров. Разбор, какие лимиты ведут себя как и почему это важно при выборе тарифа, – в тексте про мягкие и жёсткие лимиты.
И вот что панель показывает плохо. График «использование 85%» пугать вас не должен, пока вы под потолком, всё в порядке, даже впритык. Смотреть надо не на линию использования, а на счётчик faults, т.е. сколько раз за сутки вы реально упёрлись в забор. Ноль faults при загрузке в 90% означает только, что по этому лимиту вы пока не упирались в потолок. Десяток faults при средней загрузке 40% – это сайт, который дёргается в потолок пиками, и вот с этим уже надо разбираться.
Кстати, некоторые хостеры счётчик faults в панели вообще не выводят – линия использования выглядит спокойнее, и вопросов от клиента меньше. Если у вас его не видно, а сайт периодически чудит, есть смысл спросить поддержку напрямую: сколько было faults и по какому лимиту.
Чего нет в тарифе
Самое неприятное здесь, то, что в витрине тарифа вы видите не те лимиты, которые вас реально остановят. На странице с ценами крупно пишут место на диске и «безлимитный трафик», иногда память. А EP, IOPS, полоса I/O и NPROC – те самые лимиты, в которые упирается живой сайт, – часто не указаны нигде. Их приходится выпытывать у поддержки или узнавать по факту первой аварии.
Логику хостера тут понять можно. Эти цифры трудно сравнивать между тарифами, они пугают новичка и почти ничего ему не говорят, а место на диске обещать дёшево. Так появляется и «безлимитный» хостинг, который технически не врёт: диск и трафик действительно можно не считать, потому что забор стоит не там, он стоит на inode, EP и вводе-выводе, и вот они очень даже конечны. Почему «безлимит» – это перенос лимита, а не его отсутствие, разложено отдельно в тексте про «безлимитный» хостинг.
Ещё одно читается в тарифе не сразу: ресурс могут назвать гарантированным, а могут – burst, «до столько-то». Но что стоит за этими словами, зависит от политики конкретного провайдера: по одной формулировке в тарифе нельзя считать, что вам физически зарезервировали соответствующую долю железа: LVE-лимит вообще задаёт потолок потребления, а не выделенную вам часть сервера. На пустом сервере разница незаметна, на плотном может быть ощутимой. Чем гарантированные ресурсы отличаются от burst и когда переплата за гарантию оправдана, разобрано в тексте про гарантированные и burst-ресурсы.
Вытащить реальные числа до покупки можно тремя путями. Первый – заглянуть в панель на текущем хостинге: в cPanel раздел Resource Usage показывает и лимиты, и историю faults по каждому из них. Второй – прямо спросить поддержку будущего хостера, какие EP, IOPS и полоса I/O на интересующем тарифе; честный ответит цифрами, а уклончивый ответ – это тоже ответ. Третий – не верить витрине в принципе и смотреть, как хостинг ведёт себя на тестах: по какому принципу мы гоняем провайдеров и почему витринным цифрам верить нельзя, описано в методике рейтинга, а какой тариф даёт больше за свои деньги – считает индекс TVI.
Пару лет назад обращения в духе «сайт падает, а хостинг говорит, что всё в норме» шли валом, и почти всегда упор был именно в невидимый лимит, тот самый, которого в тарифе не было. Со стороны клиента это выглядит как придирка провайдера, со стороны провайдера – как честно исчерпанный ресурс, про который просто забыли написать на странице с ценами.
Один лимит – десять имён
Последнее, что стоит держать в голове при сравнении тарифов: один и тот же забор у разных хостеров называется по-разному. EP где-то «entry processes», где-то «одновременные подключения», где-то «параллельные процессы». PMEM превращается в «физическую память» или просто «RAM». Сравнивать тарифы надо по смыслу лимита, а не по слову в таблице, иначе легко решить, что у двух хостеров разные ограничения, хотя за разными названиями стоит ровно одно и то же.
Источники
- CloudLinux – Limits (SPEED, PMEM, IO, IOPS, EP, NPROC, inode)
- CloudLinux – EP and NPROC limits: a look from inside
- CloudLinux – LVE limits: default and recommended values
F.A.Q. по лимитам аккаунта
Сколько на самом деле лимитов у хостинг-аккаунта?
Обычно около десятка, и проверяется каждый сам по себе: процессорное время (CPU), память (PMEM), число одновременных входов (EP), общее число процессов (NPROC), число файлов (inode), место на диске, полоса I/O и IOPS. Останавливает сайт чаще всего не тот лимит, за которым владелец следил. Поэтому одну цифру из тарифа держать в голове мало – упереться можно в любой из заборов.
Почему сайт тормозит, хотя памяти и места хватает?
Свободная память не означает, что свободны остальные ресурсы. Чаще всего в таком случае упор идёт в CPU-лимит (сервер притормаживает вас, не выдавая ошибку) или во ввод-вывод – полосу I/O либо IOPS. Память и процессор при этом могут быть почти пустыми, а сайт всё равно вязкий. Смотреть надо на графики I/O и на счётчик faults по этим лимитам.
Что означает ошибка 508 и с каким лимитом она связана?
На Apache 508 чаще всего означает достигнутый LVE-лимит, и самый частый его виновник – исчерпанные EP, одновременные входы в изоляцию аккаунта. Все разрешённые входы заняты, и следующий запрос, которому нужен новый вход, отбивается сразу. На LiteSpeed EP устроен иначе, и периодическая 503 там не обязательно связана с этим лимитом – стоит сначала посмотреть логи. Поэтому 508 на Apache – хороший повод в первую очередь проверить EP.
Чем PMEM отличается от memory_limit?
memory_limit – это настройка PHP: сколько оперативки разрешено одному скрипту. PMEM – сколько памяти отведено всему аккаунту целиком, и этот забор обычно стоит ниже. Поднять memory_limit до 512 МБ можно, но реальным потолком останется PMEM, а сам memory_limit не отражает весь расход памяти аккаунта. Считать надо по PMEM и по большей цифре.
Почему сайт пишет «No space left on device», если диск не полный?
Скорее всего, закончились не мегабайты, а inode – число файлов, которое разрешено держать на аккаунте. Файлов уже больше лимита, хотя весят они копейки: тысячи мелких файлов кэша, старая почта, сессии. По диску при этом занято может быть процентов шестьдесят. Смотреть нужно счётчик файлов, а не свободное место.
В чём разница между EP и NPROC?
EP считает одновременные входы в изоляцию аккаунта – для сайта это прежде всего параллельные запросы к динамическим скриптам. NPROC считает вообще все процессы аккаунта, включая cron и SSH. NPROC обычно ставят выше EP, и упираются в него реже. Симптомы у них разные, поэтому и путать их не стоит.
Что такое faults и почему на него важно смотреть?
Faults – это счётчик того, сколько раз за сутки вы реально упёрлись в лимит. Линия использования в 85% пугать не должна: пока вы под потолком, всё в порядке. А вот faults больше нуля – это уже сигнал, даже если средняя загрузка выглядит скромной. Некоторые хостеры этот счётчик в панели не показывают, и тогда его стоит спросить у поддержки.
Чем IOPS отличается от полосы I/O?
Полоса – это сколько мегабайт в секунду вам разрешено читать и писать; в неё упираются большие файлы вроде видео и архивов бэкапа. IOPS – это число отдельных операций с диском в секунду; в него упирается гора мелких файлов, например галерея из сотен превью. Один сайт может тормозить по полосе, другой по IOPS, хотя на словах у обоих «диск не тянет». Обращения к дисковому кэшу при этом в лимит I/O не засчитываются.
Почему в тарифе не указывают EP, IOPS и полосу I/O?
Эти цифры трудно сравнивать между тарифами, новичку они мало что говорят, а место на диске обещать дёшево и наглядно. Поэтому на витрине пишут диск и «безлимитный трафик», а лимиты, в которые реально упирается сайт, остаются за кадром. Узнать их можно у поддержки или по факту первой аварии. Уклончивый ответ на такой вопрос – это тоже ответ.
«Безлимитный» хостинг – это правда или маркетинг?
Технически «безлимит» не врёт: диск и трафик действительно можно не считать. Но забор при этом стоит не там – он стоит на inode, EP и вводе-выводе, и вот эти ресурсы очень даже конечны. То есть лимит никуда не делся, его просто перенесли на то, что в рекламе не показывают. Поэтому «безлимитный» тариф упирается в потолок ничуть не реже обычного.
Как узнать реальные лимиты своего тарифа?
На хостинге с cPanel есть раздел Resource Usage – он показывает и сами лимиты, и историю faults по каждому из них за последние сутки. Можно спросить поддержку напрямую, какие EP, IOPS и полоса I/O на вашем тарифе. И витринные цифры с реальным поведением хостинга – не одно и то же, поэтому полезно смотреть на результаты независимых тестов.
Я добавил памяти, а сайт всё равно тормозит. Почему?
Лимиты независимы друг от друга, поэтому, разгрузив память, вы просто передвигаете нагрузку на следующий ресурс. Тот же тяжёлый плагин, который ел память, обычно не легче и по процессору, а следом в потолок упираются бэкапы по вводу-выводу. «Добавьте памяти» закрывает один симптом из нескольких, а не проблему целиком. Разбираться приходится по кругу, пока не найдётся настоящий пожиратель ресурсов.