Оптимизируйте apache / php / mysql, работающий на VPS для большой нагрузки

Вопрос об оптимизации сервера apache / mysql на VPS с 512 м ОЗУ. При нормальной нагрузке все работает быстро, без задержки соединения. Однако, когда мы получаем наши дни с интенсивным трафиком (50 000 посещений), сайт сканируется, и для возврата контента из Apache требуется более 30 секунд.

Сайт работает на Expression Engine (CMS) (на PHP), и я следовал их руководству по оптимизации под большой нагрузкой. Я гуглил и следил за апачами с некоторыми удачами, добиваясь того, где он есть сейчас, но мне нужно получать постоянное время отклика.

Я предполагаю, что это отличается от вопроса «Оптимизировать для нехватки памяти», так как у меня достаточно ОЗУ (для того, что я пытаюсь сделать), мне просто нужно, чтобы сервер не давился при большой нагрузке.

Какие-нибудь рекомендации?

Для PHP есть две важные вещи, которые увеличат емкость:

1. Расширенное кэширование PHP (APC), как уже упоминалось. Это то, что мы используем в Yahoo !. Есть и другие подобные проекты, но этот - ребенок Расмуса.
2. FastCGI вместо mod_php. Существует дискуссия по этому вопросу, так как mod_php обычно самый быстрый. Однако я бы предположил, что у вас есть один сервер Apache, предоставляющий как динамический контент PHP, так и статические ресурсы (JS, CSS, flash, изображения, PDF и т. Д.). Запросы на эти статические ресурсы не должны занимать так много памяти, но поскольку PHP является модулем, он находится в каждом потоке Apache.

Для Apache:

1. Использовать рабочий MPM
2. Включить KeepAlive

Вы также можете зайти так далеко, чтобы рассмотреть возможность перехода с Apache на Lighttpd или Nginx . Я люблю Apache. Я использую дурака из многих его продвинутых функций. Я принимаю его накладные расходы, потому что мне нужно то, что он предлагает. Для обычного стека LAMP это больше, чем необходимо, и трата ресурсов.

Для MySQL:

1. Ваши усилия по оптимизации окупятся в 10 раз, если вы потратите на анализ и исправление запросов, вместо того, чтобы настраивать значения my.cnf. Я не говорю о том, что не важно, чтобы ваш кеширование, соединения и т. Д. Были правильными ... но для большинства людей это только 9% проблемы.
2. Во время вашего QA включите общий журнал запросов на вашем staging / dev mysqld, чтобы перехватывать все отправленные запросы. (НЕ делайте этого на вашем производственном сервере MySQL!)
3. Используйте EXPLAIN для анализа запросов. Особенно, если вы используете инфраструктуру с ORM (абстрагируете БД и не позволяете писать собственный SQL), вам нужно будет очистить посторонние СОЕДИНЕНИЯ, SELECT без предложения WHERE, ORDER BY, которые вызывают «использование файловой сортировки», и запросы которые не используют индексы.
4. Если вы используете MySQL 5.1, воспользуйтесь профилировщиком запросов .

Другими инструментами, которые стоит рассмотреть, являются mk-visual-объяснение

Я привел 10 замечательных ссылок. Эти вещи должны заставить вас напевать. Пожалуйста, дайте нам знать, как это получается.

Переместите ваши файлы сеанса PHP в tmpfs , используйте APC (или другой) и удалите все ненужные модули PHP. Удалите все модули Apache, которые вам не нужны / не используются.

Создать tmpfs (каталог в оперативной памяти!)

mkdir /tmpfs; chmod 777 /tmpfs
mount -t tmpfs -o size=256M tmpfs /tmpfs

В / etc / fstab добавьте строку ниже, чтобы создать ее при перезагрузке!

tmpfs     /tmpfs    tmpfs   size=256m,mode=0777    0       0

В /etc/apache2/php.ini настройте для хранения ваших сессий в оперативной памяти (tmpfs)!

session.save_handler = files
session.save_path = "/tmpfs"

Примечание: с вашими файлами PHP и файлами сессий в оперативной памяти вы едва касаетесь диска!

Используйте expires_module в apache, чтобы браузеры кэшировали большинство вещей.

ExpiresActive On
ExpiresDefault "access plus 90 days"
ExpiresByType image/gif "access plus 90 days"
ExpiresByType image/ico "access plus 90 days"
ExpiresByType image/png "access plus 90 days"
ExpiresByType image/jpeg "access plus 90 days"
ExpiresByType image/x-icon "access plus 90 days"
ExpiresByType text/css "Access plus 90 days"
ExpiresByType text/html "Access plus 90 days"
ExpiresByType application/x-shockwave-flash "Access plus 90 days"
ExpiresByType application/x-javascript "Access plus 90 days"

Не используйте .htaccess файлы! Вместо этого жестко запишите их в конфигурационный файл vhost! Резко исключит / сократит проверки диска на все запросы http ... это действительно добавляет.

Options FollowSymLinks 
AllowOverride None

Пример использования .htaccess в вашем файле vhost.conf ...

<Directory /home/user/www/site.com/secure>
    Order Allow,Deny
    Deny from All
</Directory>

Несколько вещей приходят на ум.

Кэш кода операции всегда хорошая идея. Я предпочитаю http://eaccelerator.net/, чем APC. Если вы еще не разрабатывали APC, попытка добавить его почти всегда является болезненной. Eaccelerator, хотя и не так, как кажется, просто работает.

Обратный прокси-сервер также является хорошей идеей, но вам нужно следить за использованием оперативной памяти. Я нахожу Apache 2.2 с mpm-worker, чтобы занимать достаточное количество оперативной памяти самостоятельно. В вашем случае я бы порекомендовал что-то более легкое, например, Nginx, и запустил Apache с PHP как FASTCGI или просто оставил это как процесс. Идея использования Varnish, Squid, Nginx и т. Д. Состоит в том, чтобы они обслуживали статический контент, обрабатывали пользовательские соединения и передавали только запросы PHP в Apache, который вы рассматриваете как сервер приложений.

Если вы используете довольно свежую версию Mysql 5.1, как минимум 5.1.24, у вас теперь есть доступ к медленным журналам длительностью менее секунды. Я бы начал long_query_time с 1 или 2, а затем снизил бы его до 0,5, так как вы получаете контроль над действительно длинными. В сети также много общей информации о настройке Mysql, но у вас недостаточно оперативной памяти. Вы увеличили какие-либо настройки по умолчанию? Большинство файлов my.cnf по умолчанию настроены на использование около 64 МБ ОЗУ. По крайней мере, я бы поднял key_buffer с 16 МБ до 64 МБ.

Кроме того, вы используете таблицы Myisam или Innodb? Если вы ведете сеанс в БД, вам нужно изменить таблицу сеансов на Innodb (или вместо этого сделать ее cookie), а не оставлять ее в таблице Mysiam, которая выполняет блокировку на уровне таблицы, а не блокировку на уровне строки. По сути, любая таблица, которая более чем на 20% пишет при чтении на 80%, является кандидатом для перехода на Innodb. Помните, что вам необходимо сбалансировать объем оперативной памяти между таблицами Myisam и таблицами Innodb, поскольку буферы для каждой из них настраиваются отдельно.

И, наконец, еще 512 МБ ОЗУ будут иметь большое значение в вашей установке или даже 512 МБ VPS для запуска Mysql, если это дешевле или примерно по той же цене. Я бы на самом деле склонялся ко второму экземпляру, потому что это удвоит доступный дисковый ввод-вывод. Одна из проблем с серверами VPS заключается в том, что ваш IO не защищен от других людей на том же физическом сервере.

Хм-м-м, мой пост все рассыпан, но дает вам много мест для поиска. Удачи.

• Используйте кэш кода операции для php, как apc.
• Используйте http-ускоритель, такой как кальмар или лак.

В ситуации нехватки памяти (512 МБ мало для сервера с большим трафиком) стоит рассмотреть выбор веб-сервера и механизма БД.

Lighttp легче из коробки, чем Apache, который обычно можно сделать после долгой настройки, и есть даже более легкие варианты, чем этот. Это, конечно, невозможно, если есть функции Apache, от которых вы зависите, которые не поддерживаются на других серверах.

sqlite намного крепче, чем mySQL, и быстрее во многих условиях. Проверьте, поддерживает ли используемый вами движок, и если да, то попробуйте.

Другой вариант, более простой, состоит в том, чтобы получить больше оперативной памяти в ВМ, если вы можете себе это позволить.

Помимо замечательных предложений, следует отметить, что все VPS не созданы равными. По моему опыту, PHP оказался тяжелым процессором.

Тест Wordpress AB (ab -n 500 -c 25 http://domain.com/index.php ) для nginx / apc / phpfpm / mysql (local) на EC2 привел к ~ 2 запросам в секунду на уровне входа "2GB Сервер ОЗУ RAM / 1 ".

Тот же Benchmark, запущенный для того же самого стека (развернутый сценарием в идентичной ОС) на 512MB Rackspace Cloudserver, возвращает ~ 80 рэк / сек. Таким образом, 4x меньше оперативной памяти, 40x производительность в этом элементарном эксперименте.

При просмотре top во время AB вы видите, что EC2 просто не может справиться с параллелизмом, и сразу же достигнет 100% загрузки процессора и заблокируется. При просмотре сверху на 512 МБ сервере (виртуализированном четырехъядерном процессоре) во время одного и того же теста, ядро ​​достигнет нагрузки ~ 60% и плавно справится с тестом.

VPS чрезвычайно легко раскручивать и выключать без каких-либо обязательств, это не помешает проверить инфраструктуру, в которой находится ваша VM / VPS!

РЕДАКТИРОВАТЬ 1: Кроме того, малый экземпляр EC2 «High CPU» мог выдавать только ~ 10 / req секунд, с узким местом CPU. Мой вывод состоял в том, что вы жертвуете производительностью ради стабильности / надежности с EC2, и, конечно, есть много вариантов использования, которые требуют такой среды.