При выборе виртуального хостинга очень важно уточнить, какие устанавливаются лимиты по ресурсам памяти, процессорному времени и процессам. Достаточно часто это настраивается возможностями CloudLinux в связке с cPanel или ISPmanager. Зачастую, если ваш сайт превысит выделенные лимиты, то он может троттлиться или даже блокироваться временно или полностью.
Какие бывают лимиты
Во-первых, лимиты могут рассчитываться за разный интервал времени — час, сутки или месяц.
Во-вторых, по типу ресурса лимиты бывают:
- процессорное время общее
- процессорное время MySQL сервера
- максимальная память на аккаунт (МБ)
- максимальная память, выделяемая на процесс (МБ)
- максимальное время на выполнение кода php (c)
- использование ввода/вывода (Кб/с)
- количество одновременных входящих соединений (EP, entry process)
- общее количество процессов
- ограничения на inodes
Кроме того, сами показатели могу вычисляться по-разному. Например, процессорное время может вычисляться в процентах (обычно в панели ISPmanager) или условных единицах (CP, в панели cPanel).
Процессорные лимиты
Нагрузка на CPU — это время в минутах, суммарно затраченное процессорами сервера на обработку процессов аккаунта в течение периода времени, обычно суток. Показатель является суммируемым, то есть при стабильной нагрузке в 2 cp (cpu points) в течение 24 часов, нагрузка за сутки составит 24*2=48 cp. Нагрузка на CPU измеряется стандартной утилитой *nix — sa. Подробное описание работы данной утилиты вы можете найти, например, здесь. В статистику за день заносится суммарное накопленное за сутки значение нагрузки в процессорных минутах. Такой системой, например, пользуется Timeweb. В ее стартовом тарифе макcимальная суточная нагрузка на процессор ограничена 50 CP.
Другой вариант подсчета суммарной загрузки процессами одного пользователи — использование Process accounting — выполняется в помощью утилит acct и accton. Они, вместе с другими утилитами пишут и анализируют логи по выполненным командам:
**Command Name** **Purpose**
accton Enables or disables process accounting
acctentries Counts the number of accounting entries in the log file
accttrim Truncates the accounting file specified
dumpacct Dumps the contents of the log file
dump-acct Similar to dumpacct
handleacct.sh Script to compress and backup logs and delete the oldest
lastcomm Prints commands executed on the system, most recent first
sa Summarize accounting informationCode language: JavaScript (javascript)Собранные данные каждый час обнуляются и записываются в базу данных биллинга. В такой ситуации cp показывает количество минут, на протяжении которых работали бы все задачи клиента, при 100% нагрузке на одно ядро. Если аккаунт за прошедший час превысил часовую норму нагрузки своего тарифа (к примеру, если максимальная нагрузка в день 100% на ядро, то часовая норма 1/24 ≈ 4.2%), следующий час процессы работают с пониженным приоритетом относительно других заказов (nice level). При уменьшении нагрузки, приоритет восстанавливается.
По техническим причинам на серверах с панелями управления cPanel и ISPmanager невозможно менять nice level для скриптов конкретного клиента. Поэтому при регулярном превышении нагрузки на CPU веб-сервера, хостер вручную блокирует такой аккаунт.
Такой алгоритм позволяет не останавливать работу сайтов, если им временно требуется больше ресурсов (например, при индексации поисковыми системами), а просто немного замедлять. Данную схему практикует провайдер iHC.
Линейно cp может вычисляться по логам так:
user@server:~$ time php test.php
real 0m1.163s - реальное время
user 0m1.156s - процессорное время в юзер-мод
sys 0m0.004s - процессорное время в кернел-мод
Время user и sys складываются. Записанный в журнал результат:
user 1.15 cpu 6876k mem 0 io php
Теперь получаем cp:
>>> 1.15/60
0.019Третий подход похож на второй, но с ограничением в процентах в день по среднему. Приведу реальный пример. На данном примере время CPU 26+139 секунд в час, то есть 2,75 минуты или 2.75cp.
А суммарное время работы в минутах — это суммарное время, сколько исполняли код в данный час все ядра (при этом нагрузка могла быть очень маленькой, но постоянной). На этот параметр можно здесь не смотреть.
Далее вычисленное значение CP переводится в проценты, и если среднее за час не превышает установленного лимита (на скриншоте ниже 100% ядра), то ограничения не применяются. Если же лимит превышен, то после каждого часа применяется троттлинг процессора, в результате чего исполнение кода замедляется.
Теперь о статистических цифрах. На среднем неплохом хостинге, где у вас запущено до 10 сайтов с посещаемостью до 500 уникальных пользователей в день, средняя загрузка CPU будет 15-30% в час.
Отдельные особо одаренные хостеры ограничивают суммарное процессорное время в месяц CPU-часами. В таком случае общее общее время CPU user и sys суммируется за все дни и часы. В примере приведенном выше время CPU получается в среднем около 30 часов в месяц. Пример таких хостеров — iPIPE (большой лимит в 1000 часов), ISPserver (маленький лимит в 18 часов на стартовом тарифе).
Вычисление CP — дело нетривиальное, потому что оно будет разным на каждом хостинге в зависимости от установленных процессоров — их частоты и набора инструкций. Процессоры более новых поколений будут исполнять тот же код медленнее и соответственно, CP увеличится. Как результат, хостинги, которые давно не обновляли железо, «задушат» вас своими лимитами.
Нагрузка на MySQL — это время в секундах, суммарно затраченное на обработку запросов к базам данных аккаунта в течение суток. Нагрузка на MySQL измеряется при помощи специального модуля от Percona, входящего в используемую нами сборку MySQL. Документация о продукте доступна на сайте разработчика.
У хостера Timeweb ограничения от 1000 до 25000 секунд в день. Собранные данные каждый час обнуляются и записываются в базу данных биллинга. Если заказ за прошедшие сутки потребил ресурсов больше, чем положено по тарифу, клиенту отсылается предупреждение.
Потребленный CPU ресурс MySQL можно посмотреть командой:
mysql> select substring_index(USER, '_', 1) `order`,sum(CPU_TIME) cpu
from information_schema.user_statistics where user like 'p%' group by `order`
order by cpu desc limit 30;Code language: JavaScript (javascript)Лимиты памяти
Часто указывается два лимита — общий на аккаунт и на каждый процесс. Если у вас несколько сайтов на одном хостинге, то каждый из них будет потреблять объем памяти из общего объема доступной памяти.
Хорошим значением общего объема является 1 Гбайт, а 128 Мбайт на процесс обычно достаточно для исполнения кода популярных CMS. Обычно вычисляется среднее и пиковое потребление каждый час.
Исполнение кода
На исполнение кода PHP обычно накладывается два ограничения — максимальное время исполнения и объем памяти для исполнения.
Опять же, 128-256 Мбайт достаточно для исполнения почти любого PHP запроса, а время исполнения вполне достаточно, если ограничено 300 секундами.
Также лимитируется общее число исполняемых процессов. Обычно, для десяти CMS сайтов более 10 процессов не требуется.
Ограничения ввода-вывода
Измеряются в Кбайт/с и не должны превышать установленного лимита в час. Обычно, эти лимиты достаточно высоки и не создают проблем, если только у вас не сайт с десятитысячной посещаемостью.
Ограничения inodes
Это ограничения на количество создаваемых на диске файлов. Часто его вводят для того, чтобы не использовались сайты, где будет активная запись на диск, а для этого покупались vps/vds сервера.
Обычно эти лимиты очень большие, например, 30000, что явно больше потребностей стандартного корпоративного сайта. Однако, у хостера Евробайт есть даже ограничение на количество одновременно открытых файлов — 3176.
Прочие ограничения
Также некоторые хостеры вводят ограничения на рассылку писем в час, размер письма и на количество одновременных соединений с MySQL БД (max_user_connections). Измеряются в штуках.
Количество соединений должны быть в среднем в несколько раз больше, чем у вас баз данных.
У особо жадных хостеров, например, Евробайт, есть даже лимитирование максимального числа http соединений, то есть фактически количество одновременных посетителей файлов.