Apache 2 sature mémoire puis plante serveur

WRInaute impliqué
Bonjour,

Je n'arrive pas à trouver le problème de config apache qui fait planter un de mes serveurs dédiés... Les "Apache processes" grimpent, la mémoire sature et le serveur ne répond plus. Je suis obligé de redémarrer apache pour que toutes les valeurs redéscendent à 0 puis recommencent à grimper et ainsi de suite (durée : env. 12 à 20 heures). Voici les différents graphes ainsi que la config apache... Est ce que quelqu'un a une idée?... Merci.

(les données concernant le serveur, qui avaient été publiées au moment de la discussion, ont été supprimées ensuite par sécurité)
 
WRInaute accro
juste un question c'est ton .htaccess le code ou ton .HTTPD.CONF, si c'est la cas il nous manque le HTTPD.conf du serveur, en suite moi j'avais des plantage aléatoire à cause d'un module PHP qui en fait n'était pas correctement installer c'était MODULE PHP Zip, qui n'a rien à voir avec gzip, car en fait le module php zip avait des fichier qui manquait, j'ai retiré le module en question est s'était fini, moins de plantage.

ils nous manque aussi les states de:
apache_error.log
access.log
module-.log
mysql.log

apache_error.log sera très utile pour voir si un ou des fichiers font plantouiller le serveur, et serai aussi utile en plus de access.log pour savoir si y a pas trop de charge serveur à cause d'attaque par de ROBOTS sur internet, exemple ceux qui essayer de pénétré ta base de donner myphpadmin et ou tente d'entre du WP même si tu n'en à pas, ils inventent des répertoire que tu n'a pas sur ton serveur tente d'executé des fichier .exe que tu n'a pas.

perso moi depuis que j'en ai mis en Deny from, mon serveur à tendance à ne plus planter à causes des attack incessantes.
 
WRInaute impliqué
Ok, alors:

- http.conf : vide.
- appache error log:

Au moment du crash :
(les données concernant le serveur, qui avaient été publiées au moment de la discussion, ont été supprimées ensuite par sécurité)

- Le access_log : il y a plus de 50 sites sur ce serveurs, dont certains à fort traffic, les logs font chacun plus de 200Mo donc difficile de les poster ici :(

- module-.log : inexistant
- Mysql.log : vide

Qu'est ce que tu veux dire par "depuis que j'en ai mis en Deny from"?
Merci

PS: pour info j'ai déjà essayé de mettre le MaxClients de apache sur 512 mais arrivé à 512 sur le graphe, le serveur rame à mort...
 
WRInaute accro
j'ai interdit l'accès à un grand nombre de serveur qui tentais de hacker mon site internet, sauf que de hacker au mieux le serveur apache tombais.
 
WRInaute accro
une question comme ça, lorsqu'un client se connecte au serveur, une fois que le client n'est plus connecter du serveur, le serveur arrive t-il à comprendre que la connexion du client est arrêter.

genre j'imagine la chose suivante, un visiteur arrive sur le site, fait se qu'il à affaire, sauf que dans certaines condition, dans certains cas , lorsque le visiteur quitte le site internet, le serveur APACHE considère que la session du client est toujours là, en gros il ne kill pas les tache des clients qui ne répondent plus passer un certain délai, et à mon avis cela peut arrive dans certains cas bien spécifique.


donc en gros dans certains cas les connexions reste active même si y a plus de client connecter dessus, du coup les thread ne sont pas killer automatique à la fin de chaque connexion client ou au bon d'un délai de non réponse du coté client.

édit: question photo N°3 dans Number OF Process, zombies currents=46.2m AVG=353.38m, cela signifie quoi, que se sont des processus orphelin( pourquoi ça me rappel un sketch de KAMELOTE ça!!

(les données concernant le serveur, qui avaient été publiées au moment de la discussion, ont été supprimées ensuite par sécurité)

re-édit: et uninteruptible, cela signifie t-il qu'il y a des threads que APACHE ne peux interrompre pour une raison inconnu
 
WRInaute accro
ben le .HTACCESS, mais c'est mal, normalement ça devrait etre l'inverse, car j'ai lu sur le forum de WAMP serveur que .HTACCESS était plus lourd à gérer que HTTPD.CONF, donc en fait il devrait copier et vider sont .HTACCESS et remplir sont HTTPD.conf, enfin c'est que mon avis, c'est pour ça que j'ai posé la question pour le httpd.conf.

en fait, on ne doit utiliser le .htaccess que et uniquement sur du mutualiser ou on à pas accès à httpd.conf, c'est ça que j'ai lu sur un autre site internet.

edit: en suite éventuellement se que je recommanderais, c'est soit via httpd.conf ou via .htaccess d’interdir cet liste de serveur( je sent que je vais me faire censuré par un modo m'enfin bon)

Code:
Deny from 65.60.42.250
Deny from 75.146.48.33
Deny from 174.129.241.217
Deny from 81.31.228.242
Deny from 207.241.227.98
Deny from 208.94.146.80
Deny from 50.28.7.169
Deny from .rock.to
deny from www.rock.to
Deny from 212.100.253.3
Deny from 108.59.8.70
Deny from 1.214.50.116
Deny from 81.214.50.116
Deny from 58.218.199.
Deny from 58.218.199.227
Deny from 90.44.17.100
Deny from 58.218.199.227
Deny from 79.98.16.81
Deny from 221.132.36.24
Deny from 221.132.36.
Deny from 221.132.3
Deny from vodkavodka.net
Deny from .startdedicated.com
Deny from startdedicated.com
Deny from .network-consulting.fr
Deny from network-consulting.fr
Deny from 58.218.199.147
Deny from 58.218.199.227
Deny from 91.226.212.41
Deny from 58.218.199.250
Deny from 91.226.212.41
Deny from 92.240.68.96
Deny from mail.hq42.net
Deny from mail.ebookhost.com
Deny from 21.202.248.220
Deny from 220.248.202.21
Deny from 76.218.104.153
Deny from 184.74.162.26
Deny from 178.22.4
Deny from 208.80.192
Deny from 208.80.194
Deny from 208.80.199
Deny from 68.192.228
Deny from .kimsufi.com
Deny from ks311135.kimsufi.com
Deny from ool-44c0e478.dyn.optonline.net
Deny from .dyn.optonline.net
Deny from dyn.optonline.net
Deny from .optonline.net
Deny from optonline.net
Deny from a81.ip.network-consulting.fr
Deny from .network-consulting.fr
Deny from network-consulting.fr
Deny from www.googlealert.com
Deny from ferdowsi.um.ac.ir
Deny from .um.ac.ir
Deny from um.ac.ir
Deny from .ac.ir
Deny from ac.ir
Deny from 217.219.244.41
Deny from 217.219.244.
Deny from 115.239.227.
Deny from 182.236.160.
Deny from 173.45.65.157
Deny from 99.125.252.
Deny from 99.125.252.193
Deny from 119.63.196.
Deny from 119.63.196.24
Deny from 119.63.196.18
Deny from 119.63.196.27
Deny from 176.53.16.10
Deny from 176.53.16.
Deny from 61.150.76.240
Deny from 209.172.34.155
Deny from 209.172.34
Deny from hosted-by.leaseweb.com
Deny from dynamic.chello.pl
Deny from .chello.pl
Deny from chello.pl
Deny from 9e.41.2d.static.xlhost.com
Deny from .static.xlhost.com
Deny from .xlhost.com
Deny from xlhost.com
Deny from 99-125-252-193.lightspeed.hstntx.sbcglobal.net
Deny from server.hedefbulten.com
Deny from hedefbulten.com
Deny from .lightspeed.hstntx.sbcglobal.net
Deny from .hstntx.sbcglobal.net
Deny from .sbcglobal.net
Deny from sbcglobal.net
Deny from netznutz.net
Deny from websitevalue.us
Deny from pornel.net
 
WRInaute impliqué
mipc: je ne sais pas, ce sont les graphes apr défaut de Munin, je ne sais pas interprêter toutes les indications... :(
Pour les sessions, oui, ça pourrait coller, mais comment savoir si c'est le cas? Comment faire pour que les sessions soient tuées après qu'elles ne soient plus utilisées?...
 
WRInaute impliqué
salva a dit:
Recif a dit:
- http.conf : vide.
Si ton httpd.conf est vide, quel est le fichier qui gère apache ?

Que donne (si installé, sinon à installer)
Code:
/etc/mysql/tuning-primer.sh

Le apache2.conf, non?...
tuning-primer.sh : pas installé et jamais réussi à l'installer... Mais ce n'est pas MySQL qui pose problème ici, c'est bien apache.
 
WRInaute accro
Recif a dit:
mipc: je ne sais pas, ce sont les graphes apr défaut de Munin, je ne sais pas interprêter toutes les indications... :(
Pour les sessions, oui, ça pourrait coller, mais comment savoir si c'est le cas? Comment faire pour que les sessions soient tuées après qu'elles ne soient plus utilisées?...


et bien normalement, pour chaque session ouvert, c'est automatique si au bout de X secondes, le client ne répond pas, c'est qu'il n'est plus connecter, après le problème peux n’apparaître que sous certaines conditions bien spécifiques et particulières.
 
WRInaute impliqué
mipc a dit:
et bien normalement, pour chaque session ouvert, c'est automatique si au bout de X secondes, le client ne répond pas, c'est qu'il n'est plus connecter, après le problème peux n’apparaître que sous certaines conditions bien spécifiques et particulières.

Oui, j'ai bien compris le principe, mais comment fait on pour régler ça?...
 
WRInaute accro
Recif a dit:
mipc a dit:
je sent que je vais me faire censuré par un modo m'enfin bon)
Pourquoi tu te ferais sensurer??


la dernière fois je créer un topic pour dire que y a un gars sous VPN qui tente plus de 10fois de hack mon site en tentand d'accéder WP et myphpadmin (ça tombe bien j'en ai pas) et un modo à remplacer le nom du serveur et l'ip par des X, m'en fout j'en ait parler sur google+.

edit: tu sais moi je début en APACHE, je suis un béotien, je suis en apprentissage, à par émettre des théories mêmes bonnes, je ne suis pas asser calé, alors si j'ai vraiment du temps je peux chercher la solution sur internet, mais si non posé la question un WEEK end sur un forum, même les GEEK on une vie de famille.
 
WRInaute accro
'register_globals' is deprecated in PHP 5.3 and greate
'register_long_arrays' is deprecated in PHP 5.3 and greater
'magic_quotes_gpc' ...

Tu as changé (updaté) la version de php juste avant que les problèmes arrivent ?
 
WRInaute passionné
(certaines indications ont été supprimées pour des raisons de sécurité)

Après je vois que ça a l'air d'être MySQL qui en chie, faudrait que tu passes des coups de FULL PROCESSLIST voir ce qui bouffe autant...

Que donne la commande :
Code:
netstat -tanpu|grep SYN_RECV |wc -l

Est-ce que tu peux me sortir un :
Code:
ls /etc/apache2/mods-enabled/
Je sens que t'as pleins de modules à désactiver, ça ferait du bien ;)
 
WRInaute impliqué
Bonjour Julia41,

Ok, j'ai modifié les deux parametres.

netstat -tanpu|grep SYN_RECV |wc -l = 14

ls /etc/apache2/mods-enabled/
(liste supprimée)

Par contre hier soir j'ai mis le parametre MaxRequestsPerChild sur 2000 (avant il était sur 0) et dans les courbes, j'ai l'impression que maintenant ça plafonne à mi hauteur de ce qu'il y avait avant... Mais bon, il est encore trop tôt pour crier victoire :wink:
 
WRInaute accro
ben c'est évident parce que MaxRequestsPerChild à 0, ça veut dire illimité, alors que MaxRequestsPerChild à 2000, ça veut dire que ça ne dépassera pas 2000 requête maximum par enfant.

edit: et une petite recherche google plutard: http://httpd.apache.org/docs/2.0/mod/mpm_common.html

https://www.webrankinfo.com/forum/t/article-bien-configurer-apache.63439/

MaxRequestsPerChild : ce paramètre fixe la limite du nombre de demandes qu'un processus apache satisfera en générant un processus fils avant de mourir. Il faut savoir qu’un processus fils consomme plus de mémoire après chaque demande.

Si MaxRequestsPerChild vaut 0, alors le processus ne meurt jamais, sa taille augmente au fur est en mesure des demandes et vous vous retrouvez avec la mémoire du serveur saturée et apache qui ne réponds pratiquement plus.

Si MaxRequestsPerChild vaut 1, alors le processus meurt après chaque service. Le nouveau processus crée pour repondre au client utilise un minimum de mémoire mais en contrepartie, sa génération est plus lente.

Le choix de cette valeur est un compromis entre l’utilisation mémoire et la vitesse d’exécution. Moins votre contenu est dynamique, plus haute peut être la valeur de ce paramètre. Si la valeur est trop faible, vous consommerais beaucoup de CPU pour créer des processus, si elle est trop élevée vous verrez augmenter la taille de vos processus apache. Gardez à l’esprit que plus vos processus apache sont lourds plus vous serez emmené à réduire le MaxClients.

Pour déterminer la valeur la plus appropriée il vous faudra faire des tests de valeurs entre 50 et 1000 selon votre utilisation du serveur. Lors d’une commande "ps aux –sort :rss" observez la durée de vie de vos processus apache et considérez en regard la taille des processus, cela vous donnera des pistes.
 
WRInaute passionné
T'as vraiment besoin de tous ces modules ?
ruby
dav*
geoip
...
Un bon inventaire et nettoyage ferait du bien je pense :p
 
WRInaute impliqué
Geoip oui.
Dav et ruby je sais pas ce que c'est...

Mais bonne nouvelle: Le graphe est maintenant correct depuis les modifs!

(image supprimée)
 
WRInaute accro
A propos des messages d'erreur que je citais plus haut, tu devrais en chercher la source (cela peut être les sites hébergés qui ne sont pas full compatible avec ta version php (d'où ma question sur le changement de version)) pour éviter de gonfler tes fichiers de log. Les fichiers de log mal contrôlés peuvent saturer le disque (j'ai eu le cas) donc finir par plomber les perfs du système. Des disques saturés, peuvent aussi influer sur le comportement au travers du swap (qui est sur disque) dès que la mémoire physique est trop sollicitée (ou trop faible) bref c'est un point a surveiller.
 
WRInaute impliqué
zeb: oui, je vais regarder. Mais pour les disques, j'ai presque 1To de libre encore. Mais tu as raison, il faut que je regarde ça.
 
WRInaute accro
Recif a dit:
zeb: oui, je vais regarder. Mais pour les disques, j'ai presque 1To de libre encore. Mais tu as raison, il faut que je regarde ça.
1 To de libre sur ton serveur soit, mais combien pour le compte qui permet de faire fonctionner apache ?
 
WRInaute accro
Leonick a dit:
Recif a dit:
zeb: oui, je vais regarder. Mais pour les disques, j'ai presque 1To de libre encore. Mais tu as raison, il faut que je regarde ça.
1 To de libre sur ton serveur soit, mais combien pour le compte qui permet de faire fonctionner apache ?
Et sachant que dans certains cas les logs peuvent se trouver sur une partition donnée qui elle est peut être "juste".
 
WRInaute impliqué
zeb a dit:
Et sachant que dans certains cas les logs peuvent se trouver sur une partition donnée qui elle est peut être "juste".

Non, là c'est bon, les logs sont sur la partition qui a cet espace disque.
 
Discussions similaires
Haut