Bonjour,
je viens chercher un peu d'aide à un problème que je n'arrive pas identifier et donc pas à résoudre concernant un site web hébergé sur l'un de mes serveurs. Je vais tenter de donner autant d'informations que possible en essayant de ne pas vous perdre.
La machine que j'appelerai NET2 est un serveur dédié SuperPlan BestOF chez OVH (Intel Core i5-2400 - 4x3.1+ GHz - 64 bits - 16 Go DDR3 - 2x 2To - SATA2) qui tourne sous debian squeeze. Dessus sont installés apache 2.2.16 et PHP 5.3.3-7+squeeze14 with Suhosin-Patch (+ un postfix pour l'envoi des mails). Cette machine n'héberge qu'un seul site web dont le trafic n'est pas très important (600-700 visites/jours pour 3000-4000 pages). Initialement ce site était hébergé sur une autre machine (que j'appellerai NET1) avec la même configuration et plusieurs autres site. C'est à cause des crashs qu'il génère que nous l'avons déplacé.
Le site est développé sous ZendFramework (1.12), avec une base de données MySQL hébergée sur NET1 (mysql Ver 14.14 Distrib 5.1.63, for debian-linux-gnu (x86_64) using readline 6.1). Les fichiers (php, html, css, images, etc…) sont sur un NAS. Ce site utilise également une “base de données” distante qui retourne un fichier XML via un appel d'URL. Ces fichiers XML sont mis en cache sur le serveur pour réduire les temps de latence (la base distante étant assez lente et fréquemment inaccessible). Ce site est également multilingue (fr, en, de, nl, it).
2-3 fois par jour, le site devient presque inaccessible. Les pages mettent plus de 2 minutes à être affichées, sans qu'il n'y ait de timeout ou autre. Lorsque ce site était sur NET1 et que ce phénomène se produisait, dans un premier temps lui seul était impacté. Mais au bout de quelques minutes, tous les processus apache étaient occupé par des requêtes sur ce site, ce qui rendait les autres inaccessible. C'est pourquoi nous l'avons déplacé sur NET2.
Cela fait maintenant 1 semaine que le site est isolé. Malgré quelques correction d'erreur php (Warning ou Notice) le problème est toujours présent. Et je n'ai malheureusement aucune information dans les logs du serveur, que ce soit ceux d'apache ou du système. La seule chose que je sais, c'est que lorsque ce phénomène se produit, c'est le chargement des traductions qui met du temps à s'exécuté. Je l'ai identifié en utilisant utilisant microtime_debut_appel_fonction - microtime_fin_appel_fonction. Pourtant, ces traductions qui utilisent des fichiers PO (gettext) sont également mise en cache via Zend_Cache dans Zend_Translate.
Voici les graphiques munin du serveur montrant ce crash/latence apache :
On peut constater les trous correspondants aux périodes où le site met plusieurs minutes à répondre. La RAM est loin d'être saturée, le processeur n'est quasiment pas utilisé (je n'ai pas mis le graphique mais la valeur mini de idle sur la même période est de 367%), le load average est de 0.1 (maxi 0.3). Le point inquiétant c'est qu'il y a des process zombies.
Je ne sais plus trop où chercher pour identifier le problème. Toutes les idées et les conseils seront les bienvenus. S'il vous faut plus d'infos, et je me doute bien que oui, demandez les. D'avance merci.
je viens chercher un peu d'aide à un problème que je n'arrive pas identifier et donc pas à résoudre concernant un site web hébergé sur l'un de mes serveurs. Je vais tenter de donner autant d'informations que possible en essayant de ne pas vous perdre.
La machine que j'appelerai NET2 est un serveur dédié SuperPlan BestOF chez OVH (Intel Core i5-2400 - 4x3.1+ GHz - 64 bits - 16 Go DDR3 - 2x 2To - SATA2) qui tourne sous debian squeeze. Dessus sont installés apache 2.2.16 et PHP 5.3.3-7+squeeze14 with Suhosin-Patch (+ un postfix pour l'envoi des mails). Cette machine n'héberge qu'un seul site web dont le trafic n'est pas très important (600-700 visites/jours pour 3000-4000 pages). Initialement ce site était hébergé sur une autre machine (que j'appellerai NET1) avec la même configuration et plusieurs autres site. C'est à cause des crashs qu'il génère que nous l'avons déplacé.
Le site est développé sous ZendFramework (1.12), avec une base de données MySQL hébergée sur NET1 (mysql Ver 14.14 Distrib 5.1.63, for debian-linux-gnu (x86_64) using readline 6.1). Les fichiers (php, html, css, images, etc…) sont sur un NAS. Ce site utilise également une “base de données” distante qui retourne un fichier XML via un appel d'URL. Ces fichiers XML sont mis en cache sur le serveur pour réduire les temps de latence (la base distante étant assez lente et fréquemment inaccessible). Ce site est également multilingue (fr, en, de, nl, it).
2-3 fois par jour, le site devient presque inaccessible. Les pages mettent plus de 2 minutes à être affichées, sans qu'il n'y ait de timeout ou autre. Lorsque ce site était sur NET1 et que ce phénomène se produisait, dans un premier temps lui seul était impacté. Mais au bout de quelques minutes, tous les processus apache étaient occupé par des requêtes sur ce site, ce qui rendait les autres inaccessible. C'est pourquoi nous l'avons déplacé sur NET2.
Cela fait maintenant 1 semaine que le site est isolé. Malgré quelques correction d'erreur php (Warning ou Notice) le problème est toujours présent. Et je n'ai malheureusement aucune information dans les logs du serveur, que ce soit ceux d'apache ou du système. La seule chose que je sais, c'est que lorsque ce phénomène se produit, c'est le chargement des traductions qui met du temps à s'exécuté. Je l'ai identifié en utilisant utilisant microtime_debut_appel_fonction - microtime_fin_appel_fonction. Pourtant, ces traductions qui utilisent des fichiers PO (gettext) sont également mise en cache via Zend_Cache dans Zend_Translate.
Voici les graphiques munin du serveur montrant ce crash/latence apache :
On peut constater les trous correspondants aux périodes où le site met plusieurs minutes à répondre. La RAM est loin d'être saturée, le processeur n'est quasiment pas utilisé (je n'ai pas mis le graphique mais la valeur mini de idle sur la même période est de 367%), le load average est de 0.1 (maxi 0.3). Le point inquiétant c'est qu'il y a des process zombies.
Je ne sais plus trop où chercher pour identifier le problème. Toutes les idées et les conseils seront les bienvenus. S'il vous faut plus d'infos, et je me doute bien que oui, demandez les. D'avance merci.
