J'ai un serveur virtuel chez PHPNET; j'aimerais faire appel aux
compétences de ceux qui auraient un tel hébergement.
Pour des raisons que j'ignore, le serveur devient par moment
indisponible (bloqué); on le reboote à distance, et quand j'analyse les
log je ne vois rien de concret qui puisse expliquer le phénomène.
Je dois dire que le support PHPNET est très réactif à chaque fois que je
le sollicite; mais comme rien d'évident ne peut être mis en lumière.
Il semble qu'une tache se mette à utiliser tout le temps CPU.
J'aimerais donc que quelqu'un d'expérimenté puisse me suggérer des voies
de recherche (j'ai fait pour l'instant un travail qualitatif sur les
bases MySQL; le phénomène s'est toutefois reproduit).
L'hébergement est réalisé à partir d'une distrib Linux debian.
Cordialement.
- --
Thierry Houx (thierry.houx@alussinan.org)
Tourisme en Haute-Normandie, informatique libre et généalogie:
http://thierry.houx.free.fr/index.html
Webmestre du site http://www.geneacaux.org/ membre CGPCSM N°72-2576
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
Exemple de select: "(select ID, TYPACT, DATETXT, COMMUNE, NOM, PRE, 'X' as C_NOM, 'Y' as C_PRE, LADATE,'Décès' as LIBELLE " Les index sont nombreux, les tables correspondent au type d'actes: décès, mariages, naissances, actes divers. Les recherches se font souvent sur l'ensemble des tables Bon... j'ai déjà "consulté" pour geneanet et ils ont quelques millions
d'enregistrements. Ca ne tient pas dans 256 de RAM. En fait ils ont plusieurs serveurs (je ne sais plus combien, mais beaucoup). Je sais, ça n'a pas grand chose à voir, mais ça donne un ordre d'idée.
En fait notre site était hébergé chez Geneanet; j'ai dû changer car la taille de la base et le nombre de connectés écroulaient le serveur qui est mutualisé (ça commençait à tousser fort chez Geneanet). C'est pourquoi je suis passé à un serveur virtualisé, dont le fonctionnement est rapide.
Maintenant, quand tu dis que ça "plante" quand il n'y a personne, alors le problème est peut-être ailleurs que dans la coupure pour surcharge.
Si ça tient le coup pour 60 visiteurs simultanés, alors moi j'ai tendance à dire que c'est pas un problème de charge pour le moment.
Je suis d'accord avec cette analyse; mon idée est qu'un script doit à un moment boucler et saturer le CPU. La difficulté étant de savoir par quel moyen identifier le "fautif". La grosse quantité des sollicitations étant sur le php et MySQL, c'est ceux-là que j'incrimine en premier.
Cordialement. - -- Thierry Houx () Tourisme en Haute-Normandie, informatique libre et généalogie: http://thierry.houx.free.fr/index.html Webmestre du site http://www.geneacaux.org/ membre CGPCSM N°72-2576 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFH4VQhvEfAUqhIJHURAsfvAJsHOw9fBi0etU8B3NUtSauieTLSpgCg3L8C FrJU05CBxpL9iFZDcc6qLN0 > =zaQ9 -----END PGP SIGNATURE----- Je dis peut être un imbécilité mais il n'y aurait pas une étreinte
mortelle ? est ce que vous utiliser beaucoup les locks sur les tables ?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thierry Houx wrote:
Exemple de select:
"(select ID, TYPACT, DATETXT, COMMUNE, NOM, PRE, 'X' as C_NOM, 'Y' as
C_PRE, LADATE,'Décès' as LIBELLE "
Les index sont nombreux, les tables correspondent au type d'actes:
décès, mariages, naissances, actes divers. Les recherches se font
souvent sur l'ensemble des tables
Bon... j'ai déjà "consulté" pour geneanet et ils ont quelques millions
d'enregistrements. Ca ne tient pas dans 256 de RAM. En fait ils ont
plusieurs serveurs (je ne sais plus combien, mais beaucoup).
Je sais, ça n'a pas grand chose à voir, mais ça donne un ordre d'idée.
En fait notre site était hébergé chez Geneanet; j'ai dû changer car la
taille de la base et le nombre de connectés écroulaient le serveur qui
est mutualisé (ça commençait à tousser fort chez Geneanet).
C'est pourquoi je suis passé à un serveur virtualisé, dont le
fonctionnement est rapide.
Maintenant, quand tu dis que ça "plante" quand il n'y a personne, alors
le problème est peut-être ailleurs que dans la coupure pour surcharge.
Si ça tient le coup pour 60 visiteurs simultanés, alors moi j'ai
tendance à dire que c'est pas un problème de charge pour le moment.
Je suis d'accord avec cette analyse; mon idée est qu'un script doit à un
moment boucler et saturer le CPU. La difficulté étant de savoir par quel
moyen identifier le "fautif". La grosse quantité des sollicitations
étant sur le php et MySQL, c'est ceux-là que j'incrimine en premier.
Cordialement.
- --
Thierry Houx (thierry.houx@alussinan.org)
Tourisme en Haute-Normandie, informatique libre et généalogie:
http://thierry.houx.free.fr/index.html
Webmestre du site http://www.geneacaux.org/ membre CGPCSM N°72-2576
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFH4VQhvEfAUqhIJHURAsfvAJsHOw9fBi0etU8B3NUtSauieTLSpgCg3L8C
FrJU05CBxpL9iFZDcc6qLN0 > =zaQ9
-----END PGP SIGNATURE-----
Je dis peut être un imbécilité mais il n'y aurait pas une étreinte
mortelle ? est ce que vous utiliser beaucoup les locks sur les tables ?
Exemple de select: "(select ID, TYPACT, DATETXT, COMMUNE, NOM, PRE, 'X' as C_NOM, 'Y' as C_PRE, LADATE,'Décès' as LIBELLE " Les index sont nombreux, les tables correspondent au type d'actes: décès, mariages, naissances, actes divers. Les recherches se font souvent sur l'ensemble des tables Bon... j'ai déjà "consulté" pour geneanet et ils ont quelques millions
d'enregistrements. Ca ne tient pas dans 256 de RAM. En fait ils ont plusieurs serveurs (je ne sais plus combien, mais beaucoup). Je sais, ça n'a pas grand chose à voir, mais ça donne un ordre d'idée.
En fait notre site était hébergé chez Geneanet; j'ai dû changer car la taille de la base et le nombre de connectés écroulaient le serveur qui est mutualisé (ça commençait à tousser fort chez Geneanet). C'est pourquoi je suis passé à un serveur virtualisé, dont le fonctionnement est rapide.
Maintenant, quand tu dis que ça "plante" quand il n'y a personne, alors le problème est peut-être ailleurs que dans la coupure pour surcharge.
Si ça tient le coup pour 60 visiteurs simultanés, alors moi j'ai tendance à dire que c'est pas un problème de charge pour le moment.
Je suis d'accord avec cette analyse; mon idée est qu'un script doit à un moment boucler et saturer le CPU. La difficulté étant de savoir par quel moyen identifier le "fautif". La grosse quantité des sollicitations étant sur le php et MySQL, c'est ceux-là que j'incrimine en premier.
Cordialement. - -- Thierry Houx () Tourisme en Haute-Normandie, informatique libre et généalogie: http://thierry.houx.free.fr/index.html Webmestre du site http://www.geneacaux.org/ membre CGPCSM N°72-2576 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFH4VQhvEfAUqhIJHURAsfvAJsHOw9fBi0etU8B3NUtSauieTLSpgCg3L8C FrJU05CBxpL9iFZDcc6qLN0 > =zaQ9 -----END PGP SIGNATURE----- Je dis peut être un imbécilité mais il n'y aurait pas une étreinte
mortelle ? est ce que vous utiliser beaucoup les locks sur les tables ?
Thierry Houx
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Je dis peut être un imbécilité mais il n'y aurait pas une étreinte mortelle ? est ce que vous utiliser beaucoup les locks sur les tables ?
Je vais regarder de ce côté!
Cordialement. - -- Thierry Houx () Tourisme en Haute-Normandie, informatique libre et généalogie: http://thierry.houx.free.fr/index.html Webmestre du site http://www.geneacaux.org/ membre CGPCSM N°72-2576 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
Je dis peut être un imbécilité mais il n'y aurait pas une étreinte
mortelle ? est ce que vous utiliser beaucoup les locks sur les tables ?
Je vais regarder de ce côté!
Cordialement.
- --
Thierry Houx (thierry.houx@alussinan.org)
Tourisme en Haute-Normandie, informatique libre et généalogie:
http://thierry.houx.free.fr/index.html
Webmestre du site http://www.geneacaux.org/ membre CGPCSM N°72-2576
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
Je dis peut être un imbécilité mais il n'y aurait pas une étreinte mortelle ? est ce que vous utiliser beaucoup les locks sur les tables ?
Je vais regarder de ce côté!
Cordialement. - -- Thierry Houx () Tourisme en Haute-Normandie, informatique libre et généalogie: http://thierry.houx.free.fr/index.html Webmestre du site http://www.geneacaux.org/ membre CGPCSM N°72-2576 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
