Я запускаю сервер Mumble (Murmur) на гостевом KVM Debian Wheezy Beta 4 (x86_64), который работает на гипервизоре KVM Debian Wheezy Beta 4 (x86_64). Гостевые машины подключаются к мостовому устройству в системе гипервизора через сетевые интерфейсы Virtio. Гипервизор подключен к восходящей линии связи 100 Мбит / с и выполняет IP-маршрутизацию между гостевыми машинами и оставшимся Интернетом.
В этой настройке мы наблюдаем четко распознаваемую задержку между двойным щелчком по каналу в клиенте и выполнением действия присоединения к каналу. Это происходит с множеством разных клиентов между 1.2.3 и 1.2.4 в системах Linux и Windows.
На качество передачи голоса и время задержки это не влияет. В большинстве случаев в информационном диалоговом окне клиента указывается задержка в 16 мс для голосового канала и канала управления. Отклонение для каналов управления в большинстве случаев намного выше, чем для одного из голосовых каналов. В некоторых ситуациях канал управления отображается с пингом 100 мс и отклонением около 1000. Кажется, здесь проблема с производительностью TCP.
У нас не было проблем с более ранней установкой, которая в принципе была очень похожа на новую. Вместо этого мы использовали гипервизор Xen на базе Debian Lenny и гостевую машину с программной виртуализацией, а также более раннюю версию серии Mumble 1.2.3.
Электрический ток murmurd --version говорит: 1.2.3-349-g315b5f5-2.1
Обновить: Я нашел это обсуждение где есть люди, использующие Mumble в виртуализированной системе, которые сталкиваются с той же проблемой, что и я.
Что я пробовал до сих пор (безуспешно):
Обновить: Ранее я заявлял, что тестировал размещение базы данных Mumble и файла журнала в tmpfs файловая система в памяти, и это не решило проблему. Я сделал там ошибку, поэтому на самом деле он не был сохранен внутри tmpfs. Теперь, когда я это сделал, проблем с производительностью больше нет. Но храня его в tmpfs На самом деле это не настоящее решение моей проблемы.
Я выяснил, что это связано с проблемой производительности ввода-вывода, поместив базу данных и файл журнала сервера Mumble в файловую систему в памяти. Причина большой задержки ввода-вывода была предметом этот вопрос. Проблема была решена добавлением nobarrier опция монтирования, которая была впервые добавлена после появления Linux 2.6.33 barrier как вариант по умолчанию. Обратите внимание, что это вызвать проблему безопасности. Кроме того, доступ к разделу был осуществлен через Virtio, а для кеширования установлено значение none или writeback. Производительность все еще была плохой, когда кеш был установлен на writethrough