problème : apache ne ferme pas ses conections mysql !!?

[neglau]

j'ai un probleme depuis la fin de la semaine derniere.
mon serveur web apache qui tourne sous une redhat 9 avec mysql et php
et tres tres tres lent ! apres avoir verifier un peut le systeme je remarque que le nombre de process apache et au max. En regardant les process mysql il aparait qu'il y en a tout autant !! il devraient se fermer apres chaque utilisation dans une page php mais il ne le font pas (les process mysql) il reste donc en memoire en mode sleep pendant 80s (je pense que c'est le max avant d'etre arreté par mysql lui même). le proc est a 100% aussi ! en general 20% a 30% pour mysql et le reste repartit dans les process httpd.

je me suis dis que c'etait un probleme avec mes versions qui etait un peut vielles ! donc mise a jour des tous les programmes :
- apache, mysql, php !
mais rien n'a changer !
je decide des passer sur un serveur de secour (avec heartbeat) le proc est plus petit AMD 1800+ et 512 Mo (contre 2600+ et 1Go pour le serveur principal). La aucun soucis que ce soit avec les anciennes versions et les nouvelles versions) !!!

donc ou peut se situer le problème d'apres vous ?

l'ajout de 512mo au serveur principal n'a rien changer !
la seul solution (qu'i n'en est pas une est de relancer apache et la tout repart a zero et le serveur tourne bien mais pour une dizaine de minutes avec d'etre a nouveau saturé par mysql)

(j'utilise mysql_connect et non mysql_pconnect pour ceux qui le demanderais

version des softs actuel :
apache 1.3.33
mysql-max-4.0.23-pc-linux-i686
php-4.3.10

toute aide sera la bien venue !

Merci d'avance

Laurent

[mad_dog]

SAlut ..

le problème ne viendrait'il pas des connexions persistentes à MYSQL configuré dans PHP ???
regarde la conf. de ton PHP via un phpinfo();

[Gm_Gari]

l'emploi de mysql_close ne serait-il pas suffisant

[neglau]

mysql_close n'y fait rien !!

le probleme n'y est que depuis vendredi !! avant aucun probleme. Idem sur le serveur de secours, no problem.

pour ce qui est de la config php il est vrai que dans le fichier de config les conexction persistente etait a On mais la mise a off n'a rien changer !!

[neglau]

bon la resolution n'est pas totale car en fait un deuxieme serveurs etait connecté a la base mysql pour la replication de celle ci. il pouvait aussi remplacer le sereur si celui ci tombait en panne avec heartbeat !
il se trouve qu'apres reinstalation de ce serveur secondaire j'ai du recopier la base mysql du primaire sur ce secondaire. j'ai au passage fait un "flush master" pour vider les log de replication et tout est rentrer dans l'ordre depuis la fin de l'install !
probleme des log de replication non vide depuis longtemp ou pb sur le serveur secondaire qui faisait bugguer le principal ? je ne sais pas trop ! je verrais si le probleme se pose a nouveau d'ici quelque mois !

[neglau]

le probleme est revenu ! quelques jours et est repartis deux jours puis est de nouveaux la depuis samedi matin !!!
voila diffrente infos de mon systeme !
mysql> show FULL PROCESSLIST;
+--------+---------------+--------------------+-----------+-------------+------+-----------------------------------------------------------------------+-----------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+--------+---------------+--------------------+-----------+-------------+------+-----------------------------------------------------------------------+-----------------------------------------------------------+
| 1 | system user | | NULL | Connect | 3522 | Waiting for master to send event | NULL |
| 3 | root | localhost | mysql | Query | 0 | NULL | show FULL PROCESSLIST |
| 4 | MDF-replicate | l_LINUX-MDF2:33801 | NULL | Binlog Dump | 3468 | Has sent all binlog to slave; waiting for binlog to be updated | NULL |
| 7 | system user | | NULL | Connect | 3401 | Has read all relay log; waiting for the I/O slave thread to update it | NULL |
| 289816 | mdpweb | localhost | mdpnew | Sleep | 7 | | NULL |
| 289860 | mdpweb | localhost | mdpnew | Sleep | 7 | | NULL |

.......

| NULL |
| 290597 | mdpweb | localhost | mdpnew | Sleep | 1 | | NULL |
| 290599 | mdpweb | localhost | mdpnew | Sleep | 1 | | NULL |
| 290602 | mdpweb | localhost | mdpnew | Sleep | 1 | | NULL |
| 290624 | immouser | localhost | iws | Query | 1 | NULL | NULL |
| 290642 | immomain | localhost | NULL | Connect | NULL | login | NULL |
| 290704 | mdpweb | localhost | mdpnew | Sleep | 1 | | NULL |
| 290707 | mdpweb | localhost | mdpnew | Sleep | 1 | | NULL |
| 290728 | mdpweb | localhost | mdpnew | Sleep | 0 | | NULL |
| 290741 | mdpweb | localhost | mdpnew | Query | 0 | cleaning up | SELECT site_nom FROM sites_infos WHERE site_id = '93' |
| 290742 | immomain | localhost | iws | Query | 0 | NULL | NULL |
| 290748 | mdpweb | localhost | mdpnew | Query | 0 | NULL | NULL |
| 290757 | mdpweb | localhost | NULL | Connect | NULL | login | NULL |
| 290758 | immomain | localhost | NULL | Connect | NULL | login | NULL |
| 290759 | mdpweb | localhost | NULL | Connect | NULL | login | NULL |
| 290760 | immomain | localhost | NULL | Connect | NULL | login | NULL |
| 290763 | mdpweb | localhost | mdpnew | Query | 0 | cleaning up | SELECT site_adresse FROM sites_infos WHERE site_id = '93' |
| 290770 | mdpweb | localhost | mdpnew | Query | 0 | preparing | SELECT site_nom FROM sites_infos WHERE site_id = '93' |
| 290771 | mdpweb | localhost | NULL | Connect | NULL | login | NULL |
| 290772 | mdpweb | localhost | NULL | Connect | NULL | login

.........

| 290780 | mdpweb | localhost | NULL | Connect | NULL | login | NULL |
| 290781 | mdpweb | localhost | NULL | Connect | NULL | login | NULL |
+--------+---------------+--------------------+-----------+-------------+------+-----------------------------------------------------------------------+-----------------------------------------------------------+
48 rows in set (0.00 sec)





10:55:33 up 19 days, 18:39, 2 users, load average: 3,01, 3,15, 4,59
96 processes: 92 sleeping, 3 running, 1 zombie, 0 stopped
CPU states: 88,0% user 11,9% system 0,0% nice 0,0% iowait 0,0% idle
Mem: 1548016k av, 1201980k used, 346036k free, 0k shrd, 178116k buff
577368k actv, 171176k in_d, 100816k in_c
Swap: 2040212k av, 7520k used, 2032692k free 664588k cached

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
9111 mysql 25 0 31852 31M 3212 R 9,3 2,0 6:59 0 mysqld
30642 nobody 15 0 14156 13M 2484 S 5,3 0,9 0:03 0 httpd
6120 nobody 16 0 13892 13M 2272 S 5,1 0,8 0:00 0 httpd
30829 nobody 15 0 14196 13M 2344 S 4,9 0,9 0:01 0 httpd
30609 nobody 15 0 13992 13M 2344 S 4,7 0,9 0:02 0 httpd
30912 nobody 15 0 14212 13M 2344 S 4,7 0,9 0:01 0 httpd
30606 nobody 15 0 14212 13M 2400 S 3,9 0,9 0:01 0 httpd
30607 nobody 16 0 14140 13M 2344 S 3,9 0,9 0:02 0 httpd
30608 nobody 15 0 14160 13M 2344 S 3,9 0,9 0:03 0 httpd
30880 nobody 15 0 14384 14M 2436 S 3,9 0,9 0:01 0 httpd
32603 nobody 15 0 14096 13M 2288 S 3,9 0,9 0:02 0 httpd
30633 nobody 15 0 14336 14M 2344 S 3,7 0,9 0:02 0 httpd
30644 nobody 16 0 14028 13M 2344 S 3,7 0,9 0:03 0 httpd
32610 nobody 15 0 13960 13M 2344 S 3,7 0,9 0:02 0 httpd
30687 nobody 15 0 14180 13M 2344 S 3,5 0,9 0:01 0 httpd
6217 nobody 17 0 13880 13M 2284 S 3,1 0,8 0:00 0 httpd
30703 nobody 15 0 14260 13M 2344 S 2,9 0,9 0:01 0 httpd
30610 nobody 15 0 14288 13M 2344 S 2,3 0,9 0:01 0 httpd
6347 nobody 17 0 13828 13M 2272 S 2,3 0,8 0:00 0 httpd
6348 nobody 18 0 13844 13M 2196 S 2,1 0,8 0:00 0 httpd
30894 nobody 15 0 14000 13M 2344 S 1,9 0,9 0:02 0 httpd
30645 nobody 15 0 14028 13M 2364 S 1,1 0,9 0:01 0 httpd


(100% du proc uniquement avec les httpd et mysql)


quelqu'une a une idée !!!

[neglau]

bon j'ai la solution !
apparement php s'entremelle les pincaux qu'on il y a un peut trop d'includes.

le probleme etait que des conection mysql etait perdus par php. Elles etaient encore active et utiliser de la memoire et du proc mais n'etait plus accessible par le code php !
en faite un connection etait ouverte puis plus loin dans le code un include d'include réouvrer la même connection !
j'ai suprimmé ca et tout est rentré dans l'ordre !

probleme de codage ?
bug de PHP ? peut etre etant donne que si on ouvre plusieurs fois la même conection sans que ce probleme ce reproduise dans un même fichier (pas dans des includes).

voila !