От High Ceph Latency к Kernel Patch с помощью eBPF/BCC

В Linux есть большое количество инструментов для отладки ядра и приложений. Большинство из них негативно сказываются на производительности приложений и не могут быть использованы в продакшене.

Пару лет назад был разработан ещё один инструмент — eBPF. Он дает возможность трассировать ядро и пользовательские приложения с низким оверхедом и без необходимости пересборки программ и загрузки сторонних модулей в ядро.
lwn.net/Articles/740157/

Сейчас уже существует множество прикладных утилит, которые используют eBPF, и в этой статье мы рассмотрим, как написать собственную утилиту для профилирования на основе библиотеки PythonBCC. Статья основана на реальных событиях. Мы пройдем путь от появления проблемы и до её исправления, чтобы показать, как могут быть использованы уже существующие утилиты в конкретных ситуациях.

Ceph Is Slow
В кластер Ceph добавили новый хост. После миграции части данных на него, мы заметили, что скорость обработки запросов на запись им гораздо ниже, чем на других серверах.

В отличие от других платформ, на этом хосте использовался bcache и новое ядро linux 4.15. Хост такой конфигурации использовался здесь впервые. И на тот момент было ясно, что корнем проблемы теоретически могло быть что угодно.

Investigating the Host
Начнем с того, что посмотрим, что происходит внутри процесса ceph-osd. Для этого воспользуемся perf и flamescope (подробнее о которых можно прочитать здесь):

Картинка говорит нам о том, что функция fdatasync() потратила много времени при отправке запроса в функции generic_make_request(). Значит, что, скорее всего, причина проблем где-то вне самого демона osd. Это может быть либо ядро, либо диски. Вывод iostat показывал высокую задержку обработки запросов bcache-дисками.

При проверке хоста мы обнаружили, что демон systemd-udevd потребляет большое количество времени CPU — около 20% на нескольких ядрах. Это странное поведение, так что нужно выяснить его причину. Так как Systemd-udevd работает с uevent’ами, мы решили посмотреть на них через udevadm monitor. Оказывается, генерировалось большое количество change-событий для каждого блочного устройства в системе. Это довольно необычно, поэтому нужно будет посмотреть, что генерирует все эти ивенты.

Подробнее
blog.selectel.ru/from-high-ceph-latency-to-kernel-patch-with-ebpf-bcc/