Maîtrise de la charge des serveurs de base de données

Voilà une part importante du travail des équipes techniques d'Overblog : maîtriser la consommation de ressources sur les serveurs de base de données.

Les bases de données, ce sont ces lieux de stockage de toutes les infos de vos blogs : articles, commentaires, albums, communautés, utilisateurs, configuration du blog, ...

Un serveur de base de données c'est un serveur qui coûte cher à l'achat (il est équipé de disques dur de très grande qualité, de CPU puissants, de beaucoup de mémoire) et à l'usage en consommation électrique (à cause du nombre de disques). Multiplier les serveurs de base de données est donc la dernière opération d'optimisation à faire. Avant cela il faut se pencher sur tous les éléments de la chaîne de production, depuis la requête du navigateur client en passant par les caches frontaux, les serveurs de construction des pages HTML, les clusters de type memcache et enfin les les serveurs de bases de données.

Il est vrai que la période estivale est moins chargée qu'à l'habitude mais nous sommes parvenus hier à une optimisation très poussée de l'utilisation de nos ressources en lecture sur les serveurs de bases de données. En effet, toute la production d'Overblog en lecture (affichage des blogs, non compris le portail) est désormais assurée par 2 seuls serveurs de bases de données (ce sont des octocores -8 CPU- équipés de 28 et 32 Go de RAM). Et tout ça avec une grande largesse, puisque la charge de chacun des serveurs ne dépasse pas 2.5 (la charge nominale maximale d'un octocore étant de 8). Pour autant le logiciel de bases de données (PostgreSQL 8.3) sert environ 4000 transactions par seconde (chiffre cumulé des 2 serveurs).

Pour en arriver là, il y a eu beaucoup de travail fait tout d'abord sur le plan logiciel (requêter intelligemment la base de données), sur le schéma de base (comment ranger les données intelligemment), sur la configuration des logiciels (réglage fin des paramètres de PostgreSQL pour optimiser son fonctionnement) et enfin sur l'optimisation du taux de cache kernel et logiciel sur les serveurs de base de données.
Pour ce dernier point nous essayons de séparer au mieux le trafic entrant pour que les données d'un blog soient toujours cherchées sur le même serveur de bases de données. Ainsi on augmente le taux de cache PostgreSQL sur les requêtes concernant ce blog ainsi que le taux de cache disque (géré par le kernel) lorsque PostgreSQL doit accéder aux données sur disque.