Напоследък домашният ми сървър и VM хост на случаен принцип започна да губи мрежова свързаност. Отвън изглежда, че още работи, но не можех да го достъпя по никакъв отдалечен начин. Ethernet адаптерът изглеждаше включен според суича, така че проблемът трябваше да е някъде в софтуера.
Нямаше да е първият път, в който драйвер причинява зависване на мрежовата връзка. В миналото съм се опарвал от бъгави WiFi драйвери както на Linux, така и на Windows компютри.
След като поразрових малко системните логове, се натъкнах на следното:
vmhost kernel: e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang:
vmhost kernel: TDH <0>
vmhost kernel: TDT <1>
vmhost kernel: next_to_use <1>
vmhost kernel: next_to_clean <0>
vmhost kernel: buffer_info[next_to_clean]:
vmhost kernel: time_stamp <10fbc2f81>
vmhost kernel: next_to_watch <0>
vmhost kernel: jiffies <10fbc3871>
vmhost kernel: next_to_watch.status <0>
vmhost kernel: MAC Status <40080083>
vmhost kernel: PHY Status <796d>
vmhost kernel: PHY 1000BASE-T Status <7800>
vmhost kernel: PHY Extended Status <3000>
vmhost kernel: PCI Status <10>
vmhost kernel: e1000e 0000:00:1f.6 eth0: Reset adapter unexpectedly
vmhost kernel: vmbr0: port 1(eth0) entered disabled state
След това ресетваше мрежовия адаптер и малко по-късно го правеше пак, докато машината накрая изобщо не излезе офлайн.
Търсейки отговори онлайн, попаднах на тази тема в ServerFault.
Причина
От различни източници и списъци с бъг репорти излиза, че най-лесният начин да се възпроизведе проблемът е ситуация с висока честотна лента на устройството, т.е. поточно пренасяне на големи количества данни, които насищат интерфейса.
При мен това обикновено се случваше, когато стриймвам медия от локалния Plex сървър към някое устройство. Заради начина, по който е изградена мрежата, Windows VM-ът, на който върви Plex, трябва да вземе медийния файл от NFS мрежов дял на отделно устройство, да го транскодира във VM-а и после да го изпрати към устройството за възпроизвеждане.
Това се натрупва до много мрежов трафик, обикновено ~40-100 mbit/s, в зависимост от устройството, което пуска файла, и от качеството на оригиналния файл.
Същият проблем се появи и при стриймване на игри през Steam Link към нашия Apple TV. Връзката е кабелна, но не е необичайно мрежата да прекъсне. Мисля, че е свързано със същия проблем, но ще държа под око дали ще се повтори в бъдеще след поправката.
Възможна поправка
Изглежда, че възможна поправка е да се изключат GSO (Generic Segmentation Offload), TSO (TCP Segmentation Offload) и GRO (Generic Receive Offload) на мрежовия интерфейс*:
ethtool -K eth0 gso off gro off tso off
Приложих това при себе си и чакам да видя дали наистина ще реши проблема в дългосрочен план.
Бележки под линия
* Тези опции са свързани с прехвърлянето на сегментирането на пакети към мрежовия контролер, за да се намали натоварването на процесора на машината. Повече подробности може да намерите в тази статия в Уикипедия.