Как вырастить из одного сервера настройки

Я ищу ресурсы о том, как увеличить настройки нашего сервера.

В настоящее время у нас есть один выделенный сервер с Rackspace в Великобритании следующей спецификации:

HPDL385_G2_PrevGen Одноядерный
HP Opteron 2214 (2,2 ГГц),
4 ГБ ОЗУ,
2 x 10 000 дисков SCSI в RAID 1

Наш трафик составляет до 550 000 УФ-лучей в месяц.

Сайт работает на PHP и MySQL. База данных получает абсолютный удар, у нас много сложных запросов, соединяющих многопользовательские таблицы.

Мы используем APC для кэширования PHP.

Я подхожу к этапу, когда я сделал как можно больше оптимизации БД и запросов, и задаюсь вопросом, каким должен быть следующий шаг ......

Я посмотрел на memcache, но у меня сложилось впечатление, что ему требуется большой объем оперативной памяти и в идеале выделенная коробка ....

Таков следующий шаг, чтобы иметь две коробки; один для базы данных, один для Apache? Или есть шаг, который я упустил.

Наша нагрузка обычно составляет около 2 баллов, но сейчас она выросла до 20!

Некоторые графики из Мунина:

Купите некоторое оборудование, но поместите его в свою тестовую лабораторию, а не в центр обработки данных. Затем делайте акцент на своем приложении на различных комбинациях аппаратного и программного обеспечения, пока не найдете подходящий вариант, который будет делать то, что вы хотите.

Конечно, вам нужно спроектировать что-то, что может создать фальшивый трафик для производственной базы данных, на которой запущена тестовая копия вашего приложения. Но кто сказал, что это будет легко.

Если вы не делаете этого и просто делаете что-то на производстве, вы не представляете, сработает ли это или нет, и, возможно, вы потратили немало инженерных усилий на реализацию таких вещей, как кеши (что придет со своей справедливой долей ошибок!) на то, что не помогает.

Тестируйте, тестируйте и тестируйте больше. Не вносите изменения в оборудование / программное обеспечение в производство, пока не получите хорошие данные о производительности, показывающие, что это может значительно улучшить ситуацию. Инженерные работы стоят дорого, тестирование оборудования - нет (особенно).

Memcached - это всего лишь один из вариантов, и вам, вероятно, не стоит его рассматривать, пока у вас не будет оптимальной работы кэширования базы данных. Это означает, что нужно поместить его на выделенную (64-битную) коробку с разумным объемом оперативной памяти (а не у 4G - у ноутбуков, который сейчас есть; 32G определенно доступен) и настроить его соответствующим образом.

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

Профилируйте ваши запросы к базе данных. Для этого есть инструменты - вы должны иметь возможность имитировать производственную нагрузку в вашей тестовой среде. Хитрость заключается в том, чтобы избежать медленных запросов и обеспечить быстрое выполнение часто выполняемых.

Если ваши проблемы с производительностью связаны с синхронизацией ввода-вывода, потому что вы просто делаете слишком много транзакций для базы данных, убедитесь, что вы используете raid-контроллер с батарейным питанием, который ведет себя правильно (поговорите с вашим поставщиком об этом). Они дают намного больше операций записи ввода-вывода, чем операции без поддержки батареи (потому что данные должны попасть в кеш, прежде чем ОС получит подтверждение). В качестве альтернативы, если ваши данные не имеют большого значения, рассмотрите возможность ослабления параметров долговечности базы данных (синхронизация innodb при фиксации).

Посмотрев на решения для кэширования, как и многие другие, предложили здесь, вы можете рассчитывать на то, что в итоге вы получите около 10% нагрузки, которую вы имеете сегодня, а может быть, и меньше.

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

Вы должны попытаться профилировать, какие запросы к базе данных занимают больше всего времени, используя либо медленный журнал запросов MySQL (или эквивалент для вашей базы данных), либо используя такой инструмент, как mytop . Кроме того, EXPLAIN SELECTсинтаксис MySQL может быть полезным.

Кэширование результатов нескольких выбранных запросов MySQL (даже на короткий промежуток времени) действительно может значительно улучшить вашу производительность.

Я много работаю над производительностью и масштабируемость, и я обнаружил, что:

Каждая загрузка приложения уникальна

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

Мера правильных вещей

Одна из самых больших проблем заключается в определении того, какие критерии важны. Это часто требует шага назад, и вы должны поставить себя на место вашего клиента. Иногда упрощенный дизайн сайта меняется и приводит к огромным преимуществам для веб-посетителя. Вот почему мне нравятся такие инструменты, как YSlow! которые сосредоточены больше на опыте конечного пользователя, а не на уровне сервера. Как только вы решите, какой эталонный тест для вашего сайта, вы можете приступить к настройке. Тестами могут быть общее время загрузки страницы, общий размер страницы, эффективность кэширования, задержка сайта и т. Д. Вы должны выбрать тот, который имеет смысл для вашего приложения.

Гайки и болты

Когда вы отслеживаете правильные ориентиры, начинайте с очень низкого уровня. Мне нравится использовать sysstat. Вы можете получить массу информации от sysstat и помочь разобраться, какая система может ограничивать общую производительность приложения. Как правило, я сводлю проблемы производительности в:

• Сетевой стек
• стек памяти
• диск io
• прикладной уровень
• ос слой

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

Например, я видел сбой высоконагруженных серверов из-за того, как было настроено их приложение. Плохое кэширование, отсутствие заголовков expires для статического контента, использование HTTP и файловых включений и т. Д. - все это способствовало снижению производительности приложения. Исправление этих проблем приложения не требовало никаких изменений оборудования. В других случаях я видел, что диски максимально загружены, несмотря на тонны кеширования. Переход на более быстрые диски устранил проблему.

Промыть и повторить

Часто во время настройки приложения вы устраняете одно узкое место, чтобы найти только другое. Вот почему я рекомендую пытаться контролировать то, что вы настраиваете.

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

Получите правильные инструменты

Убедитесь, что вы используете правильные инструменты для работы. Мониторинг, тестирование, бенчмаркинг, профилирование и другие методы оптимизации имеют множество инструментов. Найдите инструмент, который лучше всего соответствует вашей ситуации.

Эмпирические правила

Хотя каждое приложение уникально, я нахожу несколько стандартных отправных точек:

• базы данных памяти любят память
• Диск все, кроме рейда 10 может убить производительность базы данных
• неправильные оптимизации - большие значения не приводят к большой производительности
• приложение - обвинять сервер в плохом дизайне приложения

Ваши следующие шаги

Если вы не найдете своего узкого места, добавление сервера может не сильно помочь. Для решения дискового ввода-вывода вам может понадобиться другой сервер или SAN. Если у вас есть узкое место оперативной памяти, другой сервер решит проблему только в том, что он добавляет больше оперативной памяти. Довольно дорогостоящий шаг по сравнению с простым добавлением ОЗУ на существующий сервер.

Быстрая починка

За развертывание. Я должен был сделать это, когда оказалось, что проблема в стеке приложений. В основном загружаются на ЦП, ОЗУ и дисковый ввод-вывод (RAID 10, 15K SCSI или SSD). Займитесь большим количеством оборудования, а затем начните настройку. Это держит вас на плаву, пока вы не решите проблемы.

Я бы сказал, что следующим шагом должно стать кэширование (кэширование данных и / или кэширование страниц в зависимости от вашей функциональности). Если memcached кажется слишком сложным, вы можете начать с простых решений для кэширования данных, таких как PEAR Cache Lite, которые требуют всего несколько строк кода, но могут иметь огромное значение. Кэширование страниц (или частей страниц) поддерживается Smarty например, движком шаблонов .

Как только кэширование больше не сокращает его, вы можете увеличить количество серверов, поскольку больше ничего не осталось.

Если у вас достаточно свободной оперативной памяти, memcached поможет вам даже на одной коробке. Попробуйте кешировать несколько самых тяжелых запросов и посмотреть, что произойдет. Кроме того, Apache слишком тяжелый, вместо этого используйте nginx или lighttpd (с PHP-приложением, работающим через FastCGI, см. Php-fpm ).

Запустите кеширование, но пока игнорируйте MySQL. Seriouosly.

Правило должно быть - остановить запрос как можно раньше. Итак, обратный прокси-сервер или правильное кэширование на уровне Apache принесут вам наилучшие результаты, затем кэширование результатов на уровне SQL внутри приложения, затем кэширование на уровне SQL;)

Чем раньше вы остановите запрос, тем меньше накладных расходов. Уровень выходного кэша - даже PHP не должен работать, так сказать.