Linux - regolazione del controller RAID hardware reale (scsi e cciss)

La maggior parte dei sistemi Linux che gestisco dispongono di controller RAID hardware (principalmente HP Smart Array ). Stanno tutti eseguendo RHEL o CentOS.

Sto cercando sintonizzatori del mondo reale per aiutare a ottimizzare le prestazioni per le configurazioni che incorporano controller RAID hardware con dischi SAS (Smart Array, Perc, LSI, ecc.) E cache supportata da batteria o flash. Supponiamo RAID 1 + 0 e più mandrini (4+ dischi).

Trascorro molto tempo a sintonizzare le impostazioni di rete di Linux per applicazioni di trading a bassa latenza e finanziarie. Ma molte di queste opzioni sono ben documentate (modifica dei buffer di invio / ricezione, modifica delle impostazioni della finestra TCP, ecc.). Cosa stanno facendo gli ingegneri dal punto di vista dello stoccaggio?

Storicamente, ho apportato modifiche all'elevatore della pianificazione degli I / O , recentemente ho optato per gli scheduler deadlinee noopper migliorare le prestazioni all'interno delle mie applicazioni. Con il progredire delle versioni RHEL, ho anche notato che anche le impostazioni predefinite compilate per i dispositivi a blocchi SCSI e CCISS sono cambiate. Ciò ha avuto un impatto nel tempo sulle impostazioni del sottosistema di archiviazione consigliate. Tuttavia, è da un po 'che non vedo consigli chiari. E so che le impostazioni predefinite del sistema operativo non sono ottimali. Ad esempio, sembra che il buffer read-ahead predefinito di 128kb sia estremamente piccolo per una distribuzione su hardware di classe server.

I seguenti articoli esplorano l'impatto delle prestazioni della modifica dei valori della cache read-ahead e dei valori nr_requests sulle code dei blocchi.

http://zackreed.me/articles/54-hp-smart-array-p410-controller-tuning
http://www.overclock.net/t/515068/tuning-a-hp-smart-array-p400-with -linux-why-tuning-davvero-importa
http://yoshinorimatsunobu.blogspot.com/2009/04/linux-io-scheduler-queue-size-and.html

Ad esempio, queste sono le modifiche suggerite per un controller RAID HP Smart Array:

echo "noop" > /sys/block/cciss\!c0d0/queue/scheduler 
blockdev --setra 65536 /dev/cciss/c0d0
echo 512 > /sys/block/cciss\!c0d0/queue/nr_requests
echo 2048 > /sys/block/cciss\!c0d0/queue/read_ahead_kb

Cos'altro può essere ottimizzato in modo affidabile per migliorare le prestazioni di archiviazione?
Sto specificatamente cercando le opzioni sysctl e sysfs negli scenari di produzione.

Ho scoperto che quando ho dovuto sintonizzarmi per una latenza inferiore rispetto alla velocità effettiva, ho ridotto nr_requests dal suo valore predefinito (fino a un minimo di 32). L'idea di essere batch più piccoli equivale a una latenza inferiore.

Anche per read_ahead_kb ho scoperto che per letture / scritture sequenziali, aumentare questo valore offre un throughput migliore, ma ho scoperto che questa opzione dipende davvero dal carico di lavoro e dal modello di I / O. Ad esempio, su un sistema di database che ho recentemente ottimizzato, ho modificato questo valore in modo che corrisponda a una singola dimensione di pagina db che ha contribuito a ridurre la latenza di lettura. L'aumento o la diminuzione al di là di questo valore ha dimostrato di danneggiare le prestazioni nel mio caso.

Come per altre opzioni o impostazioni per le code dei dispositivi a blocchi:

max_sectors_kb = Ho impostato questo valore in modo che corrisponda a ciò che l'hardware consente per un singolo trasferimento (controlla il valore del file max_hw_sectors_kb (RO) in sysfs per vedere cosa è permesso)

nomerges = questo ti permette di disabilitare o regolare la logica di ricerca per unire le richieste io. (disattivarlo può farti risparmiare alcuni cicli della CPU, ma non ho riscontrato alcun vantaggio quando lo cambio per i miei sistemi, quindi l'ho lasciato predefinito)

rq_affinity = Non l'ho ancora provato, ma ecco la spiegazione dietro ai documenti del kernel

Se questa opzione è "1", il livello di blocco eseguirà la migrazione dei completamenti della richiesta al "gruppo" della cpu che ha originariamente inviato la richiesta. Per alcuni carichi di lavoro ciò fornisce una riduzione significativa dei cicli della CPU a causa degli effetti della cache.
Per le configurazioni di archiviazione che devono massimizzare la distribuzione dell'elaborazione del completamento impostando questa opzione su '2' impone l'esecuzione del completamento sulla CPU richiedente (ignorando la logica di aggregazione "gruppo") "

scheduler = hai detto che hai provato scadenza e noop. Ho provato sia Noop che la scadenza, ma ho scoperto che la scadenza è vincente per i test che ho fatto più recentemente per un server di database.

NOOP ha funzionato bene, ma per il nostro server di database sono stato ancora in grado di ottenere prestazioni migliori regolando lo scadenzario.

Opzioni per lo scheduler delle scadenze situato in / sys / block / {sd, cciss, dm -} * / queue / iosched /:

fifo_batch = tipo di nr_requests simili, ma specifico per lo scheduler. La regola empirica viene regolata verso il basso per una latenza inferiore o verso l'alto per la velocità effettiva. Controlla la dimensione batch delle richieste di lettura e scrittura.

write_expire = imposta il tempo di scadenza per l'impostazione predefinita dei batch di scrittura è 5000ms. Ancora una volta, questo valore diminuisce la latenza di scrittura mentre aumenta il valore aumenta la velocità effettiva.

read_expire = imposta il tempo di scadenza per i lotti letti di default è 500ms. Le stesse regole si applicano qui.

front_merges = Tendo a disattivarlo ed è attivo per impostazione predefinita. Non vedo la necessità che lo scheduler sprechi i cicli della cpu cercando di fronteggiare l'unione delle richieste IO.

writes_starved = poiché la scadenza è orientata alle letture, l'impostazione predefinita qui è l'elaborazione di 2 batch di lettura prima che un batch di scrittura venga elaborato. Ho trovato che il valore predefinito 2 è buono per il mio carico di lavoro.

Più di ogni altra cosa, tutto dipende dal carico di lavoro.

read_ahead_kbpuò aiutarti se è davvero utile leggere molti dati da alcuni file in anticipo, come durante lo streaming di video. A volte può ferirti gravemente. Sì, i 128 KB predefiniti possono sembrare piccoli, ma con sufficiente concorrenza inizia a sembrare grande! D'altra parte, con un server come un server di codifica video che converte solo i video da un formato all'altro, potrebbe essere una buona idea sintonizzarsi.

nr_requests, se sovraccaricato, può facilmente inondare il controller RAID, danneggiando di nuovo le prestazioni.

Nel mondo reale, devi guardare le latenze . Se si è connessi a SAN, dare un'occhiata con iostat, saro qualsiasi altra cosa si desidera utilizzare, e vedere se i tempi di richiesta di I / O di servizio sono attraverso il tetto. Naturalmente questo aiuta anche con i dischi locali: se le latenze sono molto grandi, prendi in considerazione la possibilità di ottimizzare le impostazioni dell'elevatore I / O declassando max_requests e altre impostazioni.

Cordiali saluti read_ahead_kbe blockdev --setrasono solo modi diversi di impostare la stessa impostazione utilizzando unità diverse (kB vs settori):

foo:~# blockdev --setra 65536 /dev/cciss/c0d0
foo:~# blockdev --getra /dev/cciss/c0d0
65536
foo:~# cat /sys/block/cciss\!c0d0/queue/read_ahead_kb
32768
foo:~# echo 2048 > /sys/block/cciss\!c0d0/queue/read_ahead_kb
foo:~# cat /sys/block/cciss\!c0d0/queue/read_ahead_kb
2048
foo:~# blockdev --getra /dev/cciss/c0d0
4096

Così la

blockdev --setra 65536 /dev/cciss/c0d0

nel tuo esempio non ha alcun effetto.