Problemi di interconnessione con RAC

venerdì 23 gennaio 2009 alle 23:23 | Pubblicato su Performance Tuning, RAC | 15 commenti
Tag:

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 for comments on this post. TrackBack URI

  1. Cristian

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

    Tanti saluti

    Nigel

  2. 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

  3. 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

  4. 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.

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

  6. il driver è tg3

  7. 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

  8. 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

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

  10. i settaggi kernel relativi sono OK?:

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

  11. 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.

  12. 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

  13. 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

  14. 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).

  15. 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?


Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

Crea un sito o un blog gratuitamente presso WordPress.com.
Entries e commenti feeds.

%d blogger cliccano Mi Piace per questo: