История одного highload’а

Высоконагруженные сервера принято называть термином highload. Однако, какой ресурс считать высоконагруженным? Какая посещаемость должна быть у такого ресурса? Четкого определения мне найти не удалось, посему могу сказать лишь своё субъективное мнение. Highload как явление начинается с момента, когда сервер перестаёт быстро отдавать то, что у него запросили, тоесть попросту не успевает в силу разных причин. В таком случае пользователь начинает ждать, и как следствие возникает риск потерять его навсегда

Проблема о которой я хочу говорить сегодня началась 10 января 2011 года, когда Рождественские праздники закончились и началась жаркая пора годовых бухгалтерских отчётов. Ситуация усугубилась еще тем, что с 1 января 2011 года на Украине был введен в действие новый налоговый кодекс и люди начали искать информацию. Посещаемость портала резко возросла и уже при 45000 уников сервер стал тормозить. 350 одновременных подключений вводили сервер в ступор, LA поднимался выше 100, управление сервером по ssh было затруднено, время сборки программы на которую обычно уходила минута-две превратилось в пяти-семи минутное ожидание и это по-минимуму. Стали поступать жалобы от пользователей о недоступности ресурса. Ситуация стала критичной. Сервер стал highload?

Теперь пару слов о железе и софте которые обслуживали данный ресурс

supermicro sys-6025b-3rbЖелезо

  • платформа на базе supermicro sys-6025b-3rb
  • процессор: два черырех-ядерных xeon 2.0Ghz
  • харды: четыре сигейта серии NS по 250Гб sata 7200
  • построен raid10 на базе контроллера 3ware с дифолтным страйпом (кажется 64К)
  • оперативная память: 4Гб

Софт

  • os: freebsd 7 amd64
  • apache 2.2 (prefork)
  • php 5.3.6
  • mysql 5.1
  • форум
  • openx

Мы не были готовы к такой посещаемости. И спрогнозировать такой рост никто не мог.

Что было сделано в первое время после начала

  • Попытки как-то ограничить доступ пользователям с одного ай-пи адреса
  • Ограничение количества подключений к серверу
  • Манипуляции с настройками и последующей пересборкой апача с worker-mpm
  • Игра с настройками mysql
  • Обновление всего ПО

Всё это не дало результатов.

LA (load averages) всё время рос, активная память была занята до 3.2Гб, Show process в mysql показывал множество sleep’ов. Вывод напрашивался сам-собой, mysql не успевал и не мог обработать все запросы. И это только то, что я могу припомнить сейчас

На фоне всего этого мы стали падать в рейтинге, а конкурентные ресурсы стали подниматься

Идея с переходом на nginx в качестве фронт-енда и apache как бек-енда, была хороша, только опыта работы с nginx’ом у меня не было. Кроме того дело осложнялось тем, что часть ресурса самописная со множеством рирайтов в htaccess’ах с которыми nginx не умеет работать. Плохо было всё

Теперь о том, что облегчило ситуацию, и что предстояло сделать

Первое — форум и банерокрутилка были вынесены на арендованый сервер, что позволило распределить нагрузку и стать более доступными для пользователей. Это дало возможность принимать более 50000 уников в сутки

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

Третье — с учётом переноса нужна была реструктуризация, тоесть для разных частей портала нужен был свой набор ПО, и свои настройки

Четвёртое — полная ревизия самописного кода. Устранение лишних коннектов в базу. Максимальное использование кеширования отдаваемых страниц. Одним словом оптимизировать всё, что можно было оптимизировать не особо вкладываясь в финансы

Пятое — на всё это нужно было время

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

Предстояло изъятие сервера с колокейшена на профилактику. Для этого нужно было куда-то в третье место перенести то, что на нём оставалось. Временный сервер был найден. Очевидно было, что размещение всего портала на одной операционной системе вредно для его «здоровья». Мне нужно было несколько операционных систем, читай, серверов. И тут на помощь пришла виртуализация. В качестве гипервизора был выбран vmware exsi 4.1. Выбора особого не было, Xen 5.6 не поддерживал FreeBSD

И так, на флешку был установлен exsi, на базе четырёх хардов был построен raid10. Размер страйпа 16К, у FreeBSD block size 16К, для mysql myisam-block-size выставляем 16К. На мой взгляд согласование этих трёх параметров дало определённый перфоманс

Предполагалось завести три виртуальных сервера. Первый – сервер БД. Второй – веб-сервер использующий стороннее ПО. Третий – веб-сервер использующий самописное ПО. Назовём их X, Y и Z соответственно

На X завёл два mysql-сервера и развесил их на портах 3306 – куда поселил всё, кроме openx, и 3307 на котором собственно openx и расположил. Почему так? Да потому что, от портала вместе с форумом в базу идут в основном select’ы, в то время как банерокрутилка 90% операций с базой выполняет при помощи insert/update’ов. Соответственно в my.cnf нарисовал две конфигурации mysqld которые отличаются лишь параметром low-priority-updates=1 для сервера на 3306 и low-priority-updates=0 для сервера на 3307. Тоесть в первом случаем понижен приоритет операций с insert/update’ами, а другом, напротив, повышен. Нужно помнить, что по умолчанию установлен low-priority-updates=0. Параметр имеет смысл использовать если база в формате MyISAM. Все базы были вынесены на отдельную файловую систему

На Y для работы стороннего ПО установил связку nginx/php/php-fpm/memcached. Для работы memcached было отдано 192Мб оперативной памяти. И форум и банерокрутилка умеют работать с хранилищем memcache. И это радует

На Z для работы самописного ПО установил связку apache/nginx. Временные папки nginx’а, где собственно и складываются закешированые страницы, разместил на ram-диске. Размер ram-диска выбрал 512Мб

Таким образом я получил распределённую структуру портала по серверам. Максимально уменьшил нагрузку на диски, все кеширование ушло в оперативную память. Получил возможность провести тюнинг каждого сервера отдельно. Благодаря виртуализации выстроил сервера с “железом” по потребности

Supermicro_FAN-0070LИтак, портал был перенесён, и вскоре основной сервер прибыл на осмотр. Первое, что мы заметили, это более чем лёгкая вибрация корпуса 2U. Вскрытие выявило причину — это подгулявшие в разной степени три кулера San Ace. Анализ поверхности хардов программой MHDD не показал проблем, кроме одного харда, у которого были выявлены явные предпосылки к бедам. Уже минус один хард из четырёх

У остальных трёх хардов смарт был неутешительным. По памяти всё было отлично, memtest проблем не нашёл. Никакой пыли внутри корпуса и блоков питания обнаружено не было, дутых конденсаторов тоже

Таким образом мы провели замену трёх кулеров, вместо четырёх хардов, установили шесть новых сигейтов серии NS 7200 об/мин. в raid10, добили память до 20Гб., на всякий случай сменили термопасту и установили флеш-карту для гипервизора

Далее инсталяция, перенос портала, отправка в ДЦ, переключение на основной сервер. И вот, на сегодняшний день мы способны принять более 50000 уников или более 200000 хитов в сутки не особо напрягаясь при этом, ожидая большей посещаемости и имея запас прочности. Сервер дальше highload или уже нет?

Александр Черных
системный администратор

Статьи по теме

0