Discussion :

[urbalk]

Bonjour,

je rencontre un sérieux soucis de connection à l'un de mes servers web.

le firewall est derrère une ligne dédiée 10Mb. le serveur est hébergé derrière un firewall IpCop, seul l'interface Dmz est utilisée.

Cette Dmz héberge:
- 1 serveur web (2*Xeon 1.86GHz/3G de ram) Debian Apache2, Postfix, Backup-manager sont installés dessus, il héberge le site web
- 1 serveur de Base de données (1*Xeon 3G/1G de ram) Debian Apache2, Mysql, Phpmyadmin, Backup-manager sont installé dessus.

je fait un test de benckmark à l'aide de Siege (réalisé depuis un autre serveur Debian, en dehors de cette Dmz, sur une autre Ip publique)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
siege -dl -r25 -c200 http://mon_site.com
....
HTTP/1.1 200   0.09 secs:    4529 bytes ==> /
HTTP/1.1 200   0.12 secs:    4529 bytes ==> /
done.
Transactions:                   4994 hits
Availability:                  99.88 %
Elapsed time:                 130.59 secs
Data transferred:              21.57 MB
Response time:                  4.13 secs
Transaction rate:              38.24 trans/sec
Throughput:                     0.17 MB/sec
Concurrency:                  157.89
Successful transactions:        4994
Failed transactions:               6
Longest transaction:           52.47
Shortest transaction:           0.08

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
resultat de la commande top sur le serveur pendant le benchmark:
Tasks: 180 total,   2 running, 177 sleeping,   0 stopped,   1 zombie
Cpu(s): 18.2%us,  2.4%sy,  0.0%ni, 78.7%id,  0.2%wa,  0.0%hi,  0.5%si,  0.0%st
Mem:   3108392k total,   876060k used,  2232332k free,    30568k buffers
Swap:  2650684k total,        0k used,  2650684k free,   639312k cached

l'infrastructure me semble être correct.

Apache2 a subit quelques modifications:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
le module "apache2-mpm-worker" est installé
KeepAliveTimeout 2

le surf est très fluide, l'affichage des pages très bon.

le site est composé d'une page d'accueil, avec un script d'authentification faisant appel à la base de donnée.
c'est là que les ennuis commencent...
Dès que plus de 5 users essayent de ce connecter simultanement, le serveur se mets à lagué et le site devient indisponible, impossible d'avoir accès à la page index.ph, ni depuis le net ni depuis le lan

la requète de demande d'authentification "tourne" en boucle et n'affiche jamais la page demandée...

je me demande ce qu'il faut encore amélioré.

merci de toutes vos remarques et aides.

[_Mac_]

Là, tu donnes les perfs du serveur qui héberge Apache mais qu'en est-il du serveur qui héberge la base de données ? Il peut y avoir un problème de réseau entre les 2 serveurs, un problème sur la base de données ou encore un code mal fait. Au moins 3 pistes à examiner.

[urbalk]

le réseau:

Net 10Mbt (dédiés) ip fixe --> Firewall IpCop up to date 3 interfaces

eth0 (Wan) 1 Gbit, eth1 (Lan) 100 Mbit, eth2 (Dmz) 1 Gbit,

eth2 (Dmz) 1 Gbit --> Switch 24 ports Gbit

Tous les serveurs disposent d'interfaces ethernet Gbit et sont connectés sur le swith.

le tout relier avec des câbles ethernet catégorie 5e.

Voici un benchmark entre le serveur Apache et le serveur Mysql

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Debian:~# siege -dl -r25 -c200 http://12.34.56.1
HTTP/1.1 200   0.00 secs:     351 bytes ==> /
HTTP/1.1 200   0.00 secs:     351 bytes ==> /
HTTP/1.1 200   0.01 secs:     351 bytes ==> /
done.
Transactions:                   5000 hits
Availability:                 100.00 %
Elapsed time:                   8.23 secs
Data transferred:               1.67 MB
Response time:                  0.30 secs
Transaction rate:             607.53 trans/sec
Throughput:                     0.20 MB/sec
Concurrency:                  183.66
Successful transactions:        5000
Failed transactions:               0
Longest transaction:            6.82
Shortest transaction:           0.00
 
Debian:~#

Le telnet du serveur Apache vers le serveur Mysql:

Debian:~# telnet 12.34.56.1 3306
Trying 12.34.56.1...
Connected to 12.34.56.1.
Escape character is '^]'.
?
5.0.51a-24+lenny

Dans cet environement, j'ai testé avec une requète sql dans un script php, une interrogation de la base, et le renvois des informations. ca fonctionne parfaitement. j'ai aussi ajouter au fichier de configuration de mysql (my.conf) la commande "skip resolv-dns" ce qui selon la doc accélère la résolutions des requètes sur le serveur.

Pour information:
Avant cette installation sur deux serveurs, le site tournait avec Apache2 et Mysql sur le même serveur (celui qui actuellement héberge le serveur Mysql) et le problème était identique. les serveurs ont tous été formaté. Rien n'a été modifié sur le Firewall, si ce n'est l'ip publique et donc la redirection dns (chez un registrar aux USA).

Ensuite il y a le code, mais la ce n'est plus mon domaine, mais j'ai la structure des tables et le code.

[_Mac_]

Il faudrait le résultat d'un top sur le serveur de base de données lors d'une utilisation "normale" menant au blocage pour mettre le serveur de la base de données hors de cause. Si tu t'aperçois que le serveur de base de données pédale, soit le hardware est insuffisant, soit la base de données est mal fichue : il manque peut-être des index. La piste du hardware ne doit être envisagée qu'en second ressort : une base et des requêtes correctement tunés font souvent des miracles.

Lors de ton bench, tu es sûr qu'un appel sur / déclenche un appel à la base de données ? Avec une réponse contenant 351 octets, j'ai des doutes. Tu peux faire un bench sur un test spécial minimaliste qui fait par exemple un select count(*) sur une table pour au moins vérifier ce qui se passe lorsque PHP interroge MySQL. Mais je continue à avoir des doutes sur le code PHP et la structure de la base de données : est-ce que des index ont été postionnés là où il faut ?

[urbalk]

Bonjour,

J'ai apporté quelques modifications au site web. Celui ci est composé de 2 parties, une partie site web publique et une partie backoffice, sur le serveur web il y a la parie publique, la partie backoffice est elle installée sur une petite machine à part.

Le site web fonctionne correctement. Par contre il semblerai que lorsque nous activons la parie backoffice et que des requetes Sql y sont générées, le serveur de base de données se met à laggué. Un restart du server solutionne le problème temporairement. Dans la commande top ci dessous, une ligne m'intrigue plus particulièrement PID 9014.

resultat de la commande top quand le serveur est en saturation:

top - 12:26:20 up 8 days, 13:42, 1 user, load average: 2.10, 2.42, 2.41
Tasks: 123 total, 2 running, 121 sleeping, 0 stopped, 0 zombie
Cpu(s): 99.8%us, 0.0%sy, 0.0%ni, 0.0%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 1035832k total, 1019828k used, 16004k free, 22512k buffers
Swap: 2658716k total, 564k used, 2658152k free, 687640k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9014 mysql 20 0 133m 29m 5308 S 199 2.9 161:50.88 mysqld
1 root 20 0 2100 688 588 S 0 0.1 0:05.98 init
2 root 15 -5 0 0 0 S 0 0.0 0:00.00 kthreadd
3 root RT -5 0 0 0 S 0 0.0 0:00.10 migration/0

concernat la ligne PID 9014, la colonne TIME+ indique quoi exactement, la durée depuis quand a été générée la requête, le temps d'execution des requêtes ...?

Tu soulèves un problème de hardware insuffisant le serveur de base de donnée dispose de 1G de Ram, ce n'est pas execptionnel certe, mais bon j'ai déjà fait tourner en dépannage ce type de site web dans ces conditions sans rencontrer ce problème.

tu es sûr qu'un appel sur / déclenche un appel à la base de données ? Avec une réponse contenant 351 octets, j'ai des doutes

Je ne sais pas comment conrôler si la réponse renvois 351 octets...

un select count(*) sur une table pour au moins vérifier ce qui se passe lorsque PHP interroge MySQL

Idem ci dessus, je dois créer une requète 'count(*)' depuis le serveur sql et controler les logs d'apache, de Php...

Merci de ton retour d'info.

[_Mac_]

Tu sembles avoir isolé au moins une partie du problème : le back office

Tu soulèves un problème de hardware insuffisant

Au contraire : ce que je dis c'est que la piste du hardware doit être examinée en second lieu, lorsque les actions de tuning de base et de requête ne donnent rien :

La piste du hardware ne doit être envisagée qu'en second ressort : une base et des requêtes correctement tunés font souvent des miracles.

Visiblement, le problème vient du back office, donc tu dois pouvoir isoler la ou les requêtes qui posent problème : une fois que tu les as, regarde comment elles sont faites, vois s'il est possible de les simplifier et s'il ne manque pas quelques index. Je ne suis pas DBA donc je ne peux pas t'aider davantage, désolé, mais je le redis, c'est la piste à privilégier pour le moment.