Я унаследовал систему, для которой мне нужно максимально настроить производительность с точки зрения оборудования. Прежде всего, я веб-разработчик, а не системный администратор, я не хочу преждевременно настраивать производительность, поэтому за последние несколько дней я провел небольшое исследование, а также настроил мониторинг серверов и приложений и написал небольшой план. как все можно улучшить, но мне нужен кто-то, кто имеет опыт работы с системным администратором, чтобы это проверить.
Причина, по которой мы делаем это, заключается в том, что сайт швы быть медленными и трафик неуклонно растет. Основной план - переписать систему, поскольку из-за множества неудачных архитектурных решений сама база данных не нормализована должным образом. Итак, пока происходит переписывание, мы хотим сделать какое-то «глупое» / простое масштабирование (если возможно), просто чтобы клиенты были довольны.
У нас работает единый сервер, на котором размещены веб-приложение и база данных.
Меня не беспокоят параметры MyISAM, так как я планирую преобразовать все таблицы в InnoDB, чтобы мне было легче настраиваться.
Сохраняйте системный мониторинг на случай слабых мест, чтобы позже мы могли лучше понять, если бы настройка производительности была успешной.
Соберите информацию, какие страницы загружались дольше всего
Насколько я понимаю, Varnish, грубо говоря, кэширует всю страницу и действует как прокси, который впоследствии может обслуживать эти страницы без участия Apache. В нашем случае у нас есть много контента, который не меняется часто, хотя для его генерации требуется довольно много ресурсов.
Напишите собственный сценарий, который имитирует поведение пользователя и пытается использовать «жадные» функции. Запускайте эти сценарии одновременно, когда сайт не посещается, и собирайте информацию о производительности системы. Делайте это до и после оптимизации сайта. Хотя это имеет смысл для меня, я действительно не слышал о том, чтобы делать что-то подобное раньше, просто видел аналогичную идею в тестировании Rails, я бы хотел избежать преждевременного тестирования, поэтому я был бы рад услышать некоторые мнения по этому поводу.
Это значительно упростит весь процесс настройки.
Включите кэширование запросов и установите для него значение 256 МБ, а затем постоянно измеряйте производительность кеша, используя следующее уравнение: Qcache_hits / Qcache_inserts x 100 = Your Query Cache's effectiveness.
Устанавливать query_cache_limit = 256 КБ
FLUSH QUERY CACHE;SQL_NO_CACHE, хотя query_cache_limit в любом случае должен предотвратить удаление Sphinx кеша.Это немного сложно, поскольку у нас есть только около 3 ГБ дополнительной памяти, которую можно выделить для MySQL. Общий размер Innodb TableSpaces в нашем случае составляет около 3 ГБ. Следующая статья: Выбор innodb_buffer_pool_size предполагает, что innodb_buffer_pool_size должен быть установлен на 10% больше, чем общий размер InnoDB TableSpaces, который в нашем случае будет 3,1 ГБ, поэтому у нас нет достаточно памяти. Однако добавить на наш сервер больше физической памяти - не проблема.
В дополнении к innodb_buffer_pool_size При настройке необходимо внести следующие изменения параметров MySQL:
innodb_flush_method = O_DIRECT (избегайте двойной буферизации)innodb_log_file_size = 256MБольшинство блогов, с которыми я столкнулся, предлагают использовать Nginx и APC (PHP-кеш). Я видел результаты тестов, и все они кажутся впечатляющими по сравнению с Apache с включенным mod_php. Но в нашем случае стоит отметить тот факт, что мы обслуживаем 3RPS в пиковое время. Изменение Apache с помощью Nginx - непростой процесс, и, честно говоря, я бы предпочел, чтобы кто-нибудь из опытных системных администраторов сделал это, если потребуется. Может, кто-нибудь посоветует, стоит ли переносить серверы в нашем случае?
Может ли кто-нибудь, учитывая мою ситуацию, дать мне отзыв об этом плане?
Спасибо!
Ваш общий план хорош. Продолжайте мониторинг системы и профилирование скорости страницы перед касаясь чего-либо. Вы не можете исправить проблемы, пока не узнаете, где они находятся.
Как только вы узнаете, какие у вас узкие места (диск, ЦП, ОЗУ, база данных, веб-приложение), вы можете начать нацеливать их в том порядке, в котором они влияют на ваших пользователей.
Что касается настройки, один конкретный элемент, который вы упустили, - это профилирование базы данных (EXPLAINзапросы и создание / изменение индексов для повышения производительности). Это работа для опытного администратора баз данных - создание слишком большого количества индексов приведет к блокированию вставок, а создание неправильных индексов не улучшит производительность.
Вам также следует серьезно подумать о разделении сервера базы данных и веб-сервера / сервера приложений: у обоих довольно сложные задачи, и их разделение позволит избежать перегрузки одного хоста.
Если бы я выполнял ваш план, изложенный выше, я бы поступил следующим образом:
Я бы не стал тестировать пользовательские скрипты, если у вас нет среды разработки или периода обслуживания в производственной среде (вы не хотите наносить ущерб своей производственной среде тестовой нагрузкой).