Dan Posté 7 Juin 2004 Posté 7 Juin 2004 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 Posté 7 Juin 2004 Auteur Posté 7 Juin 2004 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 Posté 7 Juin 2004 Posté 7 Juin 2004 (modifié) 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 Posté 7 Juin 2004 Posté 7 Juin 2004 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 Posté 7 Juin 2004 Auteur Posté 7 Juin 2004 bon, j ai contacte OVH pour passer en offre superieure.... dans l'espoir d une amelioration, Bernhard
Dan Posté 7 Juin 2004 Posté 7 Juin 2004 Berberber, J'ai changé les paramètres apache MaxClients et MaxRequestsPerChild .... Relances ta simulation et dis-moi ce que ça donne. Dan
valdo Posté 7 Juin 2004 Posté 7 Juin 2004 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 Posté 7 Juin 2004 Auteur Posté 7 Juin 2004 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 Posté 1 Juillet 2004 Auteur Posté 1 Juillet 2004 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 Posté 3 Juillet 2004 Posté 3 Juillet 2004 (modifié) 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 Posté 4 Juillet 2004 Auteur Posté 4 Juillet 2004 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 Posté 4 Juillet 2004 Posté 4 Juillet 2004 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 Posté 19 Octobre 2004 Posté 19 Octobre 2004 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 Posté 25 Octobre 2004 Posté 25 Octobre 2004 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 Posté 25 Octobre 2004 Posté 25 Octobre 2004 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 =>
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant