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 версии часто имеют проблемы с уязвимостями либо производительностью.
Регулярное обновление ваших сайтов обезопасит их от злоумышленников и часто помогает снизить нагрузку.
- Login to post comments
Comments (5)
Спасибо за описание, но одна орфографическая ошибочка закралась в предложение:
"Учтите что если вы не включите awstats - лог будет рости и занимать много места"
Правильно "расти" .
Коммент после правки можно удалить :)
Большое спасибо за обратную связь, поправили.
Спасибо за xhprof, иногда это просто незаменимый инструмент
xhprof +1
Спасибо!
"Отметим что включение gzip сжатия страниц крайне не рекомендуеться" (ь - лишний)
Не так, не "не рекомендуется", а крайне ОПАСЕН!
Ваш упаковщик не смотрит, сжаты ли страницы, и сжимает их во 2-ой раз (если был включен gzip на сайте).
Браузер получает страницу как хорошую (200), но пишет:
Ошибка в типе содержимого
Страница, которую вы пытаетесь просмотреть, не может быть показана, так как она использует неверную или неподдерживаемую форму компрессии.
Пожалуйста, свяжитесь с владельцами веб-сайта и проинформируйте их об этой проблеме.
Видимо для админа всё работает ОК (пока цела его сессия), но анонимы и боты получают данную пустую страницу, вместо настоящей!!!
Поправьте упаковщик или исправьте текст.
Чтобы выйти из такой ситуации, когда никто не может войти на сайт (и даже админ!), надо:
- войти в phpMyAdmin и очистить все таблицы кэша
- снять эту опцию в админке
Я в декабре экспериментировал и испытал все это на себе...