pgbench et .pgpass

16/06/2014, 12: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, 20: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 :

Un bulk build par jour dans un screen

10/05/2013, 12:40:00

Mes packages NetBSD sont préparés par pbulk, qui tourne en continu grâce au script pbulk-builder.

J'avais prévu avec l'option -1 de lui éviter d'entrer dans une boucle infinie, et j'ai pas eu tort. En effet, la majorité des tours ne fait que mettre à jour l'arbre pkgsrc, résoudre les dépendances, sans rien compiler de nouveau. La première solution que j'ai trouvé a été de créer une règle sieve pour ne pas recevoir des dizaines de mails de rapport de bulk inutiles, en les plaçant dans un répertoire séparé...

N'ayant jamais pris le temps d'utiliser cette fameuse option one-shot, j'ai décidé de mettre le lancement du bulk dans la crontab, sauf que c'est long et qu'il vaut mieux suivre ça avec screen. C'est possible grâce aux options -d et -m (avec -S pour mettre un titre) :

0 23 * * * /usr/pkg/bin/screen -dmS bulk -c /root/.screenrc /usr/pkg/bin/bash ~orgrim/nb-utils/pkgsrc/pbulk-builder -c -1 /data/pbulk

On peut alors attacher le screen quand le bulk tourne.

PS: merci au fans de tmux de passer sur le chan #netbsdfr sur Freenode pour me dire comment faire pareil avec tmux :)