Perché il tempo di risposta esplode quando la frequenza della richiesta diminuisce?

22

Correzione : il tempo di risposta ( %D) è μs non ms! 1

Ciò non cambia nulla della stranezza di questo modello, ma significa che è praticamente meno devastante.

Perché il tempo di risposta è inversamente correlato alla frequenza di richiesta?

Il server non dovrebbe rispondere più velocemente quando è meno occupato a gestire le richieste?

Qualche suggerimento su come fare in modo che Apache "tragga vantaggio" da un minor carico?

Questo modello è periodico. Ciò significa che verrà visualizzato se le impressioni scendono al di sotto di circa 200 richieste al minuto, cosa che accade (a causa della naturale attività dell'utente) da tarda notte a prima mattina.

Le richieste sono POST molto semplici che inviano un JSON di meno di 1000 caratteri - questo JSON è archiviato (aggiunto a un file di testo) - tutto qui. La risposta è solo "-".

I dati mostrati nei grafici sono stati registrati con Apache stesso:

LogFormat "%{%Y-%m-%d+%H:%M:%S}t %k %D %I %O" performance
CustomLog "/var/log/apache2/performance.log" performance

apache-2.4 ubuntu-14.04 high-load

— Raffael
fonte

2

È possibile che qualcosa stia causando la pressione della cache e, di conseguenza, deve recuperare le cose dal disco? Che aspetto ha l'attività del disco?

— TLW

2

Sono richieste in arrivo al minuto o richieste gestite al minuto?

— user253751

Quale software hai usato per registrare e tracciare questi dati? Sinceramente curioso

— Délisson Junio il

1

@wingleader: registrato con Apache2 e tracciato con R

— Raffael il

@immibis: vedi la configurazione del registro che ho aggiunto - Penso che sia "arrivo"

— Raffael

31

Questo è un comportamento comune nei data center. I tempi in cui il tempo di risposta è lento corrispondono a quella che comunemente viene chiamata la finestra batch. Questo è un periodo di tempo in cui l'attività dell'utente dovrebbe essere bassa e possono essere eseguiti processi batch. Anche i backup vengono eseguiti durante questo periodo. Queste attività possono mettere a dura prova le risorse del server e delle reti causando problemi di prestazioni come si vede.

Ci sono alcune risorse che possono causare problemi:

Alto carico della CPU. Questo può far sì che apache attenda un intervallo di tempo per elaborare la richiesta.
Utilizzo elevato della memoria. Questo può svuotare i buffer che consentono ad Apache di servire le risorse senza leggerle dal disco. Può anche causare il paging / lo scambio dei lavoratori apache.
Alta attività del disco. Ciò può causare l'accodamento dell'attività di I / O del disco con ritardi corrispondenti nella pubblicazione del contenuto.
Attività di rete elevata. Ciò può causare l'accodamento dei pacchetti per la trasmissione, l'aumento dei tentativi e il degrado del servizio.

Uso sarper indagare rilasciato in questo modo. atsarpuò essere utilizzato per raccogliere sardati in file di dati giornalieri. Questi possono essere esaminati per vedere com'è il comportamento del sistema durante il giorno quando le prestazioni sono normali e sovrascrivere quando le prestazioni sono variabili.

Se stai monitorando il sistema con munino con qualche altro sistema che raccoglie e illustra graficamente l'utilizzo delle risorse, potresti trovare alcuni indicatori lì. Trovo ancora sarpiù preciso.

Esistono strumenti simili nicee ioniceche possono essere applicati ai processi batch per ridurre al minimo il loro impatto. Sono efficaci solo per problemi di CPU o I / O. È improbabile che risolvano problemi con l'attività di memoria o di rete.

Spostamento dell'attività di backup su una rete separata e riduzione dei conflitti di rete. Alcuni software di backup possono essere configurati per limitare la larghezza di banda che verrà utilizzata. Ciò potrebbe risolvere la contesa di rete.

A seconda di come vengono attivati i processi batch, è possibile limitare il numero di processi batch in esecuzione in parallelo. Ciò può effettivamente migliorare le prestazioni dei processi batch in quanto stanno probabilmente riscontrando la stessa contesa di risorse.

— BillThor
fonte

1

Un link a sar potrebbe essere utile. Ho trovato questo: en.wikipedia.org/wiki/Sar_(Unix)

— Roger Lipscombe,

questo potrebbe non essere solo un backup, i fornitori di VM possono spostare più VM sulle stesse macchine nei tempi di inattività e spegnere alcuni rack per risparmiare energia (o, in effetti, dedicarli alle attività batch)

— Jens Timmerman,

8

Questa relazione può verificarsi nella direzione opposta se i mittenti della richiesta attendono il completamento di una richiesta precedente prima di inviarne una nuova. In tal caso il traffico diminuisce con l'aumentare dei tempi di richiesta (per qualsiasi motivo), a causa dell'accodamento sul lato client.

Oppure può essere un artefatto della misurazione: se il grafico sopra mostra le richieste completate , al contrario delle richieste in arrivo , il tasso diminuirà con l'aumentare del tempo di elaborazione della richiesta (ipotizzando capacità finita: D).

— Karol Nowak
fonte

Naturalmente questo sta solo graffiando la superficie di possibili motivi, ma la dichiarazione del problema di apertura non dà molto da guardare. Questo processo parla con qualcos'altro? Che tipo di richieste serve? Il carico di lavoro cambia nel tempo? E così via ....

— Karol Nowak,

prospettiva interessante ma non va bene con la periodicità e la durata dei sintomi

— Raffael,

7

Sebbene la risposta di @ BillThor possa essere corretta, sembra improbabile che il periodo di basso carico sia interamente occupato dai processi di backup (ovvero che i periodi coincidano esattamente).

Una spiegazione alternativa è semplicemente la memorizzazione nella cache. Se un dato script / database / qualunque cosa non sia stato utilizzato di recente, i dati memorizzati nella cache potrebbero essere stati eliminati per liberare memoria per il resto del sistema operativo. Potrebbe trattarsi di indici su un database o buffer O / S in relazione a un file o qualsiasi altra cosa simile. Una query dovrà quindi ricostituire queste informazioni se è passato un po 'di tempo dall'ultima query. Nei periodi di punta questo non si verificherà poiché l'ultima query sarà stata frequente. Questo spiegherebbe anche perché stai vedendo tempi di risposta bassi e tempi di risposta elevati durante il periodo di piena attività.

— abligh
fonte

Soprattutto se si tratta di cache di query e / o cache di accesso al disco. A parte se c'è qualche strategia di "riutilizzo del thread" che aiuta anche.

— mckenzm,

Non è prevista alcuna lettura di alcun tipo.

— Raffael,

1

@Raffael Dubito fortemente che tu possa garantire "non vi è alcuna lettura di alcun tipo". A un livello banale, supponiamo che le pagine di Apache siano state pagate perché qualcos'altro voleva la RAM? Supponiamo che il tuo MPM per Apache abbia ridotto il numero di thread / processi mentre le cose sono inattive e c'è un sovraccarico nella creazione di nuovi? Stai seriamente dicendo che se esegui straceil processo Apache, non vedi read()chiamate di sistema o simili? Sarebbe abbastanza insolito.

— circa

@abligh: bene, esatto, il mio "servizio" non implementa esplicitamente nulla che legge dal disco

— Raffael,

@Raffael se si desidera testare (solo) l'effetto della memorizzazione nella cache del sistema operativo, quindi durante un periodo di occupato fare echo 3 > /proc/sys/vm/drop_cachesogni 5 secondi per un minuto e vedere se si ottengono effetti simili sui tempi di risposta.

— circa

2

Quello che vedi lì sembra, per me, come potrebbe essere un problema statistico. Potrebbe non essere, la risposta di @ BillThor potrebbe essere giusta, ma posterò questo per completezza.

I grafici dei tempi di risposta sono basati su percentile. Un pool di esempio di 800-1000 richieste è un buon numero di esempi per questo, un pool di 50-100 richieste potrebbe non essere così tanto.

Se si presume che il numero di richieste lente non sia una funzione lineare del volume della richiesta, in modo tale che un aumento dell'ordine delle magnitudini nelle richieste non comporti un aumento dell'ordine delle magnitudini nelle richieste lente, allora maggiori volumi di richieste tempo medio di richiesta inferiore.

— Kaithar
fonte

1

se l'osservazione comprendesse solo da 50 a 100 richieste, allora in realtà potrebbe trattarsi solo di casualità, ma se guardi il grafico vedrai che stiamo parlando di esperimenti 60 x 5 che coinvolgono ciascuno da 50 a 100 richieste - è sicuramente abbastanza per escludere la casualità. Inoltre, se guardi da vicino, vedrai emergere una media stabile del 50 ° percentile a circa 2500 ms.

— Raffael,

Non necessariamente, non è esattamente il modo in cui questo tipo di statistiche si comporta alla rinfusa. Ad esempio, 1000 richieste nell'arco di 1 ora e 1000 richieste nell'arco di 1 minuto non si comporteranno allo stesso modo. Inoltre probabilmente non sta succedendo qui. I campioni di piccole dimensioni si comportano in modo strano, in questo caso è più simile ai set di campioni 60x5. Il modello potrebbe essere il risultato di un caricamento non lineare.

— Kaithar,

0

Ci sono bugie, grandi bugie e statistiche.

La mia ipotesi: hai tre categorie distinte di richieste:

Il normale flusso variabile che contiene la maggior parte delle richieste e queste sono tutte completate entro 200-300 μs.
Piccolo flusso ad una velocità costante di circa 20 richieste al minuto (anche di notte). Ciascuno richiede circa 2.500 μs per il completamento.
Piccolo flusso ad una velocità costante di circa 10 richieste al minuto (anche di notte). Ciascuno richiede ben oltre 4.000 μs.

Di notte, le 50 richieste al minuto sono rispettivamente 20 + 20 + 10. Quindi, il risultato del 50% percentile ora dipende fortemente dal risultato del flusso 2. E il 95% percentile dipende dal flusso 3, quindi non può nemmeno mostrarsi sul grafico.

Durante il giorno, i flussi 2 + 3 sono ben nascosti sopra il 95% percentile.

— kubanczyk
fonte

Cosa intendi con stream? Le richieste sono assolutamente omogenee mentre i clienti che richiedono sono assolutamente eterogenei.

— Raffael,

0

Più lo guardo, più sono propenso a pensare che ci sia un problema con la raccolta dei dati.

Prima di tutto, c'è qualcosa di veramente strano nel tuo TPS. Mentre il modello generale sembra normale, c'è un molto rottura marcata intorno alle 21:00, quindi di nuovo alle 7:00 circa. Un grafico normale sarà molto più fluido durante il passaggio alle ore non di punta.

Ciò suggerisce che c'è un cambiamento nel profilo e che possibilmente hai 2 tipi distinti di client:

Uno che opera solo tra le 7:00 (ish) e le 21:00 (ish), a volumi elevati e
un altro che probabilmente funziona tutto il giorno, a volumi più bassi.

Il secondo suggerimento è intorno alle 18:00. Il più delle volte, prima e dopo, abbiamo la alto profilo del volume - alti TPS e bassa latenza. Ma verso le 18:00 c'è un improvviso calo da 800-1000 RPM a meno di 400 RPM. Cosa potrebbe causarlo?

Il terzo suggerimento è la riduzione dei tempi di risposta del 5 ° percentile. In realtà preferisco guardare i tempi di risposta minimi (ma il 5 ° percentile è probabilmente migliore) per due motivi: mi dice il tempo di servizio (cioè tempo di risposta meno accodamento), e i tempi di risposta tendono a seguire una distribuzione Weibull che significa che la modalità (o il valore più comune) è appena sopra il minimo.

Quindi il passaggio nel 5 ° percentile mi dice che c'è una brusca interruzione della serie e che i tempi di servizio sono effettivamente diminuiti anche se sia la varianza che i tempi medi di risposta sono notevolmente aumentati.

Prossimi passi

A questo punto farei un'immersione profonda nei registri per scoprire cosa c'è di diverso nei campioni a basso volume delle 18:00 rispetto ai campioni ad alto volume prima e dopo.

Vorrei cercare:

differenze nella posizione geografica (nel caso in cui la latenza influisca su $ request_time)
differenze nell'URL (dovrebbe essere nessuna)
differenze nel metodo HTTP (POST / GET) (dovrebbe essere nessuno)
richieste ripetute dallo stesso IP
e qualsiasi altra differenza ...

A proposito, l '"evento" delle 18:00 è una prova sufficiente per me che non ha nulla a che fare con la congestione / attività dei data center. Affinché ciò sia vero, la congestione dovrebbe causare un calo del TPS, che è possibile alle 18:00, ma è estremamente improbabile che causi un calo prolungato e uniformemente curvo del TPS per 10 ore tra le 21:00 e le 7:00.

— Nathan Webb
fonte