23 ago

Instalación de PostgreSQL – Parte 4 – Configuración de la replicación

Venga ya esta la última parte de manual de como instalar PostgreSQL, nos ponemos en situación.

A estas alturas debemos tener:

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

Un PostgreSQL instalado y configurado –> Instalación de PostgreSQL – Parte 2 – Instalación y configuració

Parámetros del Kernel modificados para que trabajen bien con nuestra configuración. –> Instalación de PostgreSQL – Parte 3 – Optimización del sistema operativo

Así que ahora nos queda montar una replicación chachi para que el sistema pueda entrar en producción con alguna seguridad….

Vamos a montar una replicación Hot Standby/Streaming Replication, es una de las alternativas, yo la selecciono porque tiene las siguientes ventajas, principalmente:

  1. Consultas al servidor secundario
  2. Replicación del schema

Y cosas a tener en cuenta.

  1. Se replica toda la base de datos, no se especifican tablespaces
  2. Los dos servidores tienen que ser de 32 o 64 bits
  3. No se pueden hacer cambios en el esclavo. (No es un cluster)
  4. Enviamos registros WAL no ficheros enteros, por lo que la replicación es más rápida.

Pues dicho esto vamos al lío!

Debemos instalar el segundo servidor, el procedimiento es igual a lo explicado en los post anteriores.

Un vez instalado debemos tener el servicio apagado y empezamos por el servidor maestro.

Servidor Maestro – Configuración

Lo primero que vamos hacer es permitir que el esclavo se pueda conectar al maestro, pero con la opcion de replicacion, esto lo haremos en el fichero pg_hba.conf.


sudo vi /var/lib/pgsql/9.2/data/pg_hba.conf

Y añadimos la linea siguiente.


host replication postgres ipdelservidoresclavo/32 trust

Importante que la parte de replication seguido de un usuario con permisos de super usuario, podemos utilizar el usuario postgre o crear un usuario con la siguiente sentencia.


CREATE USER usuario WITH SUPERUSER ENCRYPTED PASSWORD 'contraseña';

Y por ultimo el tipo de autentificación trust/md5.

Ahora el fichero de postgresql.sql, explicamos los parámetros y después modificamos, así aseguramos que entendemos lo que estamos tocando.


listen_addresses = '*'

Aquí debemos asegurarnos en el caso que tengamos otro valor que *, que el servidor esclavo se va a poder conectar al maestro, sino mal vamos.


wal_level = hot_standby

Aqui le estamos diciendo que los ficheros wal se guarden en el método hot_standby con lo que nos permitirá realizar consultas en el servidor secundario.


max_wal_senders = 1

Número de conexiones que vas a permitir, aquí deberemos colocar el numero de servidores esclavos que vayamos a tener, en mi caso 1.


wal_keep_segments = 32

Aquí vamos a decirle el numero de segmentos wal que el servidor principal va a guardar antes de empezar a borrarlos o rotarlos, esto es necesario que sea un poco alto ya que un corte de conexión entre los servidores o durante las tareas de backup es posible que podamos perder la replica.

Con esto sencillos parámetros ya tenemos configurado el servidor maestro, ahora solo falta reiniciar el servicio para cargar la configuración.

Servidor Esclavo – Configuración

Pues nos vamos también al fichero postgresql.conf, donde debemos activar la opción  hot_standby

hot_standb = on

Con esta opción le decimos al servidor esclavo que permitirá las consultas.

Vale, ahora vamos por el meollo de la cuestion, debemos crear un fichero recovery.conf en el directorio $PGDATA, podemos saber cual es nuestro directorio $PGDATA haciendo lo siguiente:

cat /etc/init.d/postgresql-9.2 | grep "^PGDATA"
PGDATA=/var/lib/pgsql/9.2/data

O sea en mi caso PGDATA=/var/lib/pgsql/9.2/data, bien pues explicamos que debemos poner el recovery.conf y después lo creamos.


standby_mode = 'on'

Le decimos que el servidor arrancara el standby_mode


primary_conninfo = 'host=ipmaestro port=5432 user=postgres'

Cadena de conexión que utilizara para conectarse al maestro

Le damos permiso al usuario postgres.


chown postgres.postgres /var/lib/pgsql/9.2/data/recovery.conf

Vale pues vamos hacer la primera copia desde el servidor maestro al servidor esclavo del pg_base.

Nos vamos al servidor maestro nos conectamos al postgre y lanzamos.

psql -c "SELECT pg_start_backup('label')"

rsync -aP --exclude postmaster.pid -- exclude '*.conf' --exclude postmaster.opts /opt/PostgreSQL/9.2/ ipesclavo:/opt/PostgreSQL/9.2/

psql -c "SELECT pg_stop_backup()"

Con esto lo que estamos haciendo es, primero decirle a la base de datos que se ponga en modo backup para aseguranos la consistencia de los datos, después copiamos directamente el contenido de la BD master al esclavo excluyendo los ficheros de configuración y por ultimo sacamos a la base de datos de esta de backup.

Pues hecho eso lo único que nos queda es levantar la replica y deberemos ver algo así en el log.

LOG:  entering standby mode
LOG:  redo starts at 0/2000020
LOG:  record with zero length at 0/20001E8
LOG:  streaming replication successfully connected to primary
LOG:  consistent recovery state reached at 0/2000210
LOG:  database system is ready to accept read only connections
[  OK  ]

Así que ya tenemos nuestra replica montada!

Sentencias para comprobar el estado de la réplica.

Una buena comprobación es el fichero de log, pero ahi van unas sentencias muy interesantes.

[[email protected]] psql -h 127.0.0.1 -U postgres -c "select client_addr, state, sent_location, write_location,flush_location, replay_location from pg_stat_replication;"

client_addr  |   state   | sent_location | write_location | flush_location | replay_location
---------------+-----------+---------------+----------------+----------------+-----------------
62.73.191.194 | streaming | 0/3007C60     | 0/3007C60      | 0/3007C60      | 0/3007C60

Aqui veremos todos los clientes conectados el punto del WAL que esta utilizando y el sistema de replicación.

[[email protected] ~]# psql -h 127.0.0.1 -U postgres -c "select now() - pg_last_xact_replay_timestamp() AS replication_delay;"
replication_delay
-------------------

Esto nos mostrara el tiempo que retraso que tenemos en el esclavo respecto al maestro, comando muy util.

[[email protected] data]# ps auxww | grep ^postgres
postgres  9537  0.0  0.0 196600 10160 ?        S    Aug21   0:00 /usr/pgsql-9.2/bin/postmaster -p 5432 -D /var/lib/pgsql/9.2/data
postgres  9539  0.0  0.0 177420  1144 ?        Ss   Aug21   0:00 postgres: logger process
postgres  9540  0.0  0.0 196664  2052 ?        Ss   Aug21   0:00 postgres: startup process   recovering 000000010000000000000003
postgres  9541  0.0  0.0 196600  1816 ?        Ss   Aug21   0:00 postgres: checkpointer process
postgres  9542  0.0  0.0 196600  1372 ?        Ss   Aug21   0:00 postgres: writer process
postgres  9543  0.0  0.0 204696  3848 ?        Ss   Aug21   0:09 postgres: wal receiver process   streaming 0/3007EC0
postgres  9544  0.0  0.0 177632  1276 ?        Ss   Aug21   0:00 postgres: stats collector process

Estado de los procesos del sistema linux, donde podemos ver lo que esta haciendo.

Ale a disfrutarlo!

22 ago

Instalación de PostgreSQL – Parte 3 – Optimización del sistema operativo

Dentro del proceso de instalación de Postgre, ya hemos explicado como montar el recurso para albergar los datos de Postgre y como instalar y configurar PotgreSQL

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

Instalación de PostgreSQL – Parte 2 – Instalación y configuración de PostgreSQL

Ahora vamos a optimizar el “kernel”, bueno os explicare la mayor parte de los parámetros, pero esta vez el post estará basado en la documentación http://www.postgresql.org/docs/9.1/static/kernel-resources.html, por si queréis ampliar más información.

Lo que normalmente suele pasar es que modificamos los valores del postgres.conf olvidarnos del sistema, por ello cuando sobredimensionamos empiezan los problemas, ya que Linux se nos queda “corto”, para evitar esto debemos tener dos conceptos muy claros, la memoria compartida y los semáforos.

Bueno pues vamos por partes, primero la memoria compartida.

Los valores que vamos a tocar son lo siguientes, con su explicación pertinente.

Memoria Compartida

  • SHMMAX

El valor por defecto del núcleo es 32MB, es el tamaño de un segmento de memoria compartido. Existen varios parámetros en postgresql.conf que determinan cuanta memoria compartida necesitaremos, por ello en la mayor parte de las situaciones debemos aumentar SHMMAX como mínimo al mismo tamaño del shared_buffers, pero un poco mas siempre es mejor ya que como digo hay mas valores que comparten esta variable.

  • SHMMIN y SHMALL

El SHMMIN como os podéis imaginar es el valor mínimo y el SHMALL que debe ser SHMMAX/PAGE_SIZE, donde el PAGE_SIZE sera 4kb, lo podemos comprobar con getconf PAGESIZE.

  • fs.file-max

Numero de descripores a fichero, deberemos aumentarlo dependiendo de la ram, se puede calcular 256 por cada 4M de RAM, o ir controlando el valor cuando postgre este trabajando, de forma fácil con


lsof | wc -l

Semáforos

Bueno basándonos en la documentación las formulas para calcularlo son algo tal que así.

  • SEMMNI

ceil((max_connections + autovacuum_max_workers) / 16). El valor por defecto del núcleo suele ser 128

  • SEMMNS

ceil((max_connections + autovacuum_max_workers) / 16) * 17 + lo necesario por otras aplicaciones. El valor por defecto del núcleo suele ser 32000

  • SEMMSL

Como minimo 17. El valor por defecto del núcleo suele ser 250

  • SEMMAP

En algunos casos tiene que ser igual a SEMMNS

  • SEMVMX

Como mínimo 1000. El valor por defecto del núcleo suele ser 32767

  • SEMOPM

El valor por defecto del núcleo suele ser 32

  • SEM

Es igual a “SEMMSL SEMMNS SEMOPM SEMMNI”

Y ahora que los tenemos vamos aplicarlos al sistema, la parte de memoria primero, haremos.


vim /etc/sysctl.conf

Añadiremo o modificaremos las siguientes lineas.


kernel.shmmax = 68719476736
kernel.shmall = 4294967296
fs.file-max = 1048576

Ahora los semáforos.

Contando con la explicación se modifica con la variable kernel.sem =250     32000   32      12, en mi caso realice los cálculos que nos da la documentación y con los valores por defecto del sistema ya esta bien, pero bueno no esta de más saber como modificarlos.

Bueno resumiendo después de las tres partes debemos tener un Postgre instalado y configurado de una forma un poco diferente a la típica instalación y por norma general en el futuro nos empieza a dar problemas, por último solo nos quedara montar la replicación con eso ya tendremos un sistema listo para producción.

Ale a disfrutarlo!

20 ago

Instalación de PostgreSQL – Parte 2 – Instalación y configuración de PostgreSQL

Hoy vamos a explicar como instalar y configurar PostgreSQL, la verdad es que hay miles de documentos por internet que lo explican, pero necesito explicar ciertos valores de la configuración de PostgreSQL para poder explicar en el siguiente como configurar los parámetros del kernel.

Pues venga vamos al tema, nos ponemos en situacion, en el post anterior(Instalación de PostgreSQL – Parte 1 – Optimización del sistema de ficheros), explique como configurar y montar la partición que utilizaremos para nuestro PostgreSQL.

Pues vamos a instalarlo de forma sencilla, tenemos un RedHat 6, vamos a mirar el paquete que tenemos disponible en el repositorio y a ver si es una versión nueva, al menos la 9.2, para ver esto con un simple yum info lo veremos.

yum info postgresql.x86_64
Loaded plugins: product-id, rhnplugin, security, subscription-manager
Available Packages Name        : postgresql
Arch        : x86_64
Version     : 8.4.13 

Es mi caso tenemos una 8.4.13, era de esperar, RedHat es famoso por sus paquetes actualizados en los repositorios oficiales,  vamos a montar el repositorio oficial de PostgreSQL tal que así.

wget http://yum.postgresql.org/9.2/redhat/rhel-6-x86_64/pgdg-redhat92-9.2-7.noarch.rpm
rpm -ivh pgdg-redhat92-9.2-7.noarch.rpm
yum update
yum  --disablerepo="*" --enablerepo="pgdg92" info postgresql92-server.x86_64
Loaded plugins: product-id, rhnplugin, security, subscription-manager
Available Packages Name        : postgresql92-server
Arch        : x86_64
Version     : 9.2.4 Release     : 1PGDG.rhel6
Size        : 3.8 M Repo        : pgdg92 

Pues venga ahora a instalar.

yum  --disablerepo="*" --enablerepo="pgdg92" install postgresql92.x86_64 postgresql92-server.x86_64
service postgresql-9.2 initdb
/etc/init.d/postgresql-9.2 start

Ya esta esto instalado.

Pues vamos a por el fichero de configuración a tocar alguna cosilla, os explico las variables que vamos a tocar y después las modificamos, pensar que igual no queréis modificar las mismas o igual hay algunas que necesitáis para vuestra aplicación.

Como sabeis el fichero que debemos tocar es el postgresql.conf, pensar que esto no son reglas 100% ciertas y depende mucho de nuestro servidor y sobretodo del servicio que se le vaya a dar al postgre, en mi caso esta  destinado a DWH, asi que las valores que pongo irán encarados a este fin.

Opciones de configuración

  • listen_addresses = ‘*’

Ip por la cual estará escuchado el servicio

  • temp_buffers = 16MB

Tamaño máximo de buffers que se podrán reservar por sesión.

  • maintenance_work_mem = 3840kB

Memoria utilizada para la creación de índices, dependiendo de volumen de datos que tengamos la creación de índices puede ser muy costosa, así que es bueno no escatimar en este valor.

  • work_mem = 16MB

Uno de los valores más importantes y más despreciados, “work_mem” se refiere a la memoria temporal utilizada por cada sesión, para las operaciones de ordenamiento (ORDER BY) para las sesiones de diferenciación (GROUP … HAVING y DISTINCT) y para la gestión de hash (uniones HASH, indices HASH, hash_aggregations), si en nuestro sistema realizamos muchísimas consultas ordenadas, agrupadas, diferenciadas por cadenas, etc se crearán mucho de estos buffers de manera paralela, mientras más memoria asignemos, menos probabilidades hay que los ordenamientos y otras operaciones se hagan con archivos temporales en disco (más lentos que la memoria RAM).

  • checkpoint_completion_target = 0.9

Especifica el target of checkpoint completion

  • effective_cache_size =  22GB

Este valor es el encargado de decirle a postgre si en el proceso de optimización de la sentencia le podrá ponerla en memoria o no, así que si podemos darle un valor grandote haremos que las sentencias entren la mayoría en RAM con lo que nos ira mas rápido, una política conservadora puede ser asignar más o menos el 50% de la memoria disponible.

  • wal_buffers = 32MB

Es el tamaño de los segmentos WAL que aun no se han escrito en disco, este valor debe ser un 3% del shared_buffers, nunca menos de 64kb, pensemos que cada vez qaue grabamos la transaccion en disco es una bajada de rendimiento.

  • checkpoint_segments = 64

Numero de segmentos entre el WAL, con un numero más grande tendremos mas retención en el caso de fallo, pero tardara mas en recuperar.

  • shared_buffers = 7680kB

Es la memoria de trabajo compartida para todo el servidor postgreSQL, fíjese que por defecto en Debian GNU/Linux la opción es 24MB (y el valor por defecto si comentamos es 32MB), sin embargo, como esta es la memoria utilizada para trabajo de postgreSQL, es recomendable “al menos” el 25% de la RAM disponible (y jamás > 40%).

  • max_connections = 200

Pues eso

  • max_stack_depth = 8M

Define el tamaño del espacio utilizado para cómputo de operaciones complejas, su valor está asociado al límite máximo que un usuario (en este caso, “postgres”) tiene derecho a reservar un stack, el valor soportado por nuestro sistema operativo, que lo determinamos con “ulimit -s”, y lo modificaremos en el siguiente post.

  • superuser_reserved_connections = 3

Reservamos conexiones, por si en alguno momento tenemos la base de datos con max_connection y necesitamos entrar!

Como sabréis hay miles de opciones más, pero estas creo que son las más importantes, por supuesto os recomiendo la documentación de PostgreSQL ya que es muy buena, ahora las buscamos o añadimos en el postgresql.conf y reiniciamos el servicio.

Y con todo esto reiniciamos el servicio y ya tenemos la segunda parte de la instalación montada.

Ale a disfrutarlo!

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!