Привет всем! "Давным-давно" мы пытались мигрировать наш небольшой офисный АТС (Asterisk 11 + CentOS6) на Proxmox (контейнер LXC) и наткнулись на проблему с голосом: звуковые вызовы зависают (односторонний звук). У нас до 7 одновременных SIP-вызовов (максимум 1 Мбит/с голосового трафика). На узле работает только один контейнер, нагрузка почти 1. Мы пытались создать тестовый кластер для плавной миграции контейнера и быстрой смены аппаратного обеспечения (3 различных сервера: от "Высокого": 2xX5650, 128ГБ ОЗУ до "Низкого": 2xX5250, 16ГБ ОЗУ), на одном узле одновременно работает только один контейнер, и проблема сохраняется везде. Мы пытались зафиксировать трафик в 4 местах и одновременно пинговать каждое место с интервалом 100 мс: хост, контейнер, коммутатор (SPAN), ISP и обнаружили, что контейнер зависает на 1-1,5 секунды. Затем возникает проблема: tcpdump на хосте показал ICMP ping-ответы от контейнера (!) на ПК и односторонний RTP-трафик (от ISP к контейнеру, но не в обратном направлении). Tcpdump на контейнере ничего не показывает (но ping-ответы существуют на bridge|wire!), 0 (ноль) пакетов было захвачено за промежуток в 1-1,5 секунды — как будто контейнер завис (повесился), но пакеты существуют в захвате после и до этого "одностороннего зависания голоса". В целом, выглядит так, как будто контейнер зависает на 1-1,5 секунды. Сначала мы думали, что это проблема с сетевым мостом или veeth, но контейнер отвечает на ping и не показывает этого на tcpdump (ничего не показывало, когда проблема присутствовала). В dmesg, syslog и т.д. — нет подозрительных сообщений (таких как зависание, таймаут и т.д.) — все в порядке. Например, с "Низкого" сервера: Код: top - 11:41:09, uptime 15 дней, 3:12, 2 пользователя, нагрузка: 0,61, 0,63, 0,52
Задачи: всего 327, 1 выполняется, 266 спят, 0 остановленных, 0 зомби
%Cpu(s): 0,9 us, 1,8 sy, 0,0 ni, 96,1 id, 1,2 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: 12296532 всего, 4123032 свободно, 5691732 использовано, 2481768 буфер/кэш
KiB Swap: 8388604 всего, 8369916 свободно, 18688 использовано. 6074492 доступная память Код: pveversion -v

proxmox-ve: 5.2-2 (работающий ядро: 4.15.18-7-pve)
pve-manager: 5.2-10 (работающая версия: 5.2-10/6f892b40)
pve-kernel-4.15: 5.2-10
pve-kernel-4.15.18-7-pve: 4.15.18-27
pve-kernel-4.15.17-1-pve: 4.15.17-9
corosync: 2.4.2-pve5
criu: 2.11.1-1~bpo90
glusterfs-client: 3.8.8-1
ksm-control-daemon: 1.2-2
libjs-extjs: 6.0.1-2
libpve-access-control: 5.0-8
libpve-apiclient-perl: 2.0-5
libpve-common-perl: 5.0-40
libpve-guest-common-perl: 2.0-18
libpve-http-server-perl: 2.0-11
libpve-storage-perl: 5.0-30
libqb0: 1.0.1-1
lvm2: 2.02.168-pve6
lxc-pve: 3.0.2+pve1-3
lxcfs: 3.0.2-2
novnc-pve: 1.0.0-2
proxmox-widget-toolkit: 1.0-20
pve-cluster: 5.0-30
pve-container: 2.0-29
pve-docs: 5.2-8
pve-firewall: 3.0-14
pve-firmware: 2.0-5
pve-ha-manager: 2.0-5
pve-i18n: 1.0-6
pve-libspice-server1: 0.14.1-1
pve-qemu-kvm: 2.12.1-1
pve-xtermjs: 1.0-5
pve-zsync: 1.7-1
qemu-server: 5.0-38
smartmontools: 6.5+svn4324-1
spiceterm: 3.0-5
vncterm: 1.5-3
zfsutils-linux: 0.7.11-pve1~bpo1 Обновления ядра, lxc и т.д., настройка, чтение и изменения оборудования в течение года не решают проблему, и мы просим сообщество помочь нам, пожалуйста — как найти корень проблемы (veeth, lxc, zfs...)?