понедельник, 12 октября 2009 г.

Файловые системы, базы данных, IOPS и ZFS

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

Знаете, коллеги, что непонятно? Давным-давно (теперь уже), практически во времена она, сцепились так же (нет, не васи пупкины на iXBT) AMD и Intel. По поводу тактовых частот их процессоров и реальной производительности. И анонимные эксперты с iXBT, и все, кто мало-мальски разбирался в сути вопроса (сравнительной фаллометрии бенчмарков, синтетических тестах и реальной производительности) - все пришли к выводу, что не гигагерцем единым, но реальной производительностью конкретных приложений определяется быстродействие процессоров.

И который год лично я наблюдаю (и даже иногда участвую) в фаллометрических схватках, как надо строить системы хранения под БД, потому что (см. пруфлинк 1, пруфлинк 2, пруфлинк 3), дескать, медленно все в том или другом случае.

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

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

Иногда это провоцируют сами вендоры (чего далеко ходить, Evil Tuning Guide от Sun дорогого стоит) - де, "позвольте ZFS самой разобраться!". Иногда - синтетические тесты ( "а в IOPSах я все-таки длиннее!").

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

Давайте попробуем разобраться, правомерно ли использование синтетических тестов и бенчмарков, а также IOPS, во всех случаях. В частности, нас интересует сочетание "ZFS и базы данных".

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

Не буду пытаться пересказывать концепции ZFS или, тем более, разжевывать их. Все уже разжевано и самим автором и Sun Microsystems.

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

1. Конфигурация пулов/файловых систем ZFS по умолчанию не слишком оптимальна для баз данных. Пруфлинк.

Sun Microsystems и опытные администраторы все, как один, сходятся в одном. Для баз данных, для которых в наибольшей степени характерны короткие чтения, размер записи ZFS должен быть равен размеру блока БД. Значение по умолчанию в 128К приводит к избыточной предвыборке, перегрузке кэша ARC ненужными предвыборками и дискредитирует интеллектуальное поведение ARC. В конечном итоге, это приводит к ненужным задержкам в отклике серверов БД и перегрузке оперативной памяти чрезмерно кэшированными данными.

2. Redo-логи таких баз данных должны располагаться на файловых системах с наибольшим размером записи (т.е 128К).

Данная рекомендация преследует уменьшение накладных расходов на запись (сокращая количество операций как самой записи, так и уменьшая объем информации, записываемый в ZIL, где бы этот самый ZIL не располагался). Особенно эффективна данная рекомендация в сочетании с определенным (в общем случае - максимальном) значении параметра maxphys.

Я уже писал ранее о необходимости правильного структурирования пулов ZFS под базы данных и указания для них правильных параметров хранения здесь и здесь.

Практически, выполнение рекомендаций Sun позволило избежать на одном из фронтальных серверов с БД Oracle позади веб-сервера хронической (хотя и появлявшейся не в очень большом количестве) ошибки "503 Server Busy". Внутренняя статистика также показала улучшение времени отклика более, чем вчетверо (с 0,3 сек до 0,02 сек в среднем).

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

Об IOPS вообще разговор особый.

Сторонники измерения производительности систем хранения (и в частности их части - файловых систем) в IOPS как-то упускают из виду тот факт, что по определению, IOPS измеряет конечную производительность аппаратных частей систем хранения (процитирую определение полностью):

IOPS (Input/Output Operations Per Second) is a common benchmark for harddisks and other computer storage media. Like with any benchmark, IOPS numbers published by drive and SAN vendors are often misleading and do not guarantee real-world application performance.

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

(Я хочу перевести определение на совсем элементарный язык. Значение IOPS показывает лишь, как быстро дрыгают диски головками и как быстро крутятся их шпиндели и при прочих равных условиях показатель тем выше, чем большее количество дисков собрано в одну систему хранения. И ВСЕ! Никакого отношения к количеству записанных-прочитанных гигабайт в секунду в реальных условиях работы с реальными приложениями данный показатель не имеет и иметь не может!)

Говоря простым языком, если ZFS показывает на порядок-два меньшее число IOPS на одном и том же железе - это отнюдь не означает, что ZFS медленная. Скорее, наоборот.

Выводы из всего вышесказанного будут следующие:

1. IOPS не показатель ни скорости работы файловой системы по отношению к другой файловой системе.

2. IOPS не показатель скорости работы системы в целом вообще.

3. ZFS не проигрывает другим файловым системам и LVM в скорости. Сравнения, утверждающие нечто подобное, почти всегда являются некорректными.

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

Последнее утверждение я перефразирую на основе собственного опыта как "Тюнинг не является злом. Он по-прежнему необходим - даже с ZFS".