LAWspb

Ограничения CPU

Ваш аккаунт находится в группе серверов, объединенных в кластер.

Работа сайтов обслуживается одновременно множеством серверов, у каждого из которых своя "специализация". Объединенные таким образом серверы обеспечивают повышенную отказоустойчивость и сравнительно большую независимость каждого отдельного сайта от "соседей" по серверу.

На данной странице представлена информация о лимитах, накладываемых на работу каждого сайта на Вашем аккаунте.

1. Все поступающие к Вашему сайту запросы обрабатываются в первую очередь легким веб-сервером Nginx, одновременно запросы поступают на два физических сервера. Каждый Nginx принимает 16 запросов в секунду к каждому сайту. В случае если количество запросов превышает это значение, они выстраиваются в очередь на обработку.
Для статических файлов (картинки, js-скрипты, mp3-файлы, архивы, видео и другой, обычно неизменяемый контент) размер очереди составляет 200 запросов, для запросов к HTML и PHP-страницам - 100 запросов.
Запросы, которые поступили к уже "заполненной" очереди сайта, отбрасываются и возвращается ответ с кодом ошибки 503 "Service Temporarily Unavailable".

2. Nginx передает запросы к веб-серверу Apache, одновременно запросы к Вашему сайту обрабатывают несколько физических серверов, приведенное ограничение действует для каждого сервера отдельно. Apache удерживает не более 10 активных подключений с одного IP-адреса (ограничение не распространяется на файлы картинок). В случае превышения этого ограничения сервер вернет ответ с кодом ошибки 503 и текстом "С Вашего IP адреса [IP-адрес посетителя] превышена частота запросов к сайту".
Страница автоматически обновится через 30 секунд.

3. Дополнительно действует ограничение на количество одновременно работающих процессов Apache на каждом физическом сервере.
Число процессов веб-сервера соответствует предельной допустимой нагрузке на CPU в соответствии с выбранным тарифным планом:
25% и более - 5 процессов Apache;
20% - 4 процесса Apache;
15% - 3 процесса Apache;
10% - 2 процесса Apache;
менее 10% - 1 процесс Apache.
Если это значение превышено, сервер вернет ответ с кодом ошибки 503 и текстом:
"Для сайта [site.ru] превышено количество одновременных запросов. Пожалуйста обновите страницу".
Страница обновится автоматически через 30 секунд.

Для увеличения скорости отдачи содержимого страниц и снижения нагрузки в Вашей группе серверов на уровне Nginx настроено кэширование статических данных (картинки, js-скрипты, mp3-файлы, архивы, видео и другой, обычно неизменяемый контент).
Для запросов с кодами ответа веб-сервера 200, 301, 302 и 304 время кеширования составляет 12 часов, результат с остальными кодами ответа не кешируется.

Запросы, которые прошли HTTP-авторизацию, не кэшируются (выставлен заголовок HTTP-Authorization).
Запросы, в которых присутсвует заголовок "Pragma: no-cache" (во всех современных браузерах он подставляется автоматически по нажатии клавиш "Ctrl+F5" или "Ctrl+r" ), пропускаются мимо кэша, одновременно обновляя содержимое кэша.

Для того чтобы переопределить время хранения кэша необходимо наличие заголовка X-Accel-Expires в ответе веб-сервера.
Установить его можно двумя способами:
через файл .htaccess:
Header add X-Accel-Expires 3600

или в коде php-скрипта:
header("X-Accel-Expires: 3600");

3600 здесь - количество секунд, по прошествии которых страница, сохраненная в кэше, считается устаревшей. Очередной запрос к странице обновит ее в кэше.

Если на время разработки или тестирования кэширование необходимо отключить - задайте это значение в 0 и обновите кэш через браузер нажатием "Ctrl+F5".
По окончании работ не забудьте вернуть настройки в состояние, когда кэширование статики включено. Это существенно увеличивает скорость работы Вашего сайта, а так же существенно увеличивает количество посетителей, которое не будет приводить к превышению описанных выше ограничений.

Здравствуйте.

30 декабря около 5 утра в работе оборудования, обслуживающего Ваш аккаунт, был зафиксирован серьезный сбой на одном их хранилищ данных, которое построено на файловой системе ZFS и работает на операционной системе Oracle Solaris. Сразу после сбоя файловая система была смонтирована в режиме "только для чтения" с целью сохранения данных и их копирования на другой носитель информации. Сайты, для работы которых требуется возможность записи на диск могли работать некорректно или не работать совсем. Всвязи с тем, что почта фактически хранится в домашей директории пользователей она также не работала. 5 января в 1 час ночи нашим инженерам удалось восстановить нормальную работу хранилища без пересоздания файловой системы. Сегодня 8 января в 4:38 вновь произошел сбой в работе хранилища. Для устранения последствий сегодняшней аварии и с целью минимизации риска повторного возникновения подобной ситуации нашими инженерами принято решение о пересоздании файловой системы и последующем восстановлении данных из резервной копии. В связи с этим обслуживание Вашего аккаунта будет приостановлено.
Файлы Вашего аккаунта будут восстановлены на состояние 30 декабря. Из-за восстановления большого объема данных, время простоя может составить от 2 до 3 суток.

Приносим свои извинения за доставленные неудобства и надеемся на Ваше понимание.

aii:
Глюк алгоритма скорее всего

Vitkus:
Они все сделаны под копирку.
фантастика:)