Les stats de PostgreSQL dans un tmpfs avec Proxmox

29/07/2014, 20:30:14

Au ${BOULOT}, on utilise Proxmox pour virtualiser, et surtout des containers OpenVZ (pour les hypeux qui ne jurent que par lxc, c'était et c'est pas encore si sec que ça lxc, faut beaucoup enrober, et on n'a pas le temps). Les machines PostgreSQL se trouvent donc être des containers OpenVZ.

Pour soulager les disques de certains I/O, des fois ça aide de placer le répertoire de travail du stats collector, par défaut $PGDATA/pg_stat_tmp et configurable par le GUC stats_temp_directory sur un ramdisk.

Sauf que dans un container, le guest ne peut pas manipuler ses filesystems, on doit passer par l'hyperviseur. Dans le cas d'OpenVZ, on peut ajouter un programme sous le nom CTID.mount qui permet de monter, justement, un tmpfs. Ce fichier est à placer à coté du fichier de conf, dans /etc/vz/conf.

On decide alors de placer nos stats dans /var/lib/postgresql/tmpfs, un tmpfs en mémoire. On ajoute ces répertoires pour garder la hiérarchie classique des instances PostgreSQL sur Debian : 9.3/main/pg_stat_tmp.

On écrit donc le script shell suivant dans /etc/vz/conf/CTID.mount, ou CTID est le numéro du container :

#!/bin/sh
# Script de montage d'un tmpfs pour les stats de PostgreSQL

# If one of these files does not exist then something
# is really broken
[ -f /etc/vz/vz.conf ] || exit 1
[ -f $VE_CONFFILE ] || exit 1
# Source both files. Note the order is important.
. /etc/vz/vz.conf
. $VE_CONFFILE

mountpoint=/var/lib/postgresql/tmpfs
subdir=9.3/main/pg_stat_tmp
postgres_uid=104
postgres_gid=108
size=104857600 # 100 Mo

mkdir -p ${VE_ROOT}${mountpoint}
mount -t tmpfs -o size=${size},uid=${postgres_uid},gid=${postgres_gid},mode=0700 tmpfs ${VE_ROOT}${mountpoint}
mkdir -p ${VE_ROOT}${mountpoint}/${subdir}
chown -R ${postgres_uid}.${postgres_gid} ${VE_ROOT}${mountpoint}

Dans le script tout ce fait dans le context de l'hyperviseur, c'est pourquoi on utilise les uid/gid numériques de postgres dans le container pour que les permissions soient correctes dès le boot.

Enfin, il ne reste qu'à modifier le fichier postgresql.conf pour configurer stats_temp_directory :

stats_temp_directory = '/var/lib/postgresql/tmpfs/9.3/main/pg_stat_tmp'

On peut alors redémarrer le container sur l'hyperviseur :

# vzctl restart CTID

Et voir depuis le container le nouveau FS :

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/simfs      100G   28G   73G  28% /
tmpfs           100M   12K  100M   1% /var/lib/postgresql/tmpfs
tmpfs           410M   32K  410M   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           820M     0  820M   0% /run/shm

pgbench et .pgpass

16/06/2014, 10:51:44

En faisant quelques tests sur le Foreign Data Wrapper, j'ai (re)fait un peu de pgbench. Pour ceux qui ne savent pas pgbench permet de simuler un benchmark TPC-B, en gros des lectures, des écritures par un certain nombre de sessions concurrentes.

Même si on peut le considérer simpliste par rapport à un Tsung, il est fourni dans les contribs de PostgreSQL et permet de facilement tester un aspect qu'on néglige souvent : les effets de la concurrence sur une base.

J'ai donc monté mon petit environnement de test avec un rôle pour pgbench et sa base dédiée. Pour aller plus vite, j'en ai profité pour configurer un fichier .pgpass, sauf que pgbench n'en voulait pas :

postgres@fdw:~$ cat .pgpass 
localhost:5432:*:bench:Clair!

postgres@fdw:~$ pgbench -h localhost -n -c 10 -j 10 -U bench bench
Password: 
Connection to database "bench" failed:
fe_sendauth: no password supplied

Poutant, la ligne pour l'utilisateur bench est correcte. Si on lui fournit explicitement le port 5432, il tient compte de l'entrée dans le .pgpass :

postgres@fdw:~$ pgbench -h localhost -n -c 10 -j 10 -U bench -p 5432 bench
transaction type: TPC-B (sort of)
scaling factor: 500
query mode: simple
number of clients: 10
number of threads: 10
number of transactions per client: 10
number of transactions actually processed: 100/100
tps = 77.993447 (including connections establishing)
tps = 88.977249 (excluding connections establishing)

La lecture de ce thread, qui se conclut sur ce patch, nous éclaire sur ce comportement.

Selon le message de commit, la modification change le comportement de la libpq. Elle n'a pas été backportée sur les autres branches et ne sera donc disponible que pour la libpq de la version 9.4 (ou Debian/Ubuntu qui prend toujours la dernière version de la libpq).

Migration du blog sur github

28/05/2014, 18:29:31

Finalement le temps ne me permettant plus d'administrer mon serveur dédié comme il faut, j'ai décidé de l'abondonner et transférer mes services ailleurs. Pour le blog et le wiki, j'ai choisi de faire un site/blog github avec jekyll, vu que c'est tout prémaché.

Sur github, l'hébergement c'est du fichier html, donc statique, on a plusieurs possibilités pour créer un site :

L'avantage de pelican est dans sa capacité à importer le contenu d'un blog dotclear, et transformer la syntaxe en markdown. Le markdown semble avoir la cote, beaucoup de générateurs de site l'utilisent, d'ailleurs je m'y suis mis.

Comme j'avais déjà fait le site de pitrery avec jekyll sur github, la migration fut plus facile, une fois le dotclear migré grâce à pelican.

Au final, j'ai maintenant un truc tout simple avec un thème bootstrap, et le jekyll de base de github est largement suffisant.

La bonne découverte fut pandoc, un super convertisseur de format de document texte, qui va me servir pour la migration du dokuwiki à base de :

pandoc -f html -t markdown http://wiki.orgrim.net/page?do=export_html

Le mot de la fin, ça demande un peu de boulot de nettoyage manuel, mais vu le nombre impressionant de posts que j'ai pu produire en quatre ans, c'était pas trop méchant.

modular-xorg, radeon et pas de KMS

23/08/2013, 19:10:00

Il y avait un moment que je n'avais pas touché à NetBSD et donc mis à jour mon lappy avec du pkg frais. Entre temps, la version de X.org modular, donc issue de pkgsrc, est revenue en 2012, avec son lot de drivers mis à jour. Le drivers xf86-video-ati, est passé en version 7.1.0, sauf qu'il fonctionne uniquement en KMS (Kernel Mode Setting), chose qu'on n'a pas encore dans notre kernel.

Il faut donc la dernière version de la branche 6 du driver, qui contient encore le support UMS, disponible dans le paquet x11/xf86-video-ati6, qui porte le même nom de package, bizarrement. Tout ça est suivi dans le PR 47935.

Pour que le serveur X trouve le device avec ce driver, j'ai du virer la ligne BusID dans la section Device du xorg.conf.

pitrery - Faciliter la restauration PITR de PostgreSQL

05/06/2013, 08:38:00

pitrery est un ensemble de scripts pour gérer plus facilement la sauvegarde à chaud et la restauration PITR dans PostgreSQL.

Il s'agit de simples scripts bash, qui n'imposent pas autant de dépendances qu'un pgbarman et se concentre uniquement sur le PITR, là où des outils tels que OmniPITR, PITRTools semblent vouloir gérer également la réplication. L'objectif de pitrery est de pouvoir facilement restaurer.

La version 1.3 apporte des nouveauté intéressantes :

La documentation est à jour sur https://dalibo.github.io/pitrery/documentation.html

Le code est disponible sur https://github.com/dalibo/pitrery/

Les versions sont disponibles sur https://dl.dalibo.com/public/pitrery/

Les idées pour la prochaine version sont, en vrac :