Apache/PHP/MySQL : 44 Mo par process httpd ?

Bon, t’es desesperant la.

Je te prouve par A+B= l’age du capitaine que tu t’es plante grave, et tu trouve le moyen de dire nawak? T’as lu ce que j’ai ecrit? Le serveur tient 200 requetes a la seconde en local, et la page est toujours la meme. c’est clair? Faut que je te fasse un dessin?

180ko/s dans un tuyau qui fait max 100ko/s, c’est pas possible, et tes resultats sont biaises a cause de ca.

Sinon, pour ton « argement », considerant 50 requetes/secondes:

Tu m’expliques pourquoi moi, en local, je trouve ca:

Et moi, 200 requetes.
Putain, c’est bizarre, on trouve pas la meme chose. Comment c’est possible? Peut etre parce que JUSTEMENT, je me suis affranchi de l’upload de 100ko/s de GB, tu crois pas?

Ca n’empeche pas que je testerais pour apache compile/source. M’enfin je trouve que t’as oublie de me fournir la ligne de compile de mysql: dans les 3 softs apache, php et mysql, je dirais que celui qui a le plus de chance de tout faire ramer, c’est mysql…

LoneWolf
Tu t’enfonces, garcon. :stuck_out_tongue:

[quote name=‘unreal’ date=’ 23 Mar 2005, 19:07’]Normalement c’est impossible d’avoir des memory leak avec apache sous unix. Il marche par folk, donc les processus sont detruits tres frequemment.
[right][post=“343669”]<{POST_SNAPBACK}>[/post][/right][/quote]

Admettons… mais alors pourquoi mes process pèse 20 Mo maintenant ? (moins d’une semaine pour gagner plus de 10 Mo)
Galère, je vois pas comment trouver la source du problème. Le serveur est en prod. et je peux pas m’amuser à le customiser dans tous les sens pour dichotomiser mes dépenses mémoires…

Antoine

Surtout que c’est absolument faux, les process ne sont pas recrees tres souvent, ca serait beaucoup trop couteux en terme de ressources. Un process comme ca c’est lourd, c’est cher, c’est lent. Les process viennent d’une process pool de taille variable qui sont crees a l’avance (comme dans un web serveur bases sur du multi thread les threads viennent d’un thread pool) et qui sont donc recycles. Il est absoluement possible d’avoir une fuite memoire qui fait grossir la taille de process. Juste un detail, mais ca vallait la precision je crois :stuck_out_tongue:

Ca depend de la config du serveur Apache…

[quote]# MaxRequestsPerChild: the number of requests each child process is

allowed to process before the child dies. The child will exit so

as to avoid problems after prolonged use when Apache (and maybe the

libraries it uses) leak memory or other resources. On most systems, this

isn’t really needed, but a few (such as Solaris) do have notable leaks

in the libraries. For these platforms, set to something like 10000

or so; a setting of 0 means unlimited.

NOTE: This value does not include keepalive requests after the initial

  request per connection. For example, if a child process handles

  an initial request and 10 subsequent “keptalive” requests, it

  would only count as 1 request towards this limit.[/quote]

Source : httpd.conf

Et sinon, je me plante p-e mais je pense que les options “MinSpareServers” et “MaxSpareServers” devraient imposer un renouvellement des processus :

[quote]# If there are fewer than MinSpareServers, it creates

a new spare.  If there are more than MaxSpareServers, some of the

spares die off.[/quote]

Ceci dit, si vous avec un site qui explique clairement pourquoi c’est pas ca, je veux bien…

Sous Linux grace entre autres au copy-on-write des pages memoires (toutes les pages memoire sont partagee entre les 2 process, jusqu’a ce qu’un des 2 process tente d’ecrire), un fork est super rapide et c’est pas une operation tres tres couteuse en memoire ou cpu. Pour un serveur web comme apache, c’est un peu mieux en pre-forkant, mais a mon avis ca pourrait quand meme fonctionner a une vitesse correcte en forkant a chaque fois (mais c’est loin d’etre le cas sous Solaris).
Sinon, ouais, comme l’a dit Unreal, un proces sert un nombre limite de requetes avant de mourrir, donc nouveaux process assez regulierement …

[quote name=‹ BokLM › date=’ 30 Mar 2005, 20:04’]Sous Linux grace entre autres au copy-on-write des pages memoires (toutes les pages memoire sont partagee entre les 2 process, jusqu’a ce qu’un des 2 process tente d’ecrire), un fork est super rapide et c’est pas une operation tres tres couteuse en memoire ou cpu. Pour un serveur web comme apache, c’est un peu mieux en pre-forkant, mais a mon avis ca pourrait quand meme fonctionner a une vitesse correcte en forkant a chaque fois (mais c’est loin d’etre le cas sous Solaris).
Sinon, ouais, comme l’a dit Unreal, un proces sert un nombre limite de requetes avant de mourrir, donc nouveaux process assez regulierement …
[right][post=« 345707 »]<{POST_SNAPBACK}>[/post][/right][/quote]
Parceque c’est clair qu’un process comme Apache ecrit jamais en memoire :stuck_out_tongue: Minimiser le cout initial et le decaler a plus tard ne change rien. Le cout des context switch est toujours enorme, le cout des fautes de pages dans le(s) cache(s) du CPU aussi. Y a des fois faut juste arreter de vouloir justifier n’importe quoi, alors qu’il y a meme pas besoin de justifier quoi que ce soit. « ca pourait fonctionner a vitesse corecte en forkant a chaque fois » mais bien sur, et puis des I/O synchrones de partout aussi tient tant qu’on y est. Apres tout le server web que tout etudiant fait en Java ou en C dans ses etudes en projet marchait tres bien… :stuck_out_tongue: Heureusement que certains s’en contentent pas. Et dans le meme genre « les memory leaks meme pas mal sous apache » faut arreter deux secondes de raconter n’importe quoi d’aussi irrealiste. Oui les process sont recycles apres un certain nombre de requetes, genial, evidemment, tu fais pas du trois 9 sans des mesures de ce genre. Mais la limite est d’ailleurs par defaut haute (10 000 sans compter les keep-alive), autant dire que avec presque une dizaine de process lance, tu peux tourner longtemps sans recycler un seul process. « Assez regulierement » est tres relatif, on parle d’a peine une fois par jour pour beaucoup de sites. Leak 1Ko a chaque requete (pas enorme…) et tu as perdu 10 megas par process avant de recycler, fais 4 requetes par keep-alive (la moyenne sur la plupart des serveur est bien au dessus de 4) et t’as perdu 40 megs par process. Une leak peut toujours etre un GROS probleme et ce systeme ne le camouflera pas, ca l’empechera juste de tout fouttre en l’air. J’ai passe 1 an de ma carriere a ecrire un module apache sous linux, j’ai une vague idee de comment ca marche, c’etait pas une attaque contre Apache et d’autre implementations ont d’autre problemes qui sont pris en compte de differente maniere…

Et SI un process systeme est toujours TRES lourd. Linux ou pas, pfff. Ce genre de pseudo debat est d’un ridicule, c’est n’importe quoi. Si encore on parlait des merites des differences d’implementation POSIX et process lourd entre le kernel linux et win, ca aurait un interet, on pourrait apprendre des trucs…

Ca doit d’ailleurs surement etre parcequ’un process ca coute si peu sous linux que Apache 2 est multi threade et que c’est ce changement architectural majeur qui fait passer la version de 1.x a 2.x. Je cite:

The original reason for creating Apache 2.0 was scalability, and the first solution was a hybrid web server; one that has both processes and threads. This solution provides the reliability that comes with not having everything in one process, combined with the scalability that threads provide.

C’est tellement leger que parfois, meme les threads sont consideres trop lourds et qu’on invente des concepts tels que les « fibers » (que pas mal de programmeurs connaissent pas encore). Les bases de donnes a haut volume fonctionnent pas mal sur de tels concepts. Chaque solution a ses avantages et ses inconvenients, process, threads, fibers ainsi que chaque implementation de chacun de ces concepts sur les differents OS a ses avantages et ses inconvenients. Qui sont, en plus, indissociables de l’implementation du scheduler. Autrement dit, avant de pouvoir en discuter serieusement il y a beaucoup de chose a apprendre et etonnament des gens qui savent, j’en ai pas vu un seul troller en terme tranches sur telle ou telle autre implementation serieuse. Resumer ca a une sorte de « machin roulaize, trop balaise, parceque X », c’est du concour de grosse bite qui apprend rien a personne.

[quote name=‘AntoineViau’ date=’ 29 Mar 2005, 12:55’]Admettons… mais alors pourquoi mes process pèse 20 Mo maintenant ? (moins d’une semaine pour gagner plus de 10 Mo)
Galère, je vois pas comment trouver la source du problème. Le serveur est en prod. et je peux pas m’amuser à le customiser dans tous les sens pour dichotomiser mes dépenses mémoires…

Antoine
[right][post=“345066”]<{POST_SNAPBACK}>[/post][/right][/quote]

La probabilité d’un leak dans le core de apache lui-même est très faible, c’est un programme très bien implémenté et très bien testé (et en plus la gestion de ses ressources est peut-être la partie la plus sophistiquée, c’est clairement pas un problème qu’ils ont traité par dessus la jambe). En revanche les modules étant des binaires loadés dynamiquement, il est tout a fait possible pour un module de leaker comme un porc dans les process apache. Et étant donné que tu utilises PHP, si j’ai bien suivi, tu as juste là le suspect idéal. PHP est un programme assez gros, qui a cru de façon parfois un peu anarchique, et dont la qualité d’implémentation n’est certainement pas au niveau de apache ou de ses modules de base (qui sont aussi énormément plus petit que PHP), ajoute à ça que PHP lui même peut loader des palanquées d’extensions pour tout et n’importe quoi et tu as juste 99% de chances pour que ça soit le module PHP ou l’une de d’extensions qui soit en train de leaker.
Et non il y a pas solution pratique et facile pour corriger le problème.

Et ben voilà… Je pose une question plein d’innocence et vous me fâchez le Glop :stuck_out_tongue:
(Et mes process sont toujours à 20 Mo…) :stuck_out_tongue:

[quote name=‘GloP’ date=’ 31 Mar 2005, 00:26’]Ca doit d’ailleurs surement etre parcequ’un process ca coute si peu sous linux que Apache 2 est multi threade et que c’est ce changement architectural majeur qui fait passer la version de 1.x a 2.x. Je cite:

The original reason for creating Apache 2.0 was scalability, and the first solution was a hybrid web server; one that has both processes and threads. This solution provides the reliability that comes with not having everything in one process, combined with the scalability that threads provide.[/quote]
Ouais, tellement genial que la conf par defaut d’apache2 sur la plupars des distribs linux c’est d’utiliser les prefork et pas de threads. Et si tu veux utiliser mod_perl ou mod_php t’as pas trop le choix si t’as l’idee d’utiliser par hasard une lib pas thread-safe.
Les thread d’apache2 ca ameliore surement pas mal les performances sur les systemes sur lesquelles creer un nouveau process coute cher, mais sous Linux creer un process ou un nouveau thread c’est quasi la meme chose, donc vu les emmerdes que ca peut t’apporter, en general ca vaut pas vraiment le coup.

[quote]Resumer ca a une sorte de “machin roulaize, trop balaise, parceque X”, c’est du concour de grosse bite qui apprend rien a personne.
[right][post=“345757”]<{POST_SNAPBACK}>[/post][/right][/quote]
Je sais pas ou tu m’as vu resumer ca comme ca.

[quote name=‹ BokLM › date=’ 31 Mar 2005, 02:32’]Ouais, tellement genial que la conf par defaut d’apache2 sur la plupars des distribs linux c’est d’utiliser les prefork et pas de threads. Et si tu veux utiliser mod_perl ou mod_php t’as pas trop le choix si t’as l’idee d’utiliser par hasard une lib pas thread-safe.
Les thread d’apache2 ca ameliore surement pas mal les performances sur les systemes  sur lesquelles creer un nouveau process coute cher, mais sous Linux creer un process ou un nouveau thread c’est quasi la meme chose, donc vu les emmerdes que ca peut t’apporter, en general ca vaut pas vraiment le coup.
[right][post=« 345810 »]<{POST_SNAPBACK}>[/post][/right][/quote]
Mais c’est n’importe quoi, c’est absolument faux (en tout cas dans un kernel 2.x recent, a une epoque linux ne savait pas faire plein de choses en rapport avec les thread, qui etaient geres en user space et pas en kernel space, ce qui voulait dire, en gros, que linux ne supportait pas les threads). Et franchement je voulais pas rentrer dans les details pour pas qu’on m’accuse de troller gratuitement sur linux, mais si c’est pour faire l’apologie de linux, tu choisit HYPER mal ton sujet, les threads et leur implementation par rapport aux autres unix etant un des point les plus noirs de l’histoire du kernel linux. Effecitvement quand les threads ne sont pas implementes dans le kernel, un process c’est pareil qu’un thread et meme avec un fork() super efficace (meme 3 fois plus que sur les autres OS), c’est toujours un process lourd! Difficile de le voir comme un avantage mais si tu insistes…

La config par defaut vient du fait que pour faire quoi que ce soit de ton apache autre que les trucs de base, pages statiques, il faut que tous les modules soient thread safe, ce qui est loin d’etre le cas et que les gens s’arracheraient les cheveux sinon. Toujours est il que de creer un process sous linux est bien plus couteux que de creer un thread. Que la difference soit moins grande que sur d’autre systemes, si tu veux, mais faut pas raconter n’importe quoi. Le fait que par defaut, 99% des modules soient pas thread safe et que donc si tu veux faire qqch de ton apache tu sois oblige de repasser en mode « comptatibilite », ne change rien au bordel. Je vois pas d’ou vient ce mythe qu’un process est equivalent a un thread sous linux mais c’est purement et simplement n’importe quoi (enfin si je sais d’ou ca vient, d’un vieil article d’ITWorld qui expliquait que comme linux avait un fork plus rapide que sur d’autre systemes, linux avait meme pas besoin de threads :stuck_out_tongue: rajoute a ce la fait que les threads ont traditionnellement ete mal implementes et un ajout relativement recent sous linux et t’as le coeur du mythe). Au final NPTL est bien plus rapide qu’un process lourd. Suffit de matter le code, puisque tu peux l’avoir sous les yeux, ou de faire un peu de lecture en cherchant « thread process linux » ou juste NPTL sur google…

[quote name=‹ GloP › date=’ 31 Mar 2005, 02:59’]Je vois pas d’ou vient ce mythe qu’un process est equivalent a un thread sous linux (enfin si je sais d’ou ca vient, c’est que les threads ont traditionnellement ete mal implementes et un ajout relativement recent sous linux) mais c’est purement et simplement n’importe quoi. Suffit de matter le code, puisque tu peux l’avoir sous les yeux.
[right][post=« 345819 »]<{POST_SNAPBACK}>[/post][/right][/quote]
Ben oui, je l’ai regarde le code puisque justement j’ai eu a patcher un truc de ce cote la. Et c’est la meme fonction qui est utilise pour creer un thread (avec l’appel system clone) ou un fork, y a juste quelques flags qui sont differents pour dire ce qui doit etre partage entre les 2.

Aller, puisque tu veux pas me croire, c’est meme ecrit sur cette page :

LinuxThreads follows the so-called « one-to-one » model: each thread is actually a separate process in the kernel. The kernel scheduler takes care of scheduling the threads, just like it schedules regular processes. The threads are created with the Linux clone() system call, which is a generalization of fork() allowing the new process to share the memory space, file descriptors, and signal handlers of the parent.

Si maintenant ils se mettent a raconter des mythes directement dans la doc des LinuxThread …

Ca fait super longtemps que Linux supporte les threads en kernel, sur cette page ils parlent de linux 1.3.56, donc pas vraiment recent.

N’importe quoi.

Sauf que comme dans tout bon OS, les threads sont implementes dans le kernel.

C’est genial :stuck_out_tongue: D’abord c’est plus vrai avec les kernels recents qui supportent la NPTL, ensuite l’argument est quand meme a mourir de rire. (edit: je corrige le quote parle en fait du mode de mapping 1:1 de la gestion du scheduler par rapport aux threads - j’ai trouve le reste du contexte sur google…).

Si hier un thread et un fork etaient la meme chose, le tout a la vitesse d’un fork dans le kernel, au final t’as tout mis a la vitesse d’un gros bon vieux fork() bien lent (par rapport a un VRAI thread), aujourd’hui c’est plus le cas. Que certains en profitaient pour dire que du coup on avait pas besoin de threads et que les process marchaient aussi bien qu’un thread est carrement du foutage de gueule. D’autant plus que les threads aujourd’hui sous linux marchent bien et enterrent le fork en terme de performances et ca marche nikel (a quelques petits details pres, cf la page du post d’avant)! Plus besoin de critiquer les threads, ou de dire c’est pareil.

Tu fais l’aplogie d’un truc qui a plus lieu d’etre bases sur des raisons qui de toute facon ne tenaient pas debout. Non un process c’est pas aussi leger qu’un thread, oui un thread ca dechire un process et oui, meme sous linux. Aujourd’hui il y a meme plus de debat ou de polemique, ils ont fait le bon choix dans l’implementation du kernel (quoi que le mapping 1:1 scheduleur par rapport a M:N se discute surtout de maniere academique ou le M:N est theoriquement superieur, mais bon ca reste marginal et apparement sans reels effect d’apres leur tests).

Au passage j’ai edite mon message precendent avec plus de details et au passage, bis, les Yes de ta page est assez comique, supporter les threads sans etre vraiment re-entrant, bien sur, joli! J’ai pas dit que c’etait recent, j’ai dit « les kernel 2.x recent », les premiere tentatives d’implementations pour dire « on supporte les threads » ne datent effectivement pas d’hier, encore faut il voir comment. Le recent (relativement parlant, 2002/2003) developpement de tout le projet NPTL est l’evidence la plus criante de cet etat de fait.

Le débat est intérressant mais on s’éloigne pas mal du sujet la.
Néanmoins, je rejoins glop sur sa position.

Pour le monsieur qui veut savoir pourquoi son apache il mange beaucoup sa ram :

peut etre un leak mémoire du a php.

as tu recompilé ton php en fonction de tes besoins deja ?
fais un phpinfo , regarde la liste des modules php supportés et vire ceux que tu sais que tu n’auras pas besoin.

Oui Sparc a absoluement raison, desole du deviage de thread :stuck_out_tongue:

A mon avis et comme l’a tres bien explique eshel, je pense qu’il faut que tu regardes du cote de php et de ses modules, vire tout ce qui est pas necessaire et qui pourrait avoir une fuite. Une fuite de apache lui meme est hautement improbable, mais un module ou une lib d’un module alacon™ est tout a fait possible et expliquerait ton bordel…

Bonne chance!

Je reviens au sujet initial, même que c’est moi l’ai initié (d’abord !) pour vous dire que le problème est résolu.
Comment ? Simple mise à jour de PHP 4.3.xx et Apache 1.3.yy (xx=8 vers 11 et yy=31 vers 33).
Depuis, mes process font 11 Mo et ne bougent pas. J’ai content.

Antoine