Comments 8
Не меряли, что происходит с производительностью, если выломать все эти спинлоки и заменить на мьютексы?
Я пробовал такое на коленке, в целом картина такая
потребление CPU сильно отличается, мьютексы почти его не используют
с мьютексами тайминги повышаются где-то в пределах от сотни микросекунд до единицы миллисекунд, но это измерение на глаз, я списал это на погрешность.
Такой тест я проводил, когда баг с коллизиями ещё не был починен, и с мьютексами я наблюдал очень интересный спецэффект - unbound переставал работать без каких-то видимых причин (аномальное повышение CPU или ошибки в логе), проблема была видна только на таймингах ответов. Сейчас конечно понятно что там происходило, но в тот момент это только усложняло понимание.
... я старший разработчик в отделе сетевой инфраструктуры Яндекса
Только начал читать статью и внезапно разработчик сетевой инфраструктуры? Простите, но возникает вопрос в Яндексе какая-то непонятная структура ролей. Статья выглядит как типичное исследование для роли SDET или для QA роли. Впрочем возможно просто сбросили на "сетевика" проблему, а потом где-то в отчетах напишут о кросфункуциональности команд.
Этот абзац конечно не очень удачный
Всё началось с того, что мне предложили помочь ребятам из команды DNS найти такие метрики и наборы запросов
Мне предложили не просто метрики найти, а доработать тестовый стенд так, чтобы он показывал эти метрики в отчётах тестирования, что я в конечном итоге и сделал.
Мне задача показалась очень интересной и я взял её с удовольствием, получил много опыта и позитива и нисколько не жалею.
Не считаю, что должность человека является тут каким-то ограничением, если все действия согласованы и по общему согласию всех сторон.
Могу ещё добавить по своему опыту, что отделы QA с сильными SDET я видел только рядом с бизнес кодом, а всякие инфраструктурные отделы обычно не имеют выделенных QA отделов.
Моё личное мнение, что привлекать людей занятых тестированием бизнес кода будет дороже, и менее эффективно, чем найти человека внутри команды способного разобраться с проблемой и починить её.
Держать для маленьких команд свои собственные выделенные QA отделы тоже не выгодно.
Можете считать, что в рамках этой задачи я временно стал SDET.
не очень понятно: вы предлагаете на QA повесить такую глубокую оптимизацию?
Насколько я вижу, параметры сложно выбрать эмпирически - размер структуры второго уровня будет варироваться от входных данных (а точнее, от хэша по этим данным). Мб тогда стоит какую-то подстройку на основе статистики иметь? Метрики, конечно, полезно (включая добавленную метрику по коллизиям), но думаю прикольно чтоб тулза сама подсказывала оптимальные параметры.
Отдельное спасибо за примеры bpftrace
Захватывающая ловля багов, которые портили работу Unbound