Спасибо.
В случае последовательных операций с большими файлами вам не будет интерестна латенси, вместо этого более интерестно рассматривать в данном случае MB/s.
IOPs'ы обычно являются мерой операций случайного чтения/записи на нагрузках мелкими блоками ( Базы Данных, VDI, почтовые сервисы и т.д.), для таких задач латенси выше 20мс считается не приемлемо высоким значением.
Другими словами, в случае вашей нагрузки, латенси 120-140msec 6000IOPs это совсем не много.
Я так понимаю это была серия тестов. И IOPs 6000 это один тест, а 500 МБ/sec это другой тест, не так ли?
Если вы имеете на 6ти R5 SATA дисках 6000 IOPS, то у вас должно быть высокое латенси.
Интересует какое значение IOPs, латенси [ms], соотношение чтение/запись [%], скорость чтения/записи [MByte/sec] наблюдается в один момент времени для одного теста.
Может у вас есть такие данные? Если нет, если не сложно, делая новый тест, запишите их пожалуйста.
Тут ещё стоило бы уточнить протокол (CIFS/NFS), задержки, соотношение чтение/запись, средний размер оперируемого блока и рандумность. Хотя рандомность полагаю = 0%, т.е. в принципе нет — все данные это фотографии большего размера.
Сами по себе иопсы — попугаи без удава. alsakharov
В случае применения СХД, настройка QoS на ввод-вывод как правило выполняется на самой СХД, а не на стороне сервера. Это кстати более удобно, когда у вас множество серверов (скорее всего гетерогенных), вы настраиваете все в одном месте, а не на каждом сервере.
Видимо отсюда и проистикает рекомендация использовать noop.
В нашем случае выигрыш был существенным, во-первых утилизация CPU упала, во-вторых была увеличина пропускная способность по записи.
В случае с netapp параметр noop рекомендован. На сколько мне известно, в случае многих других производителей СХД, имеется та же ситуация.
Так что настройки «для ноута с SDD» и «для сервера с SAN LUN» похоже имеют существенные отличия в рекомендациях по оптимизации.
Но я не стремился к сравнению noop vs CFQ. Т.е. настраивали не только шедулер, сменили файловую систему, параметры sysctl.
Стремился получить наиболее оптимальную систему по вводу-выводу. Так что может noop и проигрывал немного (если не менять всего остального), а на тюнинге других параметрах ввода-вывода выигрывал на столько, что в сумме без noop вышло лучше.
У одного заказчика, после изменения с дефолтных значений для vm.dirty_ratio и scheduler, удалось получить наиболее оптимальную производительность для RedHat Enterprice Linux6 с СХД NetApp и подключением по FC8GB со значениями vm.dirty_ratio = 2, и scheduler = noop, существенно снизив нагрузку ЦПУ хоста.
Вы всё ещё пишете в публичном доступе.
Вот именно. Если проблема не может быть повторена, значит вы не знаете в чём проблема на самом деле.
Это означает следуйте рекомендациям сапорта.
1) Вым были даны две рекомендации 2) просили создать лабораторию и повторить проблему.
И уж потом третий, самый крайний вариант, если первые два вы не можете/не хотите/не можете выполнять — это дождаться ситуации или спровоцировать её под вашим контролем и снять перфстат.
Если вы не хотите снимать перфстат, у вас были ещё варианты.
Дайте мне контакты человека который утверждает, что проблема до сих пор повторяется.
И в личной переписке я уже третий раз прошу вас закончить публичную переписку.
Единственное, что одинаково, это подход к поиску узких мест в нифраструктуре ЦОД методом последовательного исключения: СХД -> Сеть -> Хост -> Приложение. Хотя направление, откуда начинать, на самом деле не важно.
Каждый из этих узлов инфраструктуры можно условно разделить на компоненты, к примеру для хоста это может быть: Настройки самой ОС, сетевые настройки в нутри ОС, приложения.
Сначала пытаются заменить, по одному, каждый компонет на точно работающий и так один за другим, каждый раз проверяя не ушла ли проблема, таким образом определив в каком месте затык: СХД, Сеть, Хост или приложение вызывают проблемы. Определив направление проблемы переходят к детальному изучению и тюнингу этого проблемного компонента, так последовательно один за другим проверяются все компоненты узла, таким образом находят узкое место.
Уверен у HP P2000 рекомендации, по SAN Multipathing отличаются. О поддержке и скорости работы для iSCSI MCS мне не известно. Настройки MTU в принципе скорее всего совпадают. Хостовые утилиты у HP свои, у Synology их, подозреваю вообще нет, рекомендации по таймаутам уверен тоже отличаются. Perfmon/logman понятное дело работают также. Вопрос совместимости проверять стоит везде и всегда у всех вендоров, даже если у вас вся инфраструктура ЦОД построена, к примеру на HP. Рекомендации по настройке приложений тоже отличаются, как и рекомендации по параметрам монтирования файловых систем.
Так что в общем случае — рекомендации совсем разные.
Пардон промахнулся с ответом, хотел ответить «чуть выше» Ghool
Кстати в новых системах FlashRay, точно по той же причине отсутствует поддержка TRIM, несмотря на то, что в системе используются диски «потребительского» или как я выразился ранее «юзерского уровня».
Это мое личное восприятие.
В случае последовательных операций с большими файлами вам не будет интерестна латенси, вместо этого более интерестно рассматривать в данном случае MB/s.
IOPs'ы обычно являются мерой операций случайного чтения/записи на нагрузках мелкими блоками ( Базы Данных, VDI, почтовые сервисы и т.д.), для таких задач латенси выше 20мс считается не приемлемо высоким значением.
Другими словами, в случае вашей нагрузки, латенси 120-140msec 6000IOPs это совсем не много.
Если вы имеете на 6ти R5 SATA дисках 6000 IOPS, то у вас должно быть высокое латенси.
Интересует какое значение IOPs, латенси [ms], соотношение чтение/запись [%], скорость чтения/записи [MByte/sec] наблюдается в один момент времени для одного теста.
Может у вас есть такие данные? Если нет, если не сложно, делая новый тест, запишите их пожалуйста.
И IOPS это на фронтенде ведь?
Сами по себе иопсы — попугаи без удава.
alsakharov
В случае применения СХД, настройка QoS на ввод-вывод как правило выполняется на самой СХД, а не на стороне сервера. Это кстати более удобно, когда у вас множество серверов (скорее всего гетерогенных), вы настраиваете все в одном месте, а не на каждом сервере.
Видимо отсюда и проистикает рекомендация использовать noop.
В случае с netapp параметр noop рекомендован. На сколько мне известно, в случае многих других производителей СХД, имеется та же ситуация.
Так что настройки «для ноута с SDD» и «для сервера с SAN LUN» похоже имеют существенные отличия в рекомендациях по оптимизации.
Но я не стремился к сравнению noop vs CFQ. Т.е. настраивали не только шедулер, сменили файловую систему, параметры sysctl.
Стремился получить наиболее оптимальную систему по вводу-выводу. Так что может noop и проигрывал немного (если не менять всего остального), а на тюнинге других параметрах ввода-вывода выигрывал на столько, что в сумме без noop вышло лучше.
А сказали, что вас заставили ждать когда снимиться перфстат.
Вот именно. Если проблема не может быть повторена, значит вы не знаете в чём проблема на самом деле.
Это означает следуйте рекомендациям сапорта.
1) Вым были даны две рекомендации 2) просили создать лабораторию и повторить проблему.
И уж потом третий, самый крайний вариант, если первые два вы не можете/не хотите/не можете выполнять — это дождаться ситуации или спровоцировать её под вашим контролем и снять перфстат.
Если вы не хотите снимать перфстат, у вас были ещё варианты.
Дайте мне контакты человека который утверждает, что проблема до сих пор повторяется.
И в личной переписке я уже третий раз прошу вас закончить публичную переписку.
Каждый из этих узлов инфраструктуры можно условно разделить на компоненты, к примеру для хоста это может быть: Настройки самой ОС, сетевые настройки в нутри ОС, приложения.
Сначала пытаются заменить, по одному, каждый компонет на точно работающий и так один за другим, каждый раз проверяя не ушла ли проблема, таким образом определив в каком месте затык: СХД, Сеть, Хост или приложение вызывают проблемы. Определив направление проблемы переходят к детальному изучению и тюнингу этого проблемного компонента, так последовательно один за другим проверяются все компоненты узла, таким образом находят узкое место.
Так что в общем случае — рекомендации совсем разные.
Кстати в новых системах FlashRay, точно по той же причине отсутствует поддержка TRIM, несмотря на то, что в системе используются диски «потребительского» или как я выразился ранее «юзерского уровня».