хм. реалтаймовые задачи на виртуалке...

но 400мс - это дофига.

А что за драйвер сетевухи в этой старой системе? Менять пробовал ? Версия ядра древнего линуха какая?

Связка tap<->virtio обычно не является узким горлышком. На старых qemu tap мог быть тормозом, но macvtap проблему решал.

iperf3 между хостом и гостем что говорит ? (в обе стороны)

IMHO старый софт на адекватном ядре будет работать, а на адекватном ядре будет работать virtio.

Если там не libc.so.5, а какая-нибудь glibc-2.x, то проблем с ядром не должно быть IMHO.

прокидывать сетевую карточку через IOMMU/vt-d - крайний случай.

Да задача не реалтаймовая в общем то. Видеонаблюдение. Драйвера virtio. E1000 - так же себя ведёт. OS гостя: CentOS 5.

qemu - не старый, Proxmox 4.

macvtap - на сколько я понял, тот же tap

Гляди какой overload tap девайса на хосте: https://www.dropbox.com/s/wwltmduwfrcdm4q/1.png?dl=0

iperf/iperf3 между хостом и гостем что говорит ? (в обе стороны)

Если результат ниже гигабита, значит есть проблема.

Почему-то в некоторых конфигурациях с tap проявляются проблемы с производительностью (и по ifconfig есть существенное число дропов)

... 240% ... 24 Mbps ...

Видишь связь? Link speed на tap-интерфейсах установлен в 10 mbit/s, но по факту никакой роли не играет. Твоя мониторилка просто посчитала, что 10 мегабит - это максимум, а значит 24 мегабита - это 240% от максимума. В общем ничего странного тут нет.

Не смотря на то, что load average - низкий внутри машины

А снаружи? Работает ли что-либо кроме вот этой одной виртуалки?

до видеоисточников ping не стабильный и «гуляет» от 1ms до 400ms

А снаружи?

Менял какие-нибудь настройки системы? В RHEL и производных, например, есть tuned/tuned-adm, который позволяет выбрирать профили, которые меняют какие-то низкоуровневые настройки. Подозреваю, что эффект не так хорош, как от подкручивания всего руками, но лучше чем ничего. Лично наблюдал стабильное уменьшение пинга под нагрузкой на 10gbe интерфейсах при смене профиля с ⁠throughput-performance на latency-performance.

Господин хороший, а зачем вам пробрасывать сетевуху в гостя? Что за, прости Господи, херня? Я бы понял, если бы у вас 10GbE был, скажем. А на 24-х мегабитах чем вас Linux bridge не устраивает?

И, да, CentOS 5 - не «древний Linux». Он ещё поддерживается, если что. Просто немного староват)

Openvswitch ?

И, да, CentOS 5 - не «древний Linux». Он ещё поддерживается, если что.

Уже нет. Полная поддержка закончилась в 2014м, секьюрити апдейты - в марте этого года. Расширенная поддержка - до 2020го, но это индивидуально и за дополнительные деньги.

я бы еще попытался поиграться с настройками сетевухи хоста - TSO/LSO/LRO отключить например, если там бродком то разница может оказаться заметная

Настроек системы не менял (ни на хост системе ни на вирт. машине). Собственно и пришёл спросить, что можно покрутить. :)

Вот гляди какие ping идут:

Внутри вирт. машины:

PING 192.168.5.3 (192.168.5.3) 56(84) bytes of data.
64 bytes from 192.168.5.3: icmp_seq=1 ttl=128 time=0.299 ms
64 bytes from 192.168.5.3: icmp_seq=2 ttl=128 time=0.944 ms
64 bytes from 192.168.5.3: icmp_seq=3 ttl=128 time=0.266 ms
64 bytes from 192.168.5.3: icmp_seq=4 ttl=128 time=84.8 ms
64 bytes from 192.168.5.3: icmp_seq=5 ttl=128 time=96.6 ms
64 bytes from 192.168.5.3: icmp_seq=6 ttl=128 time=0.462 ms
64 bytes from 192.168.5.3: icmp_seq=7 ttl=128 time=0.289 ms
64 bytes from 192.168.5.3: icmp_seq=8 ttl=128 time=0.433 ms
64 bytes from 192.168.5.3: icmp_seq=9 ttl=128 time=0.234 ms
64 bytes from 192.168.5.3: icmp_seq=10 ttl=128 time=91.8 ms

С хост узла:

PING 192.168.5.3 (192.168.5.3) 56(84) bytes of data.
64 bytes from 192.168.5.3: icmp_seq=1 ttl=127 time=0.328 ms
64 bytes from 192.168.5.3: icmp_seq=2 ttl=127 time=0.351 ms
64 bytes from 192.168.5.3: icmp_seq=3 ttl=127 time=0.421 ms
64 bytes from 192.168.5.3: icmp_seq=4 ttl=127 time=0.385 ms
64 bytes from 192.168.5.3: icmp_seq=5 ttl=127 time=0.363 ms
64 bytes from 192.168.5.3: icmp_seq=6 ttl=127 time=0.368 ms
64 bytes from 192.168.5.3: icmp_seq=7 ttl=127 time=0.397 ms
64 bytes from 192.168.5.3: icmp_seq=8 ttl=127 time=0.301 ms
64 bytes from 192.168.5.3: icmp_seq=9 ttl=127 time=0.317 ms
64 bytes from 192.168.5.3: icmp_seq=10 ttl=127 time=0.398 ms
64 bytes from 192.168.5.3: icmp_seq=11 ttl=127 time=0.379 ms
64 bytes from 192.168.5.3: icmp_seq=12 ttl=127 time=0.266 ms
64 bytes from 192.168.5.3: icmp_seq=13 ttl=127 time=0.354 ms
64 bytes from 192.168.5.3: icmp_seq=14 ttl=127 time=0.352 ms
64 bytes from 192.168.5.3: icmp_seq=15 ttl=127 time=0.397 ms
64 bytes from 192.168.5.3: icmp_seq=16 ttl=127 time=0.391 ms
64 bytes from 192.168.5.3: icmp_seq=17 ttl=127 time=0.394 ms
64 bytes from 192.168.5.3: icmp_seq=18 ttl=127 time=0.351 ms
64 bytes from 192.168.5.3: icmp_seq=19 ttl=127 time=0.306 ms

Видишь какая заметная разница? На хосте только одна эта виртуалка.

Спасибо, связь между: 240% и 24mb/sec - развидел. Интересно. Но проблема похоже все же есть.

Господа, вот la

Внутри гостя:

load average: 3.14, 3.03, 3.37

На хосте:

load average: 18.53, 18.29, 18.54

iperf3 между хостом и гостем что говорит ?

В обе стороны не выходит, так-как ОСь анальная и firewall не получается сбросить.

Но, в одну из сторон говорит порядка: 500 мегабит. - делал прямо на внешний узел, а не на хост машину, т.к. там другая подсеть.

load average: 18.53, 18.29, 18.54

хм. а ядер сколько ?

Может именно в этом проблемы с большим откликом ?

Да CPU на хосте свободен...

%Cpu0  : 19.4 us,  3.7 sy,  0.0 ni, 75.2 id,  0.7 wa,  0.0 hi,  1.0 si,  0.0 st
%Cpu1  :  6.9 us,  4.5 sy,  0.0 ni, 87.2 id,  1.0 wa,  0.0 hi,  0.3 si,  0.0 st
%Cpu2  : 20.1 us,  4.4 sy,  0.0 ni, 75.1 id,  0.3 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  : 11.5 us,  4.7 sy,  0.0 ni, 83.4 id,  0.3 wa,  0.0 hi,  0.0 si,  0.0 st

Это значит, что кто-то хочет процессор, но не использует его, а это обычно проблема ядра.

Я понимаю... И пока я понимаю, что этот кто-то не использует процессор, т.к., ожидает пока «прокакается» сеть. Нет?

дык «perf record — sleep 30» - покажет где ядро зимует :)

отваливается PCI-e SATA контроллер.

смени marvell 91xx на 92xx или любой другой sata контроллер. и ничего не будет отваливаться.

SATA controller: Marvell Technology Group Ltd. 88SE9230

Сейчас такой установлен. Пока так же рассматриваю вариант установки Adaptec какого-нибудь. Но хотелось бы понять, что морозится.

Но хотелось бы понять, что морозится.

у них в чипе бага, у меня подобное было при включении iommu на оптероне с платой на их чипе.

https://bugzilla.redhat.com/show_bug.cgi?id=907280

О как..! Круто! Спасибина тебе большая! В общем, есть надежда что в новых версиях ядра, это когда-нибудь исправят. Правда это касается RHEL

Не сочти за труд, подскажи как корректней посмотреть где конкретно морозится? https://www.dropbox.com/s/svqw76xyd6d94zv/out.png?dl=0

Я не вижу в нем явной проблемы. А сколько VM работает одновременно ?

OS гостя: CentOS 5.

зачем нужен kvm? достаточно chroot или lxc

+1 если разрядность систем совпадает.

x86_64 хост прекрасно запускает 32-разрядные процессы, в том числе и в контейнере.

Но это нужно тащить туда multilib!

Нафиг этот зоопарк :)

Куда туда? Если ты в контейнере хочешь запустить rootfs от 32-разрядного дистра, на этом rootfs-е уже есть все необходимые 32-разрядные библиотеки.

Но это нужно тащить туда multilib!

Эээ… Разве? У меня в LXC работает 32-битный дистрибутив на 64-битном хосте без multiarch.

хм. действительно.

лет 7-8 назад были какие-то проблемы. Но тогда LXC еще был не готов.

Тогда у lxc сейчас еще больше преимущество перед запуском centos в qemu/kvm!

зачем нужен kvm? достаточно chroot или lxc

Софт анальный. Поставляется только в виде готового дистрибутива.

Решено

vel iliyap mironov_ivan nbw dyasny ktk hizel

Мужики, в общем проблема похоже решена. Дело было... В дисках. Я в шоке. У меня raid10 по 6-8 дисков на сервер (у меня несколько серверов подобых, везде были проблемы с la). И оно тупило... В общем, поставил unsafe в свойствах виртуальных дисков (lvm), и все зашуршало как нужно! Мать его..! load average стал адекватен. Учитывая, что конкретно в моём случае unsafe годится - можно закрывать тему. Но вообще я опечален тем фактом, что 20-30 паралельных потоков записи приводили к такому высокому la, что аж ping лагал. raid-10 тестил. Нареканий в хост машине он не вызывает. В общем остаюсь в unsafe.

Спасибо всем огромное. Для себя из треда кое-чего годного подчерпнул.

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

Диски SATA, но серверные. CPU серверный. ОЗУ - серверная. Не серверный только дисковый контроллер.