Read ahead что это
HelpDesk
Чем мы можем вам сегодня помочь?
Виды кэша, настройка производительности на рейд контроллерах LSI и Intel Печать
Изменено: Сб, 2 Июл, 2016 at 1:52 AM
Общие понятия по видам кэш
Рассмотрим более детально, что из себя представляет каждая политика кэширования.
Read policy (Политика чтения)
Политика Read Ahead Policy: При ее включении контроллер начинает считывать последовательно сектора на диске, находящиеся за сектором с которого извлекается информация. При низкой фрагментации данная политика позволяет увеличить скорость чтения. Каждая операция чтения будет потреблять больше ресурсов жесткого диска, но если запросы на чтение последовательные это может существенно уменьшить количество запросов на чтение на жесткие диски и может существенно повысить производительность. Этот параметр будет работать только если типичный размер запроса на чтения меньше, чем ширина полосы пропускания.
Политика No Read Ahead (Normal): При данном режиме контроллер не будет считывать последовательно данные, данный режим предпочтительнее когда будут производиться рандомные (случайные) чтения. Также этот режим рекомендуется при измерении последовательного чтения с помощью I/O meter под Windows.
Политика Adaptive Read Policy: по сути политика адаптивного чтения при которой контроллер запускает политику упреждающего чтения только после того, как две последние операции запрашивали доступ к последовательно идущим блокам данных. Если далее идут блоки рандомно разбросанные по дисковой подсистеме контроллер возвращается в нормальный режим работы. Этот режим рекомендуется использовать, если нагрузка на RAID контроллере подразумевает смешанные и последовательные операции.
Write policy (Политика записи)
Disk cache policy: это политика кэша диска. Если ее включить то на дисках будет храниться дополнительный кэш, это будет влиять на скорость записи в худшую сторону, но будут быстрее считывание, так же при включенном режиме есть риск потери данных.
Оптимизация скорости бэкапов средствами файловой системы (read ahead, опережающее чтение)
Данная статья адресована инженерам и консультантам работающим с производительностью операций, связанных с последовательным чтением файлов. В основном, это конечно бэкапы. Cюда же можно включить чтение больших файлов с файловых хранилищ, некоторые операции баз данных, например полное сканирование таблиц (зависит от размещения данных).
Примеры приведены для файловой системы VxFS (Symantec). Данная файловая система достаточно широко используется в серверных системах и поддерживается на HP-UX, AIX,Linux, Solaris.
Зачем это нужно?
Вопрос состоит в том, как получить максимальную скорость при последовательном чтении данных в один поток (!) из большого файла (бэкап большого числа мелких файлов за рамками данной статьи). Последовательным чтением считаем такое, когда блоки данных с физических дисков запрашиваются один за другим, по порядку. Считаем, что фрагментация файловых систем отсутствует. Это обоснованно, так как если на файловой системе расположено немного файлов большого размера, и они редко пересоздаются, то практически не фрагментированы. Это обычная ситуация для баз данных, типа Oracle. Чтение из файла в таком случае мало отличается от чтения с сырого устройства.
Чем ограничена скорость однопоточного чтения?
Самые быстрые из современных дисков (15K rpm) имеют время доступа (service time) около 5.5 мс (для почитателей queuing theory, считаем время ожидания равным 0).
Определим количество операций ввода-вывода, которое может выполнить процесс(бэкапа):
1/0.0055 = 182 IO per second (iops).
Если процесс последовательно выполняет операции, каждая из которых длится 5.5 мс, за секунду он выполнит 182 штуки. Предположим, что размер блока составляет 256KB. Таким образом, максимальная пропускная способность данного процесса составит: 182* 256= 46545 KB/s. (46 MB/s). Скромно, правда? Особенно скромно это выглядит для систем с сотнями физических шпинделей, когда мы расчитываем на гораздо большую скорость чтения. Возникает вопрос, как это оптимизировать. Уменьшить время доступа к диску нельзя, так как это технологические ограничения. Распараллелить бэкап тоже не всегда удается. Для снятия данного ограничения на файловых системах реализуется механизм опережающего чтения (read ahead).
Как работает опережающее чтение
В cовременных *nix системах существует два типа запросов ввода-вывода: синхронные и асинхронные. При синхронном запросе, процесс блокируется до получения ответа от дисковой подсистемы. При асинхронном, не блокируется и может делать что-либо еще. При последовательном чтении, мы читаем данные синхронно. Когда включается механизм опережающего чтения, код файловой системы, сразу после синхронного запроса, делает еще несколько асинхронных. Предположим, процесс запросил блок номер 1000. При включенном read ahead, кроме блока 1000 будут запрошены еще и 1001,1002,1003,1004. Таким образом, при запросе блока 1001 нам нет необходимости ждать 5.5 мс. C помощью настройки read ahead можно значительно (в разы) увеличить скорость последовательного чтения.
Как настраивается?
Ключевой настройкой опережающего чтения является его размер. Забегая вперед скажу, что с read ahead есть две основные проблемы: недостаточный read ahead и чрезмерный. Итак, на VxFS read ahead настраивается с помощью параметров “read_pref_io” и “read_nstream” команды vxtunefs. Когда на VxFS включается опережающее чтение, изначально запрашивается 4 блока размером “read_pref_io”. Если процесс продолжает читать последовательно, то прочитывается 4*read_pref_io*read_nstream.
Пример
Пусть read_pref_io=256k и read_nstream=4
Таким образом начальный read ahead составит: 4*256KB =1024KB.
Если последовательное чтение продолжается, то: 4*4*256KB=4096KB
Необходимо заметить, что в последнем случае, в дисковую подсистему отправятся практически одновременно 16 запросов с блоком 256KB. Это не мало и на короткое время может хорошенько подгрузить массив. В общем случае, в настройке read_pref_io и read_nstream сложно давать какие-то общие советы. Конкретные решения всегда зависят от числа дисков в массиве и характера нагрузки. Для некоторых нагрузок отлично работает read_pref_io=256k и read_nstream=32 (очень много). Иногда, read_ahead лучше отключить совсем. Так как настройка простая и ставится она на на лету, проще всего подбирать оптимальное значение. Единственное, что можно посоветовать, всегда ставить read_pref_io по степеням 2. Или как минимум, чтобы они были кратными размеру блока данных в кеше ОС. Иначе, последствия могут быть непредсказуемыми.
Влияние буферного кеша ОС
Когда read ahead асинхронно прочитывает данные, их надо хранить где-то в памяти. Для этого используется файловый кеш операционной системы. В ряде случаев, файловую систему можно смонтировать с отключенным файловым кешем (direct IO). Соответственно, функциональность read ahead в этом случае отключается.
Основные проблемы с опережающим чтением:
1) Недостаточный read ahead. Размер блока, который запросило приложение, больше блока считанного через read ahead. Например, команда ‘cp’ может читать блоком 1024 KB, а опережающее чтение настроено на чтение 256KB. То есть данных просто не хватит чтобы удовлетворить приложение и необходим еще один синхронный запрос ввода-вывода. В данном случае, включение read ahead не принесет увеличения скорости.
2) Чрезмерный read ahead
— слишком агрессивный read ahead может попросту перегрузить дисковую подсистему. Особенно, если в бэкенде установлено мало шпинделей. Большое число практически параллельных запросов свалившихся с хоста могут зафлудить дисковый массив. В этом случае, вместо ускорения вы увидите замедления в работе.
— другой проблемой с read ahead могут быть промахи, когда файловая система ошибочно определяет последовательное чтение прочитывает ненужные данные в кеш. Это приводит к паразитным операциям ввода-вывода, и создает дополнительную нагрузку на диски.
— так как данные read ahead хранятся в кеше файловой системы, большой объем read ahead может приводить к вымыванию из кеша более ценных блоков. Эти блоки потом придется прочитывать с диска снова.
3) Конфликт между read ahead файловой системы и read ahead дискового массива
К счастью, это крайне редкий случай. В большинстве современных дисковых массивов, оснащенных кеш-памятью и логикой, на аппаратном уровне реализован собственный механизм read ahead. Логика массива cама определяет последовательное чтение и контроллер оптом считывает данные с физических дисков в кеш массива. Это позволяет значительно сократить время отклика от дисковой подсистемы и увеличить скорость последовательного чтения. Опережающее чтение файловой системы несколько отличается от обычного синхронного чтения и может сбивать с толку контроллер дискового массива. Он может не распознать характер нагрузки и не включить аппаратный read ahead. Например, если дисковый массив подключен по SAN (Storage Area Networking) и до него есть несколько путей. Из-за балансировки нагрузки асинхронные запросы могут приходить на разные порты дискового массива практически одновременно. В таком случае, запросы могут быть обработаны контроллером не в том порядке, как они отправлены с сервера. Как следствие, массив не распознает последовательное чтение. Решение подобных проблем может быть наиболее долгим и трудоемким. Иногда решение лежит в области настройки, иногда помогает отключение одного из read ahead (если это возможно), иногда необходимо изменение кода одного из компонент.
Пример влияния опережающего чтения
Заказчик был неудовлетворен временем резервного копирования базы данных. В качестве теста, выполнялся бэкап одного файла размером 50 GB. Дальше приведены результаты трех тестов с различными настройками файловой системы.
Directories… 0
Regular files… 1
— Objects Total… 1
Total Size… 50.51 GB
1. Опережающее чтение выключено (Direct IO)
Run Time… 0:17:10
Backup Speed… 71.99 MB/s
2. Стандартные настройки опережающего чтения (read_pref_io = 65536, read_nstream = 1)
Run Time… 0:05:17
Backup Speed… 163.16 MB/s
3. Увеличенный (сильно) размер опережающего чтения (read_pref_io = 262144, read_nstream = 64)
Run Time… 0:02:27
Backup Speed… 222.91 MB/s
Как видно из примера, read ahead позволил значительно сократить время бэкапа. Дальнейшая эксплуатация показала, что все остальные задачи на системе нормально работали с таким большим размером read ahead (тест 3). Каких-либо проблем из-за чрезмерного read ahead не было замечено. В результате, эти настройки и оставили.
Read ahead что это
Всем привет, давно хотел написать для себя напоминалку, по поводу того какие виды кэша на рейд контроллерах LSI и Intel бывают, и какие настройки лучше всего выставлять для достижения максимальной производительности на ваших RAID контроллерах. Сразу хочу отметить, что если у вас есть запас времени, перед, тем как отдать сервер в продашен заказчику, то не поленитесь все же провести несколько тестов с разными настройками, и не забывайте, до их начала обновить все прошивки на оборудование и RAID контроллер.
Общие понятия по видам кэш
Существует три разновидности cache на RAID контроллерах:
Рассмотрим более детально, что из себя представляет каждая политика кэширования.
Read policy (Политика чтения)
Политика Read Ahead Policy: При ее включении контроллер начинает считывать последовательно сектора на диске, находящиеся за сектором с которого извлекается информация. При низкой фрагментации данная политика позволяет увеличить скорость чтения. Каждая операция чтения будет потреблять больше ресурсов жесткого диска, но если запросы на чтение последовательные это может существенно уменьшить количество запросов на чтение на жесткие диски и может существенно повысить производительность. Этот параметр будет работать только если типичный размер запроса на чтения меньше, чем ширина полосы пропускания.
Политика No Read Ahead (Normal) : При данном режиме контроллер не будет считывать последовательно данные, данный режим предпочтительнее когда будут производиться рандомные (случайные) чтения. Также этот режим рекомендуется при измерении последовательного чтения с помощью I/O meter под Windows.
Политика Adaptive Read Policy : по сути политика адаптивного чтения при которой контроллер запускает политику упреждающего чтения только после того, как две последние операции запрашивали доступ к последовательно идущим блокам данных. Если далее идут блоки рандомно разбросанные по дисковой подсистеме контроллер возвращается в нормальный режим работы. Этот режим рекомендуется использовать, если нагрузка на RAID контроллере подразумевает смешанные и последовательные операции.
Write policy (Политика записи)
Политика W rite-Through : Включая данную политику контроллер начинает посылает сигнал о завершении записи только тогда, когда информация упадет на физические носители, т.е. 100 процентов будет уже на жестких дисках. Обеспечивает более высокую безопасность. Данный режим не использует кэш для ускорения записи, и будет медленнее других, однако позволяет так же достичь хороших показателей при RAID 0 и RAID 10.
Политика Write-Back : Включая данный режим политика кэширования RAID контроллера начинает посылать сигнал о завершении записи только тогда, когда информация попадает в кэш контроллера, но еще не записана на дисковый массив. Обеспечивает более высокую прозводительность чем при политике write-through. Приложение продолжает работать, не дожидаясь, чтобы данные были физически записаны на жесткие диски. Но есть одно большое, но если во время работы RAID контроллера в таком режиме у вас пропадет электричество, то с 99 процентной вероятностью вы потеряете данные, для предотвращения этого есть BBU батарейки или модули защиты данных, так же советую проверить что у вашего сервера есть UPS (источник бесперебойного питания) и дублирующее подключение питания от блока питания.
Политика Write-Back with BBU : Данный режим это все тот же Write-Back, но разница в том, что у нас есть батарейка BBU, которая предотвращает потерю данных при выключении электропитания.
BBU или Battery Backup Unit (Модуль Резервной Батареи). BBU дает батарейную защиту питания для cache RAID контроллера. В случае сбоя питания, BBU поможет сохранить данные в кэше.
I/O Policy (Политика ввода/вывода)
Политика ввода/вывода определяет, будет ли RAID контроллер сохранять данные в кэше, который может уменьшить время доступа к ним при последующих запросах на чтение сделаными в те же самые блоки данных.
Политика direct IO : чтение происходит с дисков. Прямой режим I/O рекомендуется в большинстве случаев. Большинство файловых систем и множество приложений имеют свой собственный кэш и не требуют кэширования данных на уровне контроллера RAID.
Политика Cached IO : При ее включении чтение происходит с дисков, но прочитанные данные одновременно кладутся в кэш. Запросы тех же данных в последствии берутся из кэша. Этот режим может потребоваться, если приложение или файловая система не кэширует запросы чтения
Disk cache policy : это политика кэша диска. Если ее включить то на дисках будет храниться дополнительный кэш, это будет влиять на скорость записи в худшую сторону, но будут быстрее считывание, так же при включенном режиме есть риск потери данных.
Настройка RAID контроллера для лучшей производительности
Любой инженер по системам хранения данных, хочет чтобы его инфраструктура работала как можно быстрее и использовала весь функционал заложенный в ней. Каждый вендор RAID контроллеров, имеет некий best prictice для своей продукции, давайте сегодня рассмотрим их на примере контроллеров Intel и LSI.
Оптимальные настройки для контроллеров Intel
Ниже представлена таблица с рекомендуемыми настройками для контроллеров Intel, для достижения максимальной производительности. О таких параметрах как Stripe size, Virtual Drive initialization, Consistency Check, Patrol Read мы поговорим ниже. Как видите лучшим режимом чтения является Adaptive Read Ahead, а режимом записи Write Back.
Оптимальные настройки для контроллеров LSI
Ниже представлена таблица с рекомендуемыми настройками для контроллеров LSI, для достижения максимальной производительности. Будут рассмотрены сводные таблицы для HDD и для SSd дисков.
Оптимальные настройки для HDD
Размер stripe 256 kb, включение disk Cache Policy включен, выбран I/O Policy Direct IO, нужно дать закончить lun инициализацию
MegaRAID Settings for Maximum HDD Performance
Оптимальные настройки для SSD
Размер stripe 256 kb, включение disk Cache Policy включен, выбран I/O Policy Direct IO, нужно дать закончить lun инициализацию, режимы записи для разных видов RAID разные.
MegaRAID Settings for Maximum SSD Performance
Оптимальные настройки для HP контроллеров
Факторы влияющие на производительность
Рассмотрим что такое Stripe size, Virtual Drive initialization, Consistency Check, Patrol Read.
Упреждающее чтение
Контроллер ввода-вывода выполняет поиск и чтение блоков данных асинхронно относительно центрального процессора и генерирует прерывания по завершении операции. Если известно, что блоки, расположенные за текущей областью чтения будут впоследствии прочитаны с большой вероятностью, то запросы на их чтение могут быть выданы одновременно с запросами на чтение блоков, располеженных в текущей области чтения.
По завершении упреждающего чтения данные блока помещаются в буфер сверхопертивной памяти (кэш) и сразу же становятся доступны читающему процессу (процессам).
Принцип локальности
Ссылки
Полезное
Смотреть что такое «Упреждающее чтение» в других словарях:
Google Chrome — Для термина «Chrome» см. другие значения. Эта статья о браузере; об операционной системе см.: Google Chrome OS. Google Chrome … Википедия
Процессоры — Intel 80486DX2 в керамическом корпусе PGA. Intel Celeron 400 socket 370 в пластиковом корпусе PPGA, вид снизу. Intel Celeron 400 socket 370 в пластиковом корпусе PPGA, вид сверху … Википедия
ЦП — Intel 80486DX2 в керамическом корпусе PGA. Intel Celeron 400 socket 370 в пластиковом корпусе PPGA, вид снизу. Intel Celeron 400 socket 370 в пластиковом корпусе PPGA, вид сверху … Википедия
ЦПУ — Intel 80486DX2 в керамическом корпусе PGA. Intel Celeron 400 socket 370 в пластиковом корпусе PPGA, вид снизу. Intel Celeron 400 socket 370 в пластиковом корпусе PPGA, вид сверху … Википедия
Центральное процессорное устройство — Intel 80486DX2 в керамическом корпусе PGA. Intel Celeron 400 socket 370 в пластиковом корпусе PPGA, вид снизу. Intel Celeron 400 socket 370 в пластиковом корпусе PPGA, вид сверху … Википедия
Центральный процессор — Intel 80486DX2 в керамическом корпусе PGA. Intel Celeron 400 socket 370 в пластиковом корпусе PPGA, вид снизу. Intel Celeron 400 socket 370 в пластиковом корпусе PPGA, вид сверху … Википедия
Адаптивный Read-Ahead
Применение
Назначением технологии упреждающего чтения (read-ahead) является существенное сокращение времени доступа и повышение пропускной способности системы хранения данных при работе с последовательным запросами на чтение.
Особую ценность механизм упреждающего чтения представляет в СХД, используемых для задач видеопроизводства, где нагрузка последовательного чтения может возникать одновременно с нескольких рабочих станций. При работе с множественными последовательными потоками происходит перемешивание траффика (блендер-эффект), при котором на входе в СХД поступает поток случайной нагрузки. Для эффективной работой в такой ситуации требуются особые механизмы распознавания и обнаружения запросов.
Принцип работы
Принцип работы технологии упреждающего чтения заключается в том, чтобы на основании уже существующих запросов определить, какие данные будут запрошены следующими, и заранее переносить их с жестких дисков на более быстрые носители, такие как RAM или SSD.
При этом, работа механизма упреждающего чтения состоит из двух этапов: (1) обнаружение запросов последовательного чтения в потоке всех запросов и (2) принятие решения, о необходимости считывания данных наперед, и их объеме.
Основная особенность механизма read-ahead в RAIDIX заключается в собственном алгоритме обнаружении запросов, который основан на понятии диапазонов, соответствующих связным интервалам адресного пространства. Для каждого пришедшего запроса на чтение происходит поиск ближайших диапазонов, по которому оценивается его тип нагрузки. Если запрос оказывается в последовательном диапазоне, то для него может быть произведено упреждающее чтение.
Далее в зависимости от скорости и размеров блоков для потока определяется оптимальное количество прогнозируемых данных, которые следует поместить в кэш (RAM). Поместив «горячие данные» на быстрый накопитель, система сокращает время запросов к этим блокам, что значительно повышает общую производительность СХД.