Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method GoogleSitemapGeneratorLoader::Enable() should not be called statically in /home/sync4me/domains/aboutnetapp.ru/public_html/blog/wp-includes/plugin.php on line 311
Оптимизация на Large Sequental Read | about NetApp

Оптимизация на Large Sequental Read

Large Sequental Read, или чтение последовательными большими блоками, это один из распространенных паттернов доступа к данным. Например, с таким характером доступа работают такие задачи, как Decision Suport System (DSS), системы Business Intelligence (BI), а также многие задачи резервного копирования (full backup, например).

Вследствие характера работы WAFL, такой паттерн доступа может быть проблемным для систем хранения NetApp, поэтому, если ваши задачи часто используют Large Sequental Read, то стоит позаботиться о некоторых методах оптимизации. Я уже писал, что ситуацию с производительностью на последовательном чтении улучшает регулярное выполнение операций реаллокации (они выполняются по расписанию, или при превышении порогового уровня non-contiguous blocks placement, не обязательно гонять его вручную). Также в блоге специалиста NetApp по нагрузочному тестированию и производительности, Wei Liu, я приметил еще одну оптимизационную фишечку.

В системах Data ONTAP версии 7.3.2 и новее имеется опция wafl_max_write_alloc_blocks, по умолчанию она установлена в 64. Если у вас работа с данными осуществляется преимущественно большими блоками, имеет смысл увеличить его значение до 256. Этот параметр, наскольно я могу судить из его названия, управляет размером экстента записи данных. О влиянии и смысле этого элемента дисковой структуры я недавно писал в посте про “фрагмнтацию”. Для версий до 7.3.2 этот параметр нужно было установить в файле /etc/rc в виде строки:
setflag wafl_max_write_alloc_blocks 256

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

Опция была подсмотрена в документе: TR-3760: Building a Scalable Data Warehouse Solution, кстати любопытного и самого по себе чтива.

Отдельно обращу ваше внимание, что не стоит сразу бросаться “тюнить” систему, так как данная опция, вероятнее всего, положительно влияет только на производительность large sequental read, и может не сказаться, или сказаться отрицательно на всех других. Но если у вас DSS-like база, то, может быть, можно и попробовать.

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

20/0.075

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

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.