Impostazioni Readahead per LVM, Device-Mapper, Software Raid e Block Devices: cosa vince?


26

Ho cercato di trovare una risposta diretta su questo, e si è rivelato sfuggente. Questa domanda e la sua risposta sono vicine, ma in realtà non mi danno le specifiche che vorrei. Cominciamo con quello che penso di sapere.

Se hai un dispositivo a blocchi standard e corri sudo blockdev --reportotterrai qualcosa del genere:

RO    RA   SSZ   BSZ   StartSec            Size   Device
rw   256   512  4096          0    500107862016   /dev/sda
rw   256   512  4096       2048    399999238144   /dev/sda1
rw   256   512  1024  781252606            1024   /dev/sda2

Ora, decidi di cambiare i 256 a 128 predefiniti usando --setrasu una qualsiasi delle partizioni e succede all'intero dispositivo a blocchi, in questo modo:

sudo blockdev --setra 128 /dev/sda1
sudo blockdev --report
RO    RA   SSZ   BSZ   StartSec            Size   Device
rw   128   512  4096          0    500107862016   /dev/sda
rw   128   512  4096       2048    399999238144   /dev/sda1
rw   128   512  1024  781252606            1024   /dev/sda2

Questo ha perfettamente senso per me: il dispositivo a livello di blocco è dove si trova l'impostazione, non la partizione, quindi tutto cambia. Anche la relazione predefinita tra l'impostazione RA e il dispositivo ha senso per me, in genere è:

RA * sector size (default = 512 bytes)

Quindi, le modifiche che ho apportato sopra, con la dimensione del settore predefinito, faranno scendere la lettura da 128k a 64k. Finora tutto bene.

Tuttavia, cosa succede quando si aggiunge un RAID software o LVM e Device Mapper? Immagina invece che il tuo rapporto assomigli a questo:

RO    RA   SSZ   BSZ   StartSec            Size   Device
rw   256   512  4096          0     10737418240   /dev/xvda1
rw   256   512  4096          0    901875499008   /dev/xvdb
rw   256   512  4096          0    108447924224   /dev/xvdj
rw   256   512  4096          0    108447924224   /dev/xvdi
rw   256   512  4096          0    108447924224   /dev/xvdh
rw   256   512  4096          0    108447924224   /dev/xvdg
rw  4096   512  4096          0    433787502592   /dev/md0
rw  4096   512   512          0    429496729600   /dev/dm-0

In questo caso abbiamo un dispositivo LVM dm-0 mappato sul dispositivo in cima al md0 creato da mdadm, che in realtà è una striscia RAID0 attraverso i quattro dispositivi xvdg-j.

Sia md0 che dm-0 hanno impostazioni di 4096 per RA, molto più alte dei dispositivi a blocchi. Quindi, alcune domande qui:

  • In che modo l'impostazione RA viene trasmessa lungo la catena di dispositivi a blocco virtuale?
  • Dm-0 vince su tutto perché quello è il dispositivo di blocco di livello superiore a cui stai effettivamente accedendo?
  • Avrebbe lvchange -run impatto sul dispositivo dm-0 e non verrà visualizzato qui?

Se è semplice come, l'impostazione RA dal dispositivo a blocchi virtuale in uso viene trasmessa, significa che una lettura da dm-0 (o md0) si tradurrà in 4 letture RA 4096? (uno su ciascun dispositivo a blocchi). In tal caso, ciò significherebbe che queste impostazioni esplodono le dimensioni del readahead nello scenario sopra.

Quindi, in termini di capire cosa sta effettivamente facendo l'impostazione readahead:

Cosa usi, equivalente alla dimensione del settore sopra per determinare il valore di lettura reale per un dispositivo virtuale:

  • La dimensione di striping del RAID (per md0)?
  • Qualche equivalente in altre dimensioni del settore?
  • È configurabile e come?
  • L'FS ha un ruolo (sono principalmente interessato a ext4 e XFS)?
  • Oppure, se viene appena trasmesso, è semplicemente l'impostazione RA dal dispositivo di livello superiore moltiplicata per la dimensione del settore dei dispositivi a blocchi reali?

Infine, ci sarebbe una relazione preferita tra la dimensione della striscia e l'impostazione RA (per esempio)? Qui sto pensando che se la striscia è l'elemento più piccolo che verrà rimosso dal dispositivo RAID, idealmente non vorresti che ci fossero 2 accessi al disco per servire quell'unità minima di dati e vorresti creare l'AR abbastanza grande da soddisfare la richiesta con un unico accesso.


Quale distribuzione Linux stai usando? Stai usando un raid hardware o software? Sembra un software. Se l'hardware, quale scheda / chipset stai utilizzando, viene impostato e memorizzato nel firmware del dispositivo.
Jason Huntley il

Inoltre, le impostazioni RA dipendono molto dallo schema di allocazione del filesystem. Stai usando ext4?
Jason Huntley il

In realtà ho detto che è il software RAID e LVM nella domanda, quindi sì - il software. In termini di filesystem, sarei interessato alla differenza tra XFS ed ext4 qui, le risposte per entrambi sarebbero buone però
Adam C

XFS può essere ottimizzato pesantemente per prestazioni migliori. Questo è trattato in alcuni punti di questo sito: qui e qui ... Quale distribuzione di Linux stai usando? Questo gioca un ruolo perché ci sono anche alcuni strumenti specifici per la distribuzione disponibili.
ewwhite,

Questa non è una domanda di prestazione, è più specifica - Voglio solo conoscere le impostazioni RA e come traducono / interagiscono con i livelli RAID LVM / Software
Adam C

Risposte:


11

In che modo l'impostazione RA viene trasmessa lungo la catena di dispositivi a blocco virtuale?

Dipende. Supponiamo che tu sia dentro Xen domU e abbia RA = 256. Il tuo / dev / xvda1 è LV reale sul dom0 visibile sotto / dev / dm1. Quindi hai RA (domU (/ dev / xvda1)) = 256 e RA (dom0 (/ dev / dm1)) = 512. Avrà un tale effetto che il kernel dom0 accederà a / dev / dm1 con un altro RA rispetto al kernel di domU. Semplice come quella.

Un'altra sittutazione si verificherà se assumiamo / sittuation / dev / md0 (/ dev / sda1, / dev / sda2).

blockdev --report | grep sda
rw   **512**   512  4096          0   1500301910016   /dev/sda
rw   **512**   512  4096       2048      1072693248   /dev/sda1
rw   **512**   512  4096    2097152   1499227750400   /dev/sda2
blockdev --setra 256 /dev/sda1
blockdev --report | grep sda
rw   **256**   512  4096          0   1500301910016   /dev/sda
rw   **256**   512  4096       2048      1072693248   /dev/sda1
rw   **256**   512  4096    2097152   1499227750400   /dev/sda2

L'impostazione di / dev / md0 RA non influisce sui dispositivi di blocco / dev / sdX.

rw   **256**   512  4096       2048      1072693248   /dev/sda1
rw   **256**   512  4096    2097152   1499227750400   /dev/sda2
rw   **512**   512  4096          0      1072627712   /dev/md0

Quindi generalmente secondo me il kernel accede a blockdevice nel modo che è effettivamente impostato. È possibile accedere a un volume logico tramite RAID (di cui fa parte) o dispositivo devicemapper e ciascuno con un altro RA che verrà rispettato.

Quindi la risposta è: l'impostazione RA è IMHO non trasmessa lungo la catena del dispositivo a blocchi, ma qualunque sia l'impostazione RA del dispositivo di livello superiore, verrà utilizzata per accedere ai dispositivi costituenti

Dm-0 vince su tutto perché quello è il dispositivo di blocco di livello superiore a cui stai effettivamente accedendo?

Se intendi una propagazione profonda per "trump all", come per il mio commento precedente, penso che potresti avere RA diversi per diversi dispositivi nel sistema.

Lvchange -r avrebbe un impatto sul dispositivo dm-0 e non verrebbe visualizzato qui?

Sì, ma questo è un caso particolare. Supponiamo di avere / dev / dm0 che è / dev / vg0 / blockdevice di LVM. Se fate:

lvchange -r 512 /dev/vg0/blockdevice

/ dev / dm0 cambierà anche perché / dev / dm0 e / dev / vg0 / blockdevice è esattamente lo stesso dispositivo a blocchi quando si tratta dell'accesso al kernel.

Ma supponiamo che / dev / vg0 / blockdevice sia uguale a / dev / dm0 e / dev / xvda1 in Xen domU che lo sta utilizzando. L'impostazione della RA di / dev / xvda1 avrà effetto ma dom0 vedrà che ha ancora la propria RA.

Cosa usi, equivalente alla dimensione del settore sopra per determinare il valore di lettura reale per un dispositivo virtuale:

In genere scopro RA sperimentando valori diversi e testandolo con hdparm.

La dimensione di striping del RAID (per md0)?

Come sopra.

L'FS ha un ruolo (sono principalmente interessato a ext4 e XFS)?

Certo, questo è un argomento molto grande. Vi consiglio di iniziare qui http://archives.postgresql.org/pgsql-performance/2008-09/msg00141.php


Questo è molto vicino a quello che sto cercando e a quello che sospettavo: puoi chiarire una cosa per me: nella situazione / dev / md0 (/ dev / sda1, / dev / sda2) so che puoi impostare valori RA separati, ma se dici, mount / data su / dev / md0 e leggi un file da esso - il 512 RA viene usato per leggere da / dev / sda1 e / dev / sda2 (cioè 512 usati per entrambi) o 256 sono usati su ciascuno? Se il primo sembrasse saggio avere RAID0 RA impostato su: SUM (RA dei dispositivi nel RAID0)
Adam C

1
Sto solo raccontando dalla mia esperienza: impostare RA = 512 su / dev / md0 con / dev / sdX su dischi, agisce esattamente come abbiamo avuto accesso a / dev / sdX con RA = 512 nonostante che per esempio possiamo avere RA = 256 impostazione sul dispositivo di blocco in basso. In questo caso l'impostazione 256 verrà ignorata (notare che / dev / sda è inutile come dispositivo a blocchi se fa parte di / dev / md0). Non sono un programmatore del kernel, ma questo sembra logico e sembra essere confermato dalla mia pratica. Così riassuntivo. 3 thread da / dev / md0, RA = 512 uguali a 3 thread da / dev / sd {a, b, c} con RA = 512.
Wojciechz,

Grazie mille! Ho modificato leggermente le cose per renderlo più chiaro nella risposta. Posso chiedere un'altra cosa prima di accettare? Hai un esempio (o un link a uno) per l'utilizzo di hdparm per testare RA? Stavo per fare qualcosa di simile da solo, quindi se c'è un buon riferimento mi farebbe risparmiare tempo.
Adamo C,

Non è complicato, ma dipende da cosa vuoi controllare. Fare riferimento al manuale di hdparm. Se vuoi controllare le letture del disco (che è una derivata di readahead) puoi emettere un comando come hdparm -t / dev / md0 . Il risultato mostrerà qualcosa come Timing letture su disco bufferizzate: 310 MB in 3,02 secondi = 102,79 MB / sec . L'ultimo valore è in genere fortemente influenzato dall'impostazione RA.
Wojciechz,

1
ah, quindi non una misurazione diretta - capito, accettando ora - grazie per l'aiuto :)
Adam C

4

Conosci la risposta più difficile da spiegare, quindi lo farò nell'esempio. Supponiamo che tu abbia 3 dispositivi a blocchi e imposti il ​​tuo RA per dire 4 (4 * 512 byte) assumendo un settore standard. Se dovessi dire di usare uno schema RAID-5 usando i 3 dischi, qualsiasi lettura che abbia persino toccato una striscia su un disco univoco aggraverebbe l'AR dal fattore su cui inizialmente hai impostato l'AR del dispositivo a blocchi. Quindi, se la tua lettura si estendesse esattamente su tutti e 3 i dischi, la tua RA effettiva sarebbe 12 * 512 byte. Questo può essere aggravato dalla settina RA nei vari livelli, ad esempio MD o LVM. Come regola generale, se la mia app beneficia di RA, la imposto sul livello più alto possibile, quindi non compongo inutilmente la RA. Quindi avvio il filesystem sul settore 2049 e compenso l'inizio di ogni settore su un numero divisibile per 8. Potrei essere molto diverso da quello che mi stai chiedendo, ma questo è il mio 2 ¢.


Quindi, stai dicendo che qualunque sia l'impostazione RA sul dispositivo di livello superiore, verrà semplicemente tramandata. Pertanto, se hai utilizzato LVM -> 2 x RAID -> 4 x dischi fisici ciascuno e hai avuto RA di 4, quindi poiché ci sono 8 dispositivi fisici, si ottiene un RA effettivo di 32. Come modificheresti il le dimensioni del blocco / stripe del RAID sono efficienti in quello scenario - suppongo che desideri che l'AR copra un'intera striscia in modo da non dover accedere due volte?
Adam C

A proposito, se sto andando bene, nello scenario che descrivo, penso che vorrei avere il blocco / stripe del RAID0 impostato su X, dove X = RA * 512bytes. Pertanto, se ho un pezzo / striscia di 64k (il valore predefinito di mdadm), allora RA minimo che dovrei usare è 128 perché questo mi dà l'intera striscia in un colpo solo.
Adam C

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.