serveur lent

[Dan]

dan serait-il passé par là ? :-)

Oui, ce matin pour réviser à la baisse certains paramètres de mysql vu la taille mémoire limitée du serveur...

[Berberber]

Cela resoudrait-il des problemes, si je passais de superplan au superplan + (doublement de la memoire)

ps: dan, on a refait des essais, mais on arrive tjrs aux memes mauvais resultats

[valdo]

Quand je regarde le top, je constate que mysql prends beaucoup de CPU.

De plus je me dis qu'il est toujours normal que le temps de CPU de kswapd soit important vu que c'est quand le processus qui sert le plus dans un systeme d'exploitation.

Ensuite je me demande comment sont créés les index dans 4images.

Et je me dis que s'ils sont créés sur des colonnes qui contiennent beaucoup de données alors il faut bcp de CPU a MySQL pour les créer. De plus un index prends toujours de la mémoire.

Ensuite peut-être qu'il faudrait regarder aussi le format des tables.

Et comment expliquer aussi le fait qu'apache prenne aussi bcp de CPU ?

EDIT: Au fait essaie plutot de passer par ton compte vu que tu es aussi dans wheel.

Laurent

Modifié 7 Juin 2004 par valdo

[Dan]

De plus je me dis qu'il est toujours normal que le temps de CPU de kswapd soit important vu que c'est quand le processus qui sert le plus dans un systeme d'exploitation.

Alors il faut croire que le serveur du Hub est une exception, parce que ce processus ne prend même pas une seconde de CPU par semaine ...

    4 root       9   0     0    0     0 SW    0,0  0,0   0:00 kswapd

Ce processus ne consomme du CPU de manière significative que si le serveur "swappe"... donc quand il manque de RAM.

Et comment expliquer aussi le fait qu'apache prenne aussi bcp de CPU ?

Comme sur les configs OVH Apache est compilé avec php, c'est vraisemblablement le code exécutable php qui consomme (et s'affiche comme httpd).

[Berberber]

bon, j ai contacte OVH pour passer en offre superieure....

dans l'espoir d une amelioration,

Bernhard

[Dan]

Berberber,

J'ai changé les paramètres apache MaxClients et MaxRequestsPerChild ....

Relances ta simulation et dis-moi ce que ça donne.

Dan

[valdo]

Alors il faut croire que le serveur du Hub est une exception, parce que ce processus ne prend même pas une seconde de CPU par semaine ...

C'est bien ce que je dis. Il est normal que le processus swapd prenne beaucoup de temps CPU lorsque le serveur utilise beaucoup de mémoire. Quand les processus allouent beaucoup de mémoire (cela dépends du serveur), alors kswapd utilise beaucoup de temps CPU. Si un quelconque serveur fait beaucoup de choses (ce qui arrive souvent, mais dépends aussi de la config et de l'utilisation) alors kswapd prendra beaucoup de CPU. Ce qui me fait dire que dans le cas d'une utilisation non serveur il est parfois normal de trouver un nombre important de CPU time si l'uptime est elevé.

Je ne dis cependant pas qu'il s'agit d'une logique de fonctionnement normale pour un serveur, mais aussi et surtout qu'il y a un problème quelque part, ce qui a mon avis ne doit pas susciter de passer sur une offre supérieure.

    4 root       9   0     0    0     0 SW    0,0  0,0   0:00 kswapd

Ce processus ne consomme du CPU de manière significative que si le serveur "swappe"... donc quand il manque de RAM.

Oui, mais cela peut aussi être du a des compilations ou au fait que bernhard aie lancé son script phpdig. Il ne faut pas non plus négliger divers effets de bord de l'utilisation qui a pu être faite du serveur. Ceci dit sachant que la base MySQL fait 6 Mo, je me demande pourquoi MySQL prends temps de CPU et de RAM, surtout une fois que les index ont été créés tout devrait fonctionner normalement. Une requete MySQL sur une telle base ne devrait pas faire tant de tointoin.

Laurent.

[Berberber]

Et bien, apres intevention de dan, (merci encore) dans le fichier de configuration apache, je pourrais retitrer ce post serveur rapide....

Tout fonctionne, et je vais proceder a des tests avec visiteurs reels, et editerai ce dernier message si besoin est

[Berberber]

La vie est belle :

le probleme etait du a un bug connu lorsque trop d'images sont dans la galerie avec le generateur d'image aleatoire, suffisait de le desactiver.

Bernhard

[valdo]

Bernhard,

je ne vois pas comment tu aie pu affirmer que Dan aie rendu ton serveur rapide, si quelques jours plus tard tu le trouves toujours aussi lent.

Mine de rien il aura fallu que tu partes de chez ovh et que le staff de cineteck s'intéresse à ton serveur pour que le problème soit résolu.

Comme quoi les problèmes de lenteur sont moins une histoire de paramêtres que d'algorithmique.

Laurent.

Modifié 3 Juillet 2004 par valdo

[Berberber]

et non, j'ai résolu le probleme moi meme, et cela n'a rien a voir avec le serveur, dan a effectivement rendu le serveur plus rapide, mais le probleme empirant avec le nombre de photos, cela n'aura eu qu'un cours effet

[valdo]

Salut,

Il n'empèche tu es bien revenu chez cineteck.

Ne nie pas non plus que tu voulais que Damien intervienne....

Ensuite ce que Dan a fait, grosso modo, c'est de changer les parametres du serveur MySQL, ainsi que d'Apache, mais cela n'a fait que changer les conditions initiales et la pente de la courbe qui définit la charge du serveur en fonction du temps. Ensuite tu affirmes que le problème serait revenu en augmentant le nombre de photos, mais à mon avis il aurait suffit que le serveur fonctionne avec de véritables visiteurs, pendant ne serait-ce qu'une heure pour que le problème réapparaisse.

D'ailleurs il serait intéressant de modéliser ceci en équation différentielle. je suis sur qu'il y a matière à réflexion. On pourrait considérer le nombre de processus initiaux, la fluctuation du nombre de visteurs en fonction du temps, le nombre et le type de pages visitées, le nombre de processus max, le nombre de processeurs du système etc, le nombre d'erreurs... LOL.

Disons que la chose est trop sensible aux erreurs et aux bugs du script pour qu'une quelconque modification de parametres aie une influence sur le fonctionnement du serveur. Je doute que le serveur aie pu converger vers une limite de charge normale, même avec les modifications (bénéfiques) de Dan.

Comme quoi la question la plus critique est l'algorithme utilisé pour faire tourner ton script. La question de la montée en charge est très importante.

Laurent.

PS: A tous ceux qui nous lisent, je précise que je connais très bien berberber, alors on se permet de se disputer et de débattre en toute amitié. Vous pouvez particpier à la discussion.

[Irwan]

La vie est belle :

le probleme etait du a un bug connu lorsque trop d'images sont dans la galerie avec le generateur d'image aleatoire, suffisait de le desactiver.

Bernhard

Bonjour Berberber,

j'ai exactement le même problème que toi, tu peux me dire si tu as réellement trouvé une solution stp ?

Par avance, merci

Au passage, une toute nouvelle version de 4images est sortie voilà quelques jours, voiçi les modifs :

- New caching system (Read docs/Cache.english.txt for further informations)

- Changed session handling to PHP native sessions

- The database table 4images_sessionvars is not longer in use. Removed from

the database dump and from admin/backup.php and includes/contants.php

- Random category image is now disabled by default (define('SHOW_RANDOM_CAT_IMAGE', 0)

- PHP5 compatibility

- Improved GD2 detection

- Improvements on functions in includes/functions.php (i.e. replaced preg_match() with faster str*() functions)

- Replaced preg_match() with faster strpos() in class method Session::url() (includes/sessions.php)

- Change input type to "password" for admin password in installation screen

- Moved registration of {lang_user_online} and {lang_user_online_detail} from includes/page_header.php to includes/sessions.php

- Added display of the category ID in the overview in Control Panel

- Splitted query for $cat_cache due to performance reasons (global.php)

- Bugfix: Deleting of not activated users (http://www.4homepages.de/forum/viewtopic.php?t=9508)

- Bugfix: Database backup failing (http://www.4homepages.de/forum/viewtopic.php?t=13487)

- Bugfix: Back btn fails in Admin CP Edit Users/Images (http://www.4homepages.de/forum/viewtopic.php?t=8452)

- Bugfix: Subcategories columns dont show proportionaly? (http://www.4homepages.de/forum/viewtopic.php?t=3160)

- Bugfix: ACP - cant find images uploaded by not exist users (http://www.4homepages.de/forum/viewtopic.php?t=9585)

- Bugfix: Additional fields not being autofilled in "edit image" (http://www.4homepages.de/forum/viewtopic.php?t=12326)

- Bugfix: Cant display \\# (i.e \\2 or \\4 or \\9) (http://www.4homepages.de/forum/viewtopic.php?t=6270)

- Bugfix: Changed tag {remote_file} to {remote_media_file} in templates/default/member_uploadform.html

- Bugfix: Cant upload images when not cat_id specifyed (http://www.4homepages.de/forum/viewtopic.php?t=5935)

- Bugfix: details.php with mode=lightbox next/prev maybe wrong (http://www.4homepages.de/forum/viewtopic.php?t=7338)

- Bugfix: Error msg when update/delete user with ' in his name (http://www.4homepages.de/forum/viewtopic.php?t=8248)

- Bugfix: Image dl counter doesnt update when dl from lightbox (http://www.4homepages.de/forum/viewtopic.php?t=7850)

- Bugfix: Quotes in category names (http://www.4homepages.de/forum/viewtopic.php?t=13749)

[Anonymus]

La solution est celle qu'il donne. Tu as, dans ce script, la possibilité de générer des images aléatoirement. Hors dans le cas où tu as une grande quantité d'images, cela peut ralentir considérablement le serveur.

[Irwan]

Merci beaucoup pour cette réponse :!:

Si certains utilisent 4images, plantent et hésitent à supprimer l'image aléatoire, je confirme qu'en configurant le 'SHOW_RANDOM_CAT_IMAGE' sur 0, ca plante beaucoup moins, voir plus du tout !

webmaster-hub =>