Как стать автором
Обновить

Попытка разогнать сеть для БД со 100 до 200Гб/c или «failure is always an option»

Уровень сложностиСредний
Время на прочтение6 мин
Количество просмотров11K
Всего голосов 15: ↑13 и ↓2+18
Комментарии4

Комментарии 4

Я так понимаю NUMA выключен для увеличения производительности БД, но если есть такой прирост у сетевого оборудования, может имеет смысл протестировать всю систему с numa=on ?

Тем более что потеря производительности реально не такая уж великая (см конец статьи с описанием проведённого теста):

NUMизматика, NUMерология и просто о NUMA
https://habr.com/p/165903/

У производителя СУБД очень много советов отключить NUMA.

Для системы критичнее стабильная работа, поэтому смирились с этим. Приложение важнее. Там целый комплекс различных серверов и рассматривали возможность роста производительности за счёт метода "просто добавим больше железа".

Просто совпадение достигаемой скорости стандартной конфигурации совпало с ограничением существовавшей конфигурации 4x25Гб и на то, что сдерживающим фактором в работе железа является софт, никто не думал.

Пришлось поработать инженером по производительности решения в целом, применяя практики нагрузочного тестирования.

На этапе нахождения готовой статьи в ожидании даты публикации она уже была переслана в пару команд, которым тоже надо было цифрами и тестами показать где у них узкое место. Так что она получилась больше про "методы стресс тестирования для чайников", а не про NUMA.

Чтобы уж совсем до конца довести - а не пробовали при отключенной NUMA инстансы iperf прибивать (через affinity) к тем же CPU, на которых висит соответствующая сетевая карта?

Иногда надо упрощать. Как в нолановском Inception

Arthur : Because in a 747, the pilot's up top, and the first class cabin's in the nose, so no one would walk through. But you'd have to buy out the entire cabin. And the first class flight attendant...

Saito : I bought the airline.

[Everybody turns and stares at him. Saito just shrugs]

Saito : It seemed neater.

Перемещать десятки процессоров раскиданных по сотне ядер требует больше времени, чем однострочником отключить ненужные ядра.

Быстро отработать гипотезу очень помогает в поиске решения, особенно при ограничении по времени. Все тесты мы произвели до обеда с обоснованиями почему 200Гб/с не будет.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий