Comportmento di stack tcp solaris con traffico RTT relativamente alto e traffico bursty

Ho un'applicazione che distribuisce dati da New York a Tokyo su TCP che esegue Solaris 10. Il throughput medio è <1Mbps, il throughput di picco può raggiungere i 20-30Mbps per secondi alla volta, anche se i picchi tipici sono più simili a 10Mbps. I singoli formati di messaggi sono piccoli (~ 300bytes) e la consistenza della latenza è fondamentale. Ciò significa che stiamo tentando di rimuovere il pacco di batch in modo che nagles sia spento e l'applicazione è configurata per submit più di una coda, quindi submit.

Il RTT tra New York e Tokyo è di ~ 180ms e la window TCP è sintonizzata su un throughput teorico nella regione di ~ 40Mbps, ovvero 1M tcp_xmit_hiwat / tcp_rcv_hiwat. tcp_max_buf e tcp_cwnd_max sono anche 1M.

Il problema qui è che spesso, ma in modo intermittente, vediamo delle "pause" misteriose in cui il mittente ottiene EWOULDBLOCK che port a un accumulo in una coda interna e successivamente scarico di dati. Ci sono due problemi qui

  1. nessuna ragione ovvia per la presa di block, non sembri che stiamo colpendo il throughput di picco e niente nella cattura di pacchetti suggerisce alcun rallentamento
  2. durante il "periodo di scarico" (cioè quando la presa del mittente non è più bloccata ma ha un buffer di dati da submit), vediamo un model di segato a costante aumento alle velocità di messaggio

Il primo è la chiave del problema, se posso lavorare fuori questo non dovrebbe verificarsi. Tuttavia quest'ultimo è strano, mi aspettavo ingenuamente di salire rapidamente fino alla velocità massima e rimanere lì fino a quando non avesse ottenuto il backlog.

L'utilizzo della CPU non è un problema in entrambi i casi, dicono che le caselle sembrano buone. La congestione di networking sul collegamento WAN non è un problema, le reti dicono che la networking sembra buona. Infatti ognuno dice che each singolo pezzo sembra benissimo, sta facendo ancora male!

Qualche pensiero su come ottimizzare per questa situazione? o cose da indagare che potrebbero fornire un suggerimento su cosa sta succedendo?

One Solution collect form web for “Comportmento di stack tcp solaris con traffico RTT relativamente alto e traffico bursty”

EWOULDBLOCK / EAGAIN significa che i dati non potrebbero essere inviati subito. Abbiamo bisogno di ulteriori dettagli sul codice per capirlo.

  • Provare a capire cosa succede al mittente quando EWOULDBLOCK viene restituito. Controllare i thread e altri processi, monitorare l'utilizzo di memory / swap e CPU. Controllare i tuoi registri (/ var / messages, …) per qualsiasi errore hardware.
  • Determinare la perdita di pacchetti
  • Eseguire il programma su un altro sistema operativo prima di accusare lo stack TCP Solaris o scrivere un piccolo programma di test che invia 300B / s all'estremità remota (senza bisogno di prese non bloccanti, submit), controllare eventuali latenze, questo isolerebbe il problema della networking .

Non sono uno sviluppatore ma suggerisco di provare a sostituire i socket non bloccabili da un multiplexer di I / O: select o eseguire il polling o / dev / poll e verificare se la presa è pronta per la scrittura. Può cambiare il comportmento del tuo programma per il meglio o nel peggiore dei casi, ti dà più debug e suggerimenti sul problema reale.

Su tali lunghe distanze tutti i pacchetti stanno probabilmente utilizzando routes diversi, passando però in modo diverso, quindi nessuno può veramente valutare la qualità della networking. Un pacchetto può richiedere molto tempo per arrivare e essere riconosciuto a causa di un problema da qualche parte in profondità in Internet (è probabilmente vicina però, altrimenti la gente avrebbe segnalato e risolto), cercare di unirsi da / in altre località. Se un singolo pacchetto richiede molto tempo per essere riconosciuto, la window TCP si blocca e ulteriori dati non possono essere elaborati. È ansible che si desideri provare a aggiustare la dimensione della window TCP ad un valore superiore.

Inoltre è ansible eseguire semplicemente mtr per controllare rapidamente la qualità della networking. Eseguire più volte in quanto i pacchetti possono assumere routes diversi.

Spero che questo ha aiutato, in qualche modo: /

Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.