Je rencontre un symptôme tout à fait étonnant sur une base de 5go environ
(le fichier le plus gros fait environ 1,5go).
En production chez un client je rencontrais des ralentissements de plus en
plus important au fur et à mesure de l'enrichissement de la base. J'ai
donc décidé de faire des tests et notamment de réindexation.
Sur ce serveur une réindexation dure 5 heures mais ce qui est le plus
bizarre c'est que cette réindexation faite directement sur le serveur
paralyse complètement le serveur et ceci de plus en plus jusqu'à ne plus
pouvoir rien faire dessus. La seule solution est le reboot. Le serveur
n'est pas très performant (XEON BI-PRO 3ghz, 512mo de mémoire quand même),
mais pour avoir fait des tests sur d'autres serveurs, je ne pense pas que
ce soit la raison première du ralentissement. Le processeur ne travaille
pas particulièrement et la mémoire utilisée tourne au alentour de 422mo.
Le client m'a fourni un autre serveur à peu prêt équivalent, le problème
reste entier, le symptôme est le même.
J'ai fait d'autres tests sur d'autres serveurs avec exactement la même
base de donnée et le même OS (Windows 2000) :
XEON BI-PRO 3ghz, 512mo, durée : 5 heures 30 (serveur d'origine)
Sous windows, duplication du répertoire avec la base (15 minutes)
PENTIUM III 256mo, durée : 8 minutes (serveur à nous)
Sous windows, duplication du répertoire avec la base (10 minutes)
QUADRI-PRO XEON, 2go, durée : 4 minutes (autre serveur du client)
Sous windows, duplication du répertoire avec la base (2 minutes)
Le problème est apparu avec le grossissement de la base, si elle est plus
petite le problème n'existe pas. C'est sur la réindexation du fichier le
plus gros que le ralentissement commence à se faire sentir et ceci de plus
en plus.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Daniel
Emmanuel Haefele a écrit :
Bonjour,
Je rencontre un symptôme tout à fait étonnant sur une base de 5go environ (le fichier le plus gros fait environ 1,5go).
En production chez un client je rencontrais des ralentissements de plus en plus important au fur et à mesure de l'enrichissement de la base. J'ai donc décidé de faire des tests et notamment de réindexation.
Sur ce serveur une réindexation dure 5 heures mais ce qui est le plus bizarre c'est que cette réindexation faite directement sur le serveur paralyse complètement le serveur et ceci de plus en plus jusqu'à ne plus pouvoir rien faire dessus. La seule solution est le reboot. Le serveur n'est pas très performant (XEON BI-PRO 3ghz, 512mo de mémoire quand même), mais pour avoir fait des tests sur d'autres serveurs, je ne pense pas que ce soit la raison première du ralentissement. Le processeur ne travaille pas particulièrement et la mémoire utilisée tourne au alentour de 422mo.
Le client m'a fourni un autre serveur à peu prêt équivalent, le problème reste entier, le symptôme est le même.
J'ai fait d'autres tests sur d'autres serveurs avec exactement la même base de donnée et le même OS (Windows 2000) :
XEON BI-PRO 3ghz, 512mo, durée : 5 heures 30 (serveur d'origine) Sous windows, duplication du répertoire avec la base (15 minutes)
PENTIUM III 256mo, durée : 8 minutes (serveur à nous) Sous windows, duplication du répertoire avec la base (10 minutes)
QUADRI-PRO XEON, 2go, durée : 4 minutes (autre serveur du client) Sous windows, duplication du répertoire avec la base (2 minutes)
Le problème est apparu avec le grossissement de la base, si elle est plus petite le problème n'existe pas. C'est sur la réindexation du fichier le plus gros que le ralentissement commence à se faire sentir et ceci de plus en plus.
Déjà rencontré ce problème ? une idée ?
Par avance merci.
Cordialement,
Emmanuel Haefelé.
Bonjour,
hypertreading activé ou pas ? Disque saturé, fatigué ou lent ? Problème de bus pour accéder à la RAM (carte mère) ?
-- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
Emmanuel Haefele a écrit :
Bonjour,
Je rencontre un symptôme tout à fait étonnant sur une base de 5go environ
(le fichier le plus gros fait environ 1,5go).
En production chez un client je rencontrais des ralentissements de plus en
plus important au fur et à mesure de l'enrichissement de la base. J'ai
donc décidé de faire des tests et notamment de réindexation.
Sur ce serveur une réindexation dure 5 heures mais ce qui est le plus
bizarre c'est que cette réindexation faite directement sur le serveur
paralyse complètement le serveur et ceci de plus en plus jusqu'à ne plus
pouvoir rien faire dessus. La seule solution est le reboot. Le serveur
n'est pas très performant (XEON BI-PRO 3ghz, 512mo de mémoire quand même),
mais pour avoir fait des tests sur d'autres serveurs, je ne pense pas que
ce soit la raison première du ralentissement. Le processeur ne travaille
pas particulièrement et la mémoire utilisée tourne au alentour de 422mo.
Le client m'a fourni un autre serveur à peu prêt équivalent, le problème
reste entier, le symptôme est le même.
J'ai fait d'autres tests sur d'autres serveurs avec exactement la même
base de donnée et le même OS (Windows 2000) :
XEON BI-PRO 3ghz, 512mo, durée : 5 heures 30 (serveur d'origine)
Sous windows, duplication du répertoire avec la base (15 minutes)
PENTIUM III 256mo, durée : 8 minutes (serveur à nous)
Sous windows, duplication du répertoire avec la base (10 minutes)
QUADRI-PRO XEON, 2go, durée : 4 minutes (autre serveur du client)
Sous windows, duplication du répertoire avec la base (2 minutes)
Le problème est apparu avec le grossissement de la base, si elle est plus
petite le problème n'existe pas. C'est sur la réindexation du fichier le
plus gros que le ralentissement commence à se faire sentir et ceci de plus
en plus.
Déjà rencontré ce problème ? une idée ?
Par avance merci.
Cordialement,
Emmanuel Haefelé.
Bonjour,
hypertreading activé ou pas ?
Disque saturé, fatigué ou lent ?
Problème de bus pour accéder à la RAM (carte mère) ?
--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
Je rencontre un symptôme tout à fait étonnant sur une base de 5go environ (le fichier le plus gros fait environ 1,5go).
En production chez un client je rencontrais des ralentissements de plus en plus important au fur et à mesure de l'enrichissement de la base. J'ai donc décidé de faire des tests et notamment de réindexation.
Sur ce serveur une réindexation dure 5 heures mais ce qui est le plus bizarre c'est que cette réindexation faite directement sur le serveur paralyse complètement le serveur et ceci de plus en plus jusqu'à ne plus pouvoir rien faire dessus. La seule solution est le reboot. Le serveur n'est pas très performant (XEON BI-PRO 3ghz, 512mo de mémoire quand même), mais pour avoir fait des tests sur d'autres serveurs, je ne pense pas que ce soit la raison première du ralentissement. Le processeur ne travaille pas particulièrement et la mémoire utilisée tourne au alentour de 422mo.
Le client m'a fourni un autre serveur à peu prêt équivalent, le problème reste entier, le symptôme est le même.
J'ai fait d'autres tests sur d'autres serveurs avec exactement la même base de donnée et le même OS (Windows 2000) :
XEON BI-PRO 3ghz, 512mo, durée : 5 heures 30 (serveur d'origine) Sous windows, duplication du répertoire avec la base (15 minutes)
PENTIUM III 256mo, durée : 8 minutes (serveur à nous) Sous windows, duplication du répertoire avec la base (10 minutes)
QUADRI-PRO XEON, 2go, durée : 4 minutes (autre serveur du client) Sous windows, duplication du répertoire avec la base (2 minutes)
Le problème est apparu avec le grossissement de la base, si elle est plus petite le problème n'existe pas. C'est sur la réindexation du fichier le plus gros que le ralentissement commence à se faire sentir et ceci de plus en plus.
Déjà rencontré ce problème ? une idée ?
Par avance merci.
Cordialement,
Emmanuel Haefelé.
Bonjour,
hypertreading activé ou pas ? Disque saturé, fatigué ou lent ? Problème de bus pour accéder à la RAM (carte mère) ?
-- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
Firetox
Bonjour,
une idée des temps d'acces disque ? quels sont les caracteristique de HDD
avec des bases de ce volume c'est souvent le disque qui est en cause et pas la machine les temps d'acces aux disques (5400 tours 10 000 tours font une grosse difference) de même que la defragmentation
le fichier ndx a beaucoup d'importance, plus il y a d'index plus l'indexation est longue. ensuite pour etablir un semblant d'information sur tes différents servuer : le fait de copier la base sur un servuer a toi pour faire un test fait une defragmentaion puisque le fichier en copie sera optimiser donc pas dans la config client
bref je ferais une defrag, sur le disque client ou alors deplacement de la base pour me retrouver dans les meme conditions que si je copie la base sur une autre machine. ensuite je referais les tests de reindexation (ne pas oubliez de faire un compactage : plus long mais les prochaines reindexations devraient etre plus rapide
Bon dev @+
"Emmanuel Haefele" a écrit dans le message de news:4a0abc8b$0$17762$
Bonjour,
Je rencontre un symptôme tout à fait étonnant sur une base de 5go environ (le fichier le plus gros fait environ 1,5go).
En production chez un client je rencontrais des ralentissements de plus en plus important au fur et à mesure de l'enrichissement de la base. J'ai donc décidé de faire des tests et notamment de réindexation.
Sur ce serveur une réindexation dure 5 heures mais ce qui est le plus bizarre c'est que cette réindexation faite directement sur le serveur paralyse complètement le serveur et ceci de plus en plus jusqu'à ne plus pouvoir rien faire dessus. La seule solution est le reboot. Le serveur n'est pas très performant (XEON BI-PRO 3ghz, 512mo de mémoire quand même), mais pour avoir fait des tests sur d'autres serveurs, je ne pense pas que ce soit la raison première du ralentissement. Le processeur ne travaille pas particulièrement et la mémoire utilisée tourne au alentour de 422mo.
Le client m'a fourni un autre serveur à peu prêt équivalent, le problème reste entier, le symptôme est le même.
J'ai fait d'autres tests sur d'autres serveurs avec exactement la même base de donnée et le même OS (Windows 2000) :
XEON BI-PRO 3ghz, 512mo, durée : 5 heures 30 (serveur d'origine) Sous windows, duplication du répertoire avec la base (15 minutes)
PENTIUM III 256mo, durée : 8 minutes (serveur à nous) Sous windows, duplication du répertoire avec la base (10 minutes)
QUADRI-PRO XEON, 2go, durée : 4 minutes (autre serveur du client) Sous windows, duplication du répertoire avec la base (2 minutes)
Le problème est apparu avec le grossissement de la base, si elle est plus petite le problème n'existe pas. C'est sur la réindexation du fichier le plus gros que le ralentissement commence à se faire sentir et ceci de plus en plus.
Déjà rencontré ce problème ? une idée ?
Par avance merci.
Cordialement,
Emmanuel Haefelé.
Bonjour,
une idée des temps d'acces disque ?
quels sont les caracteristique de HDD
avec des bases de ce volume c'est souvent le disque qui est en cause et pas
la machine
les temps d'acces aux disques (5400 tours 10 000 tours font une grosse
difference) de même que la defragmentation
le fichier ndx a beaucoup d'importance, plus il y a d'index plus
l'indexation est longue. ensuite pour etablir un semblant d'information sur
tes différents servuer : le fait de copier la base sur un servuer a toi pour
faire un test fait une defragmentaion puisque le fichier en copie sera
optimiser donc pas dans la config client
bref
je ferais une defrag, sur le disque client ou alors deplacement de la base
pour me retrouver dans les meme conditions que si je copie la base sur une
autre machine. ensuite je referais les tests de reindexation (ne pas oubliez
de faire un compactage : plus long mais les prochaines reindexations
devraient etre plus rapide
Bon dev
@+
"Emmanuel Haefele" <e.haefele@wanadoo.fr> a écrit dans le message de
news:4a0abc8b$0$17762$ba4acef3@news.orange.fr...
Bonjour,
Je rencontre un symptôme tout à fait étonnant sur une base de 5go environ
(le fichier le plus gros fait environ 1,5go).
En production chez un client je rencontrais des ralentissements de plus en
plus important au fur et à mesure de l'enrichissement de la base. J'ai
donc décidé de faire des tests et notamment de réindexation.
Sur ce serveur une réindexation dure 5 heures mais ce qui est le plus
bizarre c'est que cette réindexation faite directement sur le serveur
paralyse complètement le serveur et ceci de plus en plus jusqu'à ne plus
pouvoir rien faire dessus. La seule solution est le reboot. Le serveur
n'est pas très performant (XEON BI-PRO 3ghz, 512mo de mémoire quand même),
mais pour avoir fait des tests sur d'autres serveurs, je ne pense pas que
ce soit la raison première du ralentissement. Le processeur ne travaille
pas particulièrement et la mémoire utilisée tourne au alentour de 422mo.
Le client m'a fourni un autre serveur à peu prêt équivalent, le problème
reste entier, le symptôme est le même.
J'ai fait d'autres tests sur d'autres serveurs avec exactement la même
base de donnée et le même OS (Windows 2000) :
XEON BI-PRO 3ghz, 512mo, durée : 5 heures 30 (serveur d'origine)
Sous windows, duplication du répertoire avec la base (15 minutes)
PENTIUM III 256mo, durée : 8 minutes (serveur à nous)
Sous windows, duplication du répertoire avec la base (10 minutes)
QUADRI-PRO XEON, 2go, durée : 4 minutes (autre serveur du client)
Sous windows, duplication du répertoire avec la base (2 minutes)
Le problème est apparu avec le grossissement de la base, si elle est plus
petite le problème n'existe pas. C'est sur la réindexation du fichier le
plus gros que le ralentissement commence à se faire sentir et ceci de plus
en plus.
une idée des temps d'acces disque ? quels sont les caracteristique de HDD
avec des bases de ce volume c'est souvent le disque qui est en cause et pas la machine les temps d'acces aux disques (5400 tours 10 000 tours font une grosse difference) de même que la defragmentation
le fichier ndx a beaucoup d'importance, plus il y a d'index plus l'indexation est longue. ensuite pour etablir un semblant d'information sur tes différents servuer : le fait de copier la base sur un servuer a toi pour faire un test fait une defragmentaion puisque le fichier en copie sera optimiser donc pas dans la config client
bref je ferais une defrag, sur le disque client ou alors deplacement de la base pour me retrouver dans les meme conditions que si je copie la base sur une autre machine. ensuite je referais les tests de reindexation (ne pas oubliez de faire un compactage : plus long mais les prochaines reindexations devraient etre plus rapide
Bon dev @+
"Emmanuel Haefele" a écrit dans le message de news:4a0abc8b$0$17762$
Bonjour,
Je rencontre un symptôme tout à fait étonnant sur une base de 5go environ (le fichier le plus gros fait environ 1,5go).
En production chez un client je rencontrais des ralentissements de plus en plus important au fur et à mesure de l'enrichissement de la base. J'ai donc décidé de faire des tests et notamment de réindexation.
Sur ce serveur une réindexation dure 5 heures mais ce qui est le plus bizarre c'est que cette réindexation faite directement sur le serveur paralyse complètement le serveur et ceci de plus en plus jusqu'à ne plus pouvoir rien faire dessus. La seule solution est le reboot. Le serveur n'est pas très performant (XEON BI-PRO 3ghz, 512mo de mémoire quand même), mais pour avoir fait des tests sur d'autres serveurs, je ne pense pas que ce soit la raison première du ralentissement. Le processeur ne travaille pas particulièrement et la mémoire utilisée tourne au alentour de 422mo.
Le client m'a fourni un autre serveur à peu prêt équivalent, le problème reste entier, le symptôme est le même.
J'ai fait d'autres tests sur d'autres serveurs avec exactement la même base de donnée et le même OS (Windows 2000) :
XEON BI-PRO 3ghz, 512mo, durée : 5 heures 30 (serveur d'origine) Sous windows, duplication du répertoire avec la base (15 minutes)
PENTIUM III 256mo, durée : 8 minutes (serveur à nous) Sous windows, duplication du répertoire avec la base (10 minutes)
QUADRI-PRO XEON, 2go, durée : 4 minutes (autre serveur du client) Sous windows, duplication du répertoire avec la base (2 minutes)
Le problème est apparu avec le grossissement de la base, si elle est plus petite le problème n'existe pas. C'est sur la réindexation du fichier le plus gros que le ralentissement commence à se faire sentir et ceci de plus en plus.
Déjà rencontré ce problème ? une idée ?
Par avance merci.
Cordialement,
Emmanuel Haefelé.
PYT
Je commencerai par virer les anti virus sur les fichier HF
PYT
Bonjour,
Je rencontre un symptôme tout à fait étonnant sur une base de 5go environ (le fichier le plus gros fait environ 1,5go).
En production chez un client je rencontrais des ralentissements de plus en plus important au fur et à mesure de l'enrichissement de la base. J'ai donc décidé de faire des tests et notamment de réindexation.
Sur ce serveur une réindexation dure 5 heures mais ce qui est le plus bizarre c'est que cette réindexation faite directement sur le serveur paralyse complètement le serveur et ceci de plus en plus jusqu'à ne plus pouvoir rien faire dessus. La seule solution est le reboot. Le serveur n'est pas très performant (XEON BI-PRO 3ghz, 512mo de mémoire quand même), mais pour avoir fait des tests sur d'autres serveurs, je ne pense pas que ce soit la raison première du ralentissement. Le processeur ne travaille pas particulièrement et la mémoire utilisée tourne au alentour de 422mo.
Le client m'a fourni un autre serveur à peu prêt équivalent, le problème reste entier, le symptôme est le même.
J'ai fait d'autres tests sur d'autres serveurs avec exactement la même base de donnée et le même OS (Windows 2000) :
XEON BI-PRO 3ghz, 512mo, durée : 5 heures 30 (serveur d'origine) Sous windows, duplication du répertoire avec la base (15 minutes)
PENTIUM III 256mo, durée : 8 minutes (serveur à nous) Sous windows, duplication du répertoire avec la base (10 minutes)
QUADRI-PRO XEON, 2go, durée : 4 minutes (autre serveur du client) Sous windows, duplication du répertoire avec la base (2 minutes)
Le problème est apparu avec le grossissement de la base, si elle est plus petite le problème n'existe pas. C'est sur la réindexation du fichier le plus gros que le ralentissement commence à se faire sentir et ceci de plus en plus.
Déjà rencontré ce problème ? une idée ?
Par avance merci.
Cordialement,
Emmanuel Haefelé.
Je commencerai par virer les anti virus sur les fichier HF
PYT
Bonjour,
Je rencontre un symptôme tout à fait étonnant sur une base de 5go environ
(le fichier le plus gros fait environ 1,5go).
En production chez un client je rencontrais des ralentissements de plus en
plus important au fur et à mesure de l'enrichissement de la base. J'ai
donc décidé de faire des tests et notamment de réindexation.
Sur ce serveur une réindexation dure 5 heures mais ce qui est le plus
bizarre c'est que cette réindexation faite directement sur le serveur
paralyse complètement le serveur et ceci de plus en plus jusqu'à ne plus
pouvoir rien faire dessus. La seule solution est le reboot. Le serveur
n'est pas très performant (XEON BI-PRO 3ghz, 512mo de mémoire quand même),
mais pour avoir fait des tests sur d'autres serveurs, je ne pense pas que
ce soit la raison première du ralentissement. Le processeur ne travaille
pas particulièrement et la mémoire utilisée tourne au alentour de 422mo.
Le client m'a fourni un autre serveur à peu prêt équivalent, le problème
reste entier, le symptôme est le même.
J'ai fait d'autres tests sur d'autres serveurs avec exactement la même
base de donnée et le même OS (Windows 2000) :
XEON BI-PRO 3ghz, 512mo, durée : 5 heures 30 (serveur d'origine)
Sous windows, duplication du répertoire avec la base (15 minutes)
PENTIUM III 256mo, durée : 8 minutes (serveur à nous)
Sous windows, duplication du répertoire avec la base (10 minutes)
QUADRI-PRO XEON, 2go, durée : 4 minutes (autre serveur du client)
Sous windows, duplication du répertoire avec la base (2 minutes)
Le problème est apparu avec le grossissement de la base, si elle est plus
petite le problème n'existe pas. C'est sur la réindexation du fichier le
plus gros que le ralentissement commence à se faire sentir et ceci de plus
en plus.
Je commencerai par virer les anti virus sur les fichier HF
PYT
Bonjour,
Je rencontre un symptôme tout à fait étonnant sur une base de 5go environ (le fichier le plus gros fait environ 1,5go).
En production chez un client je rencontrais des ralentissements de plus en plus important au fur et à mesure de l'enrichissement de la base. J'ai donc décidé de faire des tests et notamment de réindexation.
Sur ce serveur une réindexation dure 5 heures mais ce qui est le plus bizarre c'est que cette réindexation faite directement sur le serveur paralyse complètement le serveur et ceci de plus en plus jusqu'à ne plus pouvoir rien faire dessus. La seule solution est le reboot. Le serveur n'est pas très performant (XEON BI-PRO 3ghz, 512mo de mémoire quand même), mais pour avoir fait des tests sur d'autres serveurs, je ne pense pas que ce soit la raison première du ralentissement. Le processeur ne travaille pas particulièrement et la mémoire utilisée tourne au alentour de 422mo.
Le client m'a fourni un autre serveur à peu prêt équivalent, le problème reste entier, le symptôme est le même.
J'ai fait d'autres tests sur d'autres serveurs avec exactement la même base de donnée et le même OS (Windows 2000) :
XEON BI-PRO 3ghz, 512mo, durée : 5 heures 30 (serveur d'origine) Sous windows, duplication du répertoire avec la base (15 minutes)
PENTIUM III 256mo, durée : 8 minutes (serveur à nous) Sous windows, duplication du répertoire avec la base (10 minutes)
QUADRI-PRO XEON, 2go, durée : 4 minutes (autre serveur du client) Sous windows, duplication du répertoire avec la base (2 minutes)
Le problème est apparu avec le grossissement de la base, si elle est plus petite le problème n'existe pas. C'est sur la réindexation du fichier le plus gros que le ralentissement commence à se faire sentir et ceci de plus en plus.
Déjà rencontré ce problème ? une idée ?
Par avance merci.
Cordialement,
Emmanuel Haefelé.
Emmanuel Haefele
"Firetox" a écrit
Bonjour,
une idée des temps d'acces disque ? quels sont les caracteristique de HDD
Ca je dois dire que je ne les connais pas trop. Il y a des controleurs raid mais je n'en sais pas plus.
J'ai aussi tendance à mettre en accusation les disques. Le serveur d'origine est très fragmenté, sur l'autre (qui a les mêmes symptômes), j'ai copié la base et fait une défragmentation avant les tests.
Il y a quand même un truc que je ne comprends pas c'est la paralysie du serveur alors que le processeur n'est pas spécialement utilisé et la mémoire non plus. Autre indication, ci-dessous deux fichiers qui ont été réindéxé dans l'ordre suivant :
On constate bien la paralysie du serveur, bizarre ...
Cordialement,
Emmanuel Haefelé.
"Firetox" <firetox@free.fr> a écrit
Bonjour,
une idée des temps d'acces disque ?
quels sont les caracteristique de HDD
Ca je dois dire que je ne les connais pas trop. Il y a des controleurs
raid mais je n'en sais pas plus.
J'ai aussi tendance à mettre en accusation les disques. Le serveur
d'origine est très fragmenté, sur l'autre (qui a les mêmes symptômes),
j'ai copié la base et fait une défragmentation avant les tests.
Il y a quand même un truc que je ne comprends pas c'est la paralysie du
serveur alors que le processeur n'est pas spécialement utilisé et la
mémoire non plus. Autre indication, ci-dessous deux fichiers qui ont été
réindéxé dans l'ordre suivant :
une idée des temps d'acces disque ? quels sont les caracteristique de HDD
Ca je dois dire que je ne les connais pas trop. Il y a des controleurs raid mais je n'en sais pas plus.
J'ai aussi tendance à mettre en accusation les disques. Le serveur d'origine est très fragmenté, sur l'autre (qui a les mêmes symptômes), j'ai copié la base et fait une défragmentation avant les tests.
Il y a quand même un truc que je ne comprends pas c'est la paralysie du serveur alors que le processeur n'est pas spécialement utilisé et la mémoire non plus. Autre indication, ci-dessous deux fichiers qui ont été réindéxé dans l'ordre suivant :
On constate bien la paralysie du serveur, bizarre ...
Cordialement,
Emmanuel Haefelé.
Emmanuel Haefele
"PYT" a écrit
Bonjour Pierre-Yves,
Je commencerai par virer les anti virus sur les fichier HF
C'est une idée intéressante, je vais la creuser, merci. Théoriquement tous les serveurs sur le réseau du client sont configurés de la même manière avec trend micro je crois, mais bon je vais leur suggérer de vérifier ce point.
Cordialement,
Emmanuel Haefelé.
"PYT" <pierreyves.tavernier@free.fr> a écrit
Bonjour Pierre-Yves,
Je commencerai par virer les anti virus sur les fichier HF
C'est une idée intéressante, je vais la creuser, merci. Théoriquement tous
les serveurs sur le réseau du client sont configurés de la même manière
avec trend micro je crois, mais bon je vais leur suggérer de vérifier ce
point.
Je commencerai par virer les anti virus sur les fichier HF
C'est une idée intéressante, je vais la creuser, merci. Théoriquement tous les serveurs sur le réseau du client sont configurés de la même manière avec trend micro je crois, mais bon je vais leur suggérer de vérifier ce point.
Cordialement,
Emmanuel Haefelé.
tjfromparis
Daniel a peut etre une piste. Nous avons eu des soucis avec un autre produit qui tournait sur un serveur avec l'hyperthreading activé. Depuis MS a sorti un patch mais jette un oeil quand meme la dessus
pour mon info personnel : une grosse base comme ca sur HF : c'est parce que t'es joueur ? ;)
"Emmanuel Haefele" a écrit dans le message de groupe de discussion : 4a0abc8b$0$17762$
Bonjour,
Je rencontre un symptôme tout à fait étonnant sur une base de 5go environ (le fichier le plus gros fait environ 1,5go).
En production chez un client je rencontrais des ralentissements de plus en plus important au fur et à mesure de l'enrichissement de la base. J'ai donc décidé de faire des tests et notamment de réindexation.
Sur ce serveur une réindexation dure 5 heures mais ce qui est le plus bizarre c'est que cette réindexation faite directement sur le serveur paralyse complètement le serveur et ceci de plus en plus jusqu'à ne plus pouvoir rien faire dessus. La seule solution est le reboot. Le serveur n'est pas très performant (XEON BI-PRO 3ghz, 512mo de mémoire quand même), mais pour avoir fait des tests sur d'autres serveurs, je ne pense pas que ce soit la raison première du ralentissement. Le processeur ne travaille pas particulièrement et la mémoire utilisée tourne au alentour de 422mo.
Le client m'a fourni un autre serveur à peu prêt équivalent, le problème reste entier, le symptôme est le même.
J'ai fait d'autres tests sur d'autres serveurs avec exactement la même base de donnée et le même OS (Windows 2000) :
XEON BI-PRO 3ghz, 512mo, durée : 5 heures 30 (serveur d'origine) Sous windows, duplication du répertoire avec la base (15 minutes)
PENTIUM III 256mo, durée : 8 minutes (serveur à nous) Sous windows, duplication du répertoire avec la base (10 minutes)
QUADRI-PRO XEON, 2go, durée : 4 minutes (autre serveur du client) Sous windows, duplication du répertoire avec la base (2 minutes)
Le problème est apparu avec le grossissement de la base, si elle est plus petite le problème n'existe pas. C'est sur la réindexation du fichier le plus gros que le ralentissement commence à se faire sentir et ceci de plus en plus.
Déjà rencontré ce problème ? une idée ?
Par avance merci.
Cordialement,
Emmanuel Haefelé.
Daniel a peut etre une piste.
Nous avons eu des soucis avec un autre produit qui tournait sur un serveur
avec l'hyperthreading activé.
Depuis MS a sorti un patch mais jette un oeil quand meme la dessus
pour mon info personnel : une grosse base comme ca sur HF : c'est parce que
t'es joueur ? ;)
"Emmanuel Haefele" <e.haefele@wanadoo.fr> a écrit dans le message de groupe
de discussion : 4a0abc8b$0$17762$ba4acef3@news.orange.fr...
Bonjour,
Je rencontre un symptôme tout à fait étonnant sur une base de 5go environ
(le fichier le plus gros fait environ 1,5go).
En production chez un client je rencontrais des ralentissements de plus en
plus important au fur et à mesure de l'enrichissement de la base. J'ai
donc décidé de faire des tests et notamment de réindexation.
Sur ce serveur une réindexation dure 5 heures mais ce qui est le plus
bizarre c'est que cette réindexation faite directement sur le serveur
paralyse complètement le serveur et ceci de plus en plus jusqu'à ne plus
pouvoir rien faire dessus. La seule solution est le reboot. Le serveur
n'est pas très performant (XEON BI-PRO 3ghz, 512mo de mémoire quand même),
mais pour avoir fait des tests sur d'autres serveurs, je ne pense pas que
ce soit la raison première du ralentissement. Le processeur ne travaille
pas particulièrement et la mémoire utilisée tourne au alentour de 422mo.
Le client m'a fourni un autre serveur à peu prêt équivalent, le problème
reste entier, le symptôme est le même.
J'ai fait d'autres tests sur d'autres serveurs avec exactement la même
base de donnée et le même OS (Windows 2000) :
XEON BI-PRO 3ghz, 512mo, durée : 5 heures 30 (serveur d'origine)
Sous windows, duplication du répertoire avec la base (15 minutes)
PENTIUM III 256mo, durée : 8 minutes (serveur à nous)
Sous windows, duplication du répertoire avec la base (10 minutes)
QUADRI-PRO XEON, 2go, durée : 4 minutes (autre serveur du client)
Sous windows, duplication du répertoire avec la base (2 minutes)
Le problème est apparu avec le grossissement de la base, si elle est plus
petite le problème n'existe pas. C'est sur la réindexation du fichier le
plus gros que le ralentissement commence à se faire sentir et ceci de plus
en plus.
Daniel a peut etre une piste. Nous avons eu des soucis avec un autre produit qui tournait sur un serveur avec l'hyperthreading activé. Depuis MS a sorti un patch mais jette un oeil quand meme la dessus
pour mon info personnel : une grosse base comme ca sur HF : c'est parce que t'es joueur ? ;)
"Emmanuel Haefele" a écrit dans le message de groupe de discussion : 4a0abc8b$0$17762$
Bonjour,
Je rencontre un symptôme tout à fait étonnant sur une base de 5go environ (le fichier le plus gros fait environ 1,5go).
En production chez un client je rencontrais des ralentissements de plus en plus important au fur et à mesure de l'enrichissement de la base. J'ai donc décidé de faire des tests et notamment de réindexation.
Sur ce serveur une réindexation dure 5 heures mais ce qui est le plus bizarre c'est que cette réindexation faite directement sur le serveur paralyse complètement le serveur et ceci de plus en plus jusqu'à ne plus pouvoir rien faire dessus. La seule solution est le reboot. Le serveur n'est pas très performant (XEON BI-PRO 3ghz, 512mo de mémoire quand même), mais pour avoir fait des tests sur d'autres serveurs, je ne pense pas que ce soit la raison première du ralentissement. Le processeur ne travaille pas particulièrement et la mémoire utilisée tourne au alentour de 422mo.
Le client m'a fourni un autre serveur à peu prêt équivalent, le problème reste entier, le symptôme est le même.
J'ai fait d'autres tests sur d'autres serveurs avec exactement la même base de donnée et le même OS (Windows 2000) :
XEON BI-PRO 3ghz, 512mo, durée : 5 heures 30 (serveur d'origine) Sous windows, duplication du répertoire avec la base (15 minutes)
PENTIUM III 256mo, durée : 8 minutes (serveur à nous) Sous windows, duplication du répertoire avec la base (10 minutes)
QUADRI-PRO XEON, 2go, durée : 4 minutes (autre serveur du client) Sous windows, duplication du répertoire avec la base (2 minutes)
Le problème est apparu avec le grossissement de la base, si elle est plus petite le problème n'existe pas. C'est sur la réindexation du fichier le plus gros que le ralentissement commence à se faire sentir et ceci de plus en plus.
Déjà rencontré ce problème ? une idée ?
Par avance merci.
Cordialement,
Emmanuel Haefelé.
gimli
>>pour mon info personnel : une grosse base comme ca sur HF : c'est parce q ue
t'es joueur ? ;)
Pourquoi il y a des bases gratuites mieux adaptées pour les développements avec les outils de PC SOFT ? Si oui je pense que ça intéresse beaucoup de monde. Surtout si une étude fiable le démontre !
>>pour mon info personnel : une grosse base comme ca sur HF : c'est parce q ue
t'es joueur ? ;)
Pourquoi il y a des bases gratuites mieux adaptées pour les
développements avec les outils de PC SOFT ? Si oui je pense que ça
intéresse beaucoup de monde. Surtout si une étude fiable le démontre !
>>pour mon info personnel : une grosse base comme ca sur HF : c'est parce q ue
t'es joueur ? ;)
Pourquoi il y a des bases gratuites mieux adaptées pour les développements avec les outils de PC SOFT ? Si oui je pense que ça intéresse beaucoup de monde. Surtout si une étude fiable le démontre !
Emmanuel Haefele
"tjfromparis" a écrit :
Bonjour,
Daniel a peut etre une piste. Nous avons eu des soucis avec un autre produit qui tournait sur un serveur avec l'hyperthreading activé.
C'est vrai que je n'avais pas trop prêté attention à cette idée (désolé Daniel), je vais également y jeter un coup d'oeil. Le matériel étant relativement ancien, c'est effectivement possible que ça vienne de là.
pour mon info personnel : une grosse base comme ca sur HF : c'est parce que t'es joueur ? ;)
On pourrait le voir dans ce sens ;-)
Non plus sérieusement, le programme est ancien (1997) et n'était pas prévu au départ pour accueillir autant de données (5go/an). Maintenant un chose est certaine, en HF5 il n'aurait pas été réaliste de vouloir gérer une telle base en réseau. Heureusement que PC-Soft nous a fourni HF7 et son mode C/S car sans lui rien n'aurait été possible sauf à faire une migration du programme vers une vrai base SQL. Donc pour conclure et comparé à HF5, personnellement je suis assez satisfait du mode C/S de PC-Soft notamment en terme de fiabilité.
Voila, voila ...
Cordialement,
Emmanuel Haefelé.
"tjfromparis" <tjfromparis@gmail.com> a écrit :
Bonjour,
Daniel a peut etre une piste.
Nous avons eu des soucis avec un autre produit qui tournait sur un serveur
avec l'hyperthreading activé.
C'est vrai que je n'avais pas trop prêté attention à cette idée (désolé
Daniel), je vais également y jeter un coup d'oeil. Le matériel étant
relativement ancien, c'est effectivement possible que ça vienne de là.
pour mon info personnel : une grosse base comme ca sur HF : c'est parce
que t'es joueur ? ;)
On pourrait le voir dans ce sens ;-)
Non plus sérieusement, le programme est ancien (1997) et n'était pas prévu
au départ pour accueillir autant de données (5go/an). Maintenant un chose
est certaine, en HF5 il n'aurait pas été réaliste de vouloir gérer une telle
base en réseau. Heureusement que PC-Soft nous a fourni HF7 et son mode
C/S car sans lui rien n'aurait été possible sauf à faire une migration du
programme vers une vrai base SQL. Donc pour conclure et comparé à HF5,
personnellement je suis assez satisfait du mode C/S de PC-Soft notamment en
terme de fiabilité.
Daniel a peut etre une piste. Nous avons eu des soucis avec un autre produit qui tournait sur un serveur avec l'hyperthreading activé.
C'est vrai que je n'avais pas trop prêté attention à cette idée (désolé Daniel), je vais également y jeter un coup d'oeil. Le matériel étant relativement ancien, c'est effectivement possible que ça vienne de là.
pour mon info personnel : une grosse base comme ca sur HF : c'est parce que t'es joueur ? ;)
On pourrait le voir dans ce sens ;-)
Non plus sérieusement, le programme est ancien (1997) et n'était pas prévu au départ pour accueillir autant de données (5go/an). Maintenant un chose est certaine, en HF5 il n'aurait pas été réaliste de vouloir gérer une telle base en réseau. Heureusement que PC-Soft nous a fourni HF7 et son mode C/S car sans lui rien n'aurait été possible sauf à faire une migration du programme vers une vrai base SQL. Donc pour conclure et comparé à HF5, personnellement je suis assez satisfait du mode C/S de PC-Soft notamment en terme de fiabilité.
Voila, voila ...
Cordialement,
Emmanuel Haefelé.
gimli
On 17 mai, 12:56, "Emmanuel Haefele" wrote:
"tjfromparis" a écrit :
Bonjour,
> Daniel a peut etre une piste. > Nous avons eu des soucis avec un autre produit qui tournait sur un serv eur > avec l'hyperthreading activé.
C'est vrai que je n'avais pas trop prêté attention à cette idée ( désolé Daniel), je vais également y jeter un coup d'oeil. Le matériel étan t relativement ancien, c'est effectivement possible que ça vienne de là .
> pour mon info personnel : une grosse base comme ca sur HF : c'est parce > que t'es joueur ? ;)
On pourrait le voir dans ce sens ;-)
Non plus sérieusement, le programme est ancien (1997) et n'était pas prévu au départ pour accueillir autant de données (5go/an). Maintenant un c hose est certaine, en HF5 il n'aurait pas été réaliste de vouloir gére r une telle base en réseau. Heureusement que PC-Soft nous a fourni HF7 et son mode C/S car sans lui rien n'aurait été possible sauf à faire une migrat ion du programme vers une vrai base SQL. Donc pour conclure et comparé à HF5 , personnellement je suis assez satisfait du mode C/S de PC-Soft notamment en terme de fiabilité.
Voila, voila ...
Cordialement,
Emmanuel Haefelé.
Merci pour cette info
On 17 mai, 12:56, "Emmanuel Haefele" <e.haef...@wanadoo.fr> wrote:
"tjfromparis" <tjfrompa...@gmail.com> a écrit :
Bonjour,
> Daniel a peut etre une piste.
> Nous avons eu des soucis avec un autre produit qui tournait sur un serv eur
> avec l'hyperthreading activé.
C'est vrai que je n'avais pas trop prêté attention à cette idée ( désolé
Daniel), je vais également y jeter un coup d'oeil. Le matériel étan t
relativement ancien, c'est effectivement possible que ça vienne de là .
> pour mon info personnel : une grosse base comme ca sur HF : c'est parce
> que t'es joueur ? ;)
On pourrait le voir dans ce sens ;-)
Non plus sérieusement, le programme est ancien (1997) et n'était pas prévu
au départ pour accueillir autant de données (5go/an). Maintenant un c hose
est certaine, en HF5 il n'aurait pas été réaliste de vouloir gére r une telle
base en réseau. Heureusement que PC-Soft nous a fourni HF7 et son mode
C/S car sans lui rien n'aurait été possible sauf à faire une migrat ion du
programme vers une vrai base SQL. Donc pour conclure et comparé à HF5 ,
personnellement je suis assez satisfait du mode C/S de PC-Soft notamment en
terme de fiabilité.
> Daniel a peut etre une piste. > Nous avons eu des soucis avec un autre produit qui tournait sur un serv eur > avec l'hyperthreading activé.
C'est vrai que je n'avais pas trop prêté attention à cette idée ( désolé Daniel), je vais également y jeter un coup d'oeil. Le matériel étan t relativement ancien, c'est effectivement possible que ça vienne de là .
> pour mon info personnel : une grosse base comme ca sur HF : c'est parce > que t'es joueur ? ;)
On pourrait le voir dans ce sens ;-)
Non plus sérieusement, le programme est ancien (1997) et n'était pas prévu au départ pour accueillir autant de données (5go/an). Maintenant un c hose est certaine, en HF5 il n'aurait pas été réaliste de vouloir gére r une telle base en réseau. Heureusement que PC-Soft nous a fourni HF7 et son mode C/S car sans lui rien n'aurait été possible sauf à faire une migrat ion du programme vers une vrai base SQL. Donc pour conclure et comparé à HF5 , personnellement je suis assez satisfait du mode C/S de PC-Soft notamment en terme de fiabilité.
