Linux – tuning del controller RAID dell'hardware reale (scsi e cciss)

La maggior parte dei sisthemes Linux gestisco i controller hardware RAID (soprattutto HP Smart Array ). Sono tutti in esecuzione RHEL o CentOS.

Sto cercando accordi reali per ottimizzare le performance per le configurazioni che incorporano controller RAID hardware con dischi SAS (Smart Array, Perc, LSI, ecc.) E cache supportte da batterie o flash. Assumi RAID 1 + 0 e più mandrini (4 dischi).

Spendo una considerevole quantità di tempo per sintonizzare le impostazioni di networking di Linux per applicazioni a bassa latenza e trading finanziario. Ma molte di queste opzioni sono ben documentate (cambiando buffer di invio / ricezione, modificando le impostazioni della window TCP, ecc.). Che cosa fanno gli ingegneri sul lato dello storage?

Storicamente, ho apportto modifiche all'ascensore di pianificazione di I / O , recentemente optando per la deadline e i pianificatori noop per migliorare le performance nelle mie applicazioni. Poiché le versioni di RHEL sono avanzate, ho anche notato che le impostazioni predefinite compilate per i dispositivi di block SCSI e CCISS sono anche cambiate. Questo ha avuto un impatto sulle impostazioni consigliate del sottosistema di archiviazione nel tempo. Tuttavia, è stato un po 'da quando ho visto chiare raccomandazioni. E so che i valori predefiniti di sistema non sono ottimali. Ad esempio, sembra che il buffer di lettura predefinito di 128kb è estremamente ridotto per una distribuzione nell'hardware della class server.

Gli articoli seguenti esplorano l'impatto delle performance di modifica dei valori di cache read-ahead ei nr_requests sulle code di block.

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

Ad esempio, queste sono le modifiche proposte per un controller RAID Smart Array RAW:

 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 

Che altro può essere sintonizzato in modo affidabile per migliorare le performance di archiviazione?
Sto specificamente cercando le opzioni sysctl e sysfs in scenari di produzione.

  • Quale sistema di file distribuito come backend per cloud computing?
  • Come sono montati i canvasi di fibra ottica e attraversano un tessuto?
  • Identificare i dischi sul server SuperMicro in esecuzione FreeBSD
  • Memorizzazione per la virtualizzazione KVM
  • Qual è il caso d'uso per NAS su un arrays di storage a metà alto?
  • La soluzione di storage protetta è stata ricercata
  • Come posso misurare l'attività complessiva di I / O per sviluppare un benchmark realistico?
  • Massima produttività SAS di un disco stack?
  • 3 Solutions collect form web for “Linux – tuning del controller RAID dell'hardware reale (scsi e cciss)”

    Ho scoperto che quando ho dovuto sintonizzare per la latenza più bassa e il throughput, ho sintonizzato nr_requests dal suo default (fino a 32). L'idea di essere più piccoli è uguale a latenza più bassa.

    Anche per read_ahead_kb ho scoperto che per le letture / scritture sequenziali, aumentando questo valore offre una migliore produttività, ma ho scoperto che questa opzione dipende in realtà dal carico di lavoro e dal pattern di IO. Ad esempio su un sistema di database che ho sintonizzato di recente ho modificato questo valore per corrispondere a una singola dimensione di pagina db che ha contribuito a ridurre la latenza di lettura. Aumentare o diminuire al di là di questo valore ha dimostrato di danneggiare le performance nel mio caso.

    Per quanto riguarda altre opzioni o impostazioni per le code di dispositivi di block:

    max_sectors_kb = Ho impostato questo valore per corrispondere a quello che l'hardware consente per un singolo trasferimento (controlla il valore del file max_hw_sectors_kb (RO) in sysfs per vedere che cosa è consentito)

    nomerges = questo consente di distriggersre o regolare la logica di ricerca per la fusione di richieste io. (distriggersndo questo potresti risparmiare alcuni loops di CPU, ma non ho avuto alcun vantaggio quando lo cambio per i miei sisthemes, quindi l'ho lasciato predefinito)

    rq_affinity = Non ho ancora provato questo, ma qui è la spiegazione dietro esso dai documenti del kernel

    Se questa opzione è '1', lo strato di block migrerà i completamenti di richiesta al gruppo "CPU" che in origine ha inviato la richiesta. Per alcuni carichi di lavoro ciò consente una riduzione significativa dei loops della CPU a causa degli effetti di memorizzazione nella cache.
    Per le configurazioni di archiviazione che necessitano di massimizzare la distribuzione del process di completamento impostando questa opzione a '2', il completamento di eseguire sulla CPU richiedente (bypassando la logica di aggregazione "gruppo") "

    scheduler = hai detto che hai provato la scadenza e il noop. Ho testato sia il noop e la scadenza, ma ho scoperto che la scadenza è stata vinta per i test che ho fatto più di recente per un server di database.

    NOOP ha eseguito bene, ma per il nostro server di database sono ancora in grado di get migliori performance di adeguamento dello scheduler di scadenza.

    Opzioni per il scheduler di scadenza situato sotto / sys / block / {sd, cciss, dm -} * / coda / iosched /:

    fifo_batch = genere di come nr_requests, ma specifico dello scheduler. La regola del pollice è sintonizzata per una latenza inferiore o superiore per il throughput. Controlla la dimensione del lotto delle richieste di lettura e scrittura.

    write_expire = imposta il tempo di scadenza per i batch di scrittura predefiniti è 5000ms. Ancora una volta diminuisci questo valore diminuisce la latenza di scrittura mentre aumenta il valore aumenta il throughput.

    read_expire = imposta il tempo di scadenza per i batch di lettura predefiniti è 500ms. Le stesse regole si applicano qui.

    front_merges = Ho tendenza a distriggersre questa function ed è acceso per impostazione predefinita. Non vedo la necessità che lo scheduler rifiuti i loops di CPU che cercano di fare fronte alle richieste IO.

    writes_starved = dal momento che la scadenza è orientata a leggere l'impostazione predefinita qui è quello di elaborare due batch di lettura prima di elaborare un batch di scrittura. Ho trovato il valore predefinito di 2 per essere buono per il mio carico di lavoro.

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

    read_ahead_kb può aiutarti se è molto utile leggere un sacco di dati da alcuni file in anticipo, come quando si effettua lo streaming di video. A volte può danneggiare male. Sì, il 128 KB di default può suonare come piccolo, ma con abbastanza concorrenza inizia a suonare come 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 per sintonizzarsi.

    nr_requests , quando sovrastato, può facilmente inondare il controller RAID, che nuoce nuovamente le performance.

    Nel mondo reale, devi guardare le latenze . Se sei collegato a SAN, iostat un'occhiata con iostat , sar o qualunque cosa desideri utilizzare e vedere se i tempi di assistenza I / O richiedono attraverso il tetto. Ovviamente questo aiuta anche con i dischi locali: se le latenze sono molto grandi, consideri l'aggiustamento delle impostazioni dell'ascensore I / O riducendo max_request e altre impostazioni.

    FYI read_ahead_kb e blockdev --setra sono solo modi diversi per 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ì il

     blockdev --setra 65536 /dev/cciss/c0d0 

    nel tuo esempio non ha alcun effetto.

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