Комментарии 4
Я так понимаю NUMA выключен для увеличения производительности БД, но если есть такой прирост у сетевого оборудования, может имеет смысл протестировать всю систему с numa=on ?
Тем более что потеря производительности реально не такая уж великая (см конец статьи с описанием проведённого теста):
NUMизматика, NUMерология и просто о NUMA
https://habr.com/p/165903/
У производителя СУБД очень много советов отключить NUMA.
Для системы критичнее стабильная работа, поэтому смирились с этим. Приложение важнее. Там целый комплекс различных серверов и рассматривали возможность роста производительности за счёт метода "просто добавим больше железа".
Просто совпадение достигаемой скорости стандартной конфигурации совпало с ограничением существовавшей конфигурации 4x25Гб и на то, что сдерживающим фактором в работе железа является софт, никто не думал.
Пришлось поработать инженером по производительности решения в целом, применяя практики нагрузочного тестирования.
На этапе нахождения готовой статьи в ожидании даты публикации она уже была переслана в пару команд, которым тоже надо было цифрами и тестами показать где у них узкое место. Так что она получилась больше про "методы стресс тестирования для чайников", а не про NUMA.
Чтобы уж совсем до конца довести - а не пробовали при отключенной NUMA инстансы iperf прибивать (через affinity) к тем же CPU, на которых висит соответствующая сетевая карта?
Иногда надо упрощать. Как в нолановском Inception
[Everybody turns and stares at him. Saito just shrugs]
Перемещать десятки процессоров раскиданных по сотне ядер требует больше времени, чем однострочником отключить ненужные ядра.
Быстро отработать гипотезу очень помогает в поиске решения, особенно при ограничении по времени. Все тесты мы произвели до обеда с обоснованиями почему 200Гб/с не будет.
Попытка разогнать сеть для БД со 100 до 200Гб/c или «failure is always an option»