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