Serveur master: ROSE

Il s'agit d'une dedibox standard. Le résultat d'un lshw est fourni en annexe. Le système d'exploitation est une Debian GNU/linux 4.0 Etch. Le serveur PostgreSQL est fourni sous forme de paquets, pour la version 8.2. Il en est de même pour Slony-I dont la version est 1.2.11.

Serveur slave: PAEGA

C'est exactement le même serveur avec les mêmes paquets Slony-I et PostgreSQL.

Fichier de configuration postgresql.conf

shared_buffers       = 240MB
work_mem             = 16MB
maintenance_work_mem = 160MB
max_connections      = 100
max_fsm_pages        = 307200
effective_cache_size = 128MB
stats_block_level    = on
stats_row_level      = on
autovacuum           = on
fsync                = on

Fichier de configuration pg_hba.conf

host    cave        @benchs     88.191.69.196/32      md5
host    cave        @benchs     88.191.69.197/32      md5

Schéma

Un schéma très simple est utilisé:

# \d descriptif
                        Table « public.descriptif »
Colonne  |  Type   |                      Modificateurs
----------+---------+------------------------------------------------
id       | integer | not null default
         |         | nextval('descriptif_id_seq'::regclass)
titre    | text    |
texte    | text    |
resume   | text    |
auteur   | text    |
date_ins | date    |
date_maj | date    |
actif    | bigint  |
Index :
    « descriptif_pkey » PRIMARY KEY, btree (id)
    « actif_desc » btree (actif)
    « date_diff » btree ((date_ins <> date_maj))

Requêtes

Chaque cycle consomme chaque requête une fois.

De plus pour chaque requête, une valeur donnée par:

$actif = floor(rand()*101);

est utilisée. Elle permet d'avoir une variation dans chaque requête, limitant l'utilisation du cache.

L'utilisation du random et du limit rend plus variable le résultat des requêtes, et permet d'obtenir le ratio global suivant: 100 lignes insérées pour 50 mises à jour et 50 supprimées.

INSERT INTO descriptif
(titre,texte,resume,auteur,date_ins,date_maj,actif)
  SELECT texte,resume,auteur,titre,now(),now(),round(random()*100)
  FROM (SELECT texte,resume,auteur,titre FROM descriptif
        WHERE random() < 0.5
        AND actif = $actif
        LIMIT 200) AS a
WHERE random() < 0.5;

UPDATE descriptif
SET titre   = texte,
    texte   = resume,
    resume  = auteur,
    auteur  = titre,
    date_maj= now(),
    actif   = round(random()*100)
WHERE id IN (
  SELECT id
    FROM descriptif
    WHERE random() < 0.5
    AND actif = $actif
    AND date_ins < now()
    LIMIT 100
  )
AND random() < 0.5;

DELETE FROM descriptif
WHERE id IN (
  SELECT id
    FROM descriptif
    WHERE random() < 0.5
    AND actif = $actif
    LIMIT 100
  )
AND random() < 0.5 ;

Évolution de la volumétrie

Ce graphe montre bien l'impact important de Slony-I sur l'évolution de la volumétrie de la base de données répliquée. (Le jour 4 est le jour de blocage de la réplication).

Pour rappel, Slony-I fonctionne via des triggers on each row qui recopient les données dans des tables propres à Slony-I. Ces données, récupérées et rejouées par les autres nœuds, sont effacées lorsque la réplication fonctionne correctement.

L'accroissement normal est de 100 mégaoctets par jour environ. Une fois la réplication interrompue, le nœud master conserve les enregistrements tant qu'ils ne sont pas répliqués, l'accroissement est alors de 500 mégaoctets par 24 heures.

L'impact constaté sur la volumétrie n'est, certes, pas négligeable sur la volumétrie, mais c'est certainement un point qui ne troublera pas l'administrateur: pour devenir gênante la défaillance doit être très longue. A titre d'exemple, si cela devenait gênant après seulement 4 jours, cela serait équivalent à un accroissement normal de 20 jours; il est impensable de prévoir une si faible capacité d'espace libre en terme de temps.

Évolution des cycles

L'évolution de la durée des cycles (d'activité et de pause) nous indique qu'il n'y a pas de changement notable de performance entre le moment où la réplication fonctionne (avant) et celui où elle est en panne (après).

Sur ce graphe, on peut voir que le comportement est similaire:

• la ligne violette et bleue supérieure correspond aux durées lorsqu'un autovacuum s'est déclenché ;
• la ligne inférieure montre le temps normal ;
• les nuages de points correspondent aux variations liées au fonctionnement de PostgreSQL (checkpoint par exemple).

Enfin ces deux graphiques nous montrent bien que la perte de performance est uniforme sur l'ensemble du test.

Rappel: la construction du jeu de test est basée sur une baisse de performances normale.

Note: le nombre de delete et d'update est très proche, les deux courbes sont donc quasiment superposées.

Évolution du volume de transactions

Au niveau de l'activité du serveur, la perte du nœud slave met en évidence une baisse significative du nombre de requêtes globales. Lorsque Slony-I est en fonctionnement normal, il se produit plusieurs INSERT, UPDATE et DELETE pour ajouter, confirmer et répliquer un enregistrement. Dès que la réplication est stoppée, il ne se produit plus qu'un INSERT lié aux triggers de Slony-I.

Évolution du lag de la réplication

Ce graphique est donné à titre purement informatif:

• last update représente la différence entre les valeurs du dernier enregistrement de la table last_update de chaque nœud. C'est le meilleur indicateur du lag effectif.
• sl_lag node 1/2 est la valeur directement renvoyée par Slony-I et ne correspond pas au lag effectif mais au lag maximum (cf documentation Slony-I).

Évolution de l'utilisation mémoire

L'utilisation mémoire montre de légers changements dans sa répartition mais de façon très faible, et dans un sens plutôt positif car cela en libère.

Évolution de netstat

Le nombre de connexions actives est assez parlant: l'arrêt du slave en réduit quasiment le nombre de moitié!

Évolution des interruptions et contextes

Pour ce point là encore, l'interruption de la réplication apparaît positive: l'utilisation de l'interface réseau est bien faible, les changements de contextes moins fréquents.