Что такое нагрузка cpu
Почему нагрузка на CPU сервера важна для администратора сайта
Вступление
Вы администратор WordPress и вам в очередной раз пришло письмо от вашего хостинга, что у вас превышена нагрузка на процессор сервера? Вам пора разобраться, что такое нагрузка на CPU, как за ней следить и как её снизить.
Что такое нагрузка на CPU
Аббревиатура CPU известна всем пользователям компьютеров всех видов и типов. Это Central Processor Unit — центральный процессор.
Нагрузка на CPU, в контексте хостинга, это процентная доля вашего использования ресурсов центрального процессора сервера в рамках вашего тарифного плана.
За 100% принимается допустимая нагрузка одного ядра, 200% — полная допустимая нагрузка двух ядер.
При аренде вами шаред хостинга, вы априори делите CPU с другими пользователями хостинга. То есть вы по определению не можете использовать 100% ядра сервера.
Именно по этому при аренде общего хостинга вам нужно выяснить какая нагрузка на CPU вам разрешена по вашему тарифному плану.
Найти эти данные вы можете в договоре с хостингом. Называться данный параметр будет, скорее всего, так «максимальное суммарное потребление ресурсов процессора в сутки», измеряться может в минутах или процентах. Всё зависит от ПО хостинга.
Для администратора WordPress важно понимать, что нагрузка на сервер необязательно связана с правильной работой сайта. Если вы установили плохо «собранный» плагин или программный код создал бесконечный цикл или неправильное регулярное выражение, то нагрузка на CPU возрастёт кратно.
Помимо этого, есть нагрузка на CPU со стороны базы данных MySQL. Она лимитирована в меньшей степени, но она есть.
Итак, каждый раз, когда посетители вашего сайта его просматривают и каждый раз когда вы его администрируете, создаётся нагрузка на CPU вашего сервера. Однако эта нагрузка также создается, когда ваш сайт посещают законные или атакуют незаконные боты.
Как подсчитывается нагрузка на CPU
Нагрузка на CPU считается как время, которое тратит процессор сервера на обработку процессов пользователей. Какие при этом происходят процессы неизвестно. Однако их можно понять по логам веб-сервера (Apache). В них вы найдете дату, время, название процесса и кол-во тактов, которые потратил процессор на работу этого процесса.
Для WordPress максимальную нагрузку могут создавать:
Где посмотреть нагрузку на CPU?
В панели управления вашего хостинга должен быть раздел: Статистика CPU, Нагрузка и т. п. В этом разделе будут данные, скорее в виде графика, с указанием суточного лимита и нагрузкой вашего сайта (посуточно, еженедельно, по месяцам). Пример такого графика на фото.
Почему нагрузка на CPU должна контролироваться?
Если вы не получаете письма от хостинга и ваш сайт не блокируют, то вам не нужно каждый день следить за нагрузкой. Хостинг всё сделает за вас. Однако раз в месяц нагрузку стоит просматривать, чтобы выявлять пиковые нагрузки и их причины. Вполне возможно, что ваш сайт пытались взломать или уже взломали.
Как уменьшить нагрузку?
Кратковременные или пиковые нагрузки можно анализировать по лог-файлам вашего сайта.
Периодические (систематические) повышенные нагрузки нужно анализировать по графику нагрузок с коротким временным интервалом (если он доступен).
Выявить «тяжелый» плагин сайта вы можете из браузера, используя инструменты разработчика, вкладка Network. Она разложит процессы по времени, и вы увидите плагины которые грузятся дольше секунды. Их нужно убрать.
Можно управлять нагрузкой через плагины безопасности. В них есть блокировка пользователей и ботов по их IP, стране и т. п.
Чтобы нагрузка на CPU снизилась, администратор WordPress должен использовать кэширование средствами CMS. То есть установить плагин кеширования (на выбор): WP Super Cache, W3 Total Cache, WP Rocket, WP Fastest Cache, Comet Cache, Autoptimize.
Заключение
Если у вас молодой сайт, то нагрузка на CPU сервера вас будет мало волновать. С ростом посетителей и улучшении функционала проблема нагрузки вас посетит. Лучшее решение этой проблемы совместно с технической поддержкой хостинга.
Что такое нагрузка на CPU
Зачастую, наиболее затратными процессами, которые могут создавать нагрузку на CPU являются действия экспорта/импорта базы данных, час пик посещаемости сайта, неоптимизированные индексы в базе данных, плохо оптимизированный программный код в скриптах пользователей, инфицированный, взломанный или хакерский код.
Для удобства пользователя в панели управления хостингом есть график (раздел «Аккаунт» → «Статистика CPU, MySQL»), на котором указана максимально допустимая для текущего тарифного плана нагрузка, а также имеется возможность просматривать отдельно статистику нагрузки на CPU, и отдельно статистику нагрузки на MySQL.
На сервере находится много пользователей, и ресурсы делятся между ними. В каждый конкретный момент только часть пользователей использует ресурсы сервера. Если кто-то будет монополизировать ресурсы сервера постоянно, то другим пользователям достанется меньше ресурсов, из-за чего их сайты и базы будут работать медленнее. Поэтому мы вынуждены принимать меры, чтобы было комфортно работать всем.
Кроме того, внезапные скачки нагрузки могут означать то, что Ваш сайт пытаются взломать или он уже взломан.
Иногда скрипты пользователя потребляют больше, чем положено по тарифному плану. Жёсткое ограничение ресурсов означает аварийное завершение скриптов пользователя и в конечном итоге, нестабильную работу его сайтов.
Если скачок нагрузки был кратковременным, или пиковым, то исходя из времени на графике следует проанализировать лог-файлы сайтов в соответствующий момент времени.
Если нагрузка возникает периодически, то необходимо внимательно просмотреть логи на момент возникновения нагрузки. Определить этот момент точнее Вам поможет график нагрузки с 5-минутным интервалом.
Для поисковых ботов достаточно задать crawl-delay или в файле robots.txt описать, какие разделы сайта можно, а какие нельзя индексировать. Примеры использования robots.txt можно увидеть здесь.
Любую нежелательную активность можно ограничить средствами веб-сервера. Это можно сделать через файл .htaccess. Пример ограничения по user-agent:
Пример ограничения по IP-адресу:
Если нагрузка постоянная, то нужно начинать с анализа логов. При неизменной посещаемости, проблему следует искать в коде Вашей CMS.
Если Вы разработчик, можем предложить подключение модуля php XHprof. Вместе с инструментами веб-разработчика в браузере он предоставляет достаточно информации для профилирования кода.
Для обычных пользователей в качестве общих рекомендаций мы можем предложить включить кэширование средствами CMS (если CMS поддерживает данную функцию), отключить неиспользуемые модули в CMS, или задуматься о смене CMS на потребляющую меньшее количество ресурсов сервера.
При нагрузке на сервер баз данных, следует анализировать структуру запросов и при необходимости создавать дополнительные индексы и оптимизировать базы данных (подробнее об этом можно узнать из нашей статьи). Также у нас ведутся логи медленных запросов, которые мы можем предоставить по просьбе пользователя.
Если бороться с нагрузкой нет возможности или желания, есть несколько решений:
Вы неверно измеряете загрузку процессора
Та метрика, которую мы называем «загрузкой процессора» на самом деле многими людьми понимается не совсем верно. Что же такое «загрузка процессора»? Это то, насколько занят наш процессор? Нет, это не так. Да-да, я говорю о той самой классической загрузке CPU, которую показывают все утилиты анализа производительности — от диспетчера задач Windows до команды top в Linux.
Вот что может означать «процессор загружен сейчас на 90%»? Возможно, вы думаете, что это выглядит как-то так:
А на самом деле это выглядит вот так:
«Работа вхолостую» означает, что процессор способен выполнить некоторые инструкции, но не делает этого, поскольку ожидает чего-то — например, ввода-вывода данных из оперативной памяти. Процентное соотношение реальной и «холостой» работы на рисунке выше — это то, что я вижу изо дня в день в работе реальных приложений на реальных серверах. Есть существенная вероятность, что и ваша программа проводит своё время примерно так же, а вы об этом и не знаете.
Что это означает для вас? Понимание того, какое количество времени процессор действительно выполняет некоторые операции, а какое — лишь ожидает данные, иногда даёт возможность изменить ваш код, уменьшив обмен данных с оперативной памятью. Это особенно актуально в нынешних реалиях облачных платформ, где политики автоматического масштабирования иногда напрямую завязаны на загрузку CPU, а значит каждый лишний такт «холостой» работы стоит нам вполне реальных денег.
Что же такое загрузка процессора на самом деле?
Та метрика, которую мы называем «загрузкой процессора» на самом деле означает нечто вроде «время не-простоя»: то есть это то количество времени, которое процессор провёл во всех потоках кроме специального «Idle»-потока. Ядро вашей операционной системы (какой бы она ни была) измеряет это количество времени при переключениях контекста между потоками исполнения. Если произошло переключение потока выполнения команд на не-idle поток, который проработал 100 милисекунд, то ядро операционки считает это время, как время, потраченное CPU на выполнение реальной работы в данном потоке.
Эта метрика впервые появилась в таком виде одновременно с появлением операционных систем с разделением времени. Руководство программиста для компьютера в лунном модуле корабля «Апполон» (передовая на тот момент система с разделением времени) называла свой idle-поток специальным именем «DUMMY JOB» и инженеры сравнивали количество команд, выполняемых этим потоком с количеством команд, выполняемых рабочими потоками — это давало им понимание загрузки процессора.
Так что в этом подходе плохого?
Сегодня процессоры стали значительно быстрее, чем оперативная память, а ожидание данных стало занимать львиную долю того времени, которое мы привыкли называть «временем работы CPU». Когда вы видите высокий процент использования CPU в выводе команды top, то можете решить, что узким местом является процессор (железка на материнской плате под радиатором и кулером), хотя на самом деле это будет совсем другое устройство — банки оперативной памяти.
Ситуация даже ухудшается со временем. Долгое время производителям процессоров удавалось наращивать скорость их ядер быстрее, чем производители памяти увеличивали скорость доступа к ней и уменьшали задержки. Где-то в 2005-ом году на рынке появились процессоры с частотой 3 Гц и производители сконцентрировались на увеличении количества ядер, гипертрейдинге, много-сокетных конфигурациях — и всё это поставило ещё большие требования по скорости обмена данных! Производители процессоров попробовали как-то решить проблему увеличением размера процессорных кэшей, более быстрыми шинами и т.д. Это, конечно, немного помогло, но не переломило ситуацию кардинально. Мы уже ждём память большую часть времени «загрузки процессора» и ситуация лишь ухудшается.
Как же понять, чем на самом деле занят процессор
Используя аппаратные счетчики производительности. В Linux они могут быть прочитаны с помощью perf и других аналогичных инструментов. Вот, например, замер производительности всей системы в течении 10 секунд:
Ключевая метрика здесь это «количество инструкций за такт» (insns per cycle: IPC), которое показывает, сколько инструкций в среднем выполнил процессор на каждый свой такт. Упрощённо: чем больше это число, тем лучше. В примере выше это число равно 0.78, что, на первый взгляд кажется не таким уж плохим результатом (78% времени выполнялась полезная работа?). Но нет, на этом процессоре максимально возможным значением IPC могло бы быть 4.0 (это связано со способом получения и выполнения инструкций современными процессорами). То есть наше значение IPC (равное 0.78) составляет всего 19.5% от максимально возможной скорости выполнения инструкций. А в процессорах Intel начиная со Skylake максимальное значение IPC уже равно 5.0.
В облаках
Когда вы работаете в виртуальном окружении, то можете и не иметь доступа к реальным счетчикам производительности (это зависит от используемого гипервизора и его настроек). Вот статья о том, как это работает в Amazon EC2.
Интерпретация данных и реагирование
Если у вас IPC 1.0, то ваше приложение страдает не столько от ожидания данных, сколько от чрезмерного количества выполняемых инструкций. Ищите более эффективные алгоритмы, не делайте ненужной работы, кэшируйте результаты повторяемых операций. Применение инструментов построения и анализа Flame Graphs может быть отличным способом разобраться в ситуации. С аппаратной точки зрения вы можете использовать более быстрые процессоры и увеличить количество ядер.
Как вы видите, я провёл черту по значению IPC равному 1.0. Откуда я взял это число? Я рассчитал его для своей платформы, а вы, если не доверяете моей оценке, можете рассчитать его для своей. Для этого напишите два приложения: одно должно загружать процессор на 100% потоком выполнения инструкций (без активного обращения к большим блокам оперативной памяти), а второе должно наоборот активно манипулировать данным в ОЗУ, избегая тяжелых вычислений. Замерьте IPC для каждого из них и возьмите среднее. Это и будет примерная переломная точка для вашей архитектуры.
Что инструменты мониторинга производительности на самом деле должны показывать
Я считаю, что каждый инструмент мониторинга производительности должен показывать значение IPC рядом с загрузкой процессора. Это сделано, например, в инструменте tiptop под Linux:
Другие причины неверной трактовки термина «загрузка процессора»
Процессор может выполнять свою работу медленнее не только из-за потерь времени на ожидание данных из ОЗУ. Другими факторами могут быть:
CPU Load: когда начинать волноваться?
Аналогия транспортного потока
Так Вы говорите, 1.00 — идеальное значание load average?
Что насчет многопроцессорных систем? Мой сервер показывает загрузку 3.00 и все ОК!
У Вас четырехпроцессорная система? Все в порядке, если load average равен 3.00.
В мультипроцессорных системах загрузка вычисляется относительно количества доступных процессорных ядер. 100% загрузка обозначается числом 1.00 для одноядерной машины, числом 2.00 для двуядерной, 4.00 для четырехъядерной и т.д.
Если вернуться к нашей аналогии с мостом, 1.00 означает «одну полностью загруженную полосу движения». Если на мосту всего одна полоса, 1.00 означает, что мост загружен на 100%, если же в наличии две полосы, он загружен всего на 50%.
То же самое с процессорами. 1.00 означает 100% загрузки одноядерного процессора. 2.00 — 100% загрузки двуядерного и т.д.
Многоядерность vs. многопроцессорность
Сведем все вместе
Давайте посмотрим на средние значения загрузки с помощью команды uptime :
Здесь представлены показатели для системы с четырехъядерным процессором и мы видим, что имеется большой запас по нагрузке. Я даже не буду задумываться о ней, пока load average не превысит 3.70.
Какое среднее значение мне следует контролировать? Для одной, пяти или 15 минут?
Количество ядер важно для правильно понимания load average. Как мне его узнать?
Команда cat /proc/cpuinfo выводит информацию обо всех процессорах в вашей системе. Чтобы узнать количество ядер, «скормите» ее вывод утилите grep :
Примечания переводчика
Выше представлен перевод самой статьи. Также много интересной информации можно почерпнуть из комментариев к ней. Так, один из комментаторов говорит о том, что не для каждой системы важно иметь запас по производтельности и не допускать значения загрузки выше 0.70 — иногда нам нужно чтобы сервер работал «на всю катушку» и в таких случаях load average = 1.00 — то, что доктор прописал.
Хабраюзер dukelion добавил в комментариях ценное замечание, что в некоторых сценариях, для достижения максимального КПД «железа», стоит держать значение load average несколько выше 1.00 в ущерб эффективности работы каждого отдельного процесса.
Хабраюзер enemo в комментариях добавил замечание о том, что высокий показатель load average может быть вызван большим количеством процессов, выполняющих в данный момент операции чтения/записи. То есть, load average > 1.00 на одноядерной машине не всегда говорит о том, что в Вашей системе отсутствует запас по загрузке процессора. Требуется более внимательное изучение причин такого показателя. Кстати, это хорошая тема для нового поста на Хабре 🙂
Ограничения по нагрузке
Как считается нагрузка
Лимиты нагрузки
По умолчанию суммарная нагрузка в день не должна превышать следующие показатели:
| Тариф | Нагрузка на CPU | Нагрузка на MySQL |
|---|---|---|
| Year+ | 50 | 1000 |
| Optimo+ | 300 | 5000 |
| Century+ | 400 | 7000 |
| Millennium+ | 600 | 10000 |
| Eterno | 1000 | 15000 |
| Premium | 3000 | 25000 |
| 1Сайт | 1000 | 15000 |
С дополнительной услугой «Увеличение лимита нагрузки» лимиты могут быть расширены до следующих показателей:
Лимиты по умолчанию:
Лимиты с учетом максимально возможного увеличения:
110 cp на CPU, 2200 единиц на MySQL для обычного хостинга и тарифов «Старт» CMS-хостинга;
Отображение нагрузки в ПУ
На графиках в панели управления (раздел «Нагрузка на сервер») можно увидеть динамику нагрузки за последние 2 часа / 24 часа / 30 дней. Превышение лимита отрисовывается на графике желтым цветом.
Обратите внимание, что суточные превышения будут отображены только на графике «30 дней»; на графиках за 2 и 24 часа превышений видно не будет (если, конечно, суточный лимит нагрузки не был превышен за 15 минут или 1 час соответственно).