Nouveau serveur Kimsufi SSD pour un hébergement Nginx, PHP-fpm, Varnish et Memcached

Mes sites ont migré sur un nouveau serveur Kimsufi SSD de OVH et les performances sont bien sympathiques grâce à Nginx et Varnish.

Petite évolution du serveur hébergeant feub.net et plusieurs autres sites qui reste chez Kimsufi d’OVH mais en version SSH cette fois-ci. Cela me titillait depuis un moment car il faut bien l’avouer le SSD lorsqu’on en goûte on ne peut plus s’en passer, côté desktop mais coté serveur aussi. Mais il fallait bien avouer que le boulot de la migration me faisait renoncer, je n’avais pas trop envie de passer des heures devant un terminal lorsque je passe déjà mes journées au boulot devant des lignes de code. Après moult réflexion donc, maintenant c’est fait, un Kimsufi moins cher (9.99€/mois) que celui d’avant, avec un couple processeur/mémoires similaire, mais aussi 20% de moins d’espace disque, passant d’1Tb à 40Gb.

Je reste fidèle à Fedora, en passant à la version 23, et le serveur web d’enfer Nginx se voit désormais épaulé par l’accélérateur d’applications web Varnish que je commence à apprivoiser et Memchached pour la mise en cache d’objets PHP. Belle petite équipe qui ne demande qu’à être optimisée ^.^

Je ne vais pas m’attarder sur le détail de mes configurations, mais ce sera certainement l’objet de prochains billets sur ce blog. Pour le moment ça roule, peut-être y’a-t-il quelques couacs à droite à gauche, alors n’hésitez surtout pas à me faire part de tout problème ou anomalie.

MySQL 5.6 occupe presque 500Mo de ressources

Depuis la version 5.6.17 de MySQL dans mon environnement de développement WAMP, les ressources occupées par le moteur de base de données flirtent avec les 500Mo.

Ressource avant

C’est plutôt ennuyeux. Il semble qu’il s’agisse de la valeur de la variable table_definition_cache qui est fixée par défaut à 1400, une valeur un peu trop importante pour mes besoins limités en développement local. La documentation informe que la valeur minimale est de 400, et que par défaut celle-ci est établie comme ceci : 400 + (table_open_cache / 2), plafonnée à la limite de 2000.

Cette variable n’est en principe pas présente dans le fichier de configuration de MySQL my.ini, il suffit de l’ajouter, puis de redémarrer MySQL, et le résultat est sans appel : environ 91Mo de ressources dans mon cas.

Ressource après

A noter que la documentation officielle informe que la valeur de table_definition_cache était établie à 400 jusqu’à MySQL 5.6.8