Некоторые способы увеличения скорости работы СУБД Oracle

Современные технологии в области серверного оборудования шагнули далеко вперед. Появились 22-ядерные процессоры, 32 процессорные сервера, модули памяти в 128Гб . Причем если топовые решение стоят недоступно для многих компаний, то 10-12 ядерные процессора и 32Гб модули памяти на сегодня появляются повсеместно. А что же произошло с подсистемой хранения?

Подсистема хранения обрела вторую жизнь с приходом твердотельных жестких дисков (SSD). Благодаря бурному росту мобильных устройств, NAND Flash становилась все более технологичной и более доступной по цене. Использование SSD позволило поднять производительность дисковой подсистемы до недостижимых для классических дисков значений.

Если все так замечательно с производительностью, то почему сегодня SSD не вытеснили повсеместно классические диски? Ответ простой: цена. Стоимость SSD на сегодня все еще высока, хотя в roadmap ведущих производителей систем хранения данных написано, что в 2016-2017 годах SSD диски должны упасть в цене и обходиться покупателю дешевле классических дисков. Но пока картина несколько иная.

Сегодня я затрону тему работы СУБД Oracle и возможные доступные варианты увеличения производительности дисковой подсистемы для ускорения работы данной СУБД. Тема достаточно избитая, но найти информацию в одном месте с результатами тестов мне пока не доводилось. Я попробую обобщить свой опыт и описать все в одной статье.

Вообще, что может говорить о том, что дисковая подсистема нуждается в оптимизации? Это большой % ожиданий типа User I/O либо System I/O, большие значения latenсy для этого типа ожиданий. Наглядно в системе мониторинга это выглядит примерно так:

user_io

Что такое latency в контексте подсистемы ввода-вывода? Это время между отправкой команды подсистеме хранения и получением ответа на команду. Почему время реакции так важно для нас? Все очень просто. К примеру, если нам нужно сделать 1 миллион операций ввода-вывода, то при latency в 1 мс у нас на это уйдет 1 миллион миллисекунд, а при latency в 10 мс – в 10 раз больше времени. Из практики, могу сказать, что уменьшение latency на чтение с 8 мс до 0.8 мс ускоряет реальные процессы от 2 до 5 раз (что, в общем, не так уж и мало, если речь идет о 1 часе выполнения процесса вместо 5). Почему меня не интересуют ни предельная пропускная способность, ни IOPS, без контекста latency, очень хорошо и подробно расписано в этой статье. Всем рекомендую ознакомиться.

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

Самый верный способ сделать работу СУБД наиболее быстрой – это поместить ее целиком в оперативную память, оставив дисковой подсистеме только задачи записи изменений в базе данных и записи журналов транзакций. Этот способ подходит тем, у кого размер базы данных соизмерим с объемом доступной оперативной памяти.

Второй надежный способ – это целиком поместить базу данных и журналы транзакций на твердотельные жесткие диски (SSD). All-flash системы хранения есть на сегодня у многих производителей, они заточены на работу с твердотельными дисками. Причем, согласно некоторым материалам и пресс-релизам, не стоит бояться покупать самую доступную по цене cMLC память. Альтернативой all-flash системам хранения могут выступать сервера с NVMe SSD (SSD диски, подключаемые по шине PCI-Express). Для Oracle ASM и кластера flashgrid предлагает свое специализированное программное обеспечение, позволяющее использовать локальные дисковые ресурсы сервера для организации надежного хранения данных (технология аналогична VMWare VSAN по своей сути). Само ПО является открытым и доступно для скачивания.  Архитектурно выглядит примерно так.

flash_grid1

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

flash_grid2

По заявлением производителя ПО, flashgrid позволяет серверам с NVMe SSD конкурировать по скорости с all-flash массивами, стоя при этом значительно дешевле. По ссылке можно почитать подробное описание системы.

Что же можно сделать, если ускорить работу СУБД нужно, а денег на первый и второй вариант не хватает? Можно ускорить работу СУБД, используя технологию Oracle Database Smart Flash Cache. Суть технологии в том, что СУБД использует выделенные ей ресурсы на дисках SSD для кэширования горячих данных и при необходимости производит считывание данных именно из области Flash Cache. Согласно документа Oracle, выглядит это примерно так.

flash_cache

Примечательно, что под Flash Cache можно использовать даже одиночные самые простые SSD-диски, установленные в сервере, т.к. потеря (отказ) этого диска никак не сказывается на целостности данных в СУБД, а лишь влияет на скорость работы самой СУБД. В случае выхода из строя жестких дисков, на которых размещен кэш, СУБД продолжит работать далее, а в журнале работы СУБД появятся записи о том, что процесс DWR не смог выполнить запись в Flash Cache, Flash Cache будет отключен. Так же могут быть использованы PCI-Express SSD акселераторы, причем производительность при их использовании может быть даже выше, ввиду меньших задержек PCI-Express шины передачи данных.

На практике технология дает вполне ощутимый прирост производительности. Вот, к примеру, я тестировал в свое время SLOB в конфигурации с и без Flash Cache.

flash_cache1

Еще один интересный способ повышения производительности предлагает компания Huawei. В своем документе  они предлагают использовать как классический массив на SAS-дисках, так и массив на твердотельных дисках. И если во втором варианте, когда мы все файлы СУБД переносим на твердотельные жесткие диски, нам какие-то образом нужно обеспечить надежность хранения (использования RAID, spare-дисков и тп), что уменьшает полезное доступное дисковое пространство по сравнению с сырым, то в предлагаемой схеме нам доступно для использования все пространство дисков SSD.

Суть предложения очень проста: предлагается хранить данные на двух системах хранения, одной – надежной, но медленной, второй – быстрой, с использованием RAIDO. Отказоустойчивость же предлагается организовать средствами ASM (redundancy = normal). Диски ASM, расположенные на жестких дисках SSD, в ASM предлагается сделать предпочтительными по чтению. Я не поленился и собрал стенд, чтобы проверить, насколько это работает.

Huawei_1

Еще одна идея увеличения производительности – это использование online-компрессии при малом количестве шпинделей. Я проводил тест при количестве дисков SAS порядка 10 и дисков SSD порядка 6.

Huawei_2

Собственно, из теста было видно, что при использовании ASM и redundancy=normal производительность упирается в самые медленные диски, если не делать дополнительных настроек. При указании ssd-дисков preffered по чтению, пропускная способность заметно (более чем в 2 раза) выросла. Использование компрессии тоже дало свой положительный результат: в теории, если поток данных сжимается, дискам нужно совершать меньше операций ввода-вывода, что должно было положительно сказаться на скорости работы. Но оговорюсь, что это справедливо для данной конкретной системы. На высоконагруженной системе с большим количеством дисков ситуация может быть обратной.

Сегодня я вкратце описал, какие методы повышения производительность дисковой подсистемы при работе с СУБД Oracle доступны на сегодня. На вопросы готов ответить в комментариях.

Оставить комментарий