У меня есть пара серверов, на которых размещается один сайт электронной коммерции Magento с умеренным трафиком (60 000 просмотров страниц в день по данным Google Analytics, я думаю, около 80 000 запросов на самом сервере). Сервер базы данных работает плавно и быстро, за исключением редких случайных сбоев, но сервер apache время от времени падает.
Я настроил magento для использования рекомендованного PHP-кэширования (APC), а также для хранения своих собственных файлов кэша в 1,5-гигабайтных tmpfs (эти tmpfs регулярно переполняются, и у меня запущен скрипт для очистки файлов кэша, когда tmpfs заполнено более 80%). Я обслуживаю большинство изображений с облачного фронта амазонки. Недавно я настроил nginx в качестве обратного прокси для apache (nginx также обслуживает статические файлы). Я настроил apache в меру своих возможностей - keepalives и hostnamelookup отключены, а prefork настроен следующим образом:
<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показывает значение Айоваит от 0 до 0,2%.
Я немного застрял. То, что я мало знаю, говорит мне, что проблема в том, что процессор перегружен из-за комбинации выполняемого кода и количества пользователей. Но я не достаточно опытен, чтобы быть уверенным, что это проблема. Если это проблема, я думаю, что решения должны либо улучшить код, либо разделить сайт, размещенный на двух VPS, с помощью балансировщика нагрузки.
Итак, я думаю, мои вопросы:
- Что еще я могу сделать, чтобы найти проблемы или узкие места на сервере?
- Есть ли какие-либо очевидные изменения, которые я могу внести в конфигурацию сервера, чтобы улучшить это?
- Это хорошая идея, чтобы настроить автоматическую систему для перезапуска Apache, когда нагрузка превышает определенный уровень?
- Исходя из вышесказанного, насколько вероятно, что сайт перерос сервер?
Редактировать:
Я нашел что-то странное - / var / spool / mail / root был большим ... 38 гиг. Это звучит ... нездорово. Может ли это быть проблема?
источник
Ответы:
Как вы заметили, Magento и Zend Framework довольно загружены процессором. Лучший способ избежать нагрузки на процессор - просто рендерить любой контент только один раз, пока он не изменится. Большинство частей вашего каталога не меняются так часто, и часто только динамические блоки на вашей странице или блок «Самые популярные элементы».
Я бы предложил поместить кеш Varnish перед Apache. Это дает вам высокопроизводительное кэширование страниц, которое может серьезно разгрузить ваш стек LAMP. Мы недавно пережили очень публичный запуск веб-сайта благодаря Varnish, и я был очень впечатлен скоростью и низкой загрузкой процессора. Лак является бесплатным и достаточно гибким, чтобы кэшировать целые страницы или кэшировать только относительно статичные части и динамически включать корзину.
Тем не менее, Varnish не будет кэшировать много при установке Magento по умолчанию, так как есть много динамического контента для каждого пользователя, файлов cookie и т. Д. Модуль Magento, такой как « PageCache powered by Varnish », модифицирует Magento для хорошей работы с Varnish. Он также предоставляет файл конфигурации Varnish, соответствующий настройке Magento. Эти два вместе делают для очень эффективной установки. Это коммерческий модуль, но гораздо более доступный, чем более мощный сервер.
Части, которые вы загружаете в CDN или Nginx, не являются вашей реальной проблемой, хотя и помогают. Даже Apache может обрабатывать довольно много статических запросов. Вам необходимо кэшировать материал, который требует усилий для генерации снова и снова, то есть ваши динамические части.
источник
Обычно я устанавливаю MaxRequestsPerChild тысячами - обычно около 10 000.
Вы говорите, что у вас есть «рекомендуемое кэширование PHP» - но у вас установлен APC? Наконец, сколько пользователей вы видите, одновременно попадающих на сайт. Если у вас есть расширенная статистика Apache, вы сможете увидеть, сколько процессов Apache фактически находятся в состоянии Running за один раз.
800 обращений к файлу APC в секунду, и еще 200 пользовательских кешей - много. Если это будет двухъядерный или четырехъядерный процессор, я бы ожидал, что он будет в порядке. Если база данных действительно идет в ногу, то, по крайней мере, прямо сейчас, возможно, лучше всего получить машину большего размера и больше процессоров.
источник
Ваша средняя нагрузка слишком высока для двухъядерного VPS. 8 должно быть макс.
У меня был хороший успех с использованием mod_pagespeed и события MPM для Magento. Я бы рекомендовал перейти на использование события MPM и установить mod_pagespeed.
Дополнительная информация о Event MPM: документация по Apache event MPM
И mod_pagespeed: Google Code: mod_pagespeed
Если у вас по-прежнему возникают проблемы с нагрузкой даже после внесения вышеуказанных изменений, вы можете рассмотреть возможность перехода на другой, лучший план VPS.
источник
Как подсказывает Алистер, значение MaxRequestsPerChild, равное 400, абсурдно мало.
Средняя загрузка очень высока - но 60 000 просмотров страниц в день - это не много трафика.
сколько процессов вы обычно обслуживаете?
Я не знаком с Magento, но похоже, что с этой настройкой что-то не так. Я ожидаю, что вы сможете получить значительно большую пропускную способность при более низком уровне нагрузки.
Иди, возьми копию книги Стива Соудерса и прочитай ее. Включите сжатие для всего исходящего содержимого HTML (статического и динамического). И убедитесь, что у вас есть хороший конфиг кеширования. Начните регистрировать% D в файле access_log и создайте несколько инструментов для анализа данных / выделения медлительности. Похоже на MySQL.
Попробуйте mysqltuner.pl и посмотрите, не обнаружит ли он каких-либо проблем.
источник
Я запускаю аналогичную настройку, но с 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)?
источник
Когда вы используете VPS, вы разделяете процессор. Я бы порекомендовал вам поговорить с хостом, чтобы переместить VPS на менее загруженное оборудование или выделиться.
Из-за общего процессора ваши приложения не могут работать вовремя и продолжают получать в очередь, создавая более высокие запросы для обработки, а также накладные расходы, которые идут с ним. В конце концов, возникает условие, при котором Apache, php или mysql максимально допустили свои ограничения, и это вызывает проблемы.
Итог есть. VPS является в основном общим процессором. Ваш хост может размещать слишком много учетных записей VPS на одном процессоре.
Если вы хотите в полной мере использовать выделенный ЦП, либо попросите лучший Сервер с меньшим количеством VPS, если это возможно (переместите хост, хотя это хлопотно), либо выделите его.
Вы также можете полностью выбрать Amazon и не беспокоиться о nginx, используя их балансировщик нагрузки, который можно настроить несколькими серверами в своем облаке за несколько кликов.
папка /var/mail.../root hue означает, что она собирает много писем, которые обычно приходят из ваших приложений. Например, глючный php-скрипт пытается отправить электронное письмо, или все задания cron настроены так, чтобы отправлять вам по электронной почте информацию о состоянии запуска cron и выводе. Вы можете заглянуть в почту и посмотреть, что файл имеет. Я угадываю сообщения об ошибках, чтобы вы могли найти, откуда он.
Я добавлю больше, если вам нужна дополнительная информация и, возможно, мне тоже понадобится некоторая информация
источник