Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Отладка производительности приложения на Erlang / Максим Лапшин (Erlyvideo)

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

Ключевая возможность эрланга в том, чтобы использовать все ядра в одном приложении, т.е. иметь в памяти одни и те же данные и обеспечивать к ним доступ без запуска кучи экземпляров одного и того же приложения по количеству ядер.

С ростом обрабатываемого трафика данных начинают возникать проблемы с многоядерным доступом к данным, возникают бутылочные горлышки и более низкоуровневые проблемы синхронизации.

В этом докладе будет рассказано, какие есть методы поиска, анализа, замера и устранения различных проблем, связанных с многотредностью: синглтонные процессы, простаивания на мьютексах и т.п.

  • Login to see the comments

Отладка производительности приложения на Erlang / Максим Лапшин (Erlyvideo)

  1. 1. Отладка multicore производительности софта на Erlang Максим Лапшин max@erlyvideo.org
  2. 2. Multicore профилирование • Когда одного ядра не хватает • И процессор недозагружен • А скорость обработки падает
  3. 3. Добро пожаловать в уютный multicore ад
  4. 4. multicore там, где надо в памяти состыковывать онлайн клиентов
  5. 5. О чём поговорим • История одного тикета в нашем редмайне • Пришли два клиента, пожаловались на тормоза • Мы пошли разбираться
  6. 6. htop что-то показывает
  7. 7. Erlang использует акторы начнем их исследовать
  8. 8. Акторы вместо тредов • Актор — это микропроцесс в общем пространстве • Изоляция по данным • Коммуникация с помощью сообщений • Share nothing облегчает параллелизм • Ещё неплохо бы immutable
  9. 9. etop • в erlang вызов функции — редукция • каждый оборот цикла — редукция • etop меряет по редукциям
  10. 10. fprof, eprof • Очень грубые профилировщики линейного кода • меряют больше редукции, чем такты CPU • вносят сильные искажения в замеры
  11. 11. htop вам не друг • scheduler spin time — жжет такты впустую • надо смотреть на scheduler usage внутри beam • erlang:statistics(scheduler_wall_time)
  12. 12. Чего-то намеряли, но ничего непонятно
  13. 13. Акторы тупят • Всё весело запрограммировали, но всё легло • Пропускная способность ниже рассчетной • CPU мало используется • Как эти ваши акторы профилировать?!!
  14. 14. Бутылочные горлышки • Работы много, но всё поручили одному • Например это актор синглтон • Инспектируем очереди сообщений
  15. 15. Перегруженный актор • Берем список процессов • Забираем process_info(Pid, message_queue_len) • Сортируем • У первых 10 берем стектрейс
  16. 16. Перегруженный актор • Тысячи или миллионы сообщений в очереди • Надо шардить или рефакторить • Erlang пенализирует того, кто шлет такому сообщения (но об этом подробнее дальше) • То же самое будет в Go/Scala • Можно воспользоваться ets
  17. 17. Привет, блокировки • Треды лишь спрятаны акторами • Мьютексы никуда не делись • Просто теперь они спрятаны • Но erlang помогает их отследить!
  18. 18. Где мьютексы в erlang • главный мьютекс у каждой ets • 8-16 мьютексов на чтение и запись в ets • мьютекс у каждого процесса • и ещё около сотни
  19. 19. lcnt
  20. 20. lcnt • инструмент в erlang для сборки метрик по мьютексам • стоит некоторых ресурсов, но не смертельно • некоторые ньюансы пришлось патчить в эрланге • кроме мьютексов есть spinlock в ets
  21. 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. 22. Как можно всё испортить? • проверять process_info у другого процесса • очень много писать в ets • межтредное взаимодействие • бездумно частая аллокация
  23. 23. Перегружен синглтон
  24. 24. Механика поломок • отправитель делает process_info(flu_pulsedb, message_queue_len) • bif лочит очередь сообщений flu_pulsedb • коллизии на очереди сообщений (proc_msgq) • все шедулеры тормозят
  25. 25. Перегружена ets
  26. 26. Что делать с ets? • Шардить на разные ets. Больше таблиц, больше локов, реже коллизии • Пропускать всё через единый процесс на таблицу
  27. 27. О чём умолчим • эффект от atomic на N-процессорном сервере • false sharing • как это детектить в эрланге — непонятно
  28. 28. Локи убрали, CPU в полку, что дальше?
  29. 29. scheduler time • С помощью trace можно узнать время постановки и снятия с шедулера • очень жестокая штука • помогает получить иную картину мира
  30. 30. msacc • Очень дешевый быстрый анализ расходов CPU • аллокатор, C code, busy_wait, check_io, emulator, ets, gc, gc_full, nif, port, send, sleep, timers, other • надо перекомпиливать для расширенного варианта
  31. 31. msacc • Включается, собирает, выключается • Можно мерять за 2-10 секунд • Но имеет смысл ловить всплески за 100-200 мс
  32. 32. msacc
  33. 33. msacc • Оказалось, замучали аллокатор
  34. 34. Что делать с аллокатором? • В erlang очень, очень крутые аллокаторы • Мультитредные, многоступенчатые • Удобно и понятно настраивается • +MBas aoffcaobf +MBacul 0 -MBlmbcs 512 -MEas aobf -MElmbcs 512
  35. 35. instrument • Ещё один механизм изучения erlang VM • показывает, кто аллоцирует много данных • тяжело запускать на полном продакшне
  36. 36. instrument
  37. 37. instrument • Нашли, где делаем кучу лишней аллокации
  38. 38. erts_alloc_config • Подбирает настройки аллокатора • Но выключает мультитредный аллокатор (beam +Mea config) • Собирает историю и предлагает настройки
  39. 39. Наш опыт • Потратили 3 месяца на поиск загадочной проблемы, спонтанно возникшей где-то • Разгребли 9 фатальных локов с помощью lcnt, msacc • Починили аллокацию с помощью instrument, erts_alloc_config • Случайно нашли три строчки, портивших всё
  40. 40. Вопросы? Максим Лапшин, Flussonic max@erlyvideo.org

×