Micro coupure

[torrep]

Bonsoir,

Depuis environ 10 jours, j'ai des micros coupures d'environ 10 à 20 secondes sur legtux, plus moyen d'accéder a la page legtux.org et sur mon site perso.

Je voulais savoir si cela vous arrivez aussi ?

Cordialement

[casselinux]

J'ai remarqué aussi, aussi j'ai surveillé un moment la connexion du serveur, les micro coupures sont due a une surcharge du serveur, par contre je ne sais pas d'ou ça vien!

L'hébergeur du dédié (Kimsuffi)? Un gars qui joue au con avec son compte? Une attaque?

[Simon Le Guével]

Je vais voir ça !

[Orkaz]

Je viens juste de poster un message pour dire la même chose, mais tu m'as devancé x) C'est vrai que je remarque ça aussi, ça le fait depuis qu'OVH a eu des problèmes et que LegTux a coupé pendant plusieurs heures.

[Lilibi]

Pareil, parfois c'est indipo, j'actualise et tout remarche.

[bnmkt]

pareil, mais moi mon site fait de 5 à 10fois l'action demandée avant la micro coupure...

[Simon Le Guével]

C'est un problème d'Apache : Apache fonctionne sur le mode prefork (= un processus par requête). Donc, un simple fichier PHP qui contient une requête MySQL va devoir créer un nouveau processus sur le serveur (~5 Mo pour Apache), un nouveau processus PHP (~10 Mo) et une nouvelle requête MySQL (~2 Mo).
Ce qui en général 15 Mo de mémoire vive par requête, et donc par processus.
Les inconvénients de ce mode de fonctionnement sont les suivants : le système passe beaucoup de temps à ouvrir et fermer des processus : charge supplémentaire induite; PHP doit être lancé en tant que module à chaque nouvelle requête : temps de latence supplémentaire.

Évidemment, quand la mémoire vive disponible est bourrée par Apache, on a deux solutions : soit continuer à utiliser la mémoire, mais lorsque le dernier octet sera attribué, le système sera complètement figé, ou alors faire un script qui redémarre Apache quand la mémoire vive disponible est inférieure à 10%.
C'est cette deuxième méthode qui est appliquée sur LegTux, et qui cause ces micro-coupures quand Apache redémarre (ou essaye de redémarrer, il est capricieux le bougre !).
Ça ne se produit qu'en heure de pointe quand l'affluence est très forte, mais ça peut gêner certains.

La solution radicale serait un changement de serveur web : nginx est très léger et fonctionne sur un mode threadé, c'est à dire seulement quelques processus (moins de 5) qui tournent en attendant les requêtes (plusieurs requêtes par processus). De même pour PHP, il est lancé une fois en tant que daemon et nginx lui "passe" les requêtes, il n'y a plus besoin de le lancer à chaque requête, les chargements des pages sont donc plus rapides, même en cas de forte affluence.
Le gros inconvénient de cette solution, c'est la non-prise en charge des .htaccess, petits fichiers permettant de configurer le comportement du serveur Web pour son compte.
Il existe une fonction similaire sur nginx, mais qui possède une syntaxe différente, donc des modifications à faire, surtout pour la réécriture d'URL et les authentifications HTTP.

Désolé pour ce gros pavé !

[fujiweb]

Il supporte les .htaccess et autre?

[Guillaume]

Le gros inconvénient de cette solution, c'est la non-prise en charge des .htaccess, petits fichiers permettant de configurer le comportement du serveur Web pour son compte.
Il existe une fonction similaire sur nginx, mais qui possède une syntaxe différente, donc des modifications à faire, surtout pour la réécriture d'URL et les authentifications HTTP.

Si c'est le cas, on risque d'avoir une grosse vague de support.

[fujiweb]

Faut que je me recouche.
Sinon, on peut donner de la ram à ovh pour le serveur ou faut raquer les €€€
J'ai une barrette de 2go ddr2-800 de marque micron