CPU измеряется в % потребления за 1 минуту. 100% - значит что ваш скрипт использует одно ядро процессора 60 секунд времени. Если у вас выше 100% - это значит что ваши скрипты используют больше 1го ядра процессора одновременно и очень интенсивно.

Важно: лимит на тарифе (например 10% c Первого по Шестой тариф) - это не ограничение вашего скрипта в процессорном времени, а показатель того, что ваш сайт или сайты содержат проблемы производительности или находятся под не целевой нагрузкой, например конкурент скачивает ваш сайт, или злоумышленик пытается взломать.

Что делать: первым делом зайдите в "Использование ресурсов". Если у вас больше одного сайта, то проверьте откуда идет значительная нагрузка. Если по MySQL CPU (зеленый график) - то вам надо проверить закладку "По пользователям MySQL", если PHP CPU (голубой график) - то "по доменам". Проверяя графики по MySQL или по доменам, вы выясните на какой из сайтов идет нагрузка. 

После этого рекомендуется проверить лог доступа к сайту (файл в папке  ~/domains/logs/имя домена.log. Если у вас его нет, вам надо включить его в настройках домена в Панели Управления -> Домены -> Редактировать. Учтите что если вы не включите awstats - лог будет расти и занимать много места.) и выяснить какие запросы шли к серверу на момент нагрузки. Попробовать их повторить самостоятельно и проверить появились ли пики нагрузки на графиках. Так же рекомендуем временно включить модуль devel и посмотреть показатели времени генерации страницы и времени потраченного на запросы в базу. Это может быть отправной точкой к пониманию проблемы. 

Если у вас есть опыт работы с xhprof, вы можете активировать его в настройках devel.

xhprof directory: /usr/share/xhprof

XHProf URL: http://ваш вебсайт/xhprof

Не забудьте отключить модуль devel и xhprof после того, как закончите работу на сайте. Они могут создавать дополнительную нагрузку, а xhprof дополнительно создает много файлов в /tmp директории, что повлияет на вашу дисковую квоту.

Частые случаи:

Много проблем с нагрузкой можно решить включив встроенное в Drupal кеширование на странице Производительность вашего сайта. Следует включить опции Кэшировать страницы для анонимных пользователей и Кэширование блоков и выставить для них время жизни кеша (обязательно ограничивайте Максимальное время так как если оставить его без указания времени возможен быстрый рост БД сайта и как следствие выход за пределы дисковой квоты)

Секция Оптимизация пропускной способности позволяет включить Объединение и сжатие файлов CSS и Объединение файлов JavaScript это так же полезные опции позволяющие уменьшить время отклика Вашего сайта(но при превышении квоты на дисковое пространсво возможны проблемы с версткой и скриптами так как новые файлы не смогут создаваться)

Отметим что включение gzip сжатия страниц крайне не рекомендуеться так как сжатие страниц у нас идет на уровне сервера и включение данной опции только увеличивает нагрузку на сервер без ощутимого результата.

В нашем опыте анализа сайтов наших клиентов мы определили что нагрузку на CPU и на php и на MySQL помогает снять включение кеширования VIEWS представлений. Этим снимается большая часть проблем нагрузки. 

Так же следует обратить внимание на модули Statistics, Search - при большом количестве материалов они дают повышенную нагрузку(вместо встроенного поиска следует поискать альтернативу например модуль shpinxsearch, если Вам нужна статистика - поискать альтернативы для нужных Вам параметров) Модуль Database Logging при большом количестве посещений так же может давать дополнительную нагрузку на сайт - следует устранить все предупреждения и ошибки которые туда записываются и после отключить его.

Отмечено что модуль XMLSitemap ветки 1.х имеет большие проблемы с производительностью и переход на версию 2.х обычно решает проблему

Крайне рекомендуется настроить системный крон, вместо poormanscron на Drupal 6 или стандартной настройки на Drupal 7 - регулярный запуск cron задач производит очистку устаревших кеш записей и обслуживание Вашего сайта.

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

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

Comments (5)

sa.serge... #
11 years 47 weeks ago
ancient

Спасибо за описание, но одна орфографическая ошибочка закралась в предложение:

"Учтите что если вы не включите awstats - лог будет рости и занимать много места" 
Правильно "расти" .

Коммент после правки можно удалить :)


m.vitaly #
11 years 47 weeks ago
sysadmin

Большое спасибо за обратную связь, поправили.

Best regards, Vitaly
anemon #
11 years 45 weeks ago
ancient

Спасибо за xhprof, иногда это просто незаменимый инструмент

ooobsc #
11 years 45 weeks ago
ancient

xhprof +1
Спасибо!

Drupalov #
11 years 45 weeks ago
ancient

"Отметим что включение gzip сжатия страниц крайне не рекомендуеться" (ь - лишний)

Не так, не "не рекомендуется", а крайне ОПАСЕН!

Ваш упаковщик не смотрит, сжаты ли страницы, и сжимает их во 2-ой раз (если был включен gzip на сайте).

Браузер получает страницу как хорошую (200), но пишет:

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

Видимо для админа всё работает ОК (пока цела его сессия), но анонимы и боты получают данную пустую страницу, вместо настоящей!!!

Поправьте упаковщик или исправьте текст.

Чтобы выйти из такой ситуации, когда никто не может войти на сайт (и даже админ!), надо:
- войти в phpMyAdmin и очистить все таблицы кэша
- снять эту опцию в админке

Я в декабре экспериментировал и испытал все это на себе...