Байткод эрланга выполняет очень хорошо отлаженная виртуальная машина BEAM, которая превосходно работает даже на современных 72-х и более ядерных компьютерах. Ключевая возможность эрланга в том, чтобы использовать все ядра в одном приложении, т.е. иметь в памяти одни и те же данные и обеспечивать к ним доступ без запуска кучи экземпляров одного и того же приложения по количеству ядер. С ростом обрабатываемого трафика данных начинают возникать проблемы с многоядерным доступом к данным, возникают бутылочные горлышки и более низкоуровневые проблемы синхронизации. В этом докладе будет рассказано, какие есть методы поиска, анализа, замера и устранения различных проблем, связанных с многотредностью: синглтонные процессы, простаивания на мьютексах и т.п.

1. Отладка multicore
производительности
софта на Erlang
Максим Лапшин
max@erlyvideo.org

2. Multicore профилирование
• Когда одного ядра не хватает
• И процессор недозагружен
• А скорость обработки падает

3. Добро пожаловать в
уютный multicore ад

4. multicore там, где надо в памяти
состыковывать онлайн клиентов

5. О чём поговорим
• История одного тикета в нашем редмайне
• Пришли два клиента, пожаловались на тормоза
• Мы пошли разбираться

6. htop что-то показывает

7. Erlang использует акторы
начнем их исследовать

8. Акторы вместо тредов
• Актор — это микропроцесс в общем пространстве
• Изоляция по данным
• Коммуникация с помощью сообщений
• Share nothing облегчает параллелизм
• Ещё неплохо бы immutable

9. etop
• в erlang вызов функции — редукция
• каждый оборот цикла — редукция
• etop меряет по редукциям

10. fprof, eprof
• Очень грубые профилировщики линейного кода
• меряют больше редукции, чем такты CPU
• вносят сильные искажения в замеры

11. htop вам не друг
• scheduler spin time — жжет такты впустую
• надо смотреть на scheduler usage внутри beam
• erlang:statistics(scheduler_wall_time)

12. Чего-то намеряли, но
ничего непонятно

13. Акторы тупят
• Всё весело запрограммировали, но всё легло
• Пропускная способность ниже рассчетной
• CPU мало используется
• Как эти ваши акторы профилировать?!!

14. Бутылочные горлышки
• Работы много, но всё поручили одному
• Например это актор синглтон
• Инспектируем очереди сообщений

15. Перегруженный актор
• Берем список процессов
• Забираем process_info(Pid, message_queue_len)
• Сортируем
• У первых 10 берем стектрейс

16. Перегруженный актор
• Тысячи или миллионы сообщений в очереди
• Надо шардить или рефакторить
• Erlang пенализирует того, кто шлет такому
сообщения (но об этом подробнее дальше)
• То же самое будет в Go/Scala
• Можно воспользоваться ets

17. Привет, блокировки
• Треды лишь спрятаны акторами
• Мьютексы никуда не делись
• Просто теперь они спрятаны
• Но erlang помогает их отследить!

18. Где мьютексы в erlang
• главный мьютекс у каждой ets
• 8-16 мьютексов на чтение и запись в ets
• мьютекс у каждого процесса
• и ещё около сотни

19. lcnt

20. lcnt
• инструмент в erlang для сборки метрик по мьютексам
• стоит некоторых ресурсов, но не смертельно
• некоторые ньюансы пришлось патчить в эрланге
• кроме мьютексов есть spinlock в ets

21. lcnt
• Для тех, кто читает со slideshare
• lcnt:start(), lcnt:rt_opt({copy_save, true}),lcnt:clear(),
timer:sleep(5000), lcnt:collect(), lcnt:swap_pid_keys(),
lcnt:conflicts([{max_locks, 5}]).
• lcnt:inspect(proc_status).

22. Как можно всё испортить?
• проверять process_info у другого процесса
• очень много писать в ets
• межтредное взаимодействие
• бездумно частая аллокация

23. Перегружен синглтон

24. Механика поломок
• отправитель делает process_info(flu_pulsedb,
message_queue_len)
• bif лочит очередь сообщений flu_pulsedb
• коллизии на очереди сообщений (proc_msgq)
• все шедулеры тормозят

25. Перегружена ets

26. Что делать с ets?
• Шардить на разные ets. Больше таблиц, больше
локов, реже коллизии
• Пропускать всё через единый процесс на таблицу

27. О чём умолчим
• эффект от atomic на N-процессорном сервере
• false sharing
• как это детектить в эрланге — непонятно

28. Локи убрали, CPU в полку,
что дальше?

29. scheduler time
• С помощью trace можно узнать время постановки
и снятия с шедулера
• очень жестокая штука
• помогает получить иную картину мира

30. msacc
• Очень дешевый быстрый анализ расходов CPU
• аллокатор, C code, busy_wait, check_io, emulator,
ets, gc, gc_full, nif, port, send, sleep, timers, other
• надо перекомпиливать для расширенного
варианта

31. msacc
• Включается, собирает, выключается
• Можно мерять за 2-10 секунд
• Но имеет смысл ловить всплески за 100-200 мс

32. msacc

33. msacc
• Оказалось, замучали аллокатор

34. Что делать с аллокатором?
• В erlang очень, очень крутые аллокаторы
• Мультитредные, многоступенчатые
• Удобно и понятно настраивается
• +MBas aoffcaobf +MBacul 0 -MBlmbcs 512 -MEas
aobf -MElmbcs 512

35. instrument
• Ещё один механизм изучения erlang VM
• показывает, кто аллоцирует много данных
• тяжело запускать на полном продакшне

36. instrument

37. instrument
• Нашли, где делаем кучу лишней аллокации

38. erts_alloc_config
• Подбирает настройки аллокатора
• Но выключает мультитредный аллокатор
(beam +Mea config)
• Собирает историю и предлагает настройки

39. Наш опыт
• Потратили 3 месяца на поиск загадочной
проблемы, спонтанно возникшей где-то
• Разгребли 9 фатальных локов с помощью lcnt,
msacc
• Починили аллокацию с помощью instrument,
erts_alloc_config
• Случайно нашли три строчки, портивших всё

40. Вопросы?
Максим Лапшин, Flussonic
max@erlyvideo.org