Макс Лапшин (levgem) wrote,
Макс Лапшин
levgem

Categories:

Будни техподдержки

Обратился за помощью клиент, который у нас не просто подписан на пачку лицензий, а ещё и на платной техподдержке.

У них странная проблема: после запуска флюссоника моментально съедаются все ядра и потребление памяти растет с такой скоростью, что 30 гигабайт примерно за 100-120 секунд заканчиваются и флюссоник падает. Точнее сначала был включен своп, а с ним очень весело: пока он включен, программа не может умереть, потому что всё постоянно свопится.

Запускаю флюссоник в foreground, память жрется быстро, но в ets таблицах утечек нет, там всё по минимуму. Выключаю все каналы, запускаю заново, всё работает. По одному запускаю каналы и нахожу тот, после включения которого всё падает.



Поиск проблемы



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

Потом я догадался (блин) посмотреть в access.log. Там полно запросов к плейлисту архива длиной почти в сутки. К флюссонику можно обратиться по специально сформированному урлу (по протоколу HLS) и получить список mpegts сегментов из которых состоит архив. Выясняется, что один единственный клиент дергает этот урл во много потоков и укладывает таким образом сервер, потому что сегментов в этом плейлисте порядка 10 тыс, а сам плейлист где-то под 700 кб размером (нежатый).

Позорище, конечно, полное. Целевое время для отдачи данных из памяти у нас — единицы, максимум десятки миллисекунд. Т.е. всё что больше 100 мс — повод для грусти, а тут до 6000 мс!

Сначала я решил, что долго вытаскивается список сегментов из архива, но это не так. У нас там всё очень хорошо сделано и оптимизировано, так что список сегментов тянется за 10 мс даже под полной нагрузкой (все 8 ядер на 95%). Значит, тормозит кусок кода, который из 10 тыс сегментов делает текстовый плейлист размером в 700 кб.

Воспроизвел ситуацию у себя на ноутбуке, всё повторилось. Считанные миллисекунды даже на чтение с SSD и долгие сотни миллисекунд на работу с текстом. Профилировка (fprof) сразу ткнула в предателей: io_lib:format и модуль calendar.


Оптимизация



Итак, мы выяснили, что для получения структуры архива за сутки (более 10 гигабайт данных на диске), флюссоник тратит 10-15 мс на вытаскивание данных из собственной базы и 600 мс (на холодном ноутбуке) на превращение в текстовый плейлист и по профилировке, виноват io_lib:format и calendar, превращающий UTC в year, month, day, hour, minute, second. А тормозило всё в одном месте, где таймстемп сегмента превращался в iso8601 время этого сегмента:

Timestamp = {UTC div 1000000, UTC rem 1000000, 0},
{{Y,M,D},{H,_Min,_Sec}} = calendar:now_to_datetime(Timestamp),
iolist_to_binary(io_lib:format("~4.10.0B-~2.10.0B-~2.10.0BT~2.10.0B:~2.10.0B:~2.10.0BZ", [Y, Mo, D, H, Mn, S]))


Первая реакция была взять наш со stolen io_libc: https://github.com/maxlapshin/io_libc
Воткнул, всё стало очень хорошо, вместо 600 стало 250.

Воткнул gmtime в NIF, стало всё ещё лучше, почти 150 мс: https://github.com/maxlapshin/io_libc/commit/42a7387e4b44552d86b733b9d18256f49091df39

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


iso8601({{Y,Mo,D}, {H,Mn,S}}) ->
  <<(integer_to_binary(Y))/binary, $-,
    ($0 + (Mo div 10)), ($0 + (Mo rem 10)), $-,
    ($0 + (D div 10)), ($0 + (D rem 10)), $T,
    ($0 + (H div 10)), ($0 + (H rem 10)), $:,
    ($0 + (Mn div 10)), ($0 + (Mn rem 10)), $:,
    ($0 + (S div 10)), ($0 + (S rem 10)), $Z>>.



Этот уродливый костыль оказался самым быстрым, хотя и не таким гибким как io_libc. В итоге на бенчмарках время упало с 600 до 100 мс, потребление памяти в разы.

Сделали, собрали, выкатили клиенту. CPU в норме (150% из 800%), память держится стабильно. А взбесившаяся приставка ограничилась 15 запросами в секунду по 700 килобайт, что примерно в районе 100 мегабит.
Tags: erlang, erlyvideo, flussonic
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 9 comments