Aller au contenu

jcaron

Membre+
 Afficher le profil  Parcourir son contenu

  • Compteur de contenus

    998

  • Inscrit(e) le

  • Dernière visite

 Type de contenu 

Tout ce qui a été posté par jcaron

  1. jcaron
    Que le vmstat n'a pas été capturé au même moment que le reste :-) Le problème est effectivement visiblement au niveau des scripts php. Le premier point c'est que toutes les requêtes dynamiques consomment au moins 100 ms de CPU chacune, donc si tu dépasses 80 requêtes dynamiques/seconde (un peu moins en fait), tu satures tes CPUs. A partir de là, si tu maintiens le rythme, Apache continue à ajouter des processus, ce qui ne sert à rien, à part à consommer du temps à faire du context switch, mais c'est le moindre de tes soucis. Tu as combien de pages vues par jour? Je suppose que c'est assez concentré en termes d'horaires, non? Le problème est peut-être tout bêtement que la nouvelle version consomme plus de CPU que la précédente (plus de fonctions, plus de CPU), et ce qui passait avant ne passe maintenant plus... Tu as des graphes de l'utilisation CPU avant/après le changement de version? Jacques.
  2. jcaron
    la commande c'est "diff -uiwbB fichier1 fichier2"... Et oui, ce n'est pas une bonne idée de faire tourner quoi que ce soit en root si ce n'est pas indispensable. D'ailleurs j'espère au moins que tu ne te connectes pas en tant que root, mais bien comme un utilisateur normal, et que tu utilises su pour faire les manips utiles. Et quand tu es connecté comme utilisateur normal, tu fais un crontab -e, et voilà. Evidemment il faut que les fichiers nécessaires soient exécutables par cet utilisateur... Jacques.
  3. jcaron
    utilisateur_authentifie = personne if (il y a des machins d'authenfication) { vérifier les machins d'authentification s'ils sont bon, utilisateur_authentifie = utilisateur } if (utilisateur_authentifie == personne) { envoyer 401 } Jacques.
  4. jcaron
    Ben tu fermes un </div> de trop là où il ne faut pas, c'est exactement ce qu'il te dit. Et un peu plus loin tu as inversé le </td> et le </tr>. Le plus simple: formate ton HTML de façon à toujours avoir les <xxx> et </xxx> seuls sur une ligne, au même "niveau" (avec autant d'espaces avant). Ca rendra le problème évident. Par exemple: <html> <head> <title> truc </title> </head> <body> <div> <div> <table> <tr> <td> toto </td> </tr> </table> </div> </div> </body> </html> Au fait, une table à une seule cellule, pour quoi faire? Jacques.
  5. jcaron
    Aucun des deux fichiers n'est vide? Il doit y avoir un problème de format légèrement différent, tu peux essayer en rajoutant les flags -iwbB (diff -uiwbB fichier1 fichier2). Au fait, quand tu dis que tu mets tes commandes en cron, dans quel cron? Celui d'un utilisateur, pas celui de root ou le cron système, j'espère? Jacques.
  6. jcaron
    Le premier te donne le phpinfo pour un php executé en ligne de commande, ce n'est pas forcément pareil qu'avec Apache ou avec cron. D'ailleurs, quand tu lances ton script depuis le shell plutôt que via cron, ça marche ou pas? Pour obtenir le phpinfo httpd: Fichier phpinfo.php avec <?php phpinfo()?> curl http://tonserveur/chemin_vers_phpinfo.php >phpinfo_httpd ou wget http://tonserveur/chemin_vers_phpinfo.php (dans ce dernier cas le fichier résultat s'appelerra phpinfo.php) Pour obtenir le phpinfo cron: mettre en cron php /chmein/ver/phpinfo.php >phpinfo_cron Ensuite diff -u phpinfo_httpd phpinfo_cron Les parties importantes c'est la fin ($_ENV surtout, éventuellement $_SERVER) et tout ce qui est safe_mode_quelque_chose. Jacques.
  7. jcaron
    Et top, ps axl, server-status? Jacques.
  8. jcaron
    man diff :-) Tu colles le source de la page/du mail généré par phpinfo chacun dans un fichier, et: diff -u fichier1 fichier2 Sinon tu peux toujours te palucher les deux à la main pour trouver les différences... Jacques.
  9. jcaron
    On commence par les habituels top, ps axl, server-status, histoire de confirmer que c'est bien un problème de CPU de httpd et qu'il n'y a pas d'autre problème dans les parages. Tu as activé le cache de IPB? Jacques.
  10. jcaron
    Non, normalement tout ça est transparent (ça veut juste dire que c'est en fait postfix et pas sendmail qui est utilisé). Il y a quelque part quelque chose qui convertit "/usr/sbin/sendmail" en "/sendmail", mais je ne sais pas trop quoi. Peut-être quelque-chose du côté de safe_mode ou safe_mode_exec_dir, mais j'aurais eu tendance à penser que ça ferait une erreur plus explicite. Fais une vérification exhaustive des différences entre les phpinfo en cron et via apache (avec un bon diff par exemple), c'est forcément quelque part là-dedans... Jacques.
  11. jcaron
    Et ls -l /etc/alternatives/mta et file /etc/alternatives/mta (et ainsi de suite si c'est encore un lien symbolique, ce qu'il devrait être)? Normalement ce sont des liens symboliques vers /usr/sbin/sendmail.sendmail ou un truc du genre, mais je pense qu'il y a quelque part un wrapper en shell qui fait appel à une variable d'environnement qui n'existe pas par défaut via cron. Jacques.
  12. jcaron
    En envoyant un 401 comme dans le cas où tu ne reçois pas d'authentification. Jacques.
  13. jcaron
    Bizarre... Ajoute une trace (avec un echo ou un error_log) à la ligne 604 de class.phpmailer.php (dans la fonction SendmailSend, juste avant "if ($this->SingleTo === true)"), pour voir la valeur de $sendmail à cet endroit-là. Ca donne quoi un "ls -l /usr/sbin/sendmail" et un "file /usr/sbin/sendmail"? C'est un binaire ou un shell qui sert de wrapper autour de quelque chose d'autre? Jacques.
  14. jcaron
    Le grand classique avec cron c'est que l'environnement n'est pas le même, en particulier $PATH, et le php.ini utilisé n'est pas forcément le même (lance un cron avec un phpinfo dedans, et compare le résultat avec ce que dit phpinfo via apache). Ceci dit j'ai du mal à comprendre comment il arrive à "/sendmail". C'est quelle version de PHPMailer, est-ce-que manipules la propriété $Sendmail? Jacques.
  15. jcaron
    Il y a tout plein de façons de faire tout ça. En laissant Apache faire, via des fichiers statiques, via une bdd, en php. En utilisant des dossiers séparés, ou en vérifiant les droits au niveau de chaque script. Si tu veux utiliser Apache, des fichiers statiques, et des répertoires séparés, la solution la plus simple est probablement: .htaccess dans chaque répertoire à protéger: AuthType basic AuthName whatever AuthUserFile /chemin/vers/fichier/htpasswd AuthGroupFile /chemin/vers/fichier/htgroup require group nom_du_groupe_autorise_a_acceder_a_ce_repertoire Le fichier htgroup est de cette forme: groupe1: user1 user2 user3 groupe2: user1 user2 user3 user4 user5 etc. Tu peux aussi gérer le cas "n'importe qui à partir du moment où il est dans le fichier htpasswd" en utilisant "require valid-user" au lieu de "require group ....". Avec ça, pas besoin de rewrite, et rien à faire en php (où tu devrais quand même pouvoir récupérer $_SERVER['REMOTE_USER'] si tu en as besoin). Pas besoin de realm (AuthName) différent, puisque le même utilisateur peut se connecter à des zones différentes. Jacques.
  16. jcaron
    Avec curl, tu vois tout de suite le résultat... Et avec un petit pipe dans gunzip c'est plus clair. La page d'accueil n'est pas compressée dans ce cas de figure. Ce n'est a priori pas juste le ob_gzhandler. D'après la doc, il vérifie ce que le client accepte comme compression (dans Accept-Encoding), et s'adapte. D'ailleurs sur la page d'accueil c'est le cas: si tu ne dis rien, il ne compresse pas, et si tu dis que tu acceptes du gzip, il compresse, et il ajoute bien le header. Tu dois donc avoir quelque chose d'autre ailleurs qui compresse systématiquement les pages autres que la home, sans vérifier si le client est d'accord, et sans ajouter le header qui va bien. Jacques.
  17. jcaron
    Ton site renvoie du contenu compressé, mais n'indique pas dans les headers qu'il est compressé. Je suis en fait surpris que les browsers et certains robots s'y retrouvent quand même, mais visiblement ce n'est pas toujours le cas. Jacques.
  18. jcaron
    C'est clair, rien de passionnant. Il n'y a rien de loggué nulle part lors des blocages? C'est quoi la périodicité des blocages? C'est à intervalles réguliers, ou c'est un peu au hasard? Ah tiens une autre possibilité (mais j'y crois pas trop, ça ne donnerait pas ce genre de symptômes a priori): il pourrait y avoir surchauffe et réduction de la fréquence d'horloge pour résoudre le souci. Mais ça ferait un ralentissement, pas un blocage complet, normalement. Ceci dit, vérifie quand même pour voir ce que ça donne... Maintenant ça devient vraiment spécifique Linux (et moi je suis plutôt FreeBSD), donc je sèche un peu (je n'arrive même pas à comprendre d'après le dmesg s'il y a 2 disques SATA ou 2 disques SCSI ou les deux... on a l'impression que les 2 mêmes disques sont visibles sous deux interfaces différentes, et qu'il y a deux RAID avec les mêmes disques?). Il n'y a a priori que peu de drivers qui puissent être impliqués: les drivers de disque (SATA ou SCSI?) et le driver Ethernet. Cherche un peu dans les bugs de ces drivers s'il y a quelque chose d'intéressant... Tu peux aussi essayer de voir si un upgrade ne résoudrait pas le problème... Et si tout ça ne donne rien, tu peux toujours demander au support Dedibox, ils ont peut-être déjà rencontré le problème et pourraient avoir une solution (si ça se trouve il y a juste un problème hardware avec la machine...). Jacques.
  19. jcaron
    Ca sent pas bon :-( Ce genre de blocage, c'est a priori au niveau kernel que ça se joue, donc en général dans un driver (un bug et/ou un problème hardware). Pas facile à diagnostiquer si tu n'as pas un petit message d'erreur quelque part. La seule chose en userland qui peut avoir un effet de ce type (et encore, je pense qu'il faut réunir pas mal d'autres conditions) c'est un processus qui part en récursion infinie (l'allocation de pages supplémentaires pour la pile a tendance à être prioritaire), jusqu'à ce qu'on atteigne la taille de pile maximale. Dans ce dernier cas tu devrais avoir des messages comme quoi le processus est mort (stack overflow). Quelque chose d'intéressant dans /var/log/messages et/ou dmesg? S'il n'y a rien, il doit y avoir un moyen de passer le kernel en mode "verbose", non? Sur FreeBSD il y a, mais je ne sais pas du tout si ça existe pour Linux... Jacques.
  20. jcaron
    Deux possibilités: - il y a quelque chose qui bloque vraiment complètement ta machine pendant ces quelques secondes (a priori quelque chose dans un driver) - c'est juste un problème réseau qui fait que c'est le transit des informations entre la machine et toi qui s'interrompt Pour vérifier si c'est la première option, lance ça: perl -e '$|=1; while(1) { print time."\n"; sleep 1 }' > log_time & Après un blocage, regarde la fin du fichier (tail -20 log_time) et regarde s'il y a un "trou" (normalement tu devrais avoir des nombres consécutifs, éventuellement 2 secondes d'écart). Pense à tuer le processus une fois que c'est fait, sinon il va continuer jusqu'à ce que ton disque soit plein :-) Il est vraisamblable que ce soit plutôt la seconde option. Là, quelques points à vérifier: - si tu ouvres plusieurs sessions ssh, quand il y a un blocage, c'est sur toutes, ou juste une seule? - c'est valable uniquement pour toi, ou pour tout le monde? Tu peux examiner les logs httpd à la recherche de "trous" pour voir Tu peux faire des tests de ping assez gros pour voir si tu as de la perte de paquets entre toi et le serveur. Si tu en trouves, tu fais un traceroute, et tu fais le même test jusqu'à chaque "hop", ça permet d'isoler le lien sur lequel il y a des pertes. Tu peux aussi vérifier netstat -in et/ou ifconfig pour voir si tu as des erreurs sur l'interface. Pense aussi à jeter un coup d'oeil à /var/log/messages, on y apprend souvent des choses intéressantes. Jacques.
  21. jcaron
    Ca ne répond pas vraiment à toutes mes questions, loin de là. Il n'y a pas que le CPU qui compte, il y a beaucoup d'autres paramètres. Et puis s'ils étaient vraiment "au repos total", pourquoi est-ce-que tu aurais 3 frontaux? Tant qu'on n'aura pas vu au moins: - un "top" - un "ps axl" - un server-status Apache pour chaque machine à un moment où il y a des problèmes (maintenant par exemple), il est très difficile de se prononcer. Tu peux aussi ajouter un "netstat -in" et un "ifconfig" (expurgé des IPs si besoin est) pour faire bonne mesure. Et encore une fois, s'il y a un moyen d'envoyer une requête vers un frontal précis à coup sûr, ça peut aider... Et une indication de ce qui est utilisé pour faire le load-balancing, aussi. Je précise que vu d'ici, et avec le peu d'informations qu'on a, les deux hypothèses les plus vraisemblables sont: - saturation des processus Apache à cause de Keep-Alives - machine qui swappe à fond Les deux sont liés à des problèmes de configuration Apache qui peuvent être résolus très facilement. Jacques.
  22. jcaron
    Non, tel quel, ce n'est pas possible. A partir du moment où il y a: - espérance de gain - sacrifice financier - intervention du hasard C'est une loterie, et c'est pour le moment interdit si tu n'es pas la FDJ ou un casino autorisé. Le truc, c'est d'enlever l'un des trois éléments: - espérance de gain: il n'y a rien à gagner, ils font des donations sans rien en tirer, ça enlève le hasard aussi; - sacrifice financier: ils doivent pouvoir participer au tirage au sort sans dépenser d'argent (c'est pour ça que dans la plupart des opérations de ce type il y a la possibilité de participer une fois gratuitement, généralement par le remboursement des frais occasionnés avec une procédure super lourde); - intervention du hasard: tu fais un concours plutôt qu'une loterie, avec une question non triviale (genre écrivez un poème, dessinez un logo...), un jury indépendant pour décider qui a la meilleure soumission, etc. Attention, dans de nombreux cas le dépôt d'un règlement chez un notaire est obligatoire, ainsi que la possibilité pour les utilisateurs de le consulter, etc. Jacques.
  23. jcaron
    J'avais pas lu le lien, normalement on met le nécessaire pour faire l'authentification dans le .htaccess (directives Auth*), on laisse Apache faire tout tout seul comme un grand, et on récupère juste l'utilisateur authentifié dans REMOTE_USER. Avec la méthode que tu indiques, il faut: - que tu utilises un "realm" différent pour les différentes parties de ton site qui ont besoin d'authentification différentes. - que si l'authentification n'est pas valable (utilisateur non autorisé dans cette section, mot de passe incorrect) tu renvoies aussi un 401 comme dans le cas où il n'y a pas de REMOTE_USER etc. du tout Jacques.
  24. jcaron
    Ben si, dans le corps du bounce... Sinon tu devrais trouver quelques infos dans /var/log/maillog aussi. Jacques.
  25. jcaron
    Sans avoir le mail complet (en particulier le motif du mail d'erreur et les headers du mail qui l'a déclenché), difficile à dire... Jacques.
×
×
  • Créer...