Comprensione dei profili ottimizzati consigliati da RedHat

Distribuiremo sintonizzati (e numad) su ~ 1000 server, la maggior parte dei quali sono server VMware su NetApp o 3Par storage.

Secondo la documentazione di RedHats dovremmo scegliere il virtual-guestprofilo. Quello che sta facendo può essere visto qui: tuned.conf

Stiamo cambiando lo scheduler IO in NOOP poiché sia ​​VMware che NetApp / 3Par dovrebbero fare una pianificazione sufficiente per noi.

Tuttavia, dopo aver studiato un po 'non sono sicuro del motivo per cui stanno aumentando vm.dirty_ratioe kernel.sched_min_granularity_ns.

Per quanto ho capito, l'aumento del vm.dirty_ratio40% significa che per un server con 20 GB di RAM, 8 GB possono essere sporchi in qualsiasi momento a meno che non vengano vm.dirty_writeback_centisecscolpiti per primi. E durante lo svuotamento di questi 8 GB, tutti gli I / O dell'applicazione verranno bloccati fino a quando le pagine sporche vengono liberate.

L'aumento di dirty_ratio significherebbe probabilmente prestazioni di scrittura più elevate ai picchi poiché ora abbiamo una cache più grande, ma poi di nuovo quando la cache riempie IO verrà bloccata per un tempo considerevolmente più lungo (diversi secondi).

L'altro è il motivo per cui stanno aumentando il sched_min_granularity_ns. Se lo capisco correttamente, aumentare questo valore diminuirà il numero di intervalli di tempo per epoca ( sched_latency_ns), il che significa che le attività in esecuzione avranno più tempo per terminare il loro lavoro. Posso capire che questa è un'ottima cosa per le applicazioni con pochissimi thread, ma per es. apache o altri processi con molti thread non sarebbero controproducenti?

La risposta breve è che qualsiasi sintonizzazione è una congettura e ha valore solo quando viene eseguito il backup con dati empirici: provalo. Misuralo. Se non ti piace, modificalo.

Una risposta più lunga:

L'aumento di dirty_ratio significherebbe probabilmente prestazioni di scrittura più elevate ... IO sarà bloccato per un tempo considerevolmente più lungo

No. Aumentare il rapporto sporco significa che il tuo sistema ha meno probabilità di entrare in uno stato in cui deve iniziare a bloccare le scritture. Il rovescio della medaglia è che c'è più memoria utilizzata e un maggiore rischio di perdita di dati in caso di interruzione.

ciò significa che le attività in esecuzione avranno più tempo per terminare il loro lavoro

I processi di solito cederanno prima della scadenza del loro intervallo di tempo. Il problema con una macchina virtuale è che la macchina potrebbe competere per CPU e cache L1 / L2 con altre macchine virtuali: livelli elevati di commutazione delle attività (a causa di anticipazione) hanno un grande impatto sulla velocità effettiva. Il tipo di applicazioni che vengono solitamente utilizzate nelle macchine virtuali è associato alla CPU (server Web, server applicazioni).

Sì, l'aumento della velocità effettiva (che si applica a tutti i tipi di applicazione) arriverà al costo di un aumento della latenza, ma quest'ultimo è dell'ordine dei microsecondi quando la maggior parte delle transazioni richiede millisecondi. Se hai bisogno di funzionalità in tempo reale / latenza molto bassa, non dovresti utilizzare una macchina virtuale.

Ecco il programma delle configurazioni tuned-adm ...

Penso che aiuti a vederli in forma tabellare. La cosa principale da notare è che le impostazioni RHEL6 predefinite fanno schifo !! L'altra cosa è che i profili di archiviazione aziendale e guest virtuale sono identici, tranne per la ridotta swappiness sul lato guest virtuale (ha senso, giusto?).

Per quanto riguarda una raccomandazione sull'elevatore I / O di archiviazione, sono presenti alcuni livelli di astrazione sul livello di archiviazione. L'uso dello scheduler noop avrebbe senso se si utilizzavano RDM o si presentava lo storage direttamente alle proprie macchine virtuali. Ma dal momento che vivranno su NFS o VMFS, mi piacciono ancora le opzioni di ottimizzazione aggiuntive offerte dallo schedulatore delle scadenze.

I profili sintonizzati possono essere modificati al volo sui sistemi in esecuzione, quindi in caso di dubbi, testare con l'applicazione, l'ambiente e il benchmark specifici.

Guarda i video di ottimizzazione delle prestazioni di Shak e Larry di Summit, parlano in dettaglio dei profili sintonizzati.

• Parte 1 - http://www.youtube.com/watch?v=fATEiBJ3pKw
• Parte 2: http://www.youtube.com/watch?v=km-vLELmWLs

Uno dei più grandi aspetti previsti è che i profili sono solo un punto di partenza consigliato, non numeri immutabili che sono magicamente perfetti per ogni ambiente.

Inizia con un profilo e divertiti con le impostazioni. Genera un buon carico di lavoro di prova simile alla produzione e misura metriche importanti per la tua azienda.

Cambia una cosa alla volta e registra ogni risultato ad ogni iterazione. Al termine, rivedere i risultati e selezionare le impostazioni che hanno dato i risultati migliori. Questo è il tuo profilo sintonizzato ideale.