LINUX.ORG.RU
Форум — Admin  

Непонятные проблемы с производительностью сети и/или железа и/или софта

 , , , ,


0

1

Здравствуйте. В домашних условиях стоит маленький, слабенький десктопный компьютер, выступающий в роли сервера.

На сервере Xen поверх Debian.
На сервере одна из виртуалок - медиасервер, который раздает по dlna и ftp. Используется для просмотра всякого рода сериалов. В последнее время очень часто скорость раздачи падает до такой степени, что даже пережатое non-hd видео нормально (без лагов) посмотреть не удается.
Помогите, пожалуйста, продиагностировать данную ситуацию. Никак не могу найти, в чем же проблема

Технические подробности:
кратко о хосте: 

AMD Athlon(tm) II X2 250 Processor
RAM 4GB

Dom0: 

# uname -a
Linux xxx 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u1 x86_64 GNU/Linux

# uptime
 ....  load average: 1.00, 1.01, 1.04


# free -m
             total       used       free     shared    buffers     cached
Mem:           907        270        637          0         35        100
-/+ buffers/cache:        135        772
Swap:        15255          0      15255

# xm list | wc -l
8

# lspci | grep Eth
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)
05:06.0 Ethernet controller: D-Link System Inc DGE-528T Gigabit Ethernet Adapter (rev 10)
05:07.0 Ethernet controller: D-Link System Inc DGE-528T Gigabit Ethernet Adapter (rev 10)

# brctl show
bridge name	bridge id		STP enabled	interfaces
br0		8000.94de80782b94	no		eth0
							vif1.0
							vif3.0
							vif4.0
							vif5.2
							vif6.0
br1		8000.9094e482af7d	no		eth1
							vif2.0
							vif5.0
br2		8000.78542e6f98f3	no		eth2
							vif5.1
Все виртуалки в режиме паравиртуализации.

Виртуалка MediaVM: 

# uname -a
Linux MediaVM 3.2.0-4-amd64 #1 SMP Debian 3.2.63-2+deb7u1 x86_64 GNU/Linux

# uptime
 .....  load average: 0.09, 0.05, 0.05

# free -m
             total       used       free     shared    buffers     cached
Mem:           494        485          8          0         15        375
-/+ buffers/cache:         95        398
Swap:            0          0          0

#Виртуалка относится к br0
# ifconfig
eth0      Link encap:Ethernet  HWaddr xxxxxxxxxxxxxxxxxxxxxxxx  
          inet addr:11111111  Bcast:11111111111  Mask:11111111111111111
          inet6 addr: fe80::216:3eff:fe1f:99e1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:65410848 errors:0 dropped:430388 overruns:0 frame:0
          TX packets:37711327 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:72745393673 (67.7 GiB)  TX bytes:27386264595 (25.5 GiB)
          Interrupt:27
#НАСТОРАЖИВАЕТ КОЛИЧЕСТВО ПАКЕТОВ dropped

Для ftp использую pure-ftpd, для dlna использую mediatomb
Виртуалки мониторятся zabbix'ом. Во время лагов всплеска по трафику, диску или cpu нету.

Во внутренню сеть перед сервером стоит маршрутизатор TP-Link TL-WR1043ND с dd-wrt на борту. 

root@DD-WRT:~# uptime
 ....  load average: 0.02, 0.05, 0.04

root@DD-WRT:~# free -m
             total         used         free       shared      buffers
Mem:         29616        20620         8996            0         2472
-/+ buffers:              18148        11468
С соседями была проведена работа, после чего наши каналы wi-fi не пересекаются.
В сети есть отдельно вынесенный dns для внутренних нужд. dchp так же вынесен на виртуалку.

У меня уже кончилась фантазия, куда можно еще посмотреть? Подскажите, пожалуйста, какие еще могут быть причины такого поведения?

★★★

Ответ на: комментарий от disee

Чем обоснован выбор полной виртуализации а не контейнерной?

dvrts ★★★
()

# uptime .... load average: 1.00, 1.01, 1.04

Кто накручивает LA посмотри (top/atop/vmstat 5/iostat -x 5)

errors:0 dropped:430388 overruns:0

Не уверен на 100% но я такое интерпретирую как: 1) Железо и сеть работает нормально (errors:0, carrier:0) но система не успевает обрабатывать входящий траффик (пакеты из сети прилетают быстрее чем система успевает их обрабатывать - очереди переполняются и пакеты начинают дропатся).

Я бы посмотрел следующее: 1) Откуда берется LA > 1, возможно в iptables какойто антихак скрипт/демон нагенерил очень много правил и CPU просто не вытаскивает разбор входного траффика. 2) Возможно на сервер идет флуд траффик откудато. 3) Какойто процесс с реалтайм приоритетом занял CPU и не отдает его под другие задачи (Soft IRQ, TCP/IP Stack). 4) Возможно комбинация из нескольких вышеперечисленных проблем (каждая в отдельности не критична, но все вместе они приводят к перегрузке очередей).

zaz ★★★★
()

RX packets:65410848 TX packets:37711327 RX bytes:72745393673 (67.7 GiB) TX bytes:27386264595 (25.5 GiB)

Выглядет странно как для медиа сервера (RX намного больше TX). Даже если предположить что сторедж с контентом сетевой - все равно должен преобладать исходящий траффик (ну или траффик должен быть примерно равен а так RX в два раза больше, torrent ???). Такчто смотрите кто/что грузит сервер и поднимает LA. Если я правельно понял то проблемы на уровне dom0, либо в какойто другой виртуалке (не в MediaVM).

eth0 vif1.0 vif3.0 vif4.0 vif5.2 vif6.0

Интересно посмотреть на статистику по eth0 dom0, и «вторую сторону» этих виртуальных интерфейсов ...

Может просто какаята виртуалка потребляет сильно много ресурсов и мешает MediaVM?

zaz ★★★★
()
Ответ на: комментарий от zaz 
# vmstat 5
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 0  0      0 574264  38356 167724    0    0    51   131  399  314  0  0 100  0

в top,atop, iostat ничего необычного.

По поводу парса сети: всего 3 интерфейса. 2 из них служат, что бы поставить одну из виртуалок в разрыв линии к интернету. На этой виртуалке живет snort со стопкой стандартных рулов. На этой виртуалке cpu idle примерно 99%.

Оставшийся интерфейс для всех остальных виртуалак для доступа к ним из локальной сети (в том числе и MediaVM). Вот так в dom0 выглядит iptables: 

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             PHYSDEV match --physdev-out vif6.0 --physdev-is-bridged
ACCEPT     all  --  anywhere             anywhere             PHYSDEV match --physdev-in vif6.0 --physdev-is-bridged
ACCEPT     all  --  anywhere             anywhere             PHYSDEV match --physdev-out vif5.2 --physdev-is-bridged
ACCEPT     all  --  anywhere             anywhere             PHYSDEV match --physdev-in vif5.2 --physdev-is-bridged
ACCEPT     all  --  anywhere             anywhere             PHYSDEV match --physdev-out vif5.1 --physdev-is-bridged
ACCEPT     all  --  anywhere             anywhere             PHYSDEV match --physdev-in vif5.1 --physdev-is-bridged
ACCEPT     all  --  anywhere             anywhere             PHYSDEV match --physdev-out vif5.0 --physdev-is-bridged
ACCEPT     all  --  anywhere             anywhere             PHYSDEV match --physdev-in vif5.0 --physdev-is-bridged
ACCEPT     all  --  anywhere             anywhere             PHYSDEV match --physdev-out vif4.0 --physdev-is-bridged
ACCEPT     all  --  anywhere             anywhere             PHYSDEV match --physdev-in vif4.0 --physdev-is-bridged
ACCEPT     all  --  anywhere             anywhere             PHYSDEV match --physdev-out vif3.0 --physdev-is-bridged
ACCEPT     all  --  anywhere             anywhere             PHYSDEV match --physdev-in vif3.0 --physdev-is-bridged
ACCEPT     all  --  anywhere             anywhere             PHYSDEV match --physdev-out vif2.0 --physdev-is-bridged
ACCEPT     all  --  anywhere             anywhere             PHYSDEV match --physdev-in vif2.0 --physdev-is-bridged
ACCEPT     all  --  anywhere             anywhere             PHYSDEV match --physdev-out vif1.0 --physdev-is-bridged
ACCEPT     all  --  anywhere             anywhere             PHYSDEV match --physdev-in vif1.0 --physdev-is-bridged

disee ★★★
() автор топика
Ответ на: комментарий от zaz

в dom0 

eth0      Link encap:Ethernet  HWaddr 11111111111 
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:552533 errors:0 dropped:0 overruns:0 frame:0
          TX packets:697371 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:90536579 (86.3 MiB)  TX bytes:391280562 (373.1 MiB)
          Interrupt:54 Base address:0xe000

eth1      Link encap:Ethernet  HWaddr 11111111111
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2994906 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2328850 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2987333410 (2.7 GiB)  TX bytes:1253995116 (1.1 GiB)
          Interrupt:20 Base address:0x4000 

eth2      Link encap:Ethernet  HWaddr 11111111111111111111  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2266364 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2712813 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1369195670 (1.2 GiB)  TX bytes:2733485796 (2.5 GiB)
          Interrupt:21 Base address:0x2000

По загрузке других виртуалок- больше всех загружена виртуалка с бд: 

# vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 0  0      0   7516  39288 214624    0    0     1   170    6    3  0  0 96  3
У всех остальных загрузка меньше

RX больше, потому что на днях бэкапил на эту виртуалку толстые файлы (40гб)

disee ★★★
() автор топика
Ответ на: комментарий от disee

RX больше, потому что на днях бэкапил на эту виртуалку толстые файлы (40гб)

Тогда скорее всего и dropped набежал в процессе бекапа. В полне может быть что проблема не в этом, я бы на вашем месте для начала все рестартанул (как пинимум чтоб статистика сбросилась), потом убрал из сети WiFi (перенес железки вкучу, или пробросил длинный пачкорд) - и есще раз все протестировал. Как говорит один мой знакомый - линия передачи данных это витая пара или оптика - все остальное это лини задержек и потери данных ;). Может в радимодуле WiFi чтото случилось, или у соседей микроволновка сломалась ...

zaz ★★★★
()
Ответ на: комментарий от disee

Я так понимаю что связь между MediaVM и телевизорос осуществляется по WiFi (TP-Link + бридж перед телевизором который заварачивает WiFi назад в Ethernet). Можно подключить через этот бридж скажем ноутбук и просто для теста скачать какойто медиа файл с MediaVM - и посмотреть на скорость (понятно что если часовой медиафайл будет качатся полтора часа то нормально посмотреть его не получится). Ну и если скорость будет низкой уже в процессе тестового скачаивания смотреть что происходит (смотреть загрузки на узлах/серверах - запускать паралельно пинги смотреть потерии и тд ...).

zaz ★★★★
()
Ответ на: комментарий от zaz

Сегодня все вместе перегружу и проверю будут ли дропы при просмотре видео; отпишу.

Кстати, не знаю на сколько это связано, но в такие критические моменты я очень медленно подключаюсь по ssh. Т.е. я жмякаю ssh user@host , и проходит секунд 30, до того момента, как меня спрашивают пароль

disee ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin