Configuración de Readahead para LVM, Device-Mapper, Software Raid y Block Devices: ¿qué gana?


26

He estado tratando de encontrar una respuesta directa a esta, y ha resultado difícil de alcanzar. Esta pregunta y su respuesta están cercanas, pero en realidad no me dan los detalles que me gustaría. Comencemos con lo que creo que sé.

Si tiene un dispositivo de bloqueo estándar y lo ejecuta sudo blockdev --report, obtendrá algo como esto:

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

Ahora, decide cambiar ese valor predeterminado de 256 a 128 usando --setracualquiera de las particiones y le sucede a todo el dispositivo de bloque, así:

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

Esto tiene mucho sentido para mí: el dispositivo de nivel de bloque es donde está la configuración, no la partición, por lo que todo cambia. También la relación predeterminada entre la configuración de RA y el dispositivo tiene sentido para mí, generalmente es:

RA * sector size (default = 512 bytes)

Por lo tanto, los cambios que realicé anteriormente, con el tamaño de sector predeterminado, bajarán de 128k a 64k. Todo bien y bien hasta ahora.

Sin embargo, ¿qué sucede cuando agregamos un RAID de software, o LVM y un mapeador de dispositivos? Imagine que su informe se ve así en su lugar:

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

En este caso, tenemos un dispositivo LVM dm-0 mapeado por dispositivo encima del md0 creado por mdadm, que de hecho es una banda RAID0 en los cuatro dispositivos xvdg-j.

Tanto el md0 como el dm-0 tienen configuraciones de 4096 para RA, mucho más altas que los dispositivos de bloque. Entonces, algunas preguntas aquí:

  • ¿Cómo se pasa la configuración RA por la cadena de dispositivos de bloque virtual?
  • ¿Dm-0 triunfa todo porque ese es el dispositivo de bloqueo de nivel superior al que realmente está accediendo?
  • ¿Tendría lvchange -run impacto en el dispositivo dm-0 y no aparecería aquí?

Si es tan simple como, la configuración de RA del dispositivo de bloque virtual que está utilizando se pasa, ¿eso significa que una lectura de dm-0 (o md0) se traducirá en 4 x 4096 lecturas de RA? (uno en cada dispositivo de bloque). Si es así, eso significaría que esta configuración explota el tamaño del encabezado en el escenario anterior.

Luego, en términos de averiguar qué está haciendo realmente la configuración de readahead:

¿Qué utiliza, equivalente al tamaño del sector anterior para determinar el valor real de lectura para un dispositivo virtual:

  • ¿El tamaño de la banda del RAID (para md0)?
  • ¿Algún otro equivalente de tamaño de sector?
  • ¿Es configurable y cómo?
  • ¿El FS juega un papel (estoy principalmente interesado en ext4 y XFS)?
  • O, si simplemente se pasa, ¿es simplemente la configuración RA del dispositivo de nivel superior multiplicada por el tamaño del sector de los dispositivos de bloque real?

Finalmente, ¿habría alguna relación preferida entre el tamaño de banda y la configuración de RA (por ejemplo)? Aquí estoy pensando que si la franja es el elemento más pequeño que se va a extraer del dispositivo RAID, lo ideal sería no tener que tener 2 accesos de disco para dar servicio a esa unidad mínima de datos y desearía hacer el RA Suficientemente grande para cumplir la solicitud con un solo acceso.


¿Qué distribución de Linux estás usando? ¿Estás utilizando una redada de hardware o software? Parece un software. Si es hardware, ¿qué tarjeta / chipset está utilizando? Gran parte de esto está configurado y almacenado en el firmware del dispositivo.
Jason Huntley

Además, la configuración de RA depende en gran medida del esquema de asignación de su sistema de archivos. ¿Estás usando ext4?
Jason Huntley

De hecho, menciono que es RAID de software y LVM en la pregunta, así que sí, software. En términos del sistema de archivos, me interesaría la diferencia entre XFS y ext4 aquí, aunque las respuestas para cualquiera serían buenas
Adam C

XFS se puede ajustar mucho para un mejor rendimiento. Eso está cubierto en algunos lugares de este sitio: aquí y aquí ... ¿Qué distribución de Linux está utilizando? Eso juega un factor importante porque también hay algunas herramientas específicas de distribución disponibles.
ewwhite

Esta no es una pregunta de rendimiento, es más específica: solo quiero saber sobre la configuración de RA y cómo se traducen / interactúan con las capas LVM / RAID de software
Adam C

Respuestas:


11

¿Cómo se pasa la configuración RA por la cadena de dispositivos de bloque virtual?

Depende. Supongamos que está dentro de Xen domU y tiene RA = 256. Su / dev / xvda1 es LV real en el dom0 visible bajo / dev / dm1. Entonces tienes RA (domU (/ dev / xvda1)) = 256 y RA (dom0 (/ dev / dm1)) = 512. Tendrá tal efecto que el núcleo dom0 accederá / dev / dm1 con otro RA que no sea el núcleo domU. Simple como eso.

Se producirá otra situación si asumimos la posición / 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

Configurar / dev / md0 RA no afectará a / dev / sdX blockdevices.

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

Por lo tanto, en mi opinión, el kernel accede al dispositivo de bloque de la manera que realmente se establece. Se puede acceder a un volumen lógico a través de RAID (del que forma parte) o dispositivo devicemapper y cada uno con otro RA que será respetado.

Entonces, la respuesta es: la configuración RA es en mi humilde opinión, no se pasa por la cadena de dispositivos de bloque, pero cualquiera que sea la configuración RA del dispositivo de nivel superior, se utilizará para acceder a los dispositivos constituyentes

¿Dm-0 triunfa todo porque ese es el dispositivo de bloqueo de nivel superior al que realmente está accediendo?

Si te refieres a la propagación profunda por "triunfar sobre todo", según mi comentario anterior, creo que puedes tener diferentes RA para diferentes dispositivos en el sistema.

¿Tendría lvchange -r un impacto en el dispositivo dm-0 y no aparecería aquí?

Sí, pero este es un caso particular. Supongamos que tenemos / dev / dm0, que es / dev / vg0 / blockdevice de LVM. Si lo haces:

lvchange -r 512 /dev/vg0/blockdevice

/ dev / dm0 también cambiará porque / dev / dm0 y / dev / vg0 / blockdevice es exactamente el mismo dispositivo de bloque cuando se trata de acceso al kernel.

Pero supongamos que / dev / vg0 / blockdevice es lo mismo que / dev / dm0 y / dev / xvda1 en Xen domU que lo está utilizando. Establecer el RA de / dev / xvda1 tendrá efecto pero dom0 verá que todavía tiene su propio RA.

¿Qué utiliza, equivalente al tamaño del sector anterior para determinar el valor real de lectura para un dispositivo virtual:

Normalmente descubro RA experimentando con diferentes valores y probándolo con hdparm.

¿El tamaño de la banda del RAID (para md0)?

Lo mismo que arriba.

¿El FS juega un papel (estoy principalmente interesado en ext4 y XFS)?

Claro, este es un tema muy grande. Te recomiendo que comiences aquí http://archives.postgresql.org/pgsql-performance/2008-09/msg00141.php


Esto está muy cerca de lo que estoy buscando y de lo que sospeché: ¿puede aclararme una cosa: en la situación / dev / md0 (/ dev / sda1, / dev / sda2) sé que puede configurar valores RA separados, pero si usted dice mount / data en / dev / md0 y lee un archivo de él, ¿se usa el 512 RA para leer desde / dev / sda1 y / dev / sda2 (es decir, 512 se usa para ambos) o ¿se usa 256 en cada uno? Si lo primero parece prudente tener RAID0 RA configurado en: SUMA (RA de dispositivos en RAID0)
Adam C

1
Según mi experiencia, configurar RA = 512 en / dev / md0 con discos / dev / sdX debajo, actúa exactamente igual que tuvimos acceso a / dev / sdX con RA = 512 a pesar de que, por ejemplo, podemos tener RA = 256 ajuste en el dispositivo de bloque inferior. La configuración 256 se ignorará en este caso (tenga en cuenta que / dev / sda es inútil como un dispositivo de bloque si es parte de / dev / md0). No soy un programador de kernel, pero esto parece lógico y parece ser confirmado por mi práctica. Tan reafirmante. 3 hilos leyendo desde / dev / md0, RA = 512 igual a 3 hilos leyendo desde / dev / sd {a, b, c} con RA = 512.
wojciechz

¡Muchas gracias! He editado un poco las cosas para aclararlo en la respuesta. ¿Puedo preguntar una cosa más antes de aceptar? ¿Tiene un ejemplo (o enlace a uno) para usar hdparm para probar RA? Yo iba a hacer algo similar, así que si hay una buena referencia, me ahorraría tiempo.
Adam C

No es complicado, pero depende de lo que quieras verificar. Consulte el manual de hdparm. Si desea verificar las lecturas de disco (que es un derivado de readahead) puede emitir un comando como hdparm -t / dev / md0 . El resultado mostrará algo así como Lecturas de disco almacenadas temporalmente: 310 MB en 3.02 segundos = 102.79 MB / seg . El último valor suele verse muy afectado por la configuración de RA.
wojciechz

1
ah, entonces no es una medida directa - entendido, aceptando ahora - gracias por la ayuda :)
Adam C

4

Conozca la respuesta más difícil de explicar, así que lo haré, por ejemplo. Supongamos que tiene 3 dispositivos de bloque y configura su RA para decir 4 (4 * 512 bytes) suponiendo un sector estándar. Si tuviera que usar un esquema RAID-5 usando los 3 discos, cualquier lectura que incluso tocara una banda en un disco único agravaría el RA por el factor que inicialmente configuró para bloquear el RA del dispositivo. Entonces, si su lectura abarcó exactamente los 3 discos, su RA efectiva sería 12 * 512 byte. Esto puede agravarse mediante la configuración de RA en los distintos niveles, por ejemplo, MD o LVM. Como regla general, si mi aplicación se beneficia de RA, la configuro en la capa más alta posible para que no componga la RA innecesariamente. Luego inicio el sistema de archivos en el sector 2049 y compenso cada inicio de sector en un número divisible por 8. Puede que esté muy lejos de lo que está preguntando, pero este es mi 2 ¢.


Entonces, estás diciendo que cualquiera que sea la configuración RA en el dispositivo de nivel superior, simplemente se transmitirá. Por lo tanto, si usó LVM -> 2 x RAID -> 4 x disco físico cada uno y tuvo un RA de 4, entonces debido a que hay 8 dispositivos físicos, terminará con un RA efectivo de 32. ¿Cómo ajustaría el El tamaño del fragmento / franja del RAID será eficiente en ese escenario: ¿supongo que desea que el RA cubra una franja completa para que no tenga que acceder dos veces?
Adam C

Por cierto, si estoy haciendo esto bien, en el escenario que describo, creo que me gustaría tener el fragmento / banda del RAID0 configurado en X, donde X = RA * 512bytes. Por lo tanto, si tengo un fragmento / banda de 64k (el valor predeterminado de mdadm), entonces la RA mínima que debo usar es 128 porque eso me da la banda completa de una sola vez.
Adam C

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.