Comprensión del tamaño de un bloque

Question

Mi pregunta se dirige a Postgres, pero las respuestas pueden ser lo suficientemente buenas provenientes de cualquier antecedentes de base de datos.

Son mis supuestos correctos:

• ¿Los discos tienen un tamaño de bloque fijo?
• ¿El controlador RAID puede tener un tamaño de bloque diferente? ¿Se divide un bloque RAID en múltiples bloques de disco real?
• El sistema de archivos también tiene un tamaño de bloque independiente que nuevamente se divide en el tamaño del bloque de redadas?
• Postgres funciona con bloques fijos de 8k. ¿Cómo ocurre la asignación al tamaño del bloque del sistema de archivos aquí? ¿El sistema de archivos se agrupa por el sistema de archivos de Postgres 8K?

Al configurar un sistema, ¿es mejor tener todos los bloques a 8K? ¿O no importa la configuración? También me preguntaba si algunas configuraciones de tamaño de bloque "incorrectas" podrían poner en peligro la integridad de los datos en caso de un bloqueo. ¿Quizás si un bloque Postgres 8K tiene que dividirse en múltiples bloques de disco?

¿O nada se combina y, por lo tanto, pierdo el espacio en el disco con cada desajuste entre los tamaños de bloque definidos?

Answer 1

Sectores de disco

Un disco tiene un tamaño de sector fijo, normalmente 512 bytes o 4096 bytes en algunos discos modernos; Estos discos también tendrán un modo en el que emulan los sectores de 512 bytes. El disco tendrá pistas con un número variable de sectores; Las pistas más cercanas al exterior del disco tienen más sectores, ya que tienen más espacio para una densidad de bits dada. Esto permite un uso más eficiente del espacio del disco; Por lo general, una pista tendrá algo como 1,000 sectores de 512 bytes en un disco moderno.

Algunas estructuras de formato también pueden incluir información de corrección de errores en los SECOTRS, que se manifiesta en los discos de bajo nivel formateado con sectores de 520 o 528 bytes. En este caso, el sector todavía tiene 512 bytes de datos del usuario. Ni Windows ni Linux admiten esto directamente, aunque I5Os (IBM Iseries) y varios controladores SAN sí lo hacen.

Normalmente, el sector/cabeza/pista se traduce en una dirección de bloque lógica; Debido a los problemas históricos con la compatibilidad hacia atrás, la geometría (pistas de los sectores X cabezales X) visto por el sistema operativo (particularmente en los discos IDE y SATA) normalmente tiene poco que ver con su estructura física.

Tamaño de rayas RAID

Un controlador RAID puede tener un tamaño de franja para una matriz utilizando rayas (por ejemplo, RAID-5 o RAID-10). Si la matriz tiene (para Exmaple) una franja de 128k, cada disco tiene 128k de datos contiguos, y luego el siguiente conjunto de datos está en el siguiente disco. Normalmente puede esperar obtener aproximadamente una franja por revolución del disco, por lo que el tamaño de la franja puede afectar el rendimiento en ciertas cargas de trabajo.

Alineación de la partición

Una partición de disco puede o no alinearse exactamente con una franja de incursión, y puede causar la degradación del rendimiento debido a las lecturas divididas si no está alineada. Algunos sistemas (por ejemplo, Windows 2008 Server) configurarán automáticamente particiones para alinearse con los tamaños de franjas de volumen de disco. Algunos (por ejemplo, Windows 2003 Server) no lo harán, y debe utilizar una utilidad de partición que admite la alineación de rayas para garantizar que lo hagan.

Tamaño del bloque del sistema de archivo

El sistema de archivos asignará bloques de almacenamiento en trozos de cierto tamaño. En general, esto es configurable, por ejemplo, NTFS admitirá unidades de asignación de (IIRC) 4K a 64K. La desalineación de las particiones y los bloques del sistema de archivos a las rayas RAID puede hacer que un solo bloque del sistema de archivos se lea para generar múltiples accesos de disco donde solo uno sería necesario si los bloqueos del sistema de archivos se alinearan correctamente con las rayas RAID.

Tamaño del bloque de la base de datos

La base de datos asignará espacio en una tabla o índice en algún tamaño de bloque dado. En el caso de SQL Server, esto es 8K, y 8K es el valor predeterminado en muchos sistemas. En algunos sistemas como Oracle, esto es configurable, y en PostgreSQL es una opción de tiempo de compilación. En la mayoría de los sistemas, la asignación de espacio a las tablas se realiza normalmente en trozos más grandes, con bloques asignados dentro de esos trozos.

La desalineación del sistema de archivos y los bloques de asignación de datos pueden generar múltiples E/S para una escritura de un solo bloque, lo que puede impulsar una penalización de rendimiento.

Corro de no

Normalmente, un DBMS hará su E/S en trozos de más de un bloque. Por ejemplo, en SQL Server, todas las E/S se realizan en trozos de 8 bloques, 64k en total). En Oracle esto es configurable. La inspección casual de los documentos de PostgreSQL no revela una descripción específica de si PostgreSQL hace esto, por lo que no estoy seguro de cómo funciona en esta plataforma.

Cuando el fragmento de E/S más grande que el tamaño del bloque del sistema de archivos o se desalinea con límites de rayas RAID, una escritura de disco desde el DB puede causar múltiples escrituras de disco, lo que genera una penalización de rendimiento.

Uso del espacio en disco

No se desperdicia espacio en el disco: las E/S de la base de datos utilizarán una o más operaciones de E/S físicas en el disco para completar, pero las E/S sintonizadas incorrectamente pueden generar ineficiencias que ralentizarán la base de datos. Las principales cosas que tienen que estar alineadas son:

• Rayas y particiones RAID: la partición debe comenzar en un límite de rayas de incursión.

• El sistema de archivos de E/S de asignación de E/S y límites de ripe/partición RAID: un límite de rayas RAID debe alinearse con una unidad de asignación del sistema de archivos, y debe ser un múltiplo del tamaño de la unidad de asignación del sistema de archivos.

• Tamaño de escritura de disco y tamaño de la unidad de asignación del sistema de archivos. Debe haber una relación 1: 1 entre las operaciones de E/S de la base de datos y las operaciones de E/S del sistema de archivos.

La desalineación no crea un mayor problema de integridad de datos de lo que de otro modo estaría presente. La base de datos y el sistema de archivos tienen mecanismos para garantizar que las opciones del sistema de archivos sean atómicas. En general, un bloqueo de disco dará como resultado una pérdida de datos pero no problemas de integridad de datos.