Определяем загруженность сервера из PHP


Содержание

Мониторинг загрузки процессора сервера php-скриптом

6 ответов

1. Вариантов полагаю много, на сколько фантазии хватит.
2. В зависимости от реализации, но по любом только под юзвером делать(дать ему права если требуется)
3. Логично предположить что нет!
4. Как угодно, все зависит как вы это будете реализовывать

первое что упало в ум: распарсить top, вот.

Не понял, это что?

Ага, нашел man top Я в unix мало, что знаю, но подумаю.

Определяем загруженность сервера из PHP

Начнем с получения данных. Для этого необходимо подключить модуль mod_status. Он отслеживает работу сервера и показывает данные в виде обычной html страницы. С его помощью можно узнать:

  • количество процессов, выполняющих обработку запросов;
  • количество процессов, которые находятся в состоянии ожидания;
  • состояние каждого процесса, число обработанных им запросов и переданных данных;
  • общее количество запросов и переданных данных;
  • время работы сервера (запуск, перезапуск и общее время работы (uptime));
  • общая статистика: среднее число запросов в сек, байт на запрос, байт в сек;
  • использование CPU каждым процессом отдельно и apache’ем в целом в данный момент;
  • хосты и их запросы, которые обрабатываются в данный момент.

Переходим к настройке.

  1. Подключаем модуль. Для этого в файле httpd.conf снимаем комментарий со строки

    И открываем доступ к статистике. Добавляем в httpd.conf следующие строки

    Примечание. Здесь мы разрешили доступ к статистике только для адреса 127.0.0.1 (localhost). Для тестирования удаленного сервера вам нужно будет эту настройку изменить.

  2. Перезапускаем apache.
  3. Теперь можно просматривать статистику. Для этого вводим в браузере URL http://localhost/server-status или, если вы хотите, чтобы страница обновлялась автоматически — http://localhost/server-status?refresh=15 (вместо цифры 15 ставите задержку в секундах).

    Есть ещё один вариант страницы с этими же данными: http://localhost/server-status?auto&refresh=3

    Как видите, данные мы получили, но анализировать их, глядя на стандартную страницу не очень удобно.

    Например, на скриншоте показано состояние процессов apache:

    Символ подчеркивания означает, что процесс ожидает соединения, буква «W» — отправка ответа, точка — открытый слот без процесса.

    Примечание. Скриншот сделан для локального севера, поэтому единственный процесс, который выполняет отправку запроса — это тот, который формирует страницу со статистикой.

    Кроме того, если у вас данные постоянно обновляются (используется параметр refresh), то визуально оценить изменения будет очень сложно.

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

    В качестве примера такого скрипта рассмотрим Visualize Apache Server Status (распространяется под LGPL лицензией).

    Диагностика ресурсов сервера

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

    Чтобы этого не произошло, нужно следить за параметрами сервера. За какими и как – расскажем в этой статье.

    Как посмотреть общую нагрузку на сервер

    Отслеживать нагрузку на ОС WIndows позволяет «Диспетчер задач», в Linux свои инструменты.

    Самая распространённая утилита мониторинга – top.

    Top показывает среднюю нагрузку на сервер (Load Average) в течение 1, 5 и 15 минут. В идеале она должна быть меньше, чем количество ядер процессора. Например, LA 4 при четырёх ядрах означает: каждое ядро загружено на 100% — стоит снизить нагрузку.

    Далее последовательно указаны самые «тяжёлые» процессы, сколько они потребляют оперативной памяти и CPU.

    Другая утилита – atop – подсвечивает высокую нагрузку красным.

    Схожий функционал предоставляет nmon – при нажатии определённых клавиш выдаёт графики нагрузки: процессор (с), чтение/запись диска (d), сеть (n) и память (m) и т. д. Список нужных клавиш будет отражен при запуске программы — в приветственном окне.

    Как посмотреть нагрузку детально

    Начнём с дисковой памяти — её не покажут перечисленные утилиты.

    ISPmanager не открывается, а на сайтах возникает ошибка (например, Unable to connect to the database: Could not connect to MySQL), однако сам сервер доступен и пингуется. Скорее всего, закончилось место на диске, проверить это легко:

    Команда df -h покажет все примонтированные разделы и сообщит, сколько места занято, а сколько свободно. Картина на скрине сигнализирует – место на диске нужно срочно освобождать:

    du -hs /* отобразит размер всех директорий:

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

    Также можно освободить место через очистку временных файлов – логов, кеша, php-сессий.

    С оперативной памятью по-другому – она динамична. Процессы запускаются, отработав, умирают, и показатели меняются ежесекундно. Оценить обстановку поможет free -m.

    В строке -/+ buffers/cache увидим показатели used и free – использованная и свободная память.

    По первой строке можно определить объем доступной пользователю памяти. Для этого сложите параметры free и cached, так как закешированая память также может быть использована приложениями.

    Определить, какие процессы занимают память, поможет такой однострочник:

    Если на первый взгляд ресурсов сервера хватает, но все равно чувствуются задержки, проверьте сетевой канал.

    Всем VDS на хостинге предоставлен стомегабитный канал, хватает его или нет покажет iftop, запущенный с ключом -m 100M.

    На скриншоте видна белая полоса — это доступная ширина канала. Больше, чем наполовину, она занята процессом загрузки с серверов Яндекс. Когда полоса доходит до правой части экрана, весь доступный канал забит — необходимо увеличить пропускную способность сервера.

    Также показатели трафика на VDS покажет VMmanager — раздел “Нагрузка VM”.

    На графиках видно, сколько трафика прошло через сервер за определённый период времени.

    Как увидеть нагрузку через браузер

    Есть мониторинги нагрузки, например, Munin:

    Если на сервере установлена панель ISPmanager, в ней также можно анализировать нагрузку по процессору, памяти, занимаемому дисковому пространству:

    В списке самых прожорливых процессов Apache и Mysql

    Если нагрузку создаёт Apache, то на сервер приходит множество запросов по 80, 443 портам. Для снижения нагрузки рекомендуется использовать на сервере Nginx, включить сжатие и кэширование статичных ресурсов.

    Возможно, это легитимная посещаемость, поисковые боты или DDOS-атака. В случае поисковых ботов можно сократить время между запросами к серверу в учетной записи Яндекс.Вебмастер и Google Webmasters Tool. В случае атаки настройками не обойтись — необходимо подключить дополнительную защиту.

    Ресурсы потребляет Mysql – проведите оптимизацию настроек службы с помощью Mysqltuner.

    Также стоит по возможности оптимизировать SQL-запросы к базам данных. Проверьте их через отображения списка текущих операций Mysql — команда show full processlist.

    И обратите внимание на показатель WA в top: значение больше 20 говорит о том, что информация не успевает записываться на диск – необходимы диски SSD.

    Определяем загруженность сервера из PHP

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

    Обычно о превышении нагрузки веб-мастера узнают от своих хостеров, которые строго регламентируют и контролируют процесс потребления процессорного времени и на уровне тарифного плана задают ту допустимую нагрузку, которую может создавать аккаунт (обычно она измеряется в % от некоторого разрешенного значения или в CP/процессорных минутах).

    Хостер старается равномерно распределить ресурсы процессора среди всех клиентов сервера. Если чей-то аккаунт хостинга будет “съедать” 90% процессорных ресурсов, то остальным достанется только 10%. Поэтому в подобных случаях владельцу аккаунта, превышающего лимиты, придет предупреждение. А при систематических нарушениях аккаунт блокируется, чтобы не мешать работе других сайтов, расположенных на том же сервере. И это, отнюдь, не попытка “развести” клиента на более дорогой тариф, как думают некоторые веб-мастера, поскольку не хостер виноват в том, что сайту с некоторого времени потребовалось больше ресурсов.

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

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

    Внешние факторы

    Внешние факторы, создающие высокую нагрузку – это все то, что не зависит от настройки хостинга, работы скриптов и процесса администрирования сайта. Это результат внешних запросов к сайту различными сервисами, ботами или другими сайтами. Факторов достаточно много.

      Сканирование сайта на уязвимости, поиск «чувствительных файлов», поиск панели администратора.
      Любой сайт, страницы которого проиндексированы в поисковой системе, может стать “мишенью” для хакеров и ботов, его ежедневно кто-то будет сканировать, искать “дыры”, пытаться взломать. Остановить этот процесс невозможно, но можно ему противодействовать.
      Запросы к сайту, особенно если они выполняются интенсивно и методом POST, потребляют много процессорных ресурсов. Поэтому процесс сканирования сайта внешним сканером выражается в росте нагрузки. Если в результате сканирования злоумышленник обнаружит уязвимость или вариант взлома сайта, то вероятнее всего на сайт он загрузит вредоносный код или совершит какие-то деструктивные действия. Если никаких проблем безопасности в результате сканирования выявлены не будут, то сайт продолжит работать в штатном режиме, а нагрузка вернется к нормальному значению. До следующего сканирования…

    Подбор пароля от админ-панели сайта (брутфорс-атака).
    Одной из популярных атак, целью которой является получение административного доступа с помощью перебора популярных комбинаций логинов/паролей администратора, является атака вида «брутфорс». Хакерский бот использует специальный словарь с TOP1000 популярных комбинаций (admin/admin, admin/123456,…) и пробует зайти с ними в административную панель сайта. Сам процесс перебора повышает нагрузку, так как на страницу административной панели идут постоянные обращения, причем запросы выполняются ресурсоемким методом POST.

    Массовая регистрация пользователей или массовая отправка спама через незащищенные формы обратной связи.

    Часто на сайтах используются формы обратной связи или формы регистрации пользователей со слабыми механизмами защиты от ботов. Хорошо, если на форме установлена хоть какая-то “капча” из серии “докажи, что ты не бот”. Если сайт попал в базу спаммеров, а «капчи» или другого механизма защиты от “http флуда” нет, то начинается массовая регистрация пользователей со спам-профилями, отправка почты через форму и т.п. Все это создает нагрузку на хостинг, и кроме того, может провоцировать спам-рассылку, за которую хостинг-компания отключает почтовый сервис или блокирует сайт полностью.

    Следует отметить, что в настоящий момент все простые защитные механизмы без труда обходятся современными ботами, поэтому необходимо сразу устанавливать что-то серьезное, например, Google Recaptcha2.

    Индексирование сайта поисковыми ботами.

    Иногда при достаточно большом поисковом индексе (когда в поисковую базу Яндекса и Google попадает большое число страниц), процесс переиндексации может занимать длительное время и создавать большую нагрузку на сервере. Если на вашем сайте всего десяток страниц, вы также можете столкнуться с подобной проблемой, например, если сайт был взломан и на нем размещен дорвей на 50 000 страниц, которые попали в поисковую выдачу. Или поисковый индекс мог заспамить конкурент, который воспользовался ошибками в работе скриптов вашего сайта. Вариантов здесь масса.

    Граббинг и скраббинг контента.

    Владельцам уникального контента стоит обеспокоиться проблемой скачивания контента с сайта (скраббинг и граббинг). Этим могут промышлять специальные боты, которые обходят страницы сайта и копируют тексты и картинки, размещенные на сайте, с целью создания клонов. Если процесс сканирования вашего сайта регулярный, а страниц у сайта — много, это может создавать внушительную нагрузку на хостинг.

    Импортирование данных (фиды, выгрузка товарных позиций).

    Часто e-commerce ресурсы используют механизм обмена данными с внешними сервисами. Например, из интернет-магазинов может выгружаться список товарных позиций, в них могут загружаться данные из 1С, у новостных сайтов может происходить регулярный экспорт новостных фидов и пр. Если контент не статический, то каждый такой запрос будет создавать высокую нагрузку на сервер.

  4. Использование картинок или ссылок на ваш сайт.
    Одним из неочевидных моментов, создающих нагрузку, может быть размещение ссылки на сайт или использование изображения с сайта на более посещаемом ресурсе. Один из источника проблемы – это так называемый “хабраэффект”, когда сайт не справляется с потоком посетителей с более популярного ресурса. Второй вариант – когда кто-то (или вы сами) разместили на посещаемом блоге (например, в комментариях) картинку со своего сайта, и она загружается у каждого посетителя и создает нагрузку на ваш хостинг. Особенно это может создавать серьезные проблемы в том случае, если картинка генерируется скриптами (например, масштабируется с помощью скриптов timthumb/phpthumb).
  5. Атаки на другие сайты (например, уязвимость в xmlrpc.php).

    Часто сайты, содержашие уязвимости, используются хакерами для проведения атак на другие ресурсы. Иногда для этого злоумышленнику даже не требуется взламывать сайт. Например, с этой проблемой могут столкнуться владельцы не самых свежих версий WordPress (атака через файл xmlrpc.php). Ваш сайт в данном случае будет выступать промежуточным звеном, а работа скриптов сайта создавать большую нагрузку на сервере.

    DDOS-атака
    Если на сайт идет DDOS-атака, то без подключения специальных технических средств, проксирующих трафик (услуга хостинга или сервиса защиты от DDOS), справиться с ней не удастся. Не заметить DDOS достаточно сложно. Из-за того, что на сервер будет создаваться огромная нагрузка, хостер может поступить по-разному: предложить услугу защиты от DDOS, перенести сайт на другой сервере или полностью заблокировать (отключить) сайт. Поэтому для защиты от DDOS желательно иметь заранее заготовленное решение, чтобы при возникновении проблемы оперативно ее решить.

    Рост посещаемости

    Если трафик органический, то это самая позитивная причина роста нагрузки. Значит пришло время масштабировать сайт и задуматься об оптимизации скриптов, рассчитанных на более высокую посещаемость.

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

    В результатах анализа следует посмотреть TOP 20 запросов методом POST, TOP 20 запросов методом GET/HEAD, TOP 20 IP адресов по числу хитов, TOP 20 ссылающихся страниц по числу хитов. Все это позволит выявить источник и тип трафика, а также точки входа на сайт или скрипты, которые вызываются чаще всего. Скорее всего они и будут причиной высокой нагрузки.

    Для снижения нагрузки при внешних атаках или интенсивных запросах в большинстве случаев достаточно включить защиту от http флуда (например, классический “куки на клиенте + редирект с проверкой”) или подключить сайт к сервисам проксирования трафика, которые будут блокировать опасные или особо активные запросы, а хорошие и легитимные — пропускать. Кроме того, статический контент (картинки, скрипты и стили) будут отдаваться не с вашего сайта, а с CDN-серверов, что также существенно снизит нагрузку.
    Можно попробовать подключить кэширующий плагин в CMS или кэширующий сервис на хостинге, но в случае внешних факторов, влияющих на нагрузку, это может и не помочь.

    Внутренние факторы

    Ко внутренним факторам можно отнести все то, что влияет на производительность сайта на уровне скриптов и настроек. То есть то, что поддается контролю со стороны веб-мастера (владельца сайта).

      Неоптимизированные скрипты и разросшаяся база данных.
      Из-за неграмотно спроектированной архитектуры веб-приложения или неэффективной реализации скриптов неопытными разработчиками возможен случай, когда простое открытие стартовой страницы или отображение результатов поиска на сайте может серьезно нагружать сервер. А рост объема базы данных (например, увеличение числа товарных позиций) с каждым обновлением сайта будет его все больше замедлять, увеличивая нагрузку на хостинг. Отдельные страницы сайта с большим числом информационных блоков могут отправлять по несколько десятков запросов к базе данных, многократно выполнять одни и те же операции с файлами, а иногда даже блокировать работу других элементов сайта. Мы часто сталкиваемся с подобной проблемой у интернет-магазинов, работающих на старой версии Joomla с плагином Virtuemart. В некоторых случаях при открытии страницы каталога выполняется более 100 запросов к базе данных.

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

    Внешние легитимные подключения к сторонним ресурсам
    Мало кто принимает во внимание нагрузку, которую создают подключения к внешним источникам информации (виджеты, информеры погоды и курса валют, новостные фиды и пр). Часто данные, которые загружаются с других сайтов, не кэшируются локально и в момент открытия страницы каждый раз происходит подключение и загрузка контента с другого сервера. Если по какой-то причине внешний источник перестает быстро отвечать, это повлияет на нагрузку и скорость загрузки основного сайта.

  6. Ошибки в работе скриптов
    При работе скриптов могут возникать ошибки, которые не отображаются посетителям, но записываются в лог веб-сервера или лог php. Если сайт посещаемый или ошибок много, это также может увеличивать нагрузку на хостинг. Чаще всего ошибки начинают генерироваться в момент переключения сайта на более свежую версию PHP, с которой скрипты не совместимы. Или когда обновляются не все компоненты сайта, и возникают конфликты между новым ядром CMS и старыми версиями плагинов.

Для анализа проблемы высокой нагрузки, вызванной внутренними факторами, требуется выполнить проверку сайта на наличие вредоносного кода (например, проверить сайт бесплатным сканером AI-BOLIT), и, если вредоносного кода не обнаружено, то выполнить профилирование работы скриптов с помощью модулей xhprof или xdebug.

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

Если же причина проблем в архитектуре сайта или ошибках, то поможет оптимизация сайта силами опытного веб-разработчика. Как одно из запасных решений для второго случая – это установка кэширующего плагина, который в некоторых случаях может снизить потребление процессорных ресурсов (нагрузки на хостинг) и ускорить работу сайта.

Продолжительность

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

Если на графике потребления процессорного времени вы видите разовый скачок, то не стоит волноваться. Он практически незаметен, не влияет на доступность сайта и не мешает “соседям” по хостингу. Хуже, если график длительное время ползет вверх или в течение нескольких дней показывает предельную (или превышающую лимит) загрузку процессора. Что делать в этом случае? Необходимо проводить аудит сайтов на аккаунте так, как это было описано выше, проверяя как внешние, так и внутренние факторы, вызывающие проблемы.

Высокая нагрузка на VDS/VPS: ищем и устраняем причины

Причин сбоя в работе сайта существует огромное количество. Неполадки могут возникнуть из-за резкого наплыва посетителей в больших количествах, хакерских атак. Существует также вероятность возникновения проблем по вине администрации самого сайта, к примеру, неправильные настройки сервера практически неизбежно приводят к плохому исходу. Вся нагрузка на VDS и VPS делится на 3 основных вида: нагрузка на диск, на оперативную память и на процессор. Также избыточная нагрузка на сервер может стать критичной из-за того, что тарифы хостинга имеют ограничение на количество открытых одновременно файлов и выполняющихся одновременно процессов.

Разберемся, по каким причинам чаще всего возникает повышенная нагрузка и как ее устранить.

Анализ работы сервера

Первым шагом на пути к определению нагрузки на VDS и VPS сервере будет проверка того, насколько хорошо функционирует этот сервер. Для этого существует достаточное количество инструментов.

NIX утилиты

Хорошее представление о работе сервера в определенный момент дает раздел статистики в панели управления. Но для более подробного ознакомления лучше воспользоваться консолью. В UNIX наиболее простым средством отслеживания работы сервера является команда top. Она дает развернутую информацию, в том числе в режиме реального времени. Обратить внимание надо на столбики с названиями COMMAND, %CPU, %MEM, load average и Mem В них содержится информация о выполняемой команде, проценте используемых ресурсов процессора в данный момент, о проценте используемой памяти, среднем времени процессов в очереди и о количестве свободной и используемой в данный момент памяти. Очень плохим знаком является рост load average свыше пяти.

Еще одной командой для проверки исполняемых процессов и потребляемых ресурсов является команда ps auxw. По запросу free-m вы получите информацию о свободной и используемой памяти. Воспользовавшись vmstat вы узнаете о процессах, их активности, а также памяти с свопинга.

Нагрузка на диск определяется при помощи:
— Команды top-mio в случае FreeBSD. Информацию о проценте загруженности диска процессом нужно смотреть в столбиках COMMAND и PERCENT.
— Команды iotop, если требуется узнат, какой процесс создает нагрузку на диск. В выведенной информации вы получите эту нагрузку в процентах.

Apache


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

Лог-файлы

Не всегда приходится иметь дело с приятно визуализированной запрашиваемой информацией. Иногда для получения более подробных данных бывает нужно почитать лог-файлы. Найти их можно по-разному, в зависимости от ОС вашего ресурса.

Причины нагрузки на сервер

Если при просмотре процессов сервера вы видите, что там находится много процессов от Apache, а также протоколов php-cgi, это может быть вызвано следующими факторами.

Некорректная настройка ограничений веб-сервера

Чтобы проверить правильность настроек, нужно обратить внимание на значения MaxClients и MaxSapreServers. Наилучшее их значение можно вычислить, воспользовавшись простой формулой: MaxClients = M*0.8/H, где M и H – общее количество памяти и ее же количество, которое потребляет один процесс веб-сервера.

Действующие их значения определяются в консоли с помощью top. Не стоит выставлять эти значения выше 10. Чтобы их ограничить, воспользуйтесь файлами:

  • Для Debian — /etc/apache2/apache2.conf
  • Для Centos — etc/httpd/conf/httpd.conf
  • Для FreeBSD — /usr/local/etc/apache22/extra/httpd-mpm.conf

Также стоит обратить внимание на то, что не стоит выставлять и слишком низкое значение этих параметров. Иначе запросы не будут выполняться вовремя и сервер будет выдавать ошибки. Поэтому необходимо, чтобы данное значение было оптимальным для вашего сервера.

DDos-атака на сайт

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

Высокая посещаемость проекта

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

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

Чтобы этого избежать, вы всегда имеете возможность ограничить доступ к своему сайту для всех ботов сразу или для каких-то определенных. Для этого нужно воспользоваться файлом robots.txt или .htaccess, в котором потребуется указать некоторые настройки. Делать это нужно в корне сайта или той директории вашего сайта, доступ к которой вы хотите ограничить. Настройки для файла robots.txt, запрещающие скачивать любые файлы, кроме страниц, начинающихся с «/cgi-bin», должны выглядеть так:

В .htaccesss подобная настройка может выглядеть следующим образом, если мы, например, разрешаем доступ только User-Agent,который начинается с Google :

AdminVPS осуществляет всю настройку за своих клиентов совершенно бесплатно по системе “Все включено”

Некорректная работа скриптов

Высокая нагрузка может быть вызвана также неоптимальным распределением ресурсов между скриптами сайта. Эту нагрузку можно узнать с помощью уже описанных выше модулей веб-сервера Apache. Если проблема высокой нагрузки заключается в основном в скриптах, их работу необходимо отладить. Для выполнения трассировки можно воспользоваться расширениями php: xdebug или xhprof. Также будет полезным обращение к их разработчику.

Часто для решения такой проблемы прибегают к установке Nginx с каким-нибудь php-кэшером, например, APC, связка которых позволяет получать статистику и кэшировать пользовательские запросы, увеличивая тем самым скорость отдачи информации.

Apache создает нагрузку на процессор

Данная проблема вызвана неправильной работой скриптов, которая описана в предыдущем разделе. Также проблема может быть связана с работой с аудио и видео файлами или с их сжатием. Проверьте работу скриптов и запретите сжатие.

Нагрузка на диск от MySQL

Чтобы хранить некоторые временные данные, в этой системе могут использоваться диски серверов. Такая ситуация складывается, если в буферах памяти недостаточно места. Обычно это происходит при выполнении сложных процессов. Чтобы решить эту проблему, нужно повысить объем информации в буферах в файле настроек my.cnf. Увеличение размера директив tmp_table_size и max_heap_table_size практически всегда снижает данную нагрузку. Сделать это можно и с использованием команды mysqladmin-i2 processlist–p.

Создание временных таблиц будет происходить, пока не устранены следующие условия:

  • наличие BLOB или TEXT столбиков;
  • при условии использования GROUP BY и DISTRICT размер колонки превышает 512 байт;
  • размер колонки в выводе SELECT превышает 512 байт

Нагрузка на процессор от MySQL

Здесь проблема, скорее всего, заключается в проблемных индексах или таблицах. Проверьте логи и таблицы при помощи php MyAdmin.

Нагрузка от почтового сервера

Такая проблема возникает в случае рассылки спама. Возможно, делать это ваш почтовый сервер заставляют вредоносные коды хакеров. Проверьте сообщения, стоящие в очереди на отправку. Используйте для этого команды mailq, exim–Mvb или воспользуйтесь логами:

  • Для exim: /var/log/exim/mainlog
  • Для sendmail: /var/log/maillog

Из-за чего может отсылаться спам:

  • ваш ящик был взломан;
  • ваш сервер был взломан и были загружены вредоносные скрипты, заставляющие почтовый сервер спамить;
  • ваши пользователи специально рассылают большое количество писем.

Нагрузка от DNS сервера

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

Нагрузка от процессов tar и gzip

Чтобы избежать нагрузки данного типа, отмените резервное копирование файлов вашего сайта, если оно идет, ведь именно с ним связана работа этих процессов. Постарайтесь выполнить его в другое время, когда нагрузка на сервер со стороны других факторов будет минимальной.

Нагрузка от неизвестных процессов

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

Помощь

Диагностика ресурсов сервера

Если при открытии сайта вы получаете ошибку вида ERR_NAME_NOT_RESOLVED или в тексте ошибки есть слово DNS — причиной могут быть проблемы с доменом. Проведите диагностику по инструкции.

Если же сайт работает медленно, или при его открытии возникают ошибки 502/504, ошибки баз данных, некорректно работают скрипты — скорее всего причина в отказе служб или высокой нагрузке на сервере.

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

Диагностика из панели ISPmanager

На всех Linux-серверах мы предоставляем панель ISPmanager. С её помощью можно выполнить простую диагностику из любого браузера, без навыков администрирования. Доступ к панели описан в инструкции — Личный кабинет → Товары → Виртуальные (Выделенные) серверы → выберите сервер → сверху кнопка Инструкция .

Проверяем свободное пространство через ISPmanager

На главной странице есть блок с информацией о ресурсах сервера:

Нажмите на Размер диска — откроется вкладка, где указано, сколько сейчас занято дискового пространства.

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

Диск могут переполнить, например, резервные копии. Настройками панели можно установить ограничение по объёму или количеству хранимых копий, подробнее в нашей статье.

Если резервные копии не занимают много места или их нет, то стоит проверить содержимое сервера. Поиск по файлам лучше выполнить в командной строке. Так как файловый менеджер в ISPmanager отображает размер файлов, но не каталогов.

Подробнее про диагностику места из консоли можно почитать в соответствующем разделе. ISPmanager имеет встроенную консоль в разделе Инструменты → Shell-клиент , для поиска можете воспользоваться ей.

Проверяем нагрузку через ISPmanager

На главной странице панели справа находится график используемых ресурсов.

На графике отмечены 10 значений за последние сутки, которые обновляются раз в 2,5 часа (при высокой нагрузке могут не обновляться). Значения помогут отследить, в какой из промежутков времени был скачок нагрузки.

Например, если на вашем сайте есть ошибка баз данных, а на графике был скачок использования оперативной памяти — стоит проверить, не была ли остановлена служба БД. Это происходит, когда заканчивается свободная оперативная память и для запуска новых служб завершаются старые (вне зависимости от их важности).

Для перезапуска перейдите в раздел Система → Службы


Справа от имени службы индикатор состояния — лампочка. Например, если на сайте ошибка «DB query error» или «Не удалось подключиться к базе данных» , то, скорее всего, остановлена служба, отвечающая за работу этих баз данных. На скриншоте это mariadb , у вас может быть mysqld (mysql) . Нажмите на службы→ Рестарт После этого проверьте ваш сайт, обновите страницу.

Иногда нажатие не приводит к перезагрузке службы — больше информации о проблеме можно получить, перезапустив службу вручную из консоли. В панели ISPmanager есть SSH-клиент в разделе Инструменты , воспользуйтесь им.

По нажатию слева от графика на число процессов (см. рис 1 «Ресурсы сервера») — откроется список с информацией о том, сколько каждый процесс потребляет ресурсов.

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

Диагностика сервера из консоли

Это инструкция для пользователей, у которых есть опыт работы с командной строкой. Если у вас его нет — обратитесь за помощью к нам, и ваш вопрос рассмотрят технические специалисты.

Бывает так, что ISPmanager недоступен из-за существующей нагрузки или работает медленно. Тогда лучший вариант — подключиться к серверу по SSH и провести диагностику при помощи консольных команд и утилит. Их набор довольно обширен, но для самостоятельного изучения будет достаточно тех, что приведены ниже.

Проверяем свободное пространство через консоль

Зачастую проблемы в недоступности сайта или сервера связаны с банальным переполнением диска.

df — отобразит информацию о занятом на диске месте.

Для более удобного отображения используйте ключ -h , так как сама по себе команда отобразит размер без единиц измерения (Kилобайт, Mегабайт, Гигабайт). Ключ h означает human readable — удобный для прочтения человеком.

Если на диске не осталось или почти не осталось свободного пространства — нужно выяснить, какие файлы или каталоги занимают много места. В поиске нам поможет du

du -hs /* отобразит информацию обо всех директориях:

Теперь вы видите, сколько места на диске занимает каждый каталог в корне сервера. Чтобы найти сами файлы, которые заполнили ваш диск, нужно ввести du -hs /имя_каталога/* Например, du -hs /var/*

И таким же образом двигайтесь дальше, чтобы обнаружить каталог с файлами, которые занимают значительный объём или содержат уже ненужные вам файлы.

Пара советов для упрощения работы с командной строкой:

    Используйте стрелки вверх и вниз на клавиатуре для навигации по истории вводимых команд.
    Чтобы быстро написать название каталога используйте клавишу Tab . Например, наберите du -hs /va и нажмите Tab — в строке появится du -hs /var/ Это не сработает, если есть несколько каталогов/файлов с одинаковыми наименованиями в начале. Например, du -hs /var/lo и нажатие Tab не сработало — нажмите второй раз, и отобразится список каталогов. Всё равно не сработало — была допущена ошибка или такого файла/каталога нет.
    Двойное нажатие Tab во время ввода поможет, когда не уверены, правильно ли пишете название каталога, и если не знаете точно, какой каталог следующий.

Если вы и без поиска знаете, какой каталог всегда заполняется, используйте: du -h /путь/до/каталога/ — команда выведет информацию об объёме всех каталогов по указанному пути, включая вложенные.

Нашли каталог большого объёма? Замечательно! Давайте посмотрим что в нём. ls — выводит содержимое каталога. Например, ls /usr/local/mgr5 выведет список всего, что есть по указанному пути.

Чтобы привести список файлов в более читаемый вид, используем опцию -lha

В списке есть уже неактуальный каталог или файл вашего сайта — давайте удалим его: Перейдите в нужный нам каталог — cd /путь/до/каталога , путь нам известен по командам выше.

Для удаления файлов используйте rm

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

Хотите удалить файл — введите y или Y и нажмите Enter . Если ошиблись — сочетание клавиш Ctrl + C , и файл останется на месте.

Для удаления каталога используем ключ -R

Внимание! Используйте команду rm -Ri /* аккуратно. Существует возможность удалить все файлы на сервере. Ещё более опасный вариант этой команды — m -Rf /* — ключ f удаляет файлы без подтверждения, символ * указывает, что нужно применить действие на все файлы и каталоги.

Проверяем нагрузку через консоль

Утилита top поможет выявить, связана ли медленная работа сайта с нагрузкой на сервере.

Первое, на что стоит обратить внимание — Load Average — число процессов в очереди на выполнение за последние 1, 5 и 15 минут.

Значения LA должны быть меньше количества ядер вашего сервера. Например, при наличии 2 ядер показатель LA равный или больше 2 свидетельствует о том, что ядра уже загружены на 100%, и процессы вашего сервера не выполняется сразу, а «ждут» когда подойдёт их очередь.

Также стоит обратить внимание на следующие показатели:

  • us — время процессора, затраченное на выполнение пользовательских процессов.
  • id — время бездействия процессора.

Если значение us намного выше id — процессы пользователя создают нагрузку, в списке они обычно занимают верхние позиции.

  • По имени пользователя (столбец USER) можно понять, какой из пользователей запустил процесс.
  • В COMMAND отображается информация о команде (процессе), запустившей процесс.
  • %CPU — время ЦП, затраченное для выполнения процесса (в процентах).
  • PID — идентификационный номер процесса. Может пригодиться для его завершения, если вы уверены, что процесс не должен работать или работает некорректно и нужно его перезапустить.
  • wa — время простоя процессора (в процентах), когда он ожидал завершения операций ввода-вывода. Чтобы процесс мог считать нужные ему данные — которых нет в кеше процессора или оперативной памяти — он обращается за ними к диску. Ждёт, пока данные с диска загружаются в оперативную память. И только после этого может начать работать с ними. Если значение wa выше 10-15% — есть проблемы с работой дисковой системы. Возможная причина — высокая нагрузка от базы данных (самих процессов mysql на сервере может быть немного) Они часто обращаются к диску и могут создать «очередь», которая замедляет его работу.
  • st (Steal Time) — процессорное время, забранное у виртуальной машины гипервизором для решения других задач. В случае с услугой хостинга виртуальных серверов это работа других контейнеров, расположенных на этом же физическом родительском оборудовании. По факту этот параметр отображает оверселлинг на ноде. Значение ниже 5-10% не повлияют на производительность именно вашего сервера.

Если значения wa и st выше допустимых пределов — обратитесь в службу технической поддержки.

Утилита ps является одной из альтернатив top.

Результатом вывода без дополнительных опций будут только процессы текущего пользователя и терминала. Наиболее удобное сочетание параметров:

C помощью утилиты ps вы можете найти все процессы одного пользователя или службы. Для поиска всех нужных вам процессов:

Останавливаем процесс

Если процесс использует слишком много ресурсов, и вы уверены, что причина в его некорректной работе — можно остановить процесс по идентификатору (известен нам благодаря top или ps).

Также можно завершить процесс по его имени:

Не остановился? Тогда остановите процесс принудительно:

Опция -9 отправляет сигнал процессу о принудительной остановке, не дожидаясь его корректного завершения (подробнее о сигналах можно прочитать в Википедии).

Перезапускаем сервисы (службы)

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

Используйте следующую команду для перезапуска сервиса на любой unix-подобной операционной системе:

где — имя сервиса.

Проверяем использование оперативной памяти через консоль

free -mh отобразит значение в Мегабайтах.

  • total — общий объём оперативной памяти (ОЗУ)
  • used — сколько сейчас используется
  • free — свободная память
  • buff/cache — закешированная ОЗУ

Более подробную информацию можно получить командой cat /proc/meminfo

Однострачник покажет какие процессы используют память в текущий момент, в Мегабайтах:

Нагрузка на сервер


29.04.2012, 23:19

Нагрузка на сервер
Я сделал на сайт возможность загружать видео. С помощью ffmpeg его конвертирую. теперь мне надо.

Нагрузка if else на сервер
Здравствуйте, подскажите пожалуйста, у меня есть php код длинной примерно полторы тысячи строк, и в.

Нагрузка на сервер и браузер
На сайте у пользователя есть баланс.Решил сделать его обновление раз в 5 секунд.Через аякс.

Быстродействие, нагрузка на сервер, рациональность
Здравствуйте! Как и все, делаю свою поделку. Есть пара вопросов. Вопрос 1 Обычно, все.

Нагрузка на сервер, размер исполняемого файла
Если подключаемый файл весит 38Кб, в нем много функций но используется всего пару шт. Как это.

29.04.2012, 23:28 2 30.04.2012, 01:06 [ТС] 3 30.04.2012, 01:09 4
30.04.2012, 01:09
30.04.2012, 01:31 5

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

думаю чтобы понять смысл, проделывать такой опыт не обязательно)

30.04.2012, 07:34 6

Подключить один большой файл 1 раз будет быстрее, чем подключить N мелких файлов того же суммарного объема.

Другой вопрос в том, нужны ли они Вам всегда все вместе, как и говорит Mikanoshi.

Минус одного большого файла также в том, что его править сложнее и менее удобно, чем отдельные файла.

30.04.2012, 10:23 7

вопрос стоял про классы php — в один файл или разные;
скажу так, если красиво «раскомментируешь» все классы в одном файле, то в коде не заблудишься, работать будет быстро.
Но! Я не думаю что ты будешь использовать все классы сразу или большую из часть.
Лично у меня каждый класс имеет свой файл и не зависит от другого класса
по этому я вызываю нужный нужный класс в нужном месте.

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

Определяем загруженность сервера из PHP

Начнем с получения данных. Для этого необходимо подключить модуль mod_status. Он отслеживает работу сервера и показывает данные в виде обычной html страницы. С его помощью можно узнать:

  • количество процессов, выполняющих обработку запросов;
  • количество процессов, которые находятся в состоянии ожидания;
  • состояние каждого процесса, число обработанных им запросов и переданных данных;
  • общее количество запросов и переданных данных;
  • время работы сервера (запуск, перезапуск и общее время работы (uptime));
  • общая статистика: среднее число запросов в сек, байт на запрос, байт в сек;
  • использование CPU каждым процессом отдельно и apache’ем в целом в данный момент;
  • хосты и их запросы, которые обрабатываются в данный момент.

Переходим к настройке.

  1. Подключаем модуль. Для этого в файле httpd.conf снимаем комментарий со строки

    И открываем доступ к статистике. Добавляем в httpd.conf следующие строки

    Примечание. Здесь мы разрешили доступ к статистике только для адреса 127.0.0.1 (localhost). Для тестирования удаленного сервера вам нужно будет эту настройку изменить.

  2. Перезапускаем apache.
  3. Теперь можно просматривать статистику. Для этого вводим в браузере URL http://localhost/server-status или, если вы хотите, чтобы страница обновлялась автоматически — http://localhost/server-status?refresh=15 (вместо цифры 15 ставите задержку в секундах).

    Есть ещё один вариант страницы с этими же данными: http://localhost/server-status?auto&refresh=3

    Как видите, данные мы получили, но анализировать их, глядя на стандартную страницу не очень удобно.

    Например, на скриншоте показано состояние процессов apache:

    Символ подчеркивания означает, что процесс ожидает соединения, буква «W» — отправка ответа, точка — открытый слот без процесса.

    Примечание. Скриншот сделан для локального севера, поэтому единственный процесс, который выполняет отправку запроса — это тот, который формирует страницу со статистикой.

    Кроме того, если у вас данные постоянно обновляются (используется параметр refresh), то визуально оценить изменения будет очень сложно.

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

    В качестве примера такого скрипта рассмотрим Visualize Apache Server Status (распространяется под LGPL лицензией).

    Методы уменьшения нагрузки на VDS

    Нагрузка на VDS может возникать по ряду причин. Рост посещаемости, неправильная настройка сервисов, действия злоумышленников — это и многое другое может служить причиной нестабильной работы сервера и веб-ресурса. Условно всю нагрузку можно разделить на 3 типа: нагрузка на память, процессор и диск. Кроме того, каждый тарифный план обладает лимитом на файловые дескрипторы (фактически, количество открытых файлов) и количество одновременно запущенных процессов. В данной статье будут описаны основные причины возникновения нагрузки, их поиск и устранение.

    Содержание

    Инструменты для анализа работы сервера

    *NIX утилиты

    Чтобы локализовать проблему, необходимо провести анализ работы сервера. Примерную картину происходящего можно получить с помощью панели ISPmanager, пункт «Информация о системе». Для более детального анализа требуется работа в консоли.

    Один из самых доступных и простых в использовании средств мониторинга в Unix — команда top. Команда выдаст информацию о работе сервисов в реальном времени. Нас интересуют столбцы COMMAND (команда, выполняемая на сервере), %CPU (какой процент ресурсов центрального процессора использует сервис), %MEM (какой процент памяти использует сервис). Кроме этих столбцов следует обратить внимание на строки load average (la, среднее количество процессов, ожидающих выполнения за последние 1, 5 и 15 минут), Mem (количество свободной и используемой памяти). Вывод команды даст примерное представление о потреблении ресурсов. Если LA на вашем VDS вырос выше 5 — это плохой знак.

    Список процессов и потребление ресурсов также можно посмотреть командой ps auxw.

    Для того, чтобы узнать количество свободной и используемой памяти на ОС Linux также можно воспользоваться командой free -m.

    Команда vmstat выдает информационный отчет об активности процессов, памяти, свопинга, поблочного ввода/вывода, прерываний и процессора. Вывод vmstat сложнее в понимании.

    Нагрузку на диск можно посмотреть следующим образом:

    • Можно использовать команды gstat и iostat.
    • Для того, чтобы определить процесс, который нагружает диск в Linux можно использовать команду iotop. Вывод покажет процент загрузки диска сервисами, работающими на сервере.

    Модули Apache

    Веб-сервер Apache является главным звеном в обеспечении работоспособности сайта. Именно этот сервис занимается отдачей контента пользователю. Для Apache существует множество модулей. Такие модули, как mod_perfomance и mod_status позволяют определить, какие скрипты создают наибольшую нагрузку.

    Лог-файлы

    Проблему не всегда можно распознать «на глаз». Полезным, также, бывает чтение лог-файлов сервера. Их местоположение разниться в зависимости от используемой операционной системы и настроек сервисов.

    Причины нагрузки

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

    В списке процессов (top, ps) висит большое количество дочерних процессов apache или потоков php-cgi. Или процессы Apache создают высокую нагрузку на ЦП.

    Возможные причины и варианты решения:

    Неправильная настройка ограничений для веб-сервера

    Необходимо проверить параметры MaxClients и MaxSpareServers. Оптимальное значение MaxClients можно расчитать по формуле

    (где М — общее количество памяти; H — количество памяти, потребляемое одним процессом Apache. Эти значения можно узнать из вывода команды top). MaxSpareServers на VDS не рекомендуется устанавливать выше 10. Ограничения устанавливаются в конфигурационных файлах:

    Стоит обратить внимание на то, что настройки разделены по модулям, в зависимости от MPM, который использует Apache. Узнать это можно из вывода команды apachectl -V (строка Server MPM).

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

    Важно найти оптимальное значение данной директивы.

    Возможно, ваш сервер ресурс стал жертвой DDoS-атаки

    DDoS-атаки стали одним из самых дешевых и надежных средств «борьбы с конкурентами». Процесс обнаружения и борьбы с DDoS подробно описан в следующих статьях:

    Рост посещаемости ресурса или повышенная нагрузки из-за индексации

    Отслеживать посещаемость ресурса можно с помощью сторонних сервисов, таких как: Яндекс.Метрика,Google Analytics или счетчиков LiveInternet. Также полезно анализировать access-логи сайтов. Они расположены:

    Достаточно часто причиной скачков нагрузки на веб-сервер является работа ботов поисковых сервисов, таких как YandexBot, GoogleBot или MSNBot. При этом в access-логах сайтов появляются записи вида

    Есть возможность запретить доступ ботов к сайту частично или полностью. Делается это с помощью файла robots.txt или .htaccess в корне сайта или той директории, доступ к которой вы хотите запретить. При полном запрете поисковый сервис не сможет индексировать сайт. Правила robots.txt выглядят следующим образом

    В .htaccess это может выглядеть так:

    Более подробно можно прочитать здесь:

    Неправильная работа скриптов

    Причиной высокой нагрузки на веб-сервер может стать не оптимальное использование скриптами ресурсов сервера. Нагрузку скриптов на сервер можно проверить с помощью модулей Apache ( mod_performance и mod_status). В этом случае необходимо отлаживать скрипты. Трассировку скрипта можно сделать с помощью расширений php — xdebug или xhprof.

    Рекомендуем обратиться к разработчику скриптов. Также вам помогут следующие статьи:

    Можно попробовать установить на сервер Nginx (ISPmanager → «Возможности») и php-кэшер, например Zend Opcache. В такой связке Nginx будет отдавать статику, а Zend Opcache кэшировать запросы клиентов, что позволит увеличить скорость отдачи контента.

    Apache создает нагрузку на процессор

    Такое возникает при неправильной работе скриптов (см. выше), работе с аудио/видео или использовании mod_gzip для сжатия данных. Попробуйте отключить сжатие данных или оптимизировать скрипты.

    MySQL создает нагрузку на диск

    Причиной может являться неправильная конфигурация mysql или построение запросов.

    Иногда MySQL использует диск для хранения временных таблиц. Это происходит в случае нехватки места в буферах памяти или при использовании сложных запросов. Размер буферов регулируется директивами в конфигурационном файле my.cnf. В данном случае, необходимо увеличить директивы tmp_table_size и max_heap_table_size. Проблему можно локализовать, используя команду

    с паролем администратора MySQL. В выводе будут присутствовать записи Created_tmp_disk_tables. При оптимизации настроек очень удобно пользоваться скриптами mysqltuner.pl и tuning-primer.

    MySQL гарантировано будет создавать временные таблицы на диске в случаях если:

    • присутствует BLOB или TEXT столбец в таблице;
    • размер колонки при использовании GROUP BY или DISTINCT больше 512 байт;
    • размер колонки в выводе SELECT, при использовании UNION или UNION ALL больше 512 байт.

    MySQL создает нагрузку на процессор

    Вероятнее всего, проблема в «битых» индексах или таблицах. Информация об этом должна содержаться в логах MySQL. Необходимо запустить проверку таблиц. Сделать это можно через phpMyAdmin или командой

    введя пароль администратора MySQL.

    Почтовый сервер создает нагрузку на процессор

    Вероятнее всего, с вашего почтового сервера рассылается спам. Посмотреть очередь сообщений можно с помощью команды mailq. Используя идентификаторы из вывода команды, можно посмотреть письма в очереди. Для exim, например, это делается командами exim -Mvb (покажет тело письма), exim -Mvh (покажет заголовки письма). Для sendmail письма можно посмотреть в папке /var/spool/mqueue/. Кроме того, информацию можно найти в логах: /var/log/exim/mainlog, /var/log/maillog, для exim и sendmail соответственно. Основные причины отправки спама с сервера:

    • взлом почтового ящика (необходимо сменить пароли);
    • взлом сервера и загрузка скриптов, рассылающих спам (можно определить по заголовку письма X-PHP-Script);
    • намеренная рассылка спама одним из пользователей.

    DNS-сервер создает нагрузку на процессор

    Вероятнее всего, сервер подвергся DNS Amplification атаке.

    Атака подробно описана, например здесь.

    Для того, чтобы избежать атаки необходимо добавить в конфигурационный файл DNS-сервера опцию allow-transfer в которой перечислить только доверенные ip-адреса серверов.

    Для дистрибутивов CentOS, также присутствует ошибка в старых версиях named.

    Исправляется добавлением в конфигурационный файл строчки

    Процессы tar и gzip создают нагрузку на диск и процессор

    Эти процессы запускаются при выполнении задания резервного копирования. Попробуйте перенести задание на то время, когда нагрузка на ваш сервер минимальна.

    Неизвестные процессы создают нагрузку на сервер (память, процессор, диск)

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

    Определяем загруженность сервера из PHP

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

    Обычно о превышении нагрузки веб-мастера узнают от своих хостеров, которые строго регламентируют и контролируют процесс потребления процессорного времени и на уровне тарифного плана задают ту допустимую нагрузку, которую может создавать аккаунт (обычно она измеряется в % от некоторого разрешенного значения или в CP/процессорных минутах).

    Хостер старается равномерно распределить ресурсы процессора среди всех клиентов сервера. Если чей-то аккаунт хостинга будет “съедать” 90% процессорных ресурсов, то остальным достанется только 10%. Поэтому в подобных случаях владельцу аккаунта, превышающего лимиты, придет предупреждение. А при систематических нарушениях аккаунт блокируется, чтобы не мешать работе других сайтов, расположенных на том же сервере. И это, отнюдь, не попытка “развести” клиента на более дорогой тариф, как думают некоторые веб-мастера, поскольку не хостер виноват в том, что сайту с некоторого времени потребовалось больше ресурсов.

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

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

    Внешние факторы

    Внешние факторы, создающие высокую нагрузку – это все то, что не зависит от настройки хостинга, работы скриптов и процесса администрирования сайта. Это результат внешних запросов к сайту различными сервисами, ботами или другими сайтами. Факторов достаточно много.

      Сканирование сайта на уязвимости, поиск «чувствительных файлов», поиск панели администратора.
      Любой сайт, страницы которого проиндексированы в поисковой системе, может стать “мишенью” для хакеров и ботов, его ежедневно кто-то будет сканировать, искать “дыры”, пытаться взломать. Остановить этот процесс невозможно, но можно ему противодействовать.
      Запросы к сайту, особенно если они выполняются интенсивно и методом POST, потребляют много процессорных ресурсов. Поэтому процесс сканирования сайта внешним сканером выражается в росте нагрузки. Если в результате сканирования злоумышленник обнаружит уязвимость или вариант взлома сайта, то вероятнее всего на сайт он загрузит вредоносный код или совершит какие-то деструктивные действия. Если никаких проблем безопасности в результате сканирования выявлены не будут, то сайт продолжит работать в штатном режиме, а нагрузка вернется к нормальному значению. До следующего сканирования…

    Подбор пароля от админ-панели сайта (брутфорс-атака).
    Одной из популярных атак, целью которой является получение административного доступа с помощью перебора популярных комбинаций логинов/паролей администратора, является атака вида «брутфорс». Хакерский бот использует специальный словарь с TOP1000 популярных комбинаций (admin/admin, admin/123456,…) и пробует зайти с ними в административную панель сайта. Сам процесс перебора повышает нагрузку, так как на страницу административной панели идут постоянные обращения, причем запросы выполняются ресурсоемким методом POST.

    Массовая регистрация пользователей или массовая отправка спама через незащищенные формы обратной связи.

    Часто на сайтах используются формы обратной связи или формы регистрации пользователей со слабыми механизмами защиты от ботов. Хорошо, если на форме установлена хоть какая-то “капча” из серии “докажи, что ты не бот”. Если сайт попал в базу спаммеров, а «капчи» или другого механизма защиты от “http флуда” нет, то начинается массовая регистрация пользователей со спам-профилями, отправка почты через форму и т.п. Все это создает нагрузку на хостинг, и кроме того, может провоцировать спам-рассылку, за которую хостинг-компания отключает почтовый сервис или блокирует сайт полностью.

    Следует отметить, что в настоящий момент все простые защитные механизмы без труда обходятся современными ботами, поэтому необходимо сразу устанавливать что-то серьезное, например, Google Recaptcha2.

    Индексирование сайта поисковыми ботами.

    Иногда при достаточно большом поисковом индексе (когда в поисковую базу Яндекса и Google попадает большое число страниц), процесс переиндексации может занимать длительное время и создавать большую нагрузку на сервере. Если на вашем сайте всего десяток страниц, вы также можете столкнуться с подобной проблемой, например, если сайт был взломан и на нем размещен дорвей на 50 000 страниц, которые попали в поисковую выдачу. Или поисковый индекс мог заспамить конкурент, который воспользовался ошибками в работе скриптов вашего сайта. Вариантов здесь масса.

    Граббинг и скраббинг контента.

    Владельцам уникального контента стоит обеспокоиться проблемой скачивания контента с сайта (скраббинг и граббинг). Этим могут промышлять специальные боты, которые обходят страницы сайта и копируют тексты и картинки, размещенные на сайте, с целью создания клонов. Если процесс сканирования вашего сайта регулярный, а страниц у сайта — много, это может создавать внушительную нагрузку на хостинг.

    Импортирование данных (фиды, выгрузка товарных позиций).

    Часто e-commerce ресурсы используют механизм обмена данными с внешними сервисами. Например, из интернет-магазинов может выгружаться список товарных позиций, в них могут загружаться данные из 1С, у новостных сайтов может происходить регулярный экспорт новостных фидов и пр. Если контент не статический, то каждый такой запрос будет создавать высокую нагрузку на сервер.

  4. Использование картинок или ссылок на ваш сайт.
    Одним из неочевидных моментов, создающих нагрузку, может быть размещение ссылки на сайт или использование изображения с сайта на более посещаемом ресурсе. Один из источника проблемы – это так называемый “хабраэффект”, когда сайт не справляется с потоком посетителей с более популярного ресурса. Второй вариант – когда кто-то (или вы сами) разместили на посещаемом блоге (например, в комментариях) картинку со своего сайта, и она загружается у каждого посетителя и создает нагрузку на ваш хостинг. Особенно это может создавать серьезные проблемы в том случае, если картинка генерируется скриптами (например, масштабируется с помощью скриптов timthumb/phpthumb).
  5. Атаки на другие сайты (например, уязвимость в xmlrpc.php).

    Часто сайты, содержашие уязвимости, используются хакерами для проведения атак на другие ресурсы. Иногда для этого злоумышленнику даже не требуется взламывать сайт. Например, с этой проблемой могут столкнуться владельцы не самых свежих версий WordPress (атака через файл xmlrpc.php). Ваш сайт в данном случае будет выступать промежуточным звеном, а работа скриптов сайта создавать большую нагрузку на сервере.

    DDOS-атака
    Если на сайт идет DDOS-атака, то без подключения специальных технических средств, проксирующих трафик (услуга хостинга или сервиса защиты от DDOS), справиться с ней не удастся. Не заметить DDOS достаточно сложно. Из-за того, что на сервер будет создаваться огромная нагрузка, хостер может поступить по-разному: предложить услугу защиты от DDOS, перенести сайт на другой сервере или полностью заблокировать (отключить) сайт. Поэтому для защиты от DDOS желательно иметь заранее заготовленное решение, чтобы при возникновении проблемы оперативно ее решить.

    Рост посещаемости

    Если трафик органический, то это самая позитивная причина роста нагрузки. Значит пришло время масштабировать сайт и задуматься об оптимизации скриптов, рассчитанных на более высокую посещаемость.

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

    В результатах анализа следует посмотреть TOP 20 запросов методом POST, TOP 20 запросов методом GET/HEAD, TOP 20 IP адресов по числу хитов, TOP 20 ссылающихся страниц по числу хитов. Все это позволит выявить источник и тип трафика, а также точки входа на сайт или скрипты, которые вызываются чаще всего. Скорее всего они и будут причиной высокой нагрузки.

    Для снижения нагрузки при внешних атаках или интенсивных запросах в большинстве случаев достаточно включить защиту от http флуда (например, классический “куки на клиенте + редирект с проверкой”) или подключить сайт к сервисам проксирования трафика, которые будут блокировать опасные или особо активные запросы, а хорошие и легитимные — пропускать. Кроме того, статический контент (картинки, скрипты и стили) будут отдаваться не с вашего сайта, а с CDN-серверов, что также существенно снизит нагрузку.
    Можно попробовать подключить кэширующий плагин в CMS или кэширующий сервис на хостинге, но в случае внешних факторов, влияющих на нагрузку, это может и не помочь.

    Внутренние факторы

    Ко внутренним факторам можно отнести все то, что влияет на производительность сайта на уровне скриптов и настроек. То есть то, что поддается контролю со стороны веб-мастера (владельца сайта).

      Неоптимизированные скрипты и разросшаяся база данных.
      Из-за неграмотно спроектированной архитектуры веб-приложения или неэффективной реализации скриптов неопытными разработчиками возможен случай, когда простое открытие стартовой страницы или отображение результатов поиска на сайте может серьезно нагружать сервер. А рост объема базы данных (например, увеличение числа товарных позиций) с каждым обновлением сайта будет его все больше замедлять, увеличивая нагрузку на хостинг. Отдельные страницы сайта с большим числом информационных блоков могут отправлять по несколько десятков запросов к базе данных, многократно выполнять одни и те же операции с файлами, а иногда даже блокировать работу других элементов сайта. Мы часто сталкиваемся с подобной проблемой у интернет-магазинов, работающих на старой версии Joomla с плагином Virtuemart. В некоторых случаях при открытии страницы каталога выполняется более 100 запросов к базе данных.

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

    Внешние легитимные подключения к сторонним ресурсам
    Мало кто принимает во внимание нагрузку, которую создают подключения к внешним источникам информации (виджеты, информеры погоды и курса валют, новостные фиды и пр). Часто данные, которые загружаются с других сайтов, не кэшируются локально и в момент открытия страницы каждый раз происходит подключение и загрузка контента с другого сервера. Если по какой-то причине внешний источник перестает быстро отвечать, это повлияет на нагрузку и скорость загрузки основного сайта.

  6. Ошибки в работе скриптов
    При работе скриптов могут возникать ошибки, которые не отображаются посетителям, но записываются в лог веб-сервера или лог php. Если сайт посещаемый или ошибок много, это также может увеличивать нагрузку на хостинг. Чаще всего ошибки начинают генерироваться в момент переключения сайта на более свежую версию PHP, с которой скрипты не совместимы. Или когда обновляются не все компоненты сайта, и возникают конфликты между новым ядром CMS и старыми версиями плагинов.

Для анализа проблемы высокой нагрузки, вызванной внутренними факторами, требуется выполнить проверку сайта на наличие вредоносного кода (например, проверить сайт бесплатным сканером AI-BOLIT), и, если вредоносного кода не обнаружено, то выполнить профилирование работы скриптов с помощью модулей xhprof или xdebug.

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

Если же причина проблем в архитектуре сайта или ошибках, то поможет оптимизация сайта силами опытного веб-разработчика. Как одно из запасных решений для второго случая – это установка кэширующего плагина, который в некоторых случаях может снизить потребление процессорных ресурсов (нагрузки на хостинг) и ускорить работу сайта.

Продолжительность

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

Если на графике потребления процессорного времени вы видите разовый скачок, то не стоит волноваться. Он практически незаметен, не влияет на доступность сайта и не мешает “соседям” по хостингу. Хуже, если график длительное время ползет вверх или в течение нескольких дней показывает предельную (или превышающую лимит) загрузку процессора. Что делать в этом случае? Необходимо проводить аудит сайтов на аккаунте так, как это было описано выше, проверяя как внешние, так и внутренние факторы, вызывающие проблемы.

Илон Маск рекомендует:  Что такое код pdf_setrgbcolor_stroke
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL