Cambiate una cosa, misurate di nuovo. Come trovare il vero collo di bottiglia

Quando una piattaforma è lenta, l'ordine d'acquisto più rapido è per più di tutto. Spesso funziona un poco, costa molto e lascia al suo posto la vera causa, pronta a mordere di nuovo al prossimo picco di traffico. L'alternativa è meno entusiasmante e molto più efficace: trovare l'unica risorsa su cui il carico di lavoro sta aspettando, cambiare una sola cosa di quella risorsa e misurare di nuovo. Ecco il metodo e gli strumenti.

Partite da un numero, non da una sensazione

«Il sito è lento» non si può testare. «Il checkout impiega quattro secondi al picco serale e meno di uno di notte» sì. Prima di toccare qualsiasi cosa, ancorate il sintomo a una misura che potete ripetere: il tempo di una pagina dall'esterno, la durata di una query, il tempo di esecuzione di un job batch, il tasso di richieste a cui iniziano gli errori. Quel numero è come saprete se qualcosa che avete cambiato ha aiutato. Senza di esso, ogni modifica sembra un progresso.

Poi scrivete il percorso che l'operazione lenta compie: client, rete, load balancer, web server, applicazione, cache, database, storage. Il collo di bottiglia è da qualche parte su quel percorso, e il percorso vi dice dove guardare.

Controllate ogni risorsa per uso, saturazione ed errori

Una disciplina semplice, resa popolare da Brendan Gregg come metodo USE, tiene onesta la ricerca. Per ogni risorsa sul percorso, CPU, memoria, rete, storage, fate tre domande: quanto è occupata, c'è lavoro in coda davanti a lei, e sta segnalando errori? Una risorsa può essere poco usata ed essere comunque il problema se le richieste si accodano davanti a lei, quindi la seconda domanda conta più di tutte.

CPU.

mpstat -P ALL 1
vmstat 1
pidstat -u 1

Guardate l'uso per core, non solo la media. Un core a pieno carico mentre gli altri sono fermi indica un collo di bottiglia single-threaded che più core non risolveranno. In vmstat, una run queue (r) costantemente più grande del numero di core è saturazione.

Memoria.

free -h
vmstat 1
cat /proc/pressure/memory

La pressione sulla memoria si vede come attività di reclaim e tempo di stallo nel file pressure. Su una macchina virtuale ben costruita non c'è swap in cui nascondersi, quindi un carico di lavoro che ha davvero bisogno di più memoria di quanta ne ha fallisce in modo rumoroso, che è l'esito onesto: la soluzione è più memoria o un'applicazione più snella.

Storage.

iostat -x 1
pidstat -d 1

Le colonne che contano sono i tempi medi di attesa per letture e scritture e la dimensione della coda. %util è fuorviante su volumi flash e SAN, che servono molte richieste in parallelo e possono mostrare un'utilizzazione alta pur avendo ancora molto margine. Tempi di attesa in aumento con una coda che cresce sono il segnale vero.

Rete.

sar -n DEV 1
sar -n EDEV 1
ss -s
cat /proc/net/bonding/bond0
ethtool -S <interface> | grep -iE 'drop|err|discard'

Confrontate il traffico per membro di un bond: un membro occupato mentre l'altro è fermo è un problema di hashing, non di banda. Drop ed errori nei contatori di interfaccia puntano sotto il sistema operativo, a cavi, ottiche o switch.

Database. Molte piattaforme lente sono un database che legge da disco ciò che dovrebbe leggere dalla memoria. Su MySQL o MariaDB, confrontate le letture logiche con quelle che hanno dovuto raggiungere lo storage:

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';

Se Innodb_buffer_pool_reads (letture che hanno mancato la memoria) cresce rapidamente rispetto a Innodb_buffer_pool_read_requests, il working set non sta nel buffer pool. Lo slow query log, con una soglia ragionevole, vi dice quali query ne pagano il prezzo.

Cambiate una cosa

Quando una risorsa spicca, formulate un'ipotesi che spieghi il numero originale, e fate una sola modifica che la metta alla prova: un buffer pool dimensionato sul working set, una hash policy del bond, una cache davanti alla pagina costosa, una query a cui viene dato l'indice che le serve, una VM ridimensionata per stare in un solo socket CPU. Una modifica alla volta, perché se cambiate tre cose e il numero migliora non sapete quale abbia aiutato, e potreste averne tenute due che hanno peggiorato le cose.

Misurate di nuovo, nello stesso modo

Ripetete la misura dall'inizio, nelle stesse condizioni: stessa ora del giorno o stesso carico sintetico, stesso test, stessi strumenti. Una modifica che non ha aiutato è comunque un risultato, perché esclude qualcosa; annullatela e tornate alle risorse.

Ripetete finché il sintomo originale non sparisce o finché il prossimo collo di bottiglia non è qualcosa che davvero i soldi devono risolvere. È allora che comprare hardware è la risposta giusta, e saprete esattamente quale risorsa comprare.

Com'è nella pratica

Alcune delle impostazioni più efficaci sono lunghe una riga. Dimensioniamo i buffer di memoria dei database in modo che i dati caldi vivano in RAM e il flash serva lavoro vero, e ogni server con bond che costruiamo fa l'hash su indirizzi e porte, così entrambi i collegamenti trasportano traffico. Entrambe sono regole fisse su ogni piattaforma che gestiamo.

Come lo facciamo

Il lavoro sulle prestazioni è il modo in cui gestiamo ogni piattaforma, non un prodotto separato. Misuriamo a ogni livello, dall'I/O per volume sugli array e dai contatori per porta su bond e switch agli slow log sui database e ai tempi misurati dall'esterno attraverso la CDN, prima di nominare una causa. Le regole fisse che sono affidabilmente giuste, come bond che usano entrambi i collegamenti, flash trattato come flash e VM che stanno dentro un solo socket, vengono applicate a ogni costruzione. Quando una piattaforma ha davvero bisogno di più capacità, vi diciamo quale risorsa, quanta e perché.

Se la vostra piattaforma è lenta e l'unico suggerimento finora è stato un server più grande, lasciate che la misuriamo prima.

Parla con un ingegnere

Related

Correlati: Ingegneria delle prestazioni e della capacità · Server bare metal su HPE e Dell · Storage SAN enterprise su HPE 3PAR, all-flash