Akta

Loool! "vive audi", merci pour tes conseils :) On est quand même pas si glands.. Il n'y a aucun problème avec la config de MySQL. D'ailleurs, elle est méga optimisée. On peut difficilement faire mieux. Pour l'hébergeur, Sylvain avait une machine dédiée chez OVH. L'OS était un RedHat..et j'aime pas RedHat :P. Trève de plaisanterie : On avait pas trop le choix des packages et hormis la recompile totale du système, ça devenait un peu galère à gérer. En plus la machine manquait méchamment de pèche. Pour l'heure le serveur est très puissant et redondé avec du vrai raid matériel et tout et tout. L'initiative est louable mais je doute que quiconque ne trouve le problème de MySQL sur la plateforme. On ne va pas donner le root à tout le monde. Je maîtrise le système et mes lacunes en bases de données sont comblées par des amis dont c'est le métier (et qui sont des experts reconnus dans ce domaine...). Maintenant, certaines personnes ont peut être déjà eu ce problème... Je pense que notre salut est dans PostGres... A bientôt! Akta

Marko, ya pas 5 semaines de congés Payés en belgique? (et pas de RTT?) loool. Je comprend. Mais bon, toi aussi mets toi à ma place. Je pense qu'il faut qu'on arrête là. Cette discussion ne va nulle part... et en plus je perd du temps à écrire au lieu de googler pour convertir les bases :P Akta

Qu'est ce que tu veux que je réponde à tout ça! "Ouai super, on est super mauvais, on fait exprès de tout planter. D'ailleurs AP n'est JAMAIS dispo etc etc..." Je pense que la pluspart du temps on est à plus de 90% de dispo par mois en moyenne. Faut peut être pas pousser mémé dans les orties. En ce qui concerne la demande d'aide, c'est ouvert. Effectuez une recherche vous verrez bien !. Je n'ai eu que deux réponses... puis plus rien. C'est facile de dire quand ça marche pas. Il n'y a plus de problème de lenteurs sur AP. On corrige les problèmes les uns après les autres. Celui ci est corriace. J'avoue ne pas tout comprendre. Mais marko n'hésites pas. Si tu veux refaire un moteur MYSQL, vas y!. Comme je l'ai écrit, il faut soit convertir, soit réinstaller (la conversion étant la meilleur solution aux vues des évolutions du forum. Mais ça prend du temps). Pour ton info Marko, je rend service à Sylvain. C'est mon meilleur ami et c'est normal de s'aider entre potes (et en plus j'aime bien faire ça!). Je ne gère pas le forum. Juste le système et sa sécurité. En plus je suis impressionné par tout le boulot qu'il a réalisé depuis le début d'AudiPassion. Ca mérite bien un super coup de main!. Akta.

No Comment...

Bonsoir, Pour eclairicir les quelques esprits embrouillés, voici ce qui se passe : - Il n'y a plus aucun problème de charge avec le serveur : Les 3Go de RAM ont corrigé ce problème - Comme je l'ai expliqué de (très) nombreuses fois, la base commence a contenir beaucoup d'enregistrements (elle pèse plus d'1Go) et MySQL n'aime pas les grosses bases. - MySQL plante (se fige) pour une/des raison(s) totalement inconnue(s). Des experts DBA avec qui je travaille n'ont jamais vu ça (je suis pas "expert" DBA, je suis juste "expert" en Systèmes/Réseaux et Sécurité). Pour le plantage de ce matin, un strace sur le process n'a rien montré de probant (même gdb n'a rien montré...) hormis un "too many connexions" habituel avec ...0 users connectés... (netstat...) et 0 process APACHE (j'ai arrêté Apache pour débugger...). Malheureusement, ON NE TROUVE PAS LE PROBLEME. Donc merci d'arrêter de me casser les ... avec ça. - Les solutions identifiées sont au nombre de ... 2 1. Migrer la base MySQL sous le moteur PostGreSQL. J'ai jamais fait mais ça n'a pas l'air trop complexe. Il faut juste passer pas mal de temps dessus pour remonter une plateforme à la maison et bricoler la base. Maintenant, le résultat est loin d'être garanti. 2. Arrêter le serveur pendant 1 WE / Semaine et effectuer une réinstall complète de la machine avec un autre OS (perso j'aime plus trop Linux, je préfère revenir aux source... un bon vieux BSD sera beaucoup plus performant, et pourquoi pas passer la base sous Postgres au passage. Le problème : Si on arrête la machine pendant 1WE ou 1Semaine, certains foromistes vont (encore) faire le bronx (mon dieu c'est une horreur!!! le serveur est indispo!!! je vais m'embêter toute la journée, c'est inacceptable... etc... j'en passe et des meilleurs. Faire tout ça prend du temps. Heureusement, le bon point est que le serveur est hébergé dans la Région Parisienne (là où Sylvain et moi bossons...). Maintenant, nous avons aussi une vie, perso j'ai un enfant en bas âge qui me sollicite (normal :) ), je refais mon appart (le plâtre, vous savez tous ce que c'est...) et ma ptite famille aimerait que je passe du temps avec elle plutot que de passer 48 non stop a préparer un serveur... Heurement, le mois de mai (et ses ponts traditionnels) approche.. on va pouvoir trouver une fenêtre de tir... aux fanas d'AP près... Bonne soirée à Tous, en espérant que vous comprendrez que faire tourner un serveur avec un forum comme celui d'AP (qui vit depuis 2000-2001) n'est pas si simple. Akta

Bonjour, Nous souffrons d'un bug de mysql que je n'arrive pas à bien cerner. Je prendrai vraiment le temps de bien investiguer lors du prochain plantage, avec un peu d'optimisation du kernel pour voir si ce n'est pas une histoire d'IPC...

Bonjour a tous, Je n'avais pas encore lu tous les "posts" de contestation vis à vis des problèmes du site. Je voudrais me présenter et réagir à certains points : Je suis la personne qui "administre" le serveur (administrer le serveur ne veut pas dire administrer le site et le forum hein! :P, juste la partie OS et associés) Les problèmes du forum audipassion ne sont pas un problème d'hébergeur ni de temps. Pour l'explication technique du problème, elle a déjà été fournie dans le thread "Serveur AP". Pour rappel, vous êtes très nombreux à utiliser le forum comme un chat... et IPB n'a pas été conçu pour ça. D'autre part, beaucoup de recherches se jouent avec seulement 2 caractères (style A2, A3 etc... et oui...audi choisit des noms courts...) et ce n'est pas top pour un moteur de bases de données que de faire des recherches sur 2 caractères et des recherches en général.... sur un base de quelques Go. Surtout lorsque la machine ne dispose que de 1Go de RAM... Le moteur de DB doit sans cesse monter les données en mémoire RAM et la machine fini par "swapper" à savoir décharger sur le disque dur qui est très lent comparé à la RAM. Sauf que lorsque le SWAP est plein lui aussi... bah tout plante. Pour remédier à ce problème, nous avons ajouté 2Go de plus de RAM soit 3Go au total... et là ça va mieux.. Ca a été long parce que : 1. La machine est actuellement hébergée à Marseille 2. La personne qui a ajouté la RAM (un ami) avait un emploi du temps extrèmenent chargé et l'a fait bénévolement. Une suggestion : Pour faciliter les recherches et faire moins travailler le système, nommer les véhicules audi_a2 etc... et utilisez le chat mis à dispo sur le site ;) Pour les recherches, un autre moteur devrait être testé dans les semaines qui suivent... et qui est beaucoup plus rapide. Akta

Bonjour, Les mémoires sont arrivées et installées. La fonction recherche va être réactivée. Akta

Aux dernières nouvelles... install prévue Lundi. Rappatriement du serveur prévu au 1er décembre. Akta

Je sais, je sais. J'arrête pas de relancer la personne qui doit installer les RAM. Il est surbooké et le data center n'est pas à côté de chez lui. Il m'a promis cette semaine. De toutes façons, on va rapatrier la machine chez un hébergeur Parisien. Ca va solutionner quelques problèmes de maintenance. Courage. Akta

TonyQuattro, Ils ont quoi comme machines à proposer dans ton service informatique? Merci d'avance, Akta

Hello, Mémoires arrivées à Marseille... En attente d'installation. Ca ne devrait pas tarder. Akta

Vous inquiétez pas... ça vient, ça vient... J'ai la RAM... et elle chauffe :P pour voir si elle est bonne... Après zoo en enveloppe à Bulles pour Marseilles :)

@Maverick J'en conviens, mais 800Mo de posts pour notre serveur ça commence à faire. Ce n'est pas en effet la quantité de données le problème, mais les accès permanents à ces données (on le voit dans les stats de MySQL). Pour les index, le forum d'entre aide des développeurs MySQL recommande que la taille du cache d'index MySQL = Somme des index. Maintenant, il faut la ram qui va avec. Il ne faut pas oublier qu'AP n'a qu'un seul serveur pour : -Les bases de données, -Apache, -Mail, -FTP -Stats etc... là où des sites importants ont des architectures ntiers avec de gros serveurs. Mais c'est clair que nous devons également souffrir de problèmes d'optimisation. Akta

Bonjour, Pour info sur notre serveur actuel : P4 3GHz HyperThreadé, 1Go de RAM, RAID 1 Matériel SATA. Format 1U. ça peut être intéressant de récupérer une (des) machine(s) 1U ou 2U max (avec les rails de rack) multiprocesseurs de préférence avec au moins 2 voir 4Go de RAM (4Go est le std de ma boîte). Des machines du mêmes type pour le spare sont appréciées. Si c'est du P3, il faut au moins du P3 (Xeon) 1,4GHz. si c'est du PIV, il faut au moins du (Xeon) 2,4GHz. Me contacter si vous avez ça dans vos poubelles... on verra après ce qu'on peut en faire. Je suis preneur de la config mysql et matérielle du serveur hébergeant le forum PCI (ou d'un autre GROS forum). Akta

Le cluster est un peu bourrin pour notre problème (quoique, surtout qu'un cluster MySQL actif/actif c'est easy :P). Mais bon, ça coute 2x plus cher (1 serveur en plus + 1U d'hébergement). Vu qu'au niveau CPU, la machine pourrait largement encoder tous nos films de vacances, je ne pense pas qu'il soit nécessaire d'en arriver là. 3Go de RAM suffiront largement pour répondre à notre "incompétence / détournement de l'usage normal d'un forum IPB" :P . Pour PCINPACT, je crois qu'ils ont un IPB (c'est marqué en bas de page). Si vous connaissez un de leur sysadmin, ça peut valloir le coup de demander leur conf HARDWARE/BDD... Mais vu leur budget, je pense connaître la réponse. Autrement si l'une de nos entreprises respective balance à la benne des serveurs 1U de type bi-P3 Xeon, c'est le moment de faire de la récup! Perso, dans ma boîte, on va bientôt renouveler notre parc de serveur WEB (serveurs DELL PE1650) par des blades. Ces machines sont unitairement aussi balaises que le serveur d'AP (mais plus rapides au niveau I/O). Après, il va falloir négocier avec notre hébergeur favori! Akta

T'inquiètes pas Korbend :) Chez moi la seule IHM viable c'est le shell. Le système est un Linux hardened (SlackWare). Akta

Pour Info, ipb utilise (aussi) une seule table pour les posts...

C'est bien! On est tous d'accord qu'un forum n'est pas un chat "stateless". Il est clair que certaines tables sont trop difficiles à gérer pour MySQL/IPB. Pour ceux qui m'ont demandé la conf mysql, envoyez moi un mp avec votre adresse de courriel. Je n'ai pas mis de stats de connexions à la base. La hard-limit est 300 connexions. Il n'est pas envisageable de monter cette valeur sous peine d'explosion du système. Il est vrai qu'il peut être utile de faire plusieurs connexions dans une même instance. Maintenant, dans mon soucis de l'éternelle optimisation :P j'évite tant que possible. De toutes façons, ça explose avant :P En résumé : il faut nettoyer le forum et supprimer les trops vieux posts sans intérêt. Les modérateurs ont déjà été avertis de cette nécessité et ont commencé à faire le ménage (enfin j'espère). On va y arriver! A+ Akta

Je suis d'accord avec toi pour le nombre de com ouvertes par process. C'est d'ailleurs ce qui se passe. Mais c'est pour moi symptomatique d'une mauvaise conception. La conso mémoire n'est pas étonnante. La machine traite pour plus d'1Go de bases (rien que le forum AP = 800Mo) ce qui est énorme. MySQL réserve déjà plus de 200Mo pour les index en mémoire (pour éviter de chercher sur le disque), et l'usage fait du forum fait qu'il ya beaucoup d'écritures disque. Pour info, MySQL bouffe a lui seul plus de 500Mo de RAM. Et pourtant on a essayé d'optimiser à mort la conso mémoire. Maintenant je ne suis pas un expert en DBA (je suis plus orienté Sécurité des Systèmes et des Réseaux :) ). Je pense qu'on peut encore faire mieux, mais la littérature sur les optimisation à faire dans les confs MySQL pour IPB sont rares... Si t'as des infos :) Akta

Le problème de plantage Apache de ce matin (0H et des brouettes) a été résolu. (Bug de mod_ssl qui faisait planter httpd_core lors du restart. Merci OSR38, ça peut aider. Mais je pense que le problème vient du manque de mémoire. Le maxcon de MySQL est de 300. Le max user de Apache est de 256. Noremalement, MySQL ne devrait pas atteindre sa limite (a moins que les scripts IPB soient merdiques ce qui est une bonne hypothèse :) ). Je pense qu'apache / php /mysql partent en vrille lorsque la machine swappe trop. Il doit en effet y avoir des histoires de timeout dans tous les sens. Je vais essayer de tracer le problème. Quoi qu'il en soit, l'ajout de ram doit corriger définitivement le problème. Par contre j'ai désactivé globalement la recherche tant qu'on a pas d'extension mémoire. C'est cette fonction qui accélère la conso mémoire. Akta

Bon ben.. raté, ça vient pas de MySQL 4 puisque ça merde pareil en 5. J'en ai profité pour faire des accès directs à la base pendant le plantage et MySQL fonctionnait parfaitement. J'en conclus qu'il y a un problème PHP->MySQL lorsque le serveur est dans les choux (à cause des recherches?, des écritures trop fréquentes? ...) Reste qu'à ajouter de la RAM pour que la machine ne swap plus... et questionner Invision (ou migrer vers PHPBB:p) Akta

Il y a toujours le problème de warning au login.

C'est fort possible. je pense que certaines modifs n'ont pas été correctement mises à jour, ce qui a un peu pourri les templates. Je pressents une réinstallation from scrach d'IPB avec portage du template. Akta

J'ai refais une conf propre de MySQL doc en main. D'ailleurs le forum y gagne au niveau vitesse. Maintenant, la machine manque de RAM. Lorsque la machine lag, un ptit "free" montre 100% de ram physique consommée et 50% de swap. J'ai rappelé la personne en charge d'en rajouter. Ce sera fait cette semaine. MySQL 4 crashait lorsque la machine n'avait plus de RAM (Physique+swap) ce qui est normal. MySQL 5 semble mieux gérer ces problèmes. Akta