Лимитирование ресурсов

В условиях виртуального хостинга большое количество абонентов одновременно используют одну аппаратно-программную технологическую среду. Для обеспечения необходимого качества предоставляемых услуг для конкретного пользователя вне зависимости от действий других абонентов провайдеру приходится устанавливать ряд определенных требований и ограничений. При их выполнении какие-либо действия пользователя не оказывают заметного влияния на производительность виртуальных серверов других абонентов и, соответственно, не вызывают снижения качества предоставляемых услуг.

Существует ряд ограничений по потреблению ресурсов, которые относятся к процессам и файлам пользователей хостинга. В соответствии с устоявшейся профессиональной терминологией, мы будем называть ограничения лимитами (от англ. limits). Итак, ограничения или лимиты налагаются на работу большинства пользовательских процессов, запущенных на хостинг-сервере. Делается это для того, чтобы не допустить влияния неправильно работающих процессов одних пользователей на процессы других пользователей. Например, если некая программа работает неправильно и стремится занять все ресурсы хостинг-сервера, то ей это не удастся. Она получит лишь часть ресурсов, которая пропорциональна текущим запросам других пользователей.

Ниже мы приводим основные лимиты сервера хостинга, а также даем вам возможность понять, почему могут возникнуть сложности в работе из-за этих ограничений.

Соединения с базой данных MySQL

Для того, чтобы работать с базой данных MySQL, ваша программа должна установить соединение с ней. Как правило, одновременно используется несколько соединений, так как обычно запущено несколько программ одновременно. Происходит это из-за того, например, что на сайт одновременно заходит несколько посетителей. У нас существует ограничение на количество одновременных подключений к MySQL-серверу равное 20-ти. Если вы столкнулись с превышением этого ограничения, ваша программа получит соответствующую ошибку, после чего нужно будет задуматься об оптимизации. Как правило, доступного количества соединений хватает подавляющему большинству пользователей. Реально требуют превышения заявленного ограничения только единицы пользователей. Это говорит о том, что даже 20-ти соединений более чем достаточно для нормальной работы. Если ошибка, связанная с этим лимитом, возникает регулярно, то или ваш проект настолько серьезен, что «не умещается» в рамки виртуального хостинга или обслуживающие сайт скрипты работают некорректно.

Выполнение тяжелых SQL запросов.

MySQL будет прерывать выполнение запроса, если поступившая команда SELECT может потребовать слишком много времени для выполнения. Такая картина является следствием громоздких объединений таблиц и (или) нерационально написанном выражении WHERE, в которых ключи не используются или используются не в полной мере. При выполнении подобных запросов MуSQL должен будет производить множественные построчные считывания данных из таблиц, что в конечном итоге приводит к повышенной нагрузке на дисковую подсистему и, как следствие, к деградации сервиса. Запрос классифицируется как слишком большой, если оператору SELECT, пришлось бы обрабатывать больше строк, чем задано в переменной max_join_size = 500000. Существует неплохой способ определить, насколько хорошим является тип связывания. Для этого нужно перемножить все значения столбца rows, выводимого командой EXPLAIN. Результатом будет грубая оценка того, сколько строк должен просмотреть MySQL для выполнения запроса. Если при такой оценке результат будет слишком большим необходимо оптимизировать запрос и оценить возможности использования индексов.

Использование процессора (cputime)

Каждый процесс (CGI-программа) запущенный пользователем на нашем сервере, может потребить определенное количество ресурсов центрального процессора (CPU), после чего такой процесс получит сигнал о немедленном завершении. То есть, процесс не может использовать процессор(ы) бесконечно. Существует ограничение на использование процессора. Ваши процессы могут использовать 20 секунды времени, которое центральный процессор реально потратит на обработку вашей задачи. Процессорное время не соответствует обычному течению времени. Процессорное время - это реальное количество секунд, которое было затрачено процессорами на выполнение кода вашей задачи. Как правило, параллельно обслуживаются несколько программ. Кроме того, не все время программа пользуется процессором - она ждет результатов ввода/вывода, работает с диском и так далее. Поэтому, неправильно считать, что через 20 астрономические секунды после запуска ваш процесс будет принудительно завершен. Вероятен также вариант, что причиной превышения лимита на процессорное время, является ошибка на этапе разработки программы, например, «бесконечный цикл». Кстати, пользователь, на запрос которого такая программа будет «долго думать», наверняка уйдет со страницы, не получив результата. Поэтому любые веб-приложения принято проектировать так, чтобы отдать пользователю ответ на его запрос максимально быстро (единицы секунд).

Использование памяти (datasize)

Любое веб-приложение при выполнении использует оперативную память (ОЗУ) хостинг-сервера для размещения данных. Так как все запросы, которые формируются пользователями вашего виртуального сервера, сначала обрабатываются веб-сервером Apache, то ограничение, в первую очередь затрагивает именно CGI-процессы, которые он запускает. Каждая запущенная программа может занять не более 20 Mбайт оперативной памяти. Если программа превысит этот предел, она совершит аварийное завершение. Грамотно разработанные CGI-программы, к которым в данном контексте относятся, например, скрипты на Perl, shell или CGI-версии интерпретатора PHP, как правило, не занимают много памяти. А чрезмерное использование ОЗУ, как и других ресурсов, противоречит CGI-идеологии, которая подразумевает быстрое выполнение пользовательской задачи с немедленной выдачей результата.

Квотирование дискового пространства

Каждому пользователю хостинга выделяется ограниченное дисковое пространство на файловой системе сервера хостинга — дисковая квота. Надо очень основательно подумать о том, какой объем дискового пространства требуется для работы вашего ресурса. Если случится так, что ваш сайт начнет занимать более определенной в договоре дисковой квоты, то весьма вероятно, что это отразится на корректности работы вашего сайта, а иногда это может привести к потере полезной информации, так как механизм ограничения квоты подразумевает запрет записи на диск в случае ее превышения. Следует так же помнить что при использовании большого множества мелких файлов суммарный объем данных, хранящихся в этих файлах, может значительно отличаться (быть меньше) от суммарного фактического размера области занимаемой этими мелкими файлам на дисковом пространстве. Это является особенностью файловой системы используемой операционной системы и зависит от размера блока и фрагмента. Уменьшение величин блока и фрагмента файловой системы позволяет более оптимально использовать дисковое пространство для хранения множества мелких файлов, однако это же приводит к увеличению накладных расходов при доступе к данным файлов большого размера. Величины размеров блока и фрагмента файловой системы обратно пропорциональны величине времени доступа к данным. А поскольку одна и та же файловая система используется для хранения данных нескольких сотен пользователей хостинга, и невозможно для каждого конкретного пользователя оптимизировать параметры одной и той же файловой системы, то используются усредненные значения, рекомендуемые по умолчанию разработчиками операционной системы. Принцип организации данной файловой системы позволяет добиваться минимальной фрагментации и соответственно увеличения скорости доступа к данным расположенных на жестком диске. Размер дисковой квоты и занимаемое пространство вашим ресурсом вы можете проконтролировать через панель управления сайтом. Дисковая квота учитывает не только размер файлов в домашней директории пользователя, учитывается также пространство, занимаемое базой данных MySQL. Для предотвращения роста объема базы данных в случае превышения дисковой квоты пользователь ограничивается по привилегиям до «SELECT, DELETE, DROP, LOCK TABLES». В этом случае надо быть предельно осторожным и воздержатся от применения команды «TRUNCATE», что соответствует команде «Очистить таблицу» в интерфейсе phpMyAdmin, которая, на первый взгляд, позволяет очистить содержимое таблицы и вернутся в пределы дисковой квоты, но на самом деле эта команда подразумевает полное удаление таблицы с последующем восстановлением ее структуры, однако запрет привилегии «CREATE» не позволит восстановить структуру таблицы, и это приведет к полной потере таблицы. В этом случае следует отдавать предпочтение построчному удалению таблицы. Подобным образом следует воздерживаться и от применения команды «OPTIMIZE TABLE», результатом выполнения котрой может быть вызвано выполнение операторов «DELETE, REPLACE и UPDATE». После превышения квоты, когда пользователь возвращается в пределы отведенной ему дисковой квоты, ему сразу же разрешается дальнейшая запись на диск и в течение часа восстанавливаются привилегии на использование базы данных.

Количество соединений с веб-сервером.

Веб-сервер выделяет определенное количество ресурсов при выполнении каждого HTTP запроса. В случае, если к какому либо размещаемому сайту будет направленно аномально высокое количество запросов, либо если выполнение этих запросов занимает очень много времени, то все ресурсы веб-сервера могут быть монопольно заняты под этот сайт. Для предотвращения монопольного захвата вводится лимит. Каждый виртуальный веб-сервер одновременно сможет обработать не более 10 запросов. Разумным временем полной обработки HTTP запроса и передачи конечному пользователю ответа является величина в десятые доли секунды. В таком случае за минуту ваш сайт без проблем смогут посещать сотни пользователей.

Запрет на проксирование трафика через сервер хостинга и размещение трекеров типа BitTorrent

Особое внимание уделяется тем ресурсам, которые с помощью различных средств пытаются проксировать трафик из-за пределов области, что приводит снижению полезной пропускной способности сетевых интерфейсов сервера. Подобные попытки легко определяются утилитами сетевого мониторинга Unix-подобных систем. Обнаружение несанкционированного проксирования автоматически ведет за собой блокировку сайта-нарушителя.

Отправка электронных почтовых сообщений.

В целях борьбы со СПАМ-ом установлено ограничение на число отправляемых сообщений за единицу времени. Так, ориентировочно, на одной хост-машине работают порядка 300-500 хостинг-аккаунтов. Для них всех (т.е. в целом для одной хост-машины) установлено ограничение на отправку почтовых сообщений равное 300 сообщений в 15 минут. В случае, если этот порог превышен, сообщение становится в очередь отправки на сервере почтовой системы. Сообщения стоящие в очереди, раз в 30 минут, отправляются всё с тем же лимитом в 300 сообщений. Таким образом очередь постепенно продвигается.