Причины джиттера RTP на сервере
Изучая некоторые проблемы с качеством звонков (мертвые зоны 0,5–1 секунды при звонках), я сделал захват пакета телефонного звонка между двумя добавочными линиями на одной АТС. Поскольку я осуществлял захват с АТС, я был весьма удивлен, увидев, что Wireshark сообщает об огромном скачке джиттера, который синхронизировался с мертвой точкой в вызове:
Насколько я понимаю, джиттер вызван потерей пакетов и / или задержкой при передаче, и что поток RTP, покидающий УАТС, должен быть относительно нетронутым. Но этот всплеск проявился во всех четырех потоках RTP (из офиса 1 в PBX, из офиса 2 в PBX, из PBX в офис 1, из PBX в офис 2), поэтому кажется, что пакеты уже находятся в плохом состоянии к тому моменту, когда они покидают сервер.
УАТС - Asterisk 13 в Scientific Linux (RHEL) 6.9 (работает на гостевой системе VMWare ESXi 5.5 с недавно обновленными инструментами и адаптерами VMXNET3). ЦП довольно стабильно использует около 5-15%, а сетевой трафик минимален. Где я могу найти решение этой проблемы? Есть ли общие причины такого рода проблем? Я предполагаю, что, поскольку проблемы есть на сервере, я могу исключить проблемы на стороне внешней сети?
Наконец разобрался в этом! TL; DR: отключите управление питанием на хосте.
Несмотря на низкую загрузку процессора, мы все же полагали, что это как-то связано с загрузкой процессора. Итак, мы экспериментировали с загрузкой ЦП, ожидая, что проблема с мертвыми зонами в вызовах усугубится. Вместо этого он полностью исчез. Итак, много раз просматривая статистику использования ЦП в vCenter, я наконец заглянул в Другой линия на этом графике.
Возможно, это не новость для многих, но я узнал, что Время готовности процессора - это время, в течение которого виртуальная машина готова к использованию ЦП, но физические ресурсы не могут быть выделены хостом. Большинство источников, которые я нашел, говорят, что значение ниже 5% не является проблемой, но, похоже, это определенно влияет на наши голосовые потоки. Мы видели вырезы каждую минуту, и график также каждую минуту показывал всплеск времени готовности.
Поэтому мне стало интересно, почему это исчезает при высокой загрузке процессора, и я решил, что это должно быть какое-то управление питанием. Когда хост видит увеличенное использование, он делает ресурсы ЦП постоянно доступными для виртуальной машины. Поэтому я отключил управление питанием в BIOS хоста, и вуаля:
Небольшое увеличение времени готовности ближе к концу графика соответствует полдюжине других виртуальных машин, мигрирующих обратно на этот хост.
Трассы вызовов теперь показывают незначительное дрожание, а вырезки исчезли из вызовов. Дальнейшие исследования показали, что это довольно распространенная проблема с рабочими нагрузками, которые чувствительны к задержкам и не требуют интенсивного использования ЦП. Система управления питанием видит очень низкую загрузку ЦП и предполагает, что она может задушить процессор, хотя этого не должно быть!
У меня была аналогичная проблема, но намного хуже, с множеством всплесков на графике RTP Wireshark, шипением и прерывистым звуком.
В ходе многих экспериментов я сбросил База данных CDR, который вырос до 1,5 ГБ. Я заметил размер, но откладывал обрезку, пока не исправил проблемы со звуком. B-)
Это, по-видимому, сразу улучшило качество звука, включая перекодировку сообщений IVR в G729.
Задержки также были видны из SmokePing трассировка к VPS.