Comments 6
Очень хорошая статья, большое спасибо.
Удалось ли вам снизить нагрузку на 8-ое ядро процессора на картинке с htop-ом, скажем, до 50% путем манипуляций с планировщиком вода-вывода?
Удалось ли вам снизить нагрузку на 8-ое ядро процессора на картинке с htop-ом, скажем, до 50% путем манипуляций с планировщиком вода-вывода?
У одного заказчика, после изменения с дефолтных значений для vm.dirty_ratio и scheduler, удалось получить наиболее оптимальную производительность для RedHat Enterprice Linux6 с СХД NetApp и подключением по FC8GB со значениями vm.dirty_ratio = 2, и scheduler = noop, существенно снизив нагрузку ЦПУ хоста.
Я это, собственно, к чему: я не нашел тестов, которые бы подтверждали выигрыш от смены CFQ на noop. Вот старый тест RedHat на Oracle 10G:
Вот новый тест Фороникса, уже на SSD:
Я сомневаюсь, что код CFQ настолько плох, что становится узким местом на «обычных» хранилищах (про all-SSD я не говорю). Зато, отказываясь от CFQ мы теряем возможность задавать разным процессам разные приоритеты ввода-вывода, потому что ionice работает только с CFQ (man ionice: «Linux supports io scheduling priorities and classes since 2.6.13 with the CFQ io scheduler»)
Вот новый тест Фороникса, уже на SSD:
Я сомневаюсь, что код CFQ настолько плох, что становится узким местом на «обычных» хранилищах (про all-SSD я не говорю). Зато, отказываясь от CFQ мы теряем возможность задавать разным процессам разные приоритеты ввода-вывода, потому что ionice работает только с CFQ (man ionice: «Linux supports io scheduling priorities and classes since 2.6.13 with the CFQ io scheduler»)
В нашем случае выигрыш был существенным, во-первых утилизация CPU упала, во-вторых была увеличина пропускная способность по записи.
В случае с netapp параметр noop рекомендован. На сколько мне известно, в случае многих других производителей СХД, имеется та же ситуация.
Так что настройки «для ноута с SDD» и «для сервера с SAN LUN» похоже имеют существенные отличия в рекомендациях по оптимизации.
Но я не стремился к сравнению noop vs CFQ. Т.е. настраивали не только шедулер, сменили файловую систему, параметры sysctl.
Стремился получить наиболее оптимальную систему по вводу-выводу. Так что может noop и проигрывал немного (если не менять всего остального), а на тюнинге других параметрах ввода-вывода выигрывал на столько, что в сумме без noop вышло лучше.
В случае с netapp параметр noop рекомендован. На сколько мне известно, в случае многих других производителей СХД, имеется та же ситуация.
Так что настройки «для ноута с SDD» и «для сервера с SAN LUN» похоже имеют существенные отличия в рекомендациях по оптимизации.
Но я не стремился к сравнению noop vs CFQ. Т.е. настраивали не только шедулер, сменили файловую систему, параметры sysctl.
Стремился получить наиболее оптимальную систему по вводу-выводу. Так что может noop и проигрывал немного (если не менять всего остального), а на тюнинге других параметрах ввода-вывода выигрывал на столько, что в сумме без noop вышло лучше.
На счёт приоритетов:
В случае применения СХД, настройка QoS на ввод-вывод как правило выполняется на самой СХД, а не на стороне сервера. Это кстати более удобно, когда у вас множество серверов (скорее всего гетерогенных), вы настраиваете все в одном месте, а не на каждом сервере.
Видимо отсюда и проистикает рекомендация использовать noop.
В случае применения СХД, настройка QoS на ввод-вывод как правило выполняется на самой СХД, а не на стороне сервера. Это кстати более удобно, когда у вас множество серверов (скорее всего гетерогенных), вы настраиваете все в одном месте, а не на каждом сервере.
Видимо отсюда и проистикает рекомендация использовать noop.
Sign up to leave a comment.
RedHat/Oracle Linux с NetApp FAS (SAN)