Оптимизация Apache для работы с WordPress

5 апр. 2011 г., 03:34:32
Просмотры: 6.19K
Голосов: 10

Здравствуйте,

У меня сайт на WordPress с более чем 150 тыс. просмотров в день.

Он работает на процессоре Intel Core i5 760 @ 2.80GHz, CentOS и 4 ГБ оперативной памяти.

Проблема в том, что WordPress потребляет слишком много оперативной памяти, и через некоторое время сервер перегружается, а память заканчивается. Я пробовал различные настройки Apache, но ничего не помогает. После перезапуска Apache сайт работает нормально, но через час-два снова перегружается.

Есть ли у кого-нибудь советы, которые могут мне помочь?

Кстати, я использую WP-Super Cache.

ОБНОВЛЕНИЕ: Дополнительная информация

Вот мой список плагинов:

  • Akismet
  • Contact Form 7
  • Domain Mirror
  • Faster Image Insert
  • IntenseDebate
  • Role Manager
  • SexyBookmarks
  • Smart Youtube
  • Star Rating for Reviews
  • Thumbnail For Excerpts
  • WP-Polls
  • WP-SWFObject
  • WP Super Cache

Что касается настроек, я пробовал некоторые советы отсюда

Мои текущие настройки:

<IfModule prefork.c> 
  StartServers       8
  MinSpareServers    5 
  MaxSpareServers   20 
  ServerLimit      256 
  MaxClients       200 
  MaxRequestsPerChild  1000
</IfModule>

<IfModule worker.c> 
  StartServers       2 
  MaxClients         150
  MinSpareThreads     25 
  MaxSpareThreads    75
  ThreadsPerChild     25
  MaxRequestsPerChild  1000 
</IfModule>

Timeout 120 
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 2

Также вот мой my.cnf:

[mysqld]
set-variable=local-infile=0
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# По умолчанию используется старый формат паролей для совместимости с mysql 3.x
# клиентами (использующими пакет совместимости mysqlclient10).
old_passwords=1

# Отключение символических ссылок рекомендуется для предотвращения различных рисков безопасности;
# чтобы это сделать, раскомментируйте следующую строку:
# symbolic-links=0

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

ОБНОВЛЕНИЕ

Текущее использование памяти:

ps -ylC httpd --sort:rss

S   UID   PID  PPID  C PRI  NI   RSS    SZ WCHAN  TTY          TIME CMD
S   504  8446  8444  0  78   0  7884 59507 554050 ?        00:00:00 httpd
S   504 29164  8444  0  78   0 13380 87043 -      ?        00:00:00 httpd
[...остальные процессы...]

Изменяет ли это ваши рекомендации для меня?

4
Комментарии

Всегда полезно упомянуть, какие другие плагины вы используете, такие как xml карты сайта, SEO-вещи, сканирование на наличие вредоносных программ, связанные посты и т.д., которые могут убить ваш сервер.

Wyck Wyck
5 апр. 2011 г. 03:38:15

+1 к тому, что сказал @Wyck. Почти все проблемы с производительностью и памятью, которые я вижу, являются результатом неправильно работающего плагина.

MikeSchinkel MikeSchinkel
5 апр. 2011 г. 03:47:33

Также можете перечислить доработки Apache, которые вы пробовали, а также содержимое вашего файла my.cnf и httpd.conf. Общая проблема с Apache заключается в том, что слишком высокие значения max requests и max requests per child не позволяют процессам завершаться и просто потребляют память.

Chris_O Chris_O
5 апр. 2011 г. 03:53:33

Как сказал @Anu ниже, ваши максимальные клиенты и MaxRequest per child, вероятно, установлены слишком высоко. Попробуйте уменьшить Max Clients до 125 и MaxRequestPerChild до примерно 500. Также измените ваши MaxKeepAlive запросы до примерно 50 и уменьшите ваш Timeout до 15 или 20.

Chris_O Chris_O
6 апр. 2011 г. 08:29:59
Все ответы на вопрос 4
3

Souljacker,

Сначала я бы посмотрел на ваши плагины. Star Ratings for Reviews не обновлялся более 3 лет и, похоже, сильно нагружает базу данных. Я заметил сырой SQL с INNER JOIN, который выглядит проблемным.

На стороне сервера следует реализовать кэширование объектов. APC является стандартом де-факто и даст наилучшие результаты.

После установки APC переключитесь на W3 Total Cache или APC Object Cache Backend от Mark Jaquith, чтобы полностью использовать его преимущества.

Настройки вашего httpd.conf выглядят нормально. Судя по вашему my.cnf, вы не используете кэширование запросов MySQL, кэширование потоков или управление размерами буферов.

Вы можете использовать скрипт для настройки конфигурации my.cnf. Я предпочитаю mysqltuner, а tuning primer тоже очень хорош.

Mysqltuner выводит рекомендации и дает указания по настройке на основе использования вашей базы данных.

На моем сервере с 12 ГБ оперативной памяти настройки выглядят так. (Это всего лишь пример, не используйте эти настройки!!!)

key_buffer              = 512M
max_allowed_packet      = 32M
thread_stack            = 1M
thread_cache_size   = 128M

myisam-recover         = BACKUP
max_connections        = 60
table_cache            = 5000
table_definition_cache = 1024
thread_concurrency     = 16

# * Конфигурация кэша запросов

query_cache_type        = 1
query_cache_limit       = 4M
query_cache_size        = 48M
max_heap_table_size     = 512M
tmp_table_size          = 512M
join_buffer_size        = 3M
sort_buffer_size        = 8M
read_buffer_size        = 8M
read_rnd_buffer_size    = 8M
myisam_sort_buffer_size =16M


log_slow_queries        = /var/log/mysql/mysql-slow.log
long_query_time = 1

Как уже упоминалось, использование Nginx значительно снизит нагрузку на сервер, если вы готовы разобраться с настройками. Я написал руководство по установке и настройке Apache с Nginx в качестве обратного прокси.

Надеюсь, это поможет.

5 апр. 2011 г. 12:13:09
Комментарии

wp-supercache теперь также поддерживает использование APC в качестве кэша объектов - однако и для w3 total cache, и для wp-supercache я наблюдал странное поведение с кэшированием объектов, особенно в контексте авторизованных пользователей. Не уверен, связано ли это с моим сайтом, но будьте внимательны и тщательно тестируйте!

anu anu
5 апр. 2011 г. 12:15:24

также, хотя mysqltuner (и установка mtop) полезны, я обнаружил, что наибольший прирост производительности достигается включением логов медленных запросов и последующим использованием EXPLAIN для понимания причин медленной работы определенных запросов.

anu anu
5 апр. 2011 г. 12:17:28

Очень хорошие замечания. Я забыл упомянуть логи медленных запросов. Tuning primer подскажет вам включить их, если вы их не используете.

Chris_O Chris_O
5 апр. 2011 г. 12:21:03
7

Взгляните сюда: Советы по производительности для большой пользовательской базы — это полезный набор вещей, на которые стоит обратить внимание, выходящих за рамки просто Apache.

При оптимизации производительности очень важно рассмотреть всю инфраструктуру, чтобы выявить потенциальные проблемы. Например, на одном из моих сайтов я в итоге обнаружил проблему, которая изначально выглядела как нехватка памяти в Apache (Apache исчерпывал память при средней нагрузке), но на самом деле была вызвана медленным SQL-запросом. Решение заключалось в добавлении дополнительного индекса к таблице комментариев.

Также установите APC или другой кеш op-кода для PHP.

[Обновление]

Вполне вероятно, что ваш параметр MaxClients установлен слишком высоко. Если все 200 процессов активны и в среднем используют около 20 МБ на процесс, то это уже 4 ГБ, не учитывая MySQL и другие процессы. Уменьшите значение MaxClients и продолжайте исследовать, где именно кроется проблема.

Вы можете проверить, сколько памяти использует каждый процесс Apache, с помощью следующей команды:

ps -ylC httpd --sort:rss  

(замените httpd на apache2, если используете Ubuntu)

5 апр. 2011 г. 10:27:34
Комментарии

голосуйте за xcache вместо APC, но строго версии 1.3.x и выше

petermolnar petermolnar
5 апр. 2011 г. 10:44:40

APC — это правильный выбор. В моих тестах он превосходит xcache, плюс в конечном итоге он будет включён в состав PHP.

Chris_O Chris_O
5 апр. 2011 г. 11:47:15

да, согласно тестам, которые я видел, разница между APC и другими акселераторами опкода довольно незначительна, поэтому простота установки и тот факт, что APC скоро станет частью дистрибутива PHP (с PHP6), для меня важнее, но главное — установить один из них!

anu anu
5 апр. 2011 г. 11:57:06

Глядя на Plesk, я вижу, что ТОЛЬКО Apache использует слишком много памяти. Все остальные компоненты системы используют довольно мало памяти.

Souljacker Souljacker
5 апр. 2011 г. 17:18:10

@souljacker никто не утверждает, что MySQL сам по себе использует слишком много памяти (на самом деле, скорее всего вам даже нужно будет увеличить доступную для него память). Но, если вы прочитали, что я написал, медленные SQL-запросы могут быть причиной проблем с OOM в Apache, поскольку процессы Apache ожидают ответа от MySQL, и поэтому запускается больше процессов. Это не значит, что это ваша проблема - вам нужно провести расследование, чтобы выяснить, в чем проблема.

anu anu
5 апр. 2011 г. 18:08:08

Я установил APC. Это все? Я просто установил или мне нужно что-то настроить? Кажется, ничего не изменилось

Souljacker Souljacker
5 апр. 2011 г. 20:10:37

Можете ли вы получить доступ к apc_display.php? Вы читали документацию APC? Кроме того, дело не только в установке APC — вы читали мой ответ и другие ответы? Вряд ли вы получите один ответ, который решит все ваши проблемы — вам придется разбираться с этим самостоятельно.

anu anu
6 апр. 2011 г. 08:04:49
Показать остальные 2 комментариев
5

Сравните Nginx и Apache и сделайте выбор:

Я только что перешел с Apache на Nginx, и это заняло около 10 минут:

  1. скачать/установить Nginx (wget / yum install / apt-get / ...)
  2. изменить конфигурационный файл nginx, чтобы он указывал на вашу веб-директорию (см. примеры http://kbeezie.com/view/nginx-configuration-examples/ )
  3. запустить nginx

готово.

Я также перешел на php-fpm одновременно, и это заняло около 20 минут:

  1. скачать php
  2. настроить с необходимыми библиотеками (например, suhosin) (или изменить c-код с вашими собственными шутливыми сообщениями) (не забудьте убрать специфичные для Apache расширения и включить zlib для установки/распаковки плагинов WP прямо из WP)
  3. собрать и установить php (configure/make)
  4. изменить конфигурационный файл nginx, чтобы включить вызовы php-fpm
  5. запустить php-fpm и перезапустить nginx

готово

(добавьте файлы запуска /etc/init.d там, где это необходимо)

Я сам не проводил тесты производительности, просто слепо последовал за "остальными"

Вне рамок этого ответа: Я также планирую отказаться от MySQL и использовать MariaDB (GPL) вместо него.

5 апр. 2011 г. 08:43:03
Комментарии

Вы также можете получить облегченный Apache просто за счет правильной настройки. Не поймите меня неправильно, Nginx или любой другой облегченный веб-сервер, например lighthttpd, отличные. Мой совет - использовать Apache для динамического контента, а Nginx/lighthttpd для статического.

Roman Roman
5 апр. 2011 г. 10:14:59

было бы лучше, если бы WordPress был переписан на сервлетах C усмешка Для динамического/статического: я поражен тысячами постов в блогах о различиях, а я просто хочу поддерживать 1 веб-сервер, это проще.

edelwater edelwater
5 апр. 2011 г. 10:25:04

Я с вами согласен. Поддержка одного веб-сервера все равно проще, чем двух. Но вместо того, чтобы выбрасывать Apache и устанавливать новый веб-сервер только потому, что он "быстрее" в конфигурации по умолчанию, это не решение.

Roman Roman
5 апр. 2011 г. 10:48:26

@Roman Wünsche возможно, вы могли бы поделиться советами о том, как получить облегченную конфигурацию apache, которая будет превосходить nginx?

anu anu
5 апр. 2011 г. 12:10:23

@Roman Wünsche Именно это я и пытаюсь сделать, но пока не получилось

Souljacker Souljacker
5 апр. 2011 г. 20:03:22
2

Работа с конфигурациями prefork и Worker может быть сложной, изменение некоторых значений определенно поможет улучшить производительность и снизить использование оперативной памяти. Также стоит помнить, что Apache резервирует часть памяти, что не означает, что у вас заканчивается RAM. Ознакомьтесь с этой статьей для получения лучших советов по оптимизации.

15 янв. 2014 г. 13:14:29
Комментарии

Ответы, состоящие только из ссылок, считаются низкокачественными. Пожалуйста, используйте их только для подтверждения ваших утверждений. Включайте их в свой ответ.

kaiser kaiser
15 янв. 2014 г. 14:04:35

Недействительная ссылка, не могли бы вы обновить её?

JorgeM JorgeM
5 апр. 2023 г. 14:18:15