У меня есть пара серверов, на которых размещен один сайт электронной коммерции Magento с умеренным трафиком (60 тысяч просмотров страниц в день сообщается из аналитики Google, я думаю, около 80 тысяч сообщается на самом сервере). Сервер базы данных работает плавно и быстро, если не считать редкой случайной икоты, но сервер Apache время от времени падал.
Я настроил magento для использования рекомендованного кеширования PHP (APC), а также для хранения собственных файлов кеша в 1,5-гигабайтных tmpfs (этот tmpfs регулярно становится довольно заполненным, и у меня есть скрипт для очистки файлов кеша, когда tmpfs заполнено более чем на 80%). Я использую большинство изображений из Amazon Cloudfront. Недавно я настроил nginx в качестве обратного прокси для apache (nginx также обслуживает статические файлы). Я настроил apache в меру своих возможностей - сообщения поддержки активности и поиск имени хоста отключены, а предварительная вилка настроена следующим образом:
<IfModule prefork.c>
StartServers 50
MinSpareServers 50
MaxSpareServers 100
ServerLimit 512
MaxClients 256
MaxRequestsPerChild 400
</IfModule>
Я не отключал файлы .htaccess, а ведение журнала доступа включено. Я знаю, что есть некоторые модули, которые я могу отключить. Я не уверен, какой эффект будет иметь любое из этих трех изменений, если таковые имеются.
Сервер apache - это VPS с 6 гигабайтами оперативной памяти. На момент написания сервер сообщает load average: 17.77, 18.27, 49.76, но свободной оперативной памяти около 2 Гб. Когда все идет совсем плохо, нагрузка достигает 120+ и остается там - перезапуск apache возвращает сайт в рабочее состояние, а нагрузка - вниз.
vmstat (пока сервер сообщает о загрузке выше), я думаю, показывает, что значение простоя ЦП колеблется от 0 до 70 или около того. iostat показывает значение iowait от 0 до 0,2%.
Я немного застрял. То немногое, что я знаю, говорит мне о том, что проблема в том, что процессор перегружен в результате комбинации выполняемого кода и количества пользователей. Но у меня недостаточно опыта, чтобы быть уверенным в том, что это проблема. Если это проблема, я думаю, что решение состоит в том, чтобы либо улучшить код, либо разделить хостинг сайта на два VPS с балансировщиком нагрузки.
Итак, я предполагаю, что мои вопросы:
Редактировать:
Нашел что-то странное - / var / spool / mail / root было большим ... 38 гиг. Звучит ... нездорово. Может ли это быть проблема?
Обычно я настраиваю MaxRequestsPerChild на несколько тысяч - обычно около 10 000.
Вы говорите, что у вас есть «рекомендуемое кеширование PHP», но установлен ли у вас APC? Наконец, сколько пользователей вы видите, посещающих веб-сайт одновременно. Если у вас есть расширенная статистика Apache, вы сможете увидеть, сколько процессов Apache фактически одновременно находятся в состоянии выполнения.
800 обращений к файлу APC в секунду, а еще 200 пользовательских кешей - это много. Если это двухъядерный или четырехъядерный процессор, я бы ожидал, что он будет в порядке. Если база данных действительно идет в ногу со временем, то покупка машины большего размера и большего количества процессоров может быть лучшим решением, по крайней мере, прямо сейчас.
Как вы заметили, Magento и Zend Framework довольно загружают процессор. Лучший способ избежать загрузки ЦП - просто отрисовывать любой контент только один раз, пока он не изменится. Большинство частей вашего каталога не так часто меняются, и часто только блок корзины покупок на вашей странице или блок «самые популярные товары» являются единственными динамическими частями.
Я бы предложил поставить Лак кеш перед Apache. Это дает вам высокопроизводительное кэширование страниц, которое может серьезно разгрузить ваш стек LAMP. Недавно мы пережили публичный запуск веб-сайта благодаря Varnish, и я был серьезно впечатлен скоростью и низкой загрузкой процессора. Varnish является бесплатным и достаточно гибким, чтобы кэшировать целые страницы или кэшировать только относительно статические части и динамически включать корзину.
Однако Varnish не будет много кэшировать при установке Magento по умолчанию, поскольку существует много динамического контента для каждого пользователя, файлов cookie и т. Д. Модуль Magento, такой как 'PageCache на базе Varnish'изменяет Magento, чтобы он работал с Varnish. Он также предоставляет файл конфигурации Varnish, который соответствует настройке Magento. Эти два вместе составляют очень эффективную установку. Это коммерческий модуль, но гораздо более доступный, чем мог бы быть более мощный сервер.
Части, которые вы выгружаете на CDN или Nginx, не являются вашей реальной проблемой, хотя это действительно помогает. Даже Apache может обрабатывать большое количество статических запросов. Вам нужно кэшировать то, что требует усилий для создания снова и снова, то есть ваши динамические части.
Я запускаю аналогичную настройку, но с nginx / php-fpm / apc (opcode и fast_backend / memcached (slow_backend). Я считаю, что php является самой большой проблемой ресурсов, вероятно, потому что magento либо безумно большой, либо просто плохо закодирован. посмотрите, что именно ест ресурсы, может быть это php как в моем случае?
В дополнение к тому, что пишет Martijn Heemels, есть модуль лака с открытым исходным кодом, который вы можете попробовать. Проверять, выписываться http://moprea.ro/2011/may/6/magento-performance-optimization-varnish-cache-3/ и https://github.com/madalinoprea/magneto-varnish.
Я тестировал его только в тестовой среде, и пока все хорошо.
Вы сохраняете сеансы в базе данных или на диске (и если да, то в tmpfs)?
Как намекает Алистер, значение MaxRequestsPerChild, равное 400, абсурдно низкое.
Средняя нагрузка очень высока, но 60 тысяч просмотров страниц в день - это не так много трафика.
сколько процессов у вас обычно обслуживает запросы?
Я не знаком с Magento, но похоже, что с этой настройкой что-то не так. Я ожидал, что вы сможете получить значительно большую пропускную способность при более низком уровне нагрузки.
Пойди, возьми книгу Стива Содерса и прочитай ее. Включите сжатие для всего исходящего HTML-содержимого (статического и динамического). И убедитесь, что у вас есть хорошая конфигурация кеширования. Начните регистрировать% D в вашем файле access_log и создайте несколько инструментов для анализа данных / выявления медлительности. Аналогично MySQL.
Попробуйте mysqltuner.pl и посмотрите, не обнаруживает ли он каких-либо проблем.
Ваша средняя нагрузка слишком высока для двухъядерного VPS. 8 должно быть макс.
Я добился больших успехов в использовании mod_pagespeed и событийного MPM для Magento. Я бы порекомендовал перейти на использование событийного MPM и установить mod_pagespeed.
Подробнее о Event MPM: Документация Apache Event MPM
И mod_pagespeed: Код Google: mod_pagespeed
Если у вас по-прежнему возникают проблемы с загрузкой даже после внесения вышеуказанных изменений, вы можете подумать о переходе на другой, лучший план VPS.
Когда вы используете VPS, вы разделяете процессор. Я бы порекомендовал вам поговорить с вашим хостом, чтобы переместить ваш VPS на менее загруженное оборудование или перейти на выделенный.
Из-за общего ЦП ваши приложения не могут работать вовремя и продолжают стоять в очереди, увеличивая количество запросов, которые необходимо обработать, а также накладные расходы, связанные с этим. В конце концов возникает условие, при котором Apache, php или mysql превысили свои собственные пределы, и это вызывает проблемы.
Итог есть. VPS - это, по сути, разделяемый ЦП. Возможно, ваш хост размещает слишком много учетных записей VPS на одном процессоре.
Если вы хотите в полной мере использовать выделенный процессор, либо попросите лучший сервер с меньшим количеством VPS, если это возможно (переместите хост, хотя это проблематично), либо выделите его.
Вы также можете полностью выбрать Amazon и не беспокоиться о nginx, использующем их балансировщик нагрузки, который всего за несколько кликов можно настроить для всех ваших серверов в их облаке.
папка /var/mail.../root имеет оттенок, что означает, что она собирает много писем, которые обычно приходят из ваших приложений. Например, ошибочный скрипт php пытается отправить электронное письмо или все задания cron настроены на отправку вам по электронной почте статуса запуска cron и вывода. Вы можете заглянуть внутрь почты и посмотреть, что в файле. Я предполагаю, что это сообщения об ошибках, чтобы вы могли узнать, откуда они.
Я добавлю больше, если вам понадобится дополнительная информация, и, возможно, мне тоже понадобится какая-то информация