about NetApp

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 база, то, может быть, можно и попробовать.

Рассмотрим еще одну полезную команду для глубокой диагностики, позволяющую находить и анализировать проблемы канала передачи данных от диска к контроллерам на системах, использующих интерфейс FC к дискам. Это системы с полками DS14, которые постепенно заменяются на дисковые полки, работающие по SAS, в новых моделях FAS, но все еще широко распространенные в продакшне.

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


na_fcstat - Fibre Channel stats functions

Формат:
fcstat link_stats [ adapter number ]
fcstat fcal_stats [ adapter number ]
fcstat device_map [ adapter number ]

Continue reading ‘Оптимизация производительности. Часть 4. fcstat’ »

Приходящим с opennet.ru по некорректно озаглавленной ссылке: эти статьи НЕ про оптимизацию произвдительности систем хранения в целом, а про специальные инструменты и средства оптимизации производительности конкретно систем NetApp FAS! Если у вас не NetApp FAS, то вам, кроме вот этой первой статьи, будет неинтересно!

С неделю уже закопался в материалы по оптимизации производительности систем хранения, причем не только NetApp, но, все же, главным образом. ?? решил подкинуть вам полезных сведений, тем более из опыта знаю, что множество админов систем хранения NetApp, увы, имеют, зачастую, самые базовые представления об диагностике и траблшутинге проблем производительности. ?? это при том, что, зачастую, системы хранения, даже в базовой поставке, не считая всяких мегакрутых штук типа DFM и Performance Advisor, имеют достаточно средств “загрузить” среднего админа мыслями.

Для начала несколько вполне разумных рекомендаций от Тома Гамильтона, инженера NetApp, занимающегося в компании базами данных и оптимизацией производительности систем хранения для них. Когда вы их читаете, то кажется, что все это очевидная банальщина. Что, впрочем, не мешает все новым и новым людям их нарушать на практике, и огребать проблемы, как результат такого нарушения.

1. В первую очередь проверьте все уже известные проблемы (known issues) с софтом и оборудованием, которые часто перечисляют вендоры в документации и release notes. Вполне возможно, что ваша проблема с производительностью имеет хорошо известную причину и, соответственно, решение.
2. Рассматривайте всю систему целиком. Не занимайтесь ускорением “на 5%” отдельно взятых подсистем ее, когда, возможно, куда большие “затыки” существуют на других участках. Выбирайте как цель оптимизации наиболее существеные в общей картине участки системы. Низкое быстродействие IT-системы в целом далеко не всегда вызвано только лишь невысокой производительностью хранилища базы данных.
3. ??змеряйте и переконфигурируйте систему поэтапно.  Не пытайтесь объять необъятное и поменять сразу все. Разделите рассмотренную вцелом систему на компоненты, оцените вклад в производительность на каждом этапе, и улучшайте производительность постепенно, начиная с участков, дающих наибольший вклад.
4. Делайте изменения в конфигурации по одному за раз. Если вы найдете причину и улучшите производительность системы, то, если изменений делалось много за раз, будет непросто найти что именно дало результат.
5. Продумайте и распишите по шагам все процедуры изменений, и, что не менее важно, “путей отступления”, “отката” в исходное состояние в случае неудачи. ДО того, как вы начнете что-то менять!
6. Не твикайте систему только ради того, чтобы потвикать! О-о… Даже и комментировать не стану :)
7. Помните про “Закон убывающей доходности”. Начиная с какого-то этапа, каждая следующая ступенька относительного прироста производительности будет вам стоить все дороже и дороже.

Правильная настройка системы хранения, и системы в целом, куда входят сервера и ПО, зачастую может дать весьма серьезный результат прироста производительности. Так, например, в TR-3557 приводится вот такая картинка для результатов базы Oracle 10g на HP-UX, работающей по 10G Ethernet NFS, для настроек по умолчанию OS, и для правильных настроек:

Всегда ищите главное, наиболее существенное “бутылочное горло” системы, и начинайте оптимизацию именно с него.

По опыту Тома Гамильтона, Top5 таких “узких мест” для системы хранения это:

1. “Затык” на уровне диска
2. На уровне интерфейса к дискам FC-AL или SAS
3. На уровне процессора контроллера или OS системы хранения
4. “Потолок” сетевой карты или target-адаптера
5. Проблемы настроек tread parallelism на клиенте

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

По умолчанию, TCP-окно Snapmirror равно 1,994,752 байт. В структурах, где SnapMirror используется для репликации данных через WAN, такое значение может заметно замедлять процесс репликации. Важно правильно вычислить верные настройки TCP-окна, и соответствующим образом их установить. Базовая формула такова:

Window Size = Round Trip Delay X Desired Rate

Таким образом, если у вас используется канал 10Mb/s и средний RTD равен 100ms, то window size должен быть 125,000 байт.

Несколько замечаний о этом TCP Window size:

Это теоретически минимальное возможное окно, используемое SnapMirror, и может не быть самым оптимальным. Попробуйте несколько вариантов в районе этой цифры, чтобы выбрать наилучшее.
Установить размер TCP window size можно в файле /etc/snapmirror.conf в параметре wsize.
Это надо установить и на системе-получателе репликации.

Другая возможность, которая должна помочь в тонкой настройке, это установка опции:

options snapmirror.delayed_acks.enable off

Эта установка выключает TCP/IP delayed acknowledgments. В сетях с высоким значением задержки, это может дать выгоду. По умолчанию она включена.

romx: Хочу также обратить внимание, что в речь идет именно о тонкой настройке и оптимизации определенных вариантов конфигурации, так как настройки SnapMirror по умолчаню выбраны для удовлетворительной работы в любых условиях. Если вы не уверены в том, что вы делаете, то лучше оставьте по умолчанию. Помните первое правило профессионала: “Работает - не трогай!” :)

Оригинал тут:
http://rajeev.name/blog/2008/03/18/optimizing-snapmirror-performance/
(будьте внимательны, на хостинге этой страницы сейчас сидит веб-червяк-троян!)