|
|
 
|
|
|
Превышение лимита на использование системных ресурсов?
Введение. В данной статье речь пойдет о так называемом «превышении лимита на использование системных ресурсов» или проще говоря «перегрузках» создаваемых аккаунтами пользователей, в ходе данного материала мы ответим на следующие вопросы: - что такое перегрузка? - почему блокировка? - откуда они берутся? - анализ перегрузки? - как с ними бороться? Основным принципом виртуального хостинга или правильнее: «разделяемого» (от англ. гл. share – разделять, shared - общий) является предоставление свободных ресурсов без каких-либо ограничений, любому процессу в системе. Процессом в системе может быть любая запущенная программа, вызываемый скрипт, запрос в базу данных, подключение по ftp,отправляемое получаемое письмо и много другое, таким образом все в системе представлено в виде процессов, каждый из которых потребляет определенное количество ресурсов от центрального процессора(ов) сервера, а так же оперативную память, пропускную способность канала и что немаловажно пропускную способность дисковой подсистемы (ввод/вывод). В один и тот же момент времени процессам, как правило необходимы разные ресурсы, так например один процесс может ожидать чтения данных с дисков, в то время как другой рассчитываться процессором (CPU), третий и вовсе находится в спящем состоянии ожидая действий из вне, такой подход работы позволяет размещать более чем одного пользователя на сервере существенно снижая конечную стоимость для клиентов, именно поэтому shared-хостинг стоит в разы дешевле VPS и выделенных серверов и именно поэтому ресурсы не могут быть ограничены принудительно. Что же такое перегрузка? Перегрузка - это состояние системы, при котором возникает гонка за свободными ресурсами между процессами. В основном перегрузка выглядит, как монопольный захват имеющихся ресурсов одним или несколькими процессами на длительный срок, в результате чего остальные процессы вынуждены выстраиваться в очередь, далее все напоминает лавину, или снежный ком, так как в очередь так же попадают и системные процессы, что в результате вызывает замедление работы всей системы, более того если никак не вмешиваться, то возможна ситуация, когда система полностью перестает отвечать на запросы. Вот почему так важно не допускать подобных перегрузок, так как это не только мешает другим, но и в целом оказывает пагубное влияние на производительность. Почему применяется блокировка? Существует несколько видов блокировки: 1. Автоматическая блокировка веб-сайтов. При этой блокировке вместо сайта устанавливается информационная страничка-заглушка с сообщением о временной блокировке. Письма с детализацией в данном случае не отправляется, сама блокировка временный характер и редко превышает 15 минут. В этом режиме cPanel/ftp/почта и другие сервисы доступны, поэтому если Вы увидели подобную заглушку на своем сайте, это первый признак о том, что с аккаунтом не все в порядке и следует вмешаться. 2. Полная блокировка аккаунта. Не смотря на то, что мы всегда стараемся сначала отправлять уведомления с детализацией, пока ситуация еще исправима, но к сожалению это не всегда возможно, по следующим причинам: - пользователь вовремя не реагирует, а перегрузки продолжаются - длительный характер перегрузок - создаваемая перегрузка очень сильная и есть угроза стабильности системы Единственным вариантом в этих случаях является полная блокировка аккаунта. Внимание:не рекомендуется указывать доверительный email с доменом расположенным на том же аккаунте, так как при его блокировке вы не сможете получить письмо с детализацией, не узнаете причину и не сможете вовремя отреагировать. В случае тотальной блокировки следует обращаться в нашу службу технической поддержки через доверительный email или виртуальный офис. При этом Вам может быть предоставлен ftp/cPanel доступ для устранения причин перегрузки. Откуда берутся перегрузки? Причин появления перегрузок множество, в основном это: - Низкое качество кода, плохая архитектура движка, не оптимизированные скрипты, тяжелые запросы к БД. - Повышенная активность поисковых систем, ботов и т.п. - Высокая посещаемость Первый случай является самым частым, к сожалению множество доступного для анализа кода оставляет желать лучшего, это касается даже коммерческих CMS, так как во главу угла таких систем поставлена вовсе не производительность, а удобство работы, быстрота развертывания и добавления контента, за что и приходится расплачиваться дополнительными ресурсами. Второй случай так же весьма распространен, так как сайты находятся в публичном доступе и регулярно индексируются различными поисковыми системами, сканируются вирусными ботами в поисках уязвимостей на страницах, атакуются ими же с разными целями, полностью зеркалируются программами многопоточной загрузки и наконец посещаются обычными посетителями. Третий случай встречается реже и при исключении первых двух является фактом нехватки ресурсов. Анализ перегрузки? Прежде чем бороться надо понять причину, а для этого необходимо проанализировать детализацию перегрузки высылаемую по почте, журналы доступа у сайту, можно так же замерить процессы самостоятельно с помощью предлагаемого скрипта, провести анализ БД по средствам phpmyadmin и т.д. Далее мы рассмотрим пример присылаемой детализации перегрузки, поскольку перегрузки могут быть по различным ресурсам то и детализация может выглядеть по иному, мы рассмотрим лишь самый частый случай перегрузка центрального процессора PHP скриптами: В начале любой детализации находится имя аккаунта, которое совпадает с логином в cPanel, а так же указана суммарная нагрузка создаваемая всеми процессами аккаунта, по основным параметрам: Аккаунт: username Кол-во запущенных процессов: 9 Использование процессора(ов): 76.2 % Использование оперативной памяти: 0.1 % Детализация процессов состоит из множества значений и информации о каждом процессе: Детализация процессов: cpu: 26.1% mem: 0.1% rss: 2.2M uptime: 00m 00s cpu time: 00m 00s i/o: 0.0% (exe: /usr/bin/php) (cwd: /home/username/public_html/stockgallery) (cmd: /usr/bin/php /home/username/public_html/stockgallery/banner.xml.php) cpu: 12.5% mem: 0.0% rss: 2.0M uptime: 00m 00s cpu time: 00m 00s i/o: 0.0% (exe: /usr/bin/php) (cwd: /home/username/public_html/stockgallery) (cmd: /usr/bin/php /home/username/public_html/stockgallery/banner.xml.php) cpu: 8.9% mem: 0.0% rss: 2.0M uptime: 00m 00s cpu time: 00m 00s i/o: 0.0% (exe: /usr/bin/php) (cwd: /home/username/public_html/stockgallery) (cmd: /usr/bin/php /home/username/public_html/stockgallery/banner.xml.php) cpu: 8.6% mem: 0.0% rss: 1.2M uptime: 00m 00s cpu time: 00m 00s i/o: 0.0% (exe: /usr/bin/php) (cwd: /home/username/public_html/stockgallery) (cmd: /usr/bin/php /home/username/public_html/stockgallery/banner.xml.php) cpu: 7.6% mem: 0.0% rss: 2.0M uptime: 00m 00s cpu time: 00m 00s i/o: 0.0% (exe: /usr/bin/php) (cwd: /home/username/public_html/stockgallery) (cmd: /usr/bin/php /home/username/public_html/stockgallery/banner.xml.php) cpu: 7.1% mem: 0.0% rss: 843K uptime: 00m 00s cpu time: 00m 00s i/o: 0.0% (exe: /usr/bin/php) (cwd: /home/username/public_html/stockgallery) (cmd: /usr/bin/php /home/username/public_html/stockgallery/banner.xml.php) cpu: 2.5% mem: 0.0% rss: 1002K uptime: 00m 00s cpu time: 00m 00s i/o: 0.0% (exe: /usr/bin/php) (cwd: /home/username/public_html/stockgallery) (cmd: /usr/bin/php /home/username/public_html/stockgallery/banner.xml.php) cpu: 1.5% mem: 0.0% rss: 347K uptime: 00m 00s cpu time: 00m 00s i/o: 0.0% (exe: /usr/bin/php) (cwd: /home/username/public_html/) (cmd: /usr/bin/php /home/username/public_html/index.php) cpu: 1.4% mem: 0.0% rss: 698K uptime: 00m 00s cpu time: 00m 00s i/o: 0.0% (exe: /usr/bin/php) (cwd: /home/username/public_html/) (cmd: /usr/bin/php /home/username/public_html/stockgallery/banner.xml.php) CPU: Обозначает потребление ресурсов центрального процессора(ов) и измеряется в %, при этом суммарное значение по нагрузке на центральный процессор может превышать 100%, т.к. На технических площадках могут использоваться многоядерные и многопроцессорные системы, таким образом задача запущенная на 2-х ядерном процессоре может занимать 200% и даже 800% в случае с 4-х процессорными 2-х ядерными системами. MEM: Обозначает потребление оперативной памяти и измеряется в %, в целом превышение по оперативной памяти редкое явление. I/O: Обозначает потребление дисковой полосы пропускания и измеряется в % А так же ряд параметров несущих дополнительную информацию: rss - размер процесса в оперативной памяти, измеряется в байтах exe - Исполняемый файл cmd - Командная строка cwd - Текущая директория процесса По PHP процессам так же существует статистика частоты их вызовов и выглядит она следующим образом: PHP скрипты за последние 5 минут: 1434 times /home/username/public_html/stockgallery/banner.xml.php 50 times /home/username/public_html/index.php 3 times /home/username/public_html/phpshop/admpanel/product/action.php 2 times /home/username/public_html/phpshop/admpanel/catalog/adm_catalogID.php 2 times /home/username/public_html/phpshop/admpanel/catalog/tree.php 1 times /home/username/public_html/index.php 1 times /home/username/public_html/phpshop/admpanel/catalog/admin_cat_content.php В конце каждой детализации обязательно проставлен временной штамп: Время фиксации: Чтв 02 Июля 22:37 Исходя из разобранной детализации можно сделать вывод, что перегрузка вызвана частым запуском скрипта banner.xml.php но что бы глубже понять причину необходимо заглянуть в «необработанные журналы доступа» через cPanel проанализировав откуда вызывался такой скрипт, а так же изучить исходный код сайта/движка. Помимо приведенной в этой статье детализации могут быть указаны и другие параметры: - запросы к веб-серверу: Domain usersite.ru: 1 times GET /wp-content/plugins/wp-codebox/css/codebox.css HTTP 1.1 1 times GET /tag/cookies/ HTTP 1.1 1 times GET /images/ban88.gif HTTP 1.1 1 times GET /tag/devochki-v-stringah/?nggpage=2&pid=125 HTTP 1.1 1 times GET /wp-content/plugins/wp-postratings/images/loading.gif HTTP 1.1 1 times GET /img/banner468.gif HTTP 1.1 1 times GET /ban/3.gif HTTP 1.1 1 times GET /wp-content/plugins/wp-codebox/js/codebox.js HTTP 1.1 96 times GET / HTTP 1.1 - Запросы к MySQL: Медленные SQL запросы (если есть): DB: username_db Time: 165s count: 1 SELECT COUNT(t.id) AS cnt FROM modul_tovar AS t LEFT JOIN tovar_card AS c ON t.id = c.card_tid, razd_rus AS r WHERE t.in_stock = \'S\' AND r.vip != \'S\' AND r.cat_id = t.r_id Как мне самостоятельно узнать текущую нагрузку? Достаточно скачать Perl скрипт выводящий список процессов Вашего аккаунта. Распакуйте и сохраните скрипт в каталог например: public_html, обязательно убедитесь, что при загрузке скрипта в FTP-клиенте был выбран ASCII режим (при загрузке распакованного файла). Если файл передается в архиве ASCII режим не нужен. http://www.belihost.ru/proc.zip Далее следует создать условия для корректного запуска скрипта: 1. Права у файла должны быть 755, могут быть изменены через файловый менеджер cPanel или поддерживающий chmod ftp-клиент 2. В папке где расположен скрипт должен быть разрешен запуск CGI для этого в файле .htaccess должна быть запись: Options +ExecCGI Теперь, если Вам понадобится список процессов Вашего аккаунта в любой момент времени заходим по ссылке http://ваш_домен/proc.pl Как бороться с перегрузками? Перед тем как указать способы борьбы с перегрузками необходимо развеять часто встречающийся миф — посещаемость сайта не является показателем создаваемой им нагрузки, в некоторых ситуациях перегрузку может вызвать всего 1 скрипт запущенный через планировщик cron при этом на сайте будет 0 посетителей, а на счетчиках 0 хитов, так же известны случаи, когда плохо написанный запрос к БД способен вызвать перегрузку соизмеримую сайтами посещаемостью в 5000 уникальных ipи т.п. Поскольку единого средства борьбы с перегрузками не существует, перечислим лишь некоторые из них: 1. Оптимизация исходного кода. Не пытайтесь проводить оптимизацию исходного кода самостоятельно, так как это требует не малого опыта и еще большей практики в данном вопросе. Иногда для улучшения ситуации достаточно поправить громоздкую функцию, а иногда и вовсе отказаться от каких-либо модулей/движков/скриптов, бывали случаи когда профессионалы находили скрипты вызывающие циклическую рекурсию в результате которых скрипт переставал отвечать потребляя все больше и и больше ресурсов и его замена на аналог давала положительные результаты как в скорости работы, так и по ресурсоёмкости. 2. Оптимизация структуры БД и запросов к ней. Так же опытный программист со знанием SQLможет найти узкое место в запросах и решить его построением удачных индексов для БД или переписав сами запросы сократить время их выполнения, известны случаи когда выборка по определенным запросам без индексов занимала более 100 секунд времени, а после построения индексов это время сокращалось до 3-5 секунд. 3. Кэширование. Данный вид борьбы с перегрузками является палкой о двух концах, с одной стороны кэширование может помочь снизить нагрузку на CPU, так как не надо будет сотни раз генерировать один и тот же код, но с другой стороны если кэш размещается на диске, то это может вызвать нагрузку на дисковую подсистему или наоборот если кэш располагается в оперативной памяти, то это может существенно повысить её расход. Применяйте кэширование с осторожностью, там, где оно действительно необходимо. 4. Генерация статического контента. Если на ваш сайт поступает большое количество однотипных запросов, разумным решением будет перевод части посещаемых страниц на статику, так например вывод главной страницы сайта средствами PHP содержит в себе некоторое количество запросов к БД (например вывод новостей), вызов разного рода PHP функций, потребление ресурсов CPU для расчетов, а так же загрузку разных библиотек в оперативную память, в то время, как отдача статической страницы в сотни раз быстрее и ресурсосберегающая, так как требует только одну операцию чтения с диска и немного времени веб-сервера, что бы отдать её браузеру. Для того, что бы статическая страничка регулярно обновлялась, можно добавить задание в планировщик cron, которое будет генерировать статику из динамического скрипта раз в 5-10 минут, что обычно более чем достаточно. Как показывает практика: сайт с посещаемостью в всего-лишь в 50-70 человек в день на обычной CMS едва справлялся с нашествием поисковых ботов, а после генерации статической страницы, сайт мог обслуживать до 7000 посетителей не вызывая превышения лимитов, но конечно не каждый сайт может быть переведен на статику, поскольку все зависит от его специфики и характера запросов к нему. 5. Отказаться от всего лишнего. Такой метод снижения нагрузки создаваемой аккаунтом можно проводить самостоятельно, из практики - высокую нагрузку вызывают разного рода веб-чаты, гостевые книги, а так же разного рода модули и дополнения, особенно это касается таких CMS как WordPress, Joomla, Drupal и т.п. 6. Понижение активности ботов. В данном случае пользователь, как правило сам провоцирует перегрузку регистрируя сайт по множеству каталогов, продавая рекламные ссылки (например SAPE),а так же не устанавливая ограничений для поисковых ботов. В случае с поисковыми системами их интенсивность можно регулировать путем установки переменно crawl-delayв файле robots.txt,что бы узнать подробнее следует обратиться к документации непосредственно поисковых систем, а так же сайт http://robotstxt.org.ru/. В случае с SAPE можем посоветовать использовать экстенсивные пути решения (п.9) или попытаться обратится непосредственно к разработчикам для создания какого-либо механизма регулирования активности. 7. Атаки отказа в обслуживании. В данном случае наша компания Вам не сможет помочь, так как защита от подобных атак весьма дорогостоящее решение и как правило DDoS-атаки спровоцированы размещением нелегального или политического контента. Единственным решением при данной перегрузке может быть только переезд на хостинги с защитой от DDoS-атак или отказ от размещения провокационного контента. 8.CGI-скрипты. Отдельное и редкое явление это перегрузка CGI-скриптами (perl/python/shell), в этом случае существует возможность их запуска с пониженным приоритетом через команду nice.Так же имеет смысл понизить интенсивность запуска cron-заданий если таковые имеются. 9. Наращивание производительности (экстенсивный путь). Это самый простой способ решения проблем перегрузок, он рекомендуется только в том случае когда какая-либо оптимизация не представляется возможной или уже проведена и не принесла нужного эффекта. К данному методу относится разделение сайтов, путем покупки нескольких аккаунтов и вынесения разных частей сайта(ов) на них, таким образом можно разделять два три и более сайтов друг от друга и в сумме они не уже будут приводить к превышению лимитов. Так же возможен вариант отделения форума от основного сайта, таким образом нагрузка на сайт резко снижается и даже при каких-либо работах или блокировке сайт остается работать. Если разделение не применимо и ваш ресурс очень посещаем при максимальном уровне оптимизации, выход может быть только один — переход на решения с бОльшими ресурсами, такими как VPS или выделенный сервер. |
|||||||||||||||||||||||||||||
 |
Все права защищены. 2004-2014 © ООО "БелиХОСТ" |
