Bonjour à tous,
un certain nombre de sites de la galaxie SPIP ont ramé Dimanche et Lundi.
C’est le cas de core.spip.net, zone.spip.net et forum.spip.net
Vu que c’est sur mon serveur dédié qui les héberge, voici quelques explications.
J’utilise depuis longtemps la gamme de serveurs OVH.
Le serveur dédié (hôte) est découpé en plusieurs serveurs virtuels (CT)
Jusqu’à Samedi, le serveur hôte était un EG64 Hybrid. Cependant les performances devenaient mauvaises pendant les temps de backup - qui étaient du coup réduit au minimum, ce qui devenait moyen à force…
J’ai donc fais le choix de passer sur un serveur de gamme supérieur. J’ai opté pour un serveur MG64 car j’utilisais peu le SSD (sauf pour le système, des backups intermédiaires et la base de forum.spip.net)
Pour comprendre les différences entre le EG et le MF, je me suis basé sur leurs caractéristiques techniques - en particulier le CPU et le disque.
Côté CPU, on sait ce que c’est sur la page publique. Donc j’ai regardé les comparatifs sur http://www.cpubenchmark.net
Processeur | # Core | Freq | Rank | Passmark CPU
Kimsufi | Intel i5-2300 | 2/4 | 3,4 GHz | 181 | 5276
EG 64 | Xeon E5 1620 | 4/8 | 3,6 GHz | 38 | 9163
MG64 | Xeon E5 1650 | 6/12 | 3,2 GHz | 14 | 11392
Donc côté CPU, y’a pas photo c’est mieux !
Côté disque je n’ai pu faire le comparatif qu’une fois que j’avais commandé le serveur
Les valeurs sont prises sur http://www.harddrivebenchmark.net/
Modele | Rank | Rating
Kimsufi> Seagate ST32000641AS | 772 | 759
EG 64 | Seagate ST2000DM001-1CH1 | 584 | 977
MG 64 | Toshiba DT01ACA2 | 640 | 900
Mauvaise surprise : le MG utilise un disque un peu moins performant. Mais bon, entre 900 et 977 on peut penser que la différence est minime. D’autant plus que le nouveau serveur allait être optimisé en lecture/écriture (je vous passe les détails)
La migration des différents CT s’est faite sans trop d’histoires entre Samedi et Lundi.
Mais depuis Dimanche effectivement tous les vps du serveur ont salement ramé ( puis surtout Lundi ).
En fait le nouveau serveur sature dès qu’on lui demande trop d’accès en lecture/écriture. Et la montée en température est vite vertigineuse, par effet de boule de neige, ce qui se traduit en pratique par un ralentissement global de tous les sites et autres services hébergés dans les différents CT
Les moments où ça ramait le plus étaient ceux où étaient lancé les backup.
Et particulièrement à cause d’un de mes clients qui a beaucoup de popularité et consomme beaucoup.
C’est essentiellement lui qui nous pose problème, car son mysql pompe parfois 90% des accès disque.
Cette situation est totalement anormale.
Cette nuit j’ai en particulier travaillé sur la config de son mysql et l’ai customisée pour résoudre ces problèmes.
Je verrai dans mes prochains tests si mes suppositions sont bonnes, mais ça devrait aller mieux.
D’autres optimisations sont mises en place sur le serveur hôte et doivent être testées dans les prochains backups.
Au pire je passerai rapidement sur une gamme au dessus, mais pour l’instant je préfère chercher d’où viennent ces problèmes de blocage des accès en lecture/écriture. Une amélioration de ce côté permettrait de faire plusieurs sauvegardes sans affecter la rapidité des sites. C’est indispensable pour que l’hébergement reste fiable et rapide.
Merci d’avoir pris la peine de lire ce message jusqu’au bout,
.Gilles