[ djoka_l @ 08.06.2017. 09:01 ] @
Pre neki dan, dok sam arhivirao sar izveštaje iz maja, slučajno bacim pogled i vidim na mi na jednom serveru oko 12% rx paketa na eth0 završava u dropped:
eth0      Link encap:Ethernet  HWaddr 00:21:F6:50:0D:2B

          inet addr:xx.xx.xx.xx  Bcast:xx.xx.xx.255  Mask:255.255.255.0

          inet6 addr: fe80::221:f6ff:fe50:d2b/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:13888810655 errors:0 dropped:373754575 overruns:0 frame:0

          TX packets:7257203208 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:4368569679843 (3.9 TiB)  TX bytes:4666896888876 (4.2 TiB)




# sar -n EDEV 5

Linux 3.8.13-118.4.2.el6uek.x86_64 (xxxxxxx)  06/08/2017      _x86_64_        (2 CPU)



09:50:26 AM     IFACE   rxerr/s   txerr/s    coll/s  rxdrop/s  txdrop/s  txcarr/s  rxfram/s  rxfifo/s  txfifo/s

09:50:31 AM      eth0      0.00      0.00      0.00     12.63      0.00      0.00      0.00      0.00      0.00

09:50:31 AM        lo      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00



09:50:31 AM     IFACE   rxerr/s   txerr/s    coll/s  rxdrop/s  txdrop/s  txcarr/s  rxfram/s  rxfifo/s  txfifo/s

09:50:36 AM      eth0      0.00      0.00      0.00     11.54      0.00      0.00      0.00      0.00      0.00

09:50:36 AM        lo      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00


Malo matematike, ispada da mi je ta situacija na virtualki traje već tri meseca, ali nisam primetio neki pad performansi. Ono što mi tcpdump daje liči na pakete koje šalje hypervisor (ako dobro tumačim tcpdump):
09:28:36.245976 00:50:56:89:7b:29 (oui Unknown) > 03:bf:0a:73:3a:46 (oui Unknown), ethertype Unknown (0x886f), length 1510:

        0x0000:  bf01 dec0 0602 0000 0100 0000 0a73 3a46  .............s:F

        0x0010:  0a73 3a47 0000 0000 0100 0200 1510 f456  .s:G...........V

        0x0020:  778d 0000 0000 0000 0000 0000 00f0 ff6f  w..............o


wireshark sam instalirao, ali ne znam kako da protumačim njegov izlaz.

evo šta daje dropwatch:
# dropwatch -l kas

Initalizing kallsyms db

dropwatch> start

Enabling monitoring...

Kernel monitoring activated.

Issue Ctrl-C to stop monitoring

155 drops at dev_ingress_queue_create+70 (0xffffffff814d2e30)

11 drops at dev_ioctl+572 (0xffffffff814d5f02)

10 drops at __mkroute_input+3b0 (0xffffffff815069f0)

2 drops at skb_copy_datagram_const_iovec+296 (0xffffffff814ca766)

4 drops at tcp_rcv_state_process+112 (0xffffffff81525e62)

5 drops at tcp_v4_inbound_md5_hash+264 (0xffffffff8152f634)

2 drops at tcp_v4_gso_send_check+106 (0xffffffff81530836)

6 drops at tcp_rcv_state_process+112 (0xffffffff81525e62)

500 drops at dev_ingress_queue_create+70 (0xffffffff814d2e30)

10 drops at dev_ioctl+572 (0xffffffff814d5f02)

4 drops at tcp_v4_inbound_md5_hash+264 (0xffffffff8152f634)

2 drops at skb_copy_datagram_const_iovec+296 (0xffffffff814ca766)

17 drops at __mkroute_input+3b0 (0xffffffff815069f0)

2 drops at tcp_v4_gso_send_check+106 (0xffffffff81530836)

395 drops at dev_ingress_queue_create+70 (0xffffffff814d2e30)

12 drops at dev_ioctl+572 (0xffffffff814d5f02)

12 drops at __mkroute_input+3b0 (0xffffffff815069f0)

8 drops at tcp_rcv_state_process+112 (0xffffffff81525e62)

6 drops at tcp_v4_inbound_md5_hash+264 (0xffffffff8152f634)

2 drops at unix_stream_connect+1e0 (0xffffffff81573b80)

3 drops at skb_copy_datagram_const_iovec+296 (0xffffffff814ca766)

1 drops at tcp_v4_gso_send_check+106 (0xffffffff81530836)

1 drops at skb_copy_datagram_const_iovec+296 (0xffffffff814ca766)

1 drops at tcp_rcv_state_process+112 (0xffffffff81525e62)

2 drops at unix_stream_connect+1e0 (0xffffffff81573b80)

568 drops at dev_ingress_queue_create+70 (0xffffffff814d2e30)

14 drops at dev_ioctl+572 (0xffffffff814d5f02)

10 drops at __mkroute_input+3b0 (0xffffffff815069f0)

3 drops at tcp_rcv_state_process+112 (0xffffffff81525e62)

2 drops at tcp_v4_inbound_md5_hash+264 (0xffffffff8152f634)

2 drops at tcp_v4_gso_send_check+106 (0xffffffff81530836)

1 drops at .brk.early_pgt_alloc+1e0f1687 (0xffffffffa018b687)

^CGot a stop message

dropwatch> exit

Shutting down ...


Probao sam sa menjanjem kernel parametara, ali setovanja su već bila dobra, neke sam parametre povećao, ali ništa ne menja broj paketa koji idu u drop. Proverio sam i ostale virtualke na istom fizičkom hardveru i one se pristojno ponašaju (rxdrop postoji, ali je manji od 1%).

Pomagajte, šta da radim, gde da tražim ko mi bombarduje server paketima...


[ djoka_l @ 08.06.2017. 09:02 ] @
samo sam izmenio u naslovu da ne stoji rxdrop/2 nego rxdrop/s...
[ Miroslav Strugarevic @ 08.06.2017. 14:26 ] @
Jesu li te druge virtualke OK u smislu iskoriscenja resoursa? Da li vidis bilo kakav CPU, Memory ili Disk exhaustion? Da li si uporedio kernel podesavanja (sysctl -a) sa working i non-working virtualki? Da li si uporedio kernel verzije, ethX drajver verzije sa working i non-working virtualki?

p.s. Vrlo lepa analiza problema i odlican alat (dropwatch) ;-) Nisam nista manje ocekivao od gospodina L ;-)
[ djoka_l @ 08.06.2017. 15:01 ] @
Trenutno u klasteru imam 6 virtualki koje su identično setovane. Po jednu primarnu Oracle bazu i primarni aplikacioni server. Dve testne virtualke sa bazom i dva testna aplikaciona servera. Svih 6 mašina je konfigurisano pre 380 dana i nisu obarane od tada. Dakle, situacija identična, kernel parametre je podesila Oracle instalacija. (Oracle Linux 6)

Problem mi je na primarnom aplikacionom serveru (ista fizička mašina kao i primarni db server). Sve je identično i samo je problem na app serveru. Da je bar jedan od testnih pa da se zezam sa verzijama kernela/drajvera, ovako tražim "neinvazivnu" metodu da rešim problem. Definitivno je memorija tesna, ali dovoljna, a imam namere da dodam još neki CPU.

Mreža je možda problematična, o smislu truputa, ali ne samo na app serveru nego generalno. Tako sam i došao do podatka. Uzeo sam da obrađujem istorijske podatke, probam malo elasticsearch, zabbix i još neke alate pa sam hteo da nađem neke statističke pravilnosti kako bih reagovao na neuobičajene režime rada.

Ono što sam otpisao kao mogući problem je hardver i "žice" pošto bi se problem pojavio i na db serveru.

Trenutno su mi u igri dve teorije, jedna je neki problem sa komunikacijom Oracle VM -> Oracle Linux, a druga je da na nekom od 40 drugih servera postoji proces koji uporno gađa na neki port na kojem niko ne sluša, a ne gasi mi se onih 40 servera jedan po jedan, pa da vidim koji je...
[ Miroslav Strugarevic @ 08.06.2017. 15:35 ] @
Ja bih licno kontaktirao Oracle za support Oracle VM-a i Oracle Linux-a (ako ga imate) posto ovo nije bas lako dijagnostikovati (ili bar meni tako deluje), a ja se svakako ne bih usudio da ti dajem odgovore (vec samo savete) za nesto sto ne znam dobro, sto ne odrzavam i ne dobijam nista od toga (osim potencijalne glavobolje).

Ja verujem da je 99% problem na OS-u pre nego na hypervizoru, posto na eth0 interfejsu nema gresaka, i posto ostale virtualke rade okej, to onda znaci da sam VM server i HW nisu problem.

Mislim da je RX queue problem posto najvise gubitka imas kod dev_ingress_queue_create (eventualno da proveris netdev_max_backlog kernel parametar). Ako imas vise traffica (pps) kada pocnu RX dropovi onda kapiram da je mozda RX queue pun i da kernel ne moze da procesira pakete dovoljno brzo i da ih onda dropuje.

Sto se tice tvoje teorije da te neko bombarduje, mislim da moras uraditi tcpdump i pokazati nekom ko se bavi networking-om (iz tvoje organizacija) i onda ces lako ustanoviti tacno sta je problem. Pazi samo posto ce tcpdump sigurno da degradira performance sistema tako da opet vodi racuna da li ces, kada ces i koliko ces vremena (ili paketa) da capture-ujes.

Pitanje je kada se ovi problemi desavaju, da li su consistent ili intermitent i u koje doba dana.

Ako vec hoces sam da se "bavis" ovim problem onda pogledaj ovaj fenomenalan dokument od RedHat-a koji detaljno opisuje ovo sto tebe muci i kako se to troubleshootuje -
https://access.redhat.com/site...network_performance_tuning.pdf

Ovo je samo neka moja teorija i uzmi je sa velikom rezervom!
[ djoka_l @ 08.06.2017. 15:52 ] @
Hvala Miki!
Meni je najveći problem "previše pokretnih delova", a rešenje "ako radi ne diraj" :P
Sve radi, ali bi radilo i bolje kada bih našao šta se dešava.

A da je knozistentan, jeste! Imam oko mesec i po dana logova i za sve to vreme imam konstantan rxdrop na nivou od 11-13% bez obzira na sve ostale parametre. Nisam očekivao da dobijem odgovor koji će odmah sve da reši, ali mi je dragocen svaki hint gde da tražim.

I tako planiram da uskoro odradim veliko spremanje pa da vidimo šta će da se desi...
[ Miroslav Strugarevic @ 08.06.2017. 16:22 ] @
Nema na cemu Djole! Drago mi je ako mogu da pomognem na bilo koji nacin. Voleo bih da znam sta je bilo resenje problema, kad do njega dodjes.
[ Branimir Maksimovic @ 08.06.2017. 21:48 ] @
Pogledaj koji programi vrse komunikaciju kada ide drop i vidi koliki je protok.
[ pajaja @ 09.06.2017. 00:24 ] @
Citat:

Code:

09:28:36.245976 00:50:56:89:7b:29 (oui Unknown) > 03:bf:0a:73:3a:46 (oui Unknown), ethertype Unknown (0x886f), length 1510:

        0x0000:  bf01 dec0 0602 0000 0100 0000 0a73 3a46  .............s:F

        0x0010:  0a73 3a47 0000 0000 0100 0200 1510 f456  .s:G...........V

        0x0020:  778d 0000 0000 0000 0000 0000 00f0 ff6f  w..............o


Da li su ovo paketi koji su dropovani ili samo nesto za sta ne znas sta je? IEEE kaze da je ovaj ethertype registrovao Microsoft. Ako u mrezi imas nesto na 10.115.58.70 pogledaj ovaj link. Deluje skroz nevezano za ovo sto si opisao, ali se poklapa sa ovim paketom iznad pa ti mozda da neku ideju sta u stvari moze biti.
[ djoka_l @ 09.06.2017. 08:35 ] @
@pajaja U pravu si, nisam imao pojma šta mi je ovaj paket... Gledao sam sliku infrastrukture, spisak servera, ali ti si mi pomogao da ukapiram da mi je to farma web servera. Kolega je od negde izbunario istu sliku u koju sam ja gledao danima i vidim da je rukom upisao da je 10.115.58.70 adresa farme. Biće da nije to problem, ali si mi otkačio jednu brigu.