Hyper-V.
Verificación de la alineación de WAFL para bases de datos de Oracle
Sugerir cambios
PDF
La correcta alineación de WAFL es fundamental para un buen rendimiento. Aunque ONTAP gestiona bloques en 4KB unidades, este hecho no significa que ONTAP realice todas las operaciones en 4KB unidades. De hecho, ONTAP admite operaciones de bloque de diferentes tamaños, pero la contabilidad subyacente es administrada por WAFL en 4KB unidades.
El término “alineación” se refiere a cómo Oracle I/O corresponde a estas 4KB unidades. Para obtener un rendimiento óptimo, el bloque de 8KB KB de Oracle debe residir en dos bloques físicos de 4KB WAFL en una unidad. Si un bloque se equipara con 2KB, este bloque reside en la mitad de un bloque de 4KB KB, un 4KB bloque completo independiente y, a continuación, la mitad de un tercer bloque de 4KB KB. Esta disposición provoca una degradación del rendimiento.
La alineación no es un problema en los sistemas de archivos NAS. Los archivos de datos de Oracle se alinean con el inicio del archivo en función del tamaño del bloque de Oracle. Por lo tanto, los tamaños de bloque de 8KB, 16KB y 32KB se alinean siempre. Todas las operaciones de bloque se desplazan desde el inicio del archivo en unidades de 4 kilobytes.
Por el contrario, los LUN suelen contener algún tipo de encabezado de controlador o metadatos del sistema de archivos en su inicio que crea una desviación. La alineación rara vez es un problema en los sistemas operativos modernos, ya que estos sistemas operativos están diseñados para unidades físicas que podrían utilizar un sector nativo de 4KB, que también requiere que la E/S se alinee con los límites de 4KB para un rendimiento óptimo.
Sin embargo, hay algunas excepciones. Es posible que una base de datos se haya migrado desde un SO antiguo que no estaba optimizado para 4KB E/S, o que se haya producido un error de usuario durante la creación de la partición que podría haber producido un desplazamiento que no está en unidades de 4KB GB de tamaño.
Los siguientes ejemplos son específicos de Linux, pero el procedimiento se puede adaptar para cualquier sistema operativo.
Alineado
El siguiente ejemplo muestra una comprobación de alineación en una sola LUN con una partición única.
En primer lugar, cree la partición que utiliza todas las particiones disponibles en la unidad.
[root@host0 iscsi]# fdisk /dev/sdb
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0xb97f94c1.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.
The device presents a logical sector size that is smaller than
the physical sector size. Aligning to a physical sector (or optimal
I/O) size boundary is recommended, or performance may be impacted.
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-10240, default 1):
Using default value 1
Last cylinder, +cylinders or +size{K,M,G} (1-10240, default 10240):
Using default value 10240
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
[root@host0 iscsi]#
La alineación se puede comprobar matemáticamente con el siguiente comando:
[root@host0 iscsi]# fdisk -u -l /dev/sdb Disk /dev/sdb: 10.7 GB, 10737418240 bytes 64 heads, 32 sectors/track, 10240 cylinders, total 20971520 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 65536 bytes Disk identifier: 0xb97f94c1 Device Boot Start End Blocks Id System /dev/sdb1 32 20971519 10485744 83 Linux
La salida muestra que las unidades son de 512 bytes, y el inicio de la partición es de 32 unidades. Esto es un total de 32 x 512 = 16.834 bytes, que es un múltiplo completo de bloques de 4KB WAFL. Esta partición está correctamente alineada.
Para verificar la alineación correcta, lleve a cabo los siguientes pasos:
-
Identifique el identificador único universal (UUID) de la LUN.
FAS8040SAP::> lun show -v /vol/jfs_luns/lun0 Vserver Name: jfs LUN UUID: ed95d953-1560-4f74-9006-85b352f58fcd Mapped: mapped` ` -
Introduzca el shell del nodo en la controladora ONTAP.
FAS8040SAP::> node run -node FAS8040SAP-02 Type 'exit' or 'Ctrl-D' to return to the CLI FAS8040SAP-02> set advanced set not found. Type '?' for a list of commands FAS8040SAP-02> priv set advanced Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel. -
Inicie recopilaciones estadísticas en el UUID de destino identificado en el primer paso.
FAS8040SAP-02*> stats start lun:ed95d953-1560-4f74-9006-85b352f58fcd Stats identifier name is 'Ind0xffffff08b9536188' FAS8040SAP-02*>
-
Realice algunas operaciones de I/O. Es importante utilizar el
iflagArgumento para asegurarse de que la E/S es síncrona y no se almacena en búfer.
Tenga mucho cuidado con este comando. Inversión del ify..oflos argumentos destruyen los datos.[root@host0 iscsi]# dd if=/dev/sdb1 of=/dev/null iflag=dsync count=1000 bs=4096 1000+0 records in 1000+0 records out 4096000 bytes (4.1 MB) copied, 0.0186706 s, 219 MB/s
-
Detenga las estadísticas y visualice el histograma de alineación. Todas las operaciones de I/O deben estar en la
.0Bucket, que indica las I/O alineadas con un límite de bloque de 4KB KB.FAS8040SAP-02*> stats stop StatisticsID: Ind0xffffff08b9536188 lun:ed95d953-1560-4f74-9006-85b352f58fcd:instance_uuid:ed95d953-1560-4f74-9006-85b352f58fcd lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.0:186% lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.1:0% lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.2:0% lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.3:0% lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.4:0% lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.5:0% lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.6:0% lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.7:0%
Mal alineado
En el siguiente ejemplo, se muestran operaciones de I/O mal alineadas:
-
Cree una partición que no se alinee con un límite 4KB. Este no es el comportamiento predeterminado en los sistemas operativos modernos.
[root@host0 iscsi]# fdisk -u /dev/sdb Command (m for help): n Command action e extended p primary partition (1-4) p Partition number (1-4): 1 First sector (32-20971519, default 32): 33 Last sector, +sectors or +size{K,M,G} (33-20971519, default 20971519): Using default value 20971519 Command (m for help): w The partition table has been altered! Calling ioctl() to re-read partition table. Syncing disks. -
La partición se ha creado con un desplazamiento de 33 sectores en lugar del 32 por defecto. Repita el procedimiento descrito en "Alineado". El histograma aparece de la siguiente manera:
FAS8040SAP-02*> stats stop StatisticsID: Ind0xffffff0468242e78 lun:ed95d953-1560-4f74-9006-85b352f58fcd:instance_uuid:ed95d953-1560-4f74-9006-85b352f58fcd lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.0:0% lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.1:136% lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.2:4% lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.3:0% lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.4:0% lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.5:0% lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.6:0% lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.7:0% lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_partial_blocks:31%
La desalineación es clara. La E/S cae principalmente en el* *
.1período, que coincide con el desplazamiento esperado. Cuando se creó la partición, se movió 512 bytes más al dispositivo que el valor predeterminado optimizado, lo que significa que el histograma está compensado en 512 bytes.Además, el
read_partial_blocksLa estadística es diferente de cero, lo que significa que se han realizado I/O que no han llenado todo un bloque de 4KB KB.
Registro de repetición
Los procedimientos que se explican aquí son aplicables a los archivos de datos. Los redo logs y archive logs de Oracle tienen patrones de E/S diferentes. Por ejemplo, redo log es una sobrescritura circular de un único archivo. Si se utiliza el tamaño predeterminado de bloque de 512 bytes, las estadísticas de escritura se ven algo así:
FAS8040SAP-02*> stats stop StatisticsID: Ind0xffffff0468242e78 lun:ed95d953-1560-4f74-9006-85b352f58fcd:instance_uuid:ed95d953-1560-4f74-9006-85b352f58fcd lun:ed95d953-1560-4f74-9006-85b352f58fcd:write_align_histo.0:12% lun:ed95d953-1560-4f74-9006-85b352f58fcd:write_align_histo.1:8% lun:ed95d953-1560-4f74-9006-85b352f58fcd:write_align_histo.2:4% lun:ed95d953-1560-4f74-9006-85b352f58fcd:write_align_histo.3:10% lun:ed95d953-1560-4f74-9006-85b352f58fcd:write_align_histo.4:13% lun:ed95d953-1560-4f74-9006-85b352f58fcd:write_align_histo.5:6% lun:ed95d953-1560-4f74-9006-85b352f58fcd:write_align_histo.6:8% lun:ed95d953-1560-4f74-9006-85b352f58fcd:write_align_histo.7:10% lun:ed95d953-1560-4f74-9006-85b352f58fcd:write_partial_blocks:85%
La E/S se distribuiría en todos los bloques de histograma, pero esto no supone un problema de rendimiento. Sin embargo, las tasas de redo-log extremadamente altas podrían beneficiarse del uso de un tamaño de bloque de 4KB KB. En este caso, es conveniente asegurarse de que los LUN de redo registro están alineados correctamente. Sin embargo, esto no es tan importante para un buen rendimiento como la alineación de archivos de datos.