18 ago

Instalación de PostgreSQL – Parte 1 – Optimización del sistema de ficheros

Bueno, pues vamos a instalar un Postgre, pero eso va a ser lo de menos, os voy a explicar como optimizar el sistema de ficheros para que el Postgre trabaje bien bien.

Situación:

Tenemos 1 servidor físico que conecta por FC a una LUN de una cabina NETAPP, sencillo.

[[email protected] ~]# multipath -ll
PostGreSQL1 (360a980006470484f576f73734135392f) dm-2 NETAPP,LUN
size=120G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='round-robin 0' prio=50 status=active
| |- 5:0:0:0 sdb 8:16 active ready running
| `- 6:0:0:0 sdd 8:48 active ready running
`-+- policy='round-robin 0' prio=10 status=enabled
 |- 5:0:1:0 sdc 8:32 active ready running
 `- 6:0:1:0 sde 8:64 active ready running

La buenas practicas de los sistemas de base de datos nos dicen que instalemos Postgre en discos distintos al sistema operativo, para ser más específicos deberíamos separar los tablespace según utilización o tamaño en diferentes volúmenes,  en este caso no lo haremos tan “complicado” ya que no nos hace falta.

La idea es montar el volumen de 120G, con algunas opciones interesantes de ext4, y por supuesto explicando que es cada cosa.  Pues hecha la presentación y todos puestos en situación, vamos al lío.

Vamos a empezar por el journal, para quien no lo sepa es el sistema que disponen la mayoría de sistemas de ficheros y nos permiten organizar, reordenar la información de nuestro disco, o sea se que nos va haciendo una desfragmentación del disco, de ahí el motivo por el cual en Linux no es necesario desfragmentar el disco tan frecuentemente como en Windows, por ejemplo.

Por otro lado y muy importante se encarga de mantener un log de datos pre escritura a disco por si acaso hay un fallo en el servidor, de esta manera podemos recuperar las transacciones que se hayan quedado colgadas, esto si habeis trabajado alguna vez con Bases de datos os sonara mucho, vienen siendo similar a los redo log.

Por otro lado, la escritura  en disco también forma parte del funcionamiento de la Base de Datos, como la  de organizar los datos según vea, así que tampoco nos sera muy útil que el journal organice lo que ya esta organizado.

Resumiendo

-> No eliminaremos, pero bajaremos la intervención de journal en el sistema de ficheros.

OJO! Eliminar el journal puede ser un gran error, ya que principalmente en caso de fallo, el sistema de ficheros no tendrá los datos suficientes para recuperarse.

Más cosas/opciones

  • Extents

Bueno como sabréis el sistema de ficheros ext4 permite como máximo un tamaño de bloque igual a 4KB, este valor es importante siempre, y su elección depende del tipo de lecturas/escrituras que realice nuestro sistema, me explico.

En el caso de tener un sistema de ficheros que vaya a contener ficheros pequeños, es interesante tener un tamaño de bloque pequeño, en el caso contrario que tengamos por ejemplo una base de datos, cuanto mas grande sea el tamaño de bloque mas “rápido” realizaremos las lecturas ya que deberemos pedir menos bloques para conseguir la información y con ellos tendremos menos seek (movimiento de la aguja en disco), que es el mal del sigo XXI, pues hecha la explicación, en el caso del ext4 tenemos los extents que vienen siendo agrupaciones de hasta 128MB de tamaño mapeado continuo en bloques de 4KB.

Esta opción se activa por defecto desde el kernel 2.6.23, pero nosotros la pondremos, así  nos aseguramos que siempre lo activaremos, ya que el rendimiento es bastante mejor.

  • Uninit_bg

Por defecto se escanea y se comprueba cada grupo de inodos, sin importar si esta en uso o no, como es de esperar hacer esta comprobación requiere mucho tiempo, con la opción unint_bg lo que haremos es eliminar de la comprobación los inodos sin inicializar, lo que hace el sistema es colocar una marca en el descriptor, la cual evita que se lea o se escanea en el momento de realizar el  e2fsck, así que si el journal (por eso no lo quitamos) tiene que recuperar información lo hará mucho mas rápido.

  • Dir_index

Esta funcion es bien conocida en ext3, pero al igual que extens en ext4 esta activada por defecto a partir del Kernel 2.6.23, asi que nosotros la activaremos por si acaso y os explico lo que es, básicamente lo que estamos haciendo es decirle al sistema de ficheros que puede utilizar hashed en vez de b-trees, con lo que la lectura de directorios grandes es mucho mas rápido, no os explico los algoritmos que se hace un poco pesado, pero podeis leer un poco aqui (lectura ligera)

  • Has_journal

Con la explicación anterior de como funciona el Journal, con esta opción nos aseguramos que lo activamos.

  • Sparse_super

Este punto afecta a la información que contiene los super bloques, debemos partir de la información que contiene cada bloque, que viene siendo el numero de bloques del grupo, el numero de inodos, características compatibles, información de mantenimiento y más.

Bien pues lo que vamos hacer con esta opción es decirle que solo guarde la información duplicada de los super bloques en los bloques 0 o aquellos que sean potencia de 3, 5 o 7.

Nos queda el ultimo, pero muy importante.

  • Stride y stripe-width

En este punto si que nos hara falta cierta informacion del RAID que hemos montado por abajo, en el caso que lo montemos con MDADM lo tendremos por la mano, en el caso que realicemos el RAID con una controladora, pues si no nos hemos fijado a la hora de instalarlo,  deberemos volver a revisar la configuración.

Para que lo entendamos, en el caso de RAID, el sistema parte, los ficheros en otros mas pequeños y los distribuye por el RAID, pues estos dos valores le dicen al sistema como tiene que hacer esa distribución de datos, por un lado el stripe-width nos dice el numero de escrituras o lecturas paralelas que puede hacer al RAID,  es muy importante afinar este valor, ya que tenerlo por debajo seria desperdiciar rendimiento y tenerlo por encima… pues ya os lo imagináis.

Si habéis montado el sistema con MDADM, cuando realicéis el mkfs el sistema ya tiene información a través del MDADM del numero de discos que dispone el RAID, luego por tanto ese valor se coloca el solito, algunas controladoras RAID también le pasan esa información al sistema.

Por otro lado tenemos el stride (también lo podéis encontrar como such as block size , chunk size , stripe length or granularity), esto viene siendo el tamaño de bloque, es importante que sea igual que el de la creación del RAID, como sabréis como máximo podremos poner 4KB en ext4, asi que afinemos el RAID a este valor o al valore inferior que deseemos, como en este caso estamos preparando el sistema para un Base de Datos que va a ser grandota, contra mas grande el stride, mayor rendimiento.

Bien, pues ahora el ejemplo práctico, para calcular estos valores, en mi caso tengo como os dije una LUN que me la presenta una cabina por FC, los datos de esta LUN son los siguiente.

Numero de discos del RAID = 10

Stripe de la LUN = 4KiB

Chuck-size= 10 * 4 = 40 KiB de RAID chunk size

Tipo de RAID = RAID 5

Pues con estos datos nos vamos a esta web y lo calculamos.

En mi caso me sale, stride=10,stripe-width=90

Vale, pues ya tenemos la teoría de ahora pasamos a la practica, vamos a ver como quedaría el comando para crear la partición.

mkfs.ext4 -E stride=10,stripe-width=90 -O extents,uninit_bg,dir_index,filetype,has_journal,sparse_super /dev/ice

[[email protected] ~]# mkfs.ext4 -E stride=10,stripe-width=90 -O extents,uninit_bg,dir_index,filetype,has_journal,sparse_super /dev/mapper/PostGreSQL1
mke2fs 1.41.12 (17-May-2010)
Discarding device blocks: done
Filesystem label=
OS type: Linux
Block size=4096</strong> (log=2)
Fragment size=4096 (log=2)
Stride=10 blocks, Stripe width=90 blocks
7872512 inodes, 31460352 blocks
1573017 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
961 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
 4096000, 7962624, 11239424, 20480000, 23887872

Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 24 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.

Activamos el journal en modo write_back

tune2fs -o journal_data_writeback /dev/ice

Bien, pues ya tenemos la partición hecha, ahora toca montar de forma normal, no, mentira también pondremos algunas opciones :)

Pues vamos al lío

Primero explicamos y después el comando.

  • Data=writeback

Con esto lo que vamos hacer es que los datos se escriban en disco solo si se escribieron en el journal, de esta manera nos aseguramos de poder recuperarlos  en caso de casque.

  • Inode_readahead_blks=64

Con esto lo que haremos es aumentar la cache de lectura de sistema de ext4, por defecto son 32.

  • Discard

Por defecto ext4 realiza una operación llamada trim, para aquellos bloques que son liberados, con esta opción lo que haremos es decirle que únicamente los marque como libres y no realice la limpieza.

  • I_version

Inodos de 64 bits, que para eso tenemos un sistema de 64 bits.

  • Nobh

Ext4 asocia buffers de datos con las páginas de datos, esos bloques de cache proveen garantía de ordenamiento de los datos; “nobh” evita el uso de estos buffers de ordenamiento de datos (sólo activable con “data=writeback”).

  • Noacl y nouser_xattr

No dar atributos extendidos, ya que en nuestro caso solo postgre tendrá acceso a los datos. Y el segundo parámetro lo que le decimos es que no utilice atributos extendidos del usuario.

  • Noatime

Con esta opción quitamos que el sistema de ficheros gestione el ultimo acceso a los ficheros, lo hacemos en este caso ya que postgre ya se encarga de realizar esa labor.

Pues con estas opciones nos queda la siguiente linea del fstab.

/dev/ice carpeta ext4 rw,noatime,errors=remount-ro,nouser_xattr,noacl,i_version,data=writeback,nobh,discard 0 0

Pues con esto ya tenemos el tema montado, en los siguientes post os explicare como optimizar Linux para postgre y como optimizar postgre para Linux, el sistema de ficheros y para el mismo.

Ale a disfrutarlo!