Назад | Перейти на главную страницу

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

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

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

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

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

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

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

Для Apache:

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

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

Для MySQL:

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

Стоит рассмотреть и другие инструменты: мк-визуально-объяснять

Я привел 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-серверов заключается в том, что ваш ввод-вывод не защищен от других людей на том же физическом сервере.

Хммм, мой пост вроде бы бессмысленный, но дает вам много мест, где можно посмотреть. Удачи.

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

В ситуации с нехваткой памяти (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 запросам в секунду на их начальном уровне «2 ГБ RAM / 1 сервер вычислительных модулей».

Тот же тест, запускаемый с тем же самым точным стеком (развернутым скриптом в идентичной ОС) на облачном сервере Rackspace объемом 512 МБ, возвращает ~ 80 запросов в секунду. Итак, в 4 раза меньше оперативной памяти, в 40 раз быстрее в этом элементарном эксперименте.

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

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

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