Реальный пример: сбор метрик для базы данных

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

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

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

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

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

Собственно, базы данных Flickr находятся именно в такой ситуации. Чтобы понять это, достаточно беглого взгляда на статистику использования дисков (в сочетании с тем фактом, что объем данных, запрашиваемых у MySQL, намного превышает объем физической памяти). В качестве примера рассмотрим один из серверов. На рисунке приведены соответствующие метрики MySQL для одной базы данных пользователей Flickr во время пиковой нагрузки.

На рисунке представлены данные о количестве параллельных подключений MySQL, а также количестве выполняемых операций INSERT, UPDATE, DELETE и SELECT в секунду за один час. За время наблюдения в каждой из метрик наблюдаются пики, но только один из них заслуживает особого внимания. На нижнем графике представлена величина задержки репликации базы данных за последний час, пиковое значение достигает 80 секунд. Видеть такую задержку репликации, конечно, не хочется. Обычно она означает, что на подчиненных машинах временно отсутствуют свежие данные, загруженные на главную машину.

Flickr направляет все запросы пользователей подчиненным машинам, следовательно, пока информация на них не обновится, самые новые данные останутся недоступными для пользователей. Это может привести к различным нежелательным эффектам; скажем, пользователь пишет комментарий к фотографии, щелкает на кнопке Submit… и не видит только что введенный комментарий. Все это сбивает с толку и приводит к разного рода странностям десинхронизации. Ситуация, мягко говоря, не идеальна.

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

В этом примере Ganglia собирает и представляет в графическом виде статистику использования дисков для нашей базы данных. Отчет составляется каждые 60 секунд по значениям некоторых полей, возвращаемых командой Linux iostat: %iowait и %ioutil.

Обратите внимание: хотя интенсивность использования диска поднималась до 100 процентов более одного раза, задержка репликации MySQL увеличилась только во время того периода, когда ожидание ввода/вывода пересекло 40-процентную отметку.

Что это означает? Даже после беглого взгляда на метрики можно сделать вывод, что задержка репликации обусловлена дисковым вводом/выводом, а не общей загрузкой диска. Также можно сказать, что проблемы с задержкой репликации появляются только тогда, когда ожидание ввода/вывода составляет 40 и более процентов. Учтите, что эти результаты относятся только к конкретной конфигурации базы данных в Flickr; это всего лишь пример, а не общее правило. А может, они указывают на какой-нибудь дефект этого конкретного сервера? Возможно. Гипотеза должна легко проверяться — для этого следует спровоцировать указанное поведение на аналогичном сервере. В нашем конкретном случае анализ графиков с других серверов показал, что данная связь имеет общий характер и наблюдается в работе Flickr постоянно: другие базы данных с идентичным оборудованием также испытывали задержку репликации, когда ожидание дискового ввода/ вывода приближалось к 40 процентам.