Problemi di interconnessione con RAC

Questo non è buono, sto indagando, ma su solo uno dei nodi di un RAC 10.2.0.4 su Linux nei report di statspack trovo:

Top 5 Timed Events                                                    Avg %Total
~~~~~~~~~~~~~~~~~~                                                   wait   Call
Event                                            Waits    Time (s)   (ms)   Time
—————————————– ———— ———– —— ——
gc cr multi block request                       64,607       1,266     20   80.7
gcs log flush sync                              59,331          74      1    4.8
db file sequential read                         17,592          73      4    4.6
CPU time                                                        42           2.6
gc current block lost                               29          24    825    1.5
————————————————————-

ciò pare dovuto a questo:

db4:~ # netstat -s
Ip:
191844534 total packets received
792 with invalid addresses
0 forwarded
0 incoming packets discarded
82921507 incoming packets delivered
67029137 requests sent out
2990 fragments dropped after timeout
131641206 reassemblies required
22718971 packets reassembled ok
469374 packet reassembles failed
8768640 fragments received ok

sembra che su questo nodo, che ha la stessa identica configurazione degli altri nodi, ci sia un problema a riassemblare i pacchetti TCP. Capitasse anche sugli altri nodi me ne farei una ragione, ma siccome capita solo su uno sono perplesso.

15 Commenti »

RSS feed dei commenti a questo articolo. TrackBack URI

Cristian

Is this a symptom of hardware failure on this node – perhaps the network interconnect – card or cable – is faulty?

Tanti saluti

Nigel

Commento di Nigel Thomas — Venerdì 23 Gennaio 2009 #

Replica
Hi Nigel,
there is no other symptom indicating hardware failure. ifconfig output gives non errors. I’ve also made a test with scp of a file from another node toward this on the private address and it has worked well and without slowness. There’s no log and the interconnect is on 2 nic with bonding.
Really i don’t know what to search for still.

Se è un problema hardware, cosa probabile, è subdolo e difficile da identificare e provare.

Grazie

Commento di Cristian Cudizio — Venerdì 23 Gennaio 2009 #

Replica
Ciao Cristian,
io non ho mai avuto a che fare con questo problema, cmq girando su Metalink ho trovato i documenti 400959.1 e 563566.1, che forse avrai già letto, spero che ti possano essere utili.

Bye

Commento di Rudy — Venerdì 23 Gennaio 2009 #

Replica
Ciao Rudy, in effetti avevo trovato anch’io quei due documenti, in particolare con il secondo ho provato per scrupolo a seguire le indicazioni, aumentanto i parametri /proc/sys/net/ipv4/ipfrag* ma non ho visto giovamenti. D’altra parte sugli altri nodi i parametri sono al valore di default e non ci sono “anomalie”.
Riguardando mi è venuto un dubbio: come mai ci sono tanti packet reassembles failed e relativamente pochi fragment dropped after timeout?
Devo anche dire che non si notano picchi nell’utilizzo delle cpu sul server che giustifichino tali problemi. Si rafforza in me la convinzione di problemi hardware.

Commento di Cristian Cudizio — Sabato 24 Gennaio 2009 #

Replica
Ciao Cristian,
utilizzi un driver e1000 per caso? E se si RX flow control è attivo?

Commento di Alessandro — Lunedì 26 Gennaio 2009 #

Replica
il driver è tg3

Commento di Cristian Cudizio — Lunedì 26 Gennaio 2009 #

Replica
con ethtool dovresti vedere e/o poter cambiare i settaggi (ovviamente settarli solo se è il caso);
magari puoi verificare se quei settaggi sono uguali con gli altri nodi dove non hai il problema

Commento di Alessandro — Lunedì 26 Gennaio 2009 #

Replica
i settaggi sono uguali su tutti i nodi, sono il default e almento per quanto riguarda il “flow control” sembra attivo su tutti i nodi:

ethtool -a eth2
Pause parameters for eth2:
Autonegotiate: on
RX: on
TX: on

Commento di Cristian Cudizio — Lunedì 26 Gennaio 2009 #

Replica
per curiosità su che tipo di architettura risiede il DB del RAC (intendo OCFS piuttosto che NFS o ASM eccetera)?

Commento di Alessandro — Lunedì 26 Gennaio 2009 #

Replica
i settaggi kernel relativi sono OK?:

net.core.rmem_default
net.core.wmem_default
net.core.rmem_max
net.core.wmem_max

Commento di Alessandro — Lunedì 26 Gennaio 2009 #

Replica
Siccome ho esperienza, positiva, con ASM, sono rimasto su ASM. Per quanto riguarda i parametri del kernel, relativi al buffer UDP sono:
net.core.rmem_default = 2097152
net.core.rmem_max = 2097152
net.core.wmem_default = 262144
net.core.wmem_max = 524288

Uguali su tutti e 4 i nodi.

Commento di Cristian Cudizio — Lunedì 26 Gennaio 2009 #

Replica
partiamo dallo statspack;
ciò che si vede è “gc cr multi block request” che è un evento di attesa dove una sessione aspetta per ottenere la copia consistente (CR consistent read) di un buffer cachato in un’altra istanza finchè quella copia non è trasferita in locale..
siccome vedo che tu hai anche “db file sequential read” come evento di attesa credo che la tua situazione possa ricadere in 2 casistiche:

1) il buffer richiesto non è cachato e quindi l’istanza che lo detiene esegue una grant sul buffer all’istanza richiedente che lo legge da disco

2) il numero di copie consistenti del buffer ha raggiunto il limite stabilito dal parametro _fairness_threshold, nel qual caso l’istanza remota porta a null il lock mode sul buffer eseguendo un flush dell’informazione di redo di quel buffer su disco, in maniera che l’istanza richidente possa leggerlo con un’operazione di IO su disco

riesci magari ad individuare sessioni e SQL che possono ricadere su quanto esposto sopra?
Se ci riesci potresti effettuare un trace a livello di sessione per l’evento 10708 per vedere se riesci ad ottenere informazioni piu dettagliate

Commento di Alessandro — Martedì 27 Gennaio 2009 #

Replica
anzi sono convinto, potrei sbagliarmi ovviamente, che ti trovi molto piu probabilmente nel caso 2 perchè hai l’evento “gcs log flush sync” che rappresenta il wait di attesa relativamente al flush di informazioni di redo da parte del LGWR proprio durante la creazione una versione CR di un buffer

Commento di Alessandro — Martedì 27 Gennaio 2009 #

Replica
Ciao Alessandro, grazie per i suggerimenti e l’interessamento. E’ bene che precisi alcune cose in quanto il post è abbastanza superficiale: le query che creano reali problemi (ed elevati tempi di attesa su eventi gc )sono dei full scan. I db sequential solo le altre query indicizzate. In un report tipico con la nostra applicazione i primi eventi sono solitamente proprio CPU Time e DB Sequential Read.
La seconda cosa che non ho precisato, perché non credo sia la causa, è il fatto che l’interconnessione è su due schede di rete in “bonding”.
Quello che dici riguardo il “gcs log flush sync” è interessante e confesso di essermi concentrato più su “gc cr multi block request”. Aggiungo anche che fin dall’inizio ho sempre avuto sulla console degli alert su “GC block lost” ma non ho mai trovato errori sulle interfacce di rete.
Ho l’impressione che dopo un paio di giorni, le modifiche ai parametri /proc/sys/net/ipv4/ipfrag* abbiano migliorato la situazione, seppur non risolta; nel senso che la frequenza dei “rallentamenti” sembra calata. Ciò nonostante nell’output di netstat -s il numero di packet reassembles failed continua ad aumentare (anche se pare di meno, quindi sono convinto che sia collegato al problema di prestazioni).

Commento di Cristian Cudizio — Martedì 27 Gennaio 2009 #

Replica
tieni conto i due eventi potrebbero non essere scollegati, nel senso che ad un evento di attesa di “gc cr requests” (multiblock o meno), relativamente alle due casistiche che ti ho segnalato sopra, è sempre seguito da “db file sequential read” oppure da “db file scattered read”

guarderei anche i SQL quindi se magari si possono migliorare

per il resto trovo molto giusto cercare di agire sui valori di /proc/sys/net/ipv4/ipfrag*

che valore hai di MP_UDP_PACKET_SIZE rispetto al valore di mtu?

Commento di Alessandro — Martedì 27 Gennaio 2009 #

Replica