Point sur le serveur qui héberge Matomo

Bonsoir tout le monde,

On a comme projet dans les cartons de déménager¹ le serveur qui héberge Matomo de Scaleway vers Pulseheberg (là où est désormais notre serveur de bêta). De plus, la base de données MariaDB a souffert de quelques OOM (Out-of-memory) cette semaine. J’ouvre donc un sujet pour faire le point sur l’état du serveur qui héberge Matomo.

Pas assez de RAM ?

Le 30 avril et le 10 mai, le serveur de base de données MariaDB s’est fait tué par le OOM-killer. Conséquence : pas de base de données et impossible de sauvegarder les statistiques pendant tout le temps où la base de données ne fonctionne pas. La solution est relativement simple, à chaque fois j’ai tout simplement redémarré le service (même pas la machine toute entière !).

Pourquoi MariaDB s’est fait OOM ? J’avoue que je ne sais pas. En regardant les logs du noyau, on voit que lorsque le OOM killer s’est déclenché, c’est en effet MariaDB qui avait le plus de pages mémoire (donc c’est judicieux de tuer ce processus pour récupérer le plus de mémoire possible). Pourquoi l’OOM s’est déclenché ? Encore une fois, je ne sais pas, surtout que quand on regarde les données de la supervision, la consommation globale de RAM ne semblait pas particulièrement critique :

Comme solution (je ne sais pas à quel point ça va être utile), j’ai ajouté un fichier de SWAP de 1 Go (avec ce fichier de swap créé, il nous reste 7.7 Go de libres sur le disque système, donc on peut se permettre ce fichier de swap).

Que recommande Matomo ?

Figurez-vous que Matomo capture environ 1 million de vues de page par mois (uniquement pour le serveur de production, c’est négligeable sur le serveur de bêta)

Maintenant qu’on sait ça, on voit que Matomo recommande :

App server minimum recommended configuration: 4 CPU, 8 GB RAM, 250GB SSD disk.

Ça m’étonne, parce que le serveur qui héberge actuellement Matomo possède 2 CPU, 2 Go de RAM et on utilise environ 25 Go de stockage tout compris, et il faut dire qu’à part les OOM récents, l’impossibilité de récupérer les statistiques de contenus sur une grande période, Matomo fonctionne plutôt bien, l’interface est fluide, … C’est probablement parce qu’on utilise en réalité très peu de fonctionnalités parmi tout ce qu’offre Matomo.

Une optimisation aux petits oignons de MariaDB ?

Matomo fournit quelques recommandations pour optimiser les performances de la base de données. J’avoue que je n’y ai pas regardé en détails.

La documentation pointe aussi vers deux outils, MySQLTuner et MySQL Tuning Primer Script, qui semblent pouvoir nous donner des indications sur les optimisations possibles de notre base de données. Pareil, je n’ai pas essayé.

Pendant qu’on y est, niveau stockage, on est comment ?

Il y a presque un an, on a du ajouter du stockage au serveur hébergeant Matomo, parce que ça débordait… On a alors ajouté un disque de 20 Go, dédié uniquement aux données de MariaDB.

J’ai suivi, de façon pas vraiment régulière, l’espace occupé sur ce disque :

(je ne sais pas vraiment quels arrondis fait df)

On peut aussi regarder ce que nous montre Munin :

Si je rentre ça dans un tableur, ça me donne qu’il faut compter environ 300 Mo/mois. Encore une fois, si on regarde les recommandations de Matomo :

A rough estimate of Matomo Mysql database size usage is approximately 1GB for every 5M page views. If your website tracks 100k page views per day (3M page views per month), you can expect a DB size of ~ 7GB after 1 year.

An important factor for achieving good performance is to keep the number of unique URLs tracked low. Please make sure you setup ignored URL parameters you do not wish to count in the URL (such as session ID parameters). The less unique URLs tracked in Matomo the better!

Là on fait un peu pire, puisque si on dit dit qu’on fait 1M de vues de page par mois, on arrive plutôt à 1,5 Go pour 5M de vues de page (m’enfin vues la précision de mes chiffres, j’ai l’impression qu’on n’est quand même pas loin des recommendations).

Déménagement vers Pulseheberg

On a déménagé le serveur de bêta de Scaleway à Pulseheberg principalement pour économiser sur la facture à la fin du mois (Scaleway est bien plus orienté cloud, aspect qu’on n’utilise pas et qui coûte plus cher qu’un VPS "traditionnel").

Chez Scaleway, on a actuellement une instance DEV-1-S avec un peu de stockage en plus, qui nous coûte au total environ 13–14€ TTC / mois (c’est du cloud, ça varie un peu entre les mois).

Pour le futur serveur de Matomo, je pense qu’il nous faudrait au moins 2 CPU, 4 Go de RAM et au moins 50 Go de stockage (en SSD). Une telle offre chez Scaleway coûte plus de 20 €/mois. Chez Pulseheberg, c’est plus compliqué :

• STD-8 (pour avoir 50 Go de stockage, 8 CPU et 8 Go de RAM) à 9€ / mois
• PERF-4 (pour avoir 2 CPU et 4 Go de RAM, 60 Go de stockage) à 14€ / mois (dans ce cas, on n’économise pas par rapport à Scaleway, mais on a le double de RAM et un peu plus de stockage)
• j’exclue les offres stockage parce qu’elles ne proposent pas de SSD

Ce qui m’inquiète, c’est par rapport au stockage. Si on considère qu’on a besoin de 3 Go / an, qu’on utilise déjà 25 Go (total: système et base de données) et qu’on prend un système avec 50 Go de stockage, ça veut dire qu’on est tranquille pour 8 ans (je compte très large). Si on veut être tranquille pour au moins 3 ans, l’offre STD-8 n’est finalement peut-être pas un mauvais choix…

Revoir notre utilisation de Matomo

C’est un sujet qui revient régulièrement : est-ce qu’on utilise correctement Matomo ? Est-ce qu’on pourrait mieux l’utiliser de façon à ce qu’il consomme moins de ressources ? Je pense que ça vaut le coup de creuser le sujet, mais c’est un sujet compliqué et qui demande du temps…

Conclusion

Je voulais seulement sauvegarder quelque part ces quelques liens et chiffres, résultat, voici un très long message !

Il n’y a rien d’urgent, je ne dis pas qu’on doit prendre une décision dans le mois qui vient, l’idée de ce sujet est juste de vous communiquer ces informations et d’entamer la réflexion.

L’absence totale de swap (ou la swapiness à 0) peut provoquer des comportements franchement bizarres dans certains cas particuliers a cause de l’absence totale de marge de sécurité. Mieux vaut toujours configurer un poil de swap (ou une technologie alternative, peut-être pas pertinente sur un serveur, de BDD qui plus est).

Les problèmes rencontrés sont : soit un logiciel qui part du principe qu’il aura de la swap pour y mettre des choses dont il sait qu’il n’aura pas besoin souvent, soit l’OOM killer qui va devenir très agressif à cause de l’absence de marge de sécurité. Ce second point (via la swapiness) est d’ailleurs décrit dans la doc de MariaDB.

Donc pour moi ta solution de créer un fichier de swap est la bonne, au moins en première approche.

PS :

• STD-8 (pour avoir 50 Go de stockage, 8 CPU @2,4 GHz [Intel Xeon E5–2680v4] et 8 Go de RAM) à 9€ / mois
• PERF-4 (pour avoir 2 CPU @3,5 GHz [Intel Xeon E5–2637v4] et 4 Go de RAM, 60 Go de stockage) à 14€ / mois

J’ai ajouté en gras l’information qui permet de comprendre pourquoi PERF-4 est plus cher que STD-8 malgré son apparence moins puissante (et le fait qu’il est moins puissant en réalité, d’après le test interne de Pulseheberg…). La différence entre les deux CPU est là.

Bonjour et merci pour le résumé.

Est-ce qu’on a une idée de la consommation en CPU du serveur matomo actuel ? Et aussi des specs CPU de la VM de scaleway qui héberge matomo ? Histoire de voir si on est plus proche de l’offre STD-8 ou PERF-4.

Est-ce que côté pulseheberg on a une idée de la bande passante maximale ?

Est-ce que côté pulseheberg on a une idée de la bande passante maximale ?

Pour les deux offres concerné plus haut, la bande passante est de 500 Mbps

Pour les deux offres concerné plus haut, la bande passante est de 500 Mbps

Je pense qu’il parle non pas du débit de la connexion du serveur mais d’une éventuelle limite en quantité de données envoyées ou reçues.

Ah oui, je vois. Hum… à priori non, mais on peut les contacter pour avoir l’info, ils sont plutôt très réactifs.