(Я гуглил и искал этот форум часами, нашел несколько тем, но ни одна из них не сработала для меня)
я использую Wordpress с участием: Лак + Nginx + PHP-FPM + APC + W3 Общий кэш + PageSpeed.
Поскольку я использую Varnish, впервые звоню www.mysite.com он использует всего 10% ЦП. При повторном вызове он будет закеширован. Проблема в передача параметра запроса в URL.
Всего за 1 запрос (www.mysite.com?1=1) это проявляется в top:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
7609 nginx 20 0 438m 41m 28m S 11.6 7.0 0:00.35 php-fpm
7606 nginx 20 0 437m 39m 26m S 10.3 6.7 0:00.31 php-fpm
После полной загрузки страницы указанные выше процессы все еще активны. И через 2 секунды они заменяются еще двумя процессами php-fpm (ниже), которые активны в течение 3 секунд.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
7665 nginx 20 0 444m 47m 28m S 20.9 7.9 0:00.69 php-fpm
7668 nginx 20 0 444m 46m 28m R 20.9 7.9 0:00.63 php-fpm
40% ЦП использование только для 1 запроса не кешируется!
Странные вещи:
Когда я пытаюсь сделать 10 запросов (нажатие клавиши F5 10x), сервер перестает обслуживать и в журнале php-fpm появляется:
ВНИМАНИЕ: сервер [pool www] достиг значения max_children (10), рассмотрите возможность его увеличения
Я увеличил это значение до 20, проблема та же.
я использую pm=ondemand (pm.max_children=10 и pm.max_requests=500).
Первоначально я использовал pm=dynamic (pm.max_children=10, pm.start_servers=1, pm.min_spare_servers=1, pm.min_spare_servers=2, pm.max_requests=500) и случилась та же проблема.
Кто-нибудь может помочь, плз? Любая помощь будет оценена по достоинству!
PS:
Трудно отладить причину проблемы.
Я бы сказал, уменьшите вашу установку.
Вы используете: Varnish + Nginx + PHP-FPM + APC + W3 Total Cache + PageSpeed
Зачем нужен лак? nginx также может выполнять кеширование статических страниц. Взгляни на fastcgi_cache
PHP-FPM и APC должны быть в порядке, просто подумайте о том, что у APC достаточно памяти, чтобы все файлы можно было кэшировать без проблем с памятью и фрагментации.
Зачем вам нужен W3 Total Cache? В зависимости от параметров конфигурации это может сильно нагружать процессор, например для минимизации кода или кеширования страниц или вызовов базы данных на диск ...
То же самое с mod_pagespeed - Это оболочка, которая обрабатывает ваши выходные файлы, а также добавляет сложности, используя циклы ЦП.
Итак - если вам нужен более быстрый веб-сайт, я бы сказал, распутать этот беспорядок и упростить его:
Избавьтесь от Varnish: если у вас нет серьезных вариантов его использования. nginx может отлично выполнять кеширование и настраивать nginx для использования fastcgi_cache и используйте сокет для общения с PHP-FPM.
Избавьтесь от W3TC: используйте memcached и и Плагин кеширования объектов memcache. Это ваш DB-Cache и Object-Cache. Для кеширования полных страниц просто используйте nginx или Varnish, если необходимо. Вы можете избавиться от настройки кеширования полной страницы для nginx или Varnish, если используете batcache для кеширования целых страниц в memcached. Также попробуйте использовать сокеты для memcached.
Избавиться от mod_pagespeed. Прочтите, какие оптимизации он делает для вас, и попробуйте вручную применить их к теме вашего блога или изображениям. Если вы используете gzip в nginx, большинство вещей в любом случае не должны иметь значения.
Включите кэш запросов MySQL и найдите параметры MySQL, оптимизированные для производительности. Если у вас много записей (например, много комментариев), подумайте об использовании InnoDB.
Используйте PHP 5.4 или даже PHP 5.5. В эти выпуски было внесено много улучшений производительности и памяти, которые должны дать вам некоторое ускорение и экономию памяти.
Более продвинутые подходы:
Взгляни на профилировщик xdebug. Это должно дать вам краткое изложение того, какая функция действительно потребляет много процессора. На странице приведены некоторые сведения о том, как просматривать сгенерированные данные с помощью kcachegrind.
Вы можете попытаться посмотреть количество системных вызовов, используя strace в дереве процессов. Вам нужно будет -f флаг для этого и, вероятно, просто статистика печати -c должно быть достаточно, чтобы узнать о возможной проблеме.
Я бы сказал, применяйте принцип KISS и используйте производительность или настройку только в том случае, если у вас есть четкий пример использования для этого, и инструменты показывают улучшение с помощью профилирования.