На гостевых машинах VMWare дропаются пакеты

Вероятнее всего не хватает процессора, ядро тупо не успевает обработать весь поток пакетов и дропает их.

И насколько такая ситуация может влиять на сетевые сервисы, типа ssh, баз данных и пр?

Если устраивает производительность виртуалки, то с TCP протоколом быть проблем не должно.

посмотри подетальнее, чем-нить вроде
ip -s -s l l dev eth0 или что там у тебя

Вероятнее всего не хватает процессора, ядро тупо не успевает обработать весь поток пакетов и дропает их.

У меня 4 ядра задействовано. На реальной машине, откуда сервак переехал, всего 2 ядра. Думаеш, поможет?

Если устраивает производительность виртуалки, то с TCP протоколом быть проблем не должно.

Не устраивает, что со сбоями работают web-сервер и ssh. Грешу на ети показатели.

ip -s -s l l dev eth0 или что там у тебя

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:0c:29:08:29:35 brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast   
    304801056804 297021773 0       203147  0       0      
    RX errors: length  crc     frame   fifo    missed
               0        0       0       0       0      
    TX: bytes  packets  errors  dropped carrier collsns 
    369674162154 347177129 0       0       0       0      
    TX errors: aborted fifo    window  heartbeat
               0        0       0       0

Смотрите, насколько эти показатели активно растут. Так, хорошо бы оценить сетевую нагрузку в пиках в pps (пакеты в секунду). Тогда может кто и скажет, достаточно ли производительность железа для данной pps.

Вобще, 203147/297021773 это 0.068 % — очень мало, чтобы портить работу ssh. В чём именно проявляются сбои в работе ssh.

Проверил на отдельной тестовой виртуальной машине. Задействовал всего одно ядро и 1Гб оперативки, только сетевую выбрал VMXNET3. Дропов не обнаружил за целый день. Решил, что панацея. Однако, поменяв сетевые карты на рабочих виртуалках, ситуация изменилась в положительную сторону совсем немного. Счас процент дропнутых пакетов около 0,04.

ssh у меня бывало глючил, что я не мог подключится к машине. Приходилось перезапускать sshd, чтобы он заработал. На другой виртуалке периодически отваливался apache. После тонкой настройки стал отваливатся реже, но всё же. Как казалось, виной всему именно плохая работа сетевой.

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

1) что за ПО используется для виртуализации? vmware бывает разная :)

2) Какая гостевая ОС так себя ведёт? vmware tools установлены или используются родные драйверы из современного ядра linux?

3) Увеличение числа vCPU само по себе не панацея, при увеличении числа виртуальных процессоров растут накладные расходы на их синхронизацию. Лучше увеличь доступные ВМ процессорные ресурсы ( cpu reservation, cpu limit, cpu shared )

1) VMWare ESXi 5.0.0 build 623860

2) Ubuntu Server 12.04. vmware tools установлены, но дропающиеся пакеты замечены щё до установки

3) Ок, спасибо за идею. Пока тестю с новыми сетевыми - только сегодня перенастроил. Если лаги будут дальше, попробую ети настройки

Процент дропающихся пакетов вроде на том же уровне:

# ip -s -s l l dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UNKNOWN qlen 1000
    link/ether 00:0c:29:08:29:35 brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast   
    94477924   1308363  0       1267    0       161    
    RX errors: length  crc     frame   fifo    missed
               0        0       0       0       0      
    TX: bytes  packets  errors  dropped carrier collsns 
    10078729017 1174360  0       0       0       0      
    TX errors: aborted fifo    window  heartbeat
               0        0       0       0 

С sshd можно отдельно поразбиратся. Такой небольшой процент дропов не должен приводить к невозможности установления ssh-сесии. Причём перезапуск sshd не должен влиять на drop пакетов, значит проблема в sshd.

Можно посмотреть логи, список процессов sshd (может их там слишком много), можно смотреть трассировку системных вызовов sshd (strace), когда sshd не отвечает, будет видно, принимает ли он соединение.

Не, с ssh - ето мелочи. Он просто под руку попался с несколькими случаями «отвала» Меня больше смущало, что firebird работает не стабильно. По факту, я всё же сужу, что проблема тут в провайдере и в неоптимизированной базе. По сабжу могу только добавить, что недавно я переустановил систему на одном из физических серверов, так там процент дропов до 2-х доходит. При том, что на нём стоит голая система и при помощи rsync забираются данные с других компов. На виртуальных и етом физическом стоят гигабитные сетевые. Вероятно, дело в них. Я даже как-то поиском находил, по-моему, Ваше сообщение про то, что E1000 не особо стабильно работает с линуксами. Сервисы, как бы, работают, хотя цифра не может не смущать.

Возможно, что ssh это мелочь, но он очень хорошо протестирован и должен работать стабильно, поэтому, изучая его проблему возможно получится определить источник проблем в виртуалки.

С firebird'ом тоже нужно определятся отдельно. Одиночные потери пакетов не проблема для tcp, crc-ошибок у вас нет, значит пакеты не искажаются. И нужно смотреть, либо у вас клинет, работающий с firebird'ом, просто не даёт ему «подумать», либо firebird падает из-за косяков виртуалки.

Я не помню, чтобы я жаловался на e1000, может и было что, но мне они всегда нравились. Но я ещё раз повторю, что вам нужно определять нагрузку на сеть, прежде всего pps (кол-во пакетов в секунду). Хотя бы напишите скрипт, который раз в секунду пишет в файл вывод команды «ip -s -o link show dev eth0». Файл потом можно обработать и оценить пики pps. Далее уже можно как-то сопоставить железо и pps и понять, должно ли это железо дропать пакеты или нет (при данном уровне pps).

К виртуалкам нагрженными большими объёмами трафика у меня враждебное настроение. Если по конфигурации сервера с голой системой хоть как-то можно добится из людей ожидаемого нормального уровня pps (хотя с массой оговорок), то с виртуалками никто совсем никакой pps обещать не хочет.

Сегодня експериментировал с MTU, установил на одном из серваков значение 1300. Пакеты дропатся перестали...