Un client a installé une application de comptabilité sur un de ses
serveurs 2003. Cette application contrôle par l'intermédiaire de PIPE
(je suppose) l'accès à certains fichiers .MDB (fichiers access). Les
applications clientes sont soit sur les postes et accèdent aux fichiers
.MDB par l'intermédiaire d'un partage, soit directement sur le serveur
car il fait également office de serveur TSE. Correctement dimensionné
(4+ Go de RAM, Quadri processeur, ...)
Par contre, à certains moments plus ou moins proches, il y a de gros
problèmes de performances en écriture disque. En gros, dès qu'il y a la
saisie d'une ligne de compta, parfois le système met 5 secondes à
répondre à l'action de validation de la ligne de compta.
En regardant les compteurs de performances sur le serveur 2003, je me
suis rendu compte qu'il y avait fréquemment la long. Moyenne de file
d'attente en écriture ou lecture du disque logique où sont hébergés les
fichiers MDB qui tapait les 100%.
Ma question est la suivante : y a-t-il un moyen de savoir ce qui peut
occasionner de telles demandes d'écritures (quelle application ?) et si
c'est un processus Windows, lié à un utilisateur, quel utilisateur (et
quelle application) fait ce genre de demande d'écriture ?
Vous comprendrez qu'en ces temps de bilan pour les entreprises, il y a
une petite urgence dans la résolution de ce problème :)
Cordialement,
Guillaume
PS : Avec mon client, nous sommes également en train de voir avec
l'éditeur du logiciel.
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
Lognoul Marc [MVP]
Bonjour,
Sans connaitre la configuration exacte du serveur et le type d'application, il est difficile de répondre précisément, toutefois, voici qq commentaires/conseils ci dessous.
Un client a installé une application de comptabilité sur un de ses serveurs 2003. Cette application contrôle par l'intermédiaire de PIPE (je suppose) l'accès à certains fichiers .MDB (fichiers access). Les applications clientes sont soit sur les postes et accèdent aux fichiers .MDB par l'intermédiaire d'un partage, soit directement sur le serveur car il fait également office de serveur TSE. Correctement dimensionné (4+ Go de RAM, Quadri processeur, ...)
Si l'application est effectivement basée sur Access, elle a peu de chance d'être compilée en 64-bit. Je me poserais donc la question de l'intérêt de 4GB+ qui ne seraient donc pas adressables...
Par contre, à certains moments plus ou moins proches, il y a de gros problèmes de performances en écriture disque. En gros, dès qu'il y a la saisie d'une ligne de compta, parfois le système met 5 secondes à répondre à l'action de validation de la ligne de compta.
Cobien de disques physique? Logiques? Quels types de disques? De controleurs? Ou se trouve le ou les pagefile?
En regardant les compteurs de performances sur le serveur 2003, je me suis rendu compte qu'il y avait fréquemment la long. Moyenne de file d'attente en écriture ou lecture du disque logique où sont hébergés les fichiers MDB qui tapait les 100%.
La longueur de la file d'attente n'est pas en % mais bien en nombre d'opérations -> ne vous fiez donc pas au graphique donc l'échelle est sur 100 par défaut pour correspondre à l'utilisation CPU!
Ma question est la suivante : y a-t-il un moyen de savoir ce qui peut occasionner de telles demandes d'écritures (quelle application ?) et si c'est un processus Windows, lié à un utilisateur, quel utilisateur (et quelle application) fait ce genre de demande d'écriture ?
Par recoupement, on peu identifier des application gourmandes en I/O. Voici une manière de procéder: Configurez une capture de performance de longue durée (une journée, voire une semaine) avec les compteur suivants: Processes -> All instances -> Processot Time + tous les compteur contenant "Operations/Second" Physical disk - > All instances -> Current disk Queue Length Logical disk -> All instances -> Current disk Queue Length Sauvegardez les résultats sous forme de CSV sur un disque peu utilisé et qui ne serait pas à l'origine su problème. note: vous pouvez également prendre cette capture d'une machine distante afin d'éviter toute interférence.
Une fois la capture terminée, ouvrez le CSV dans Excel. Avec des graphes, tentez de trouver un corrélation entre Current disk Queue Length et un nombre d'IOPS pour un ou plusieurs processus donné. Si le processus est "SYSTEM", il est très probable que cette activité disque soit de la pagination.
Par contre, tracer l'utilisateur exact sera plus compliqué car les I/O ne sont pas toujours directement générés par les utilisateur. Les système les groupe pour plus d'efficacité.
Vous comprendrez qu'en ces temps de bilan pour les entreprises, il y a une petite urgence dans la résolution de ce problème :)
Si l'urgence est telle, je vous conseille d'ouvrir un incident au support MS et chez votre fournisseur logiciel. Ici , c'est un NG, pas d'obligation de résultats ni de SLA ;)
PS : Avec mon client, nous sommes également en train de voir avec l'éditeur du logiciel.
C'est à mon avis votre meilleure option, car lui seul connait en détails le comportement de son application.
-- Marc [MCSE, MCTS, MVP] [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
Bonjour,
Sans connaitre la configuration exacte du serveur et le type d'application,
il est difficile de répondre précisément, toutefois, voici qq
commentaires/conseils ci dessous.
Un client a installé une application de comptabilité sur un de ses
serveurs 2003. Cette application contrôle par l'intermédiaire de PIPE (je
suppose) l'accès à certains fichiers .MDB (fichiers access). Les
applications clientes sont soit sur les postes et accèdent aux fichiers
.MDB par l'intermédiaire d'un partage, soit directement sur le serveur car
il fait également office de serveur TSE. Correctement dimensionné (4+ Go
de RAM, Quadri processeur, ...)
Si l'application est effectivement basée sur Access, elle a peu de chance
d'être compilée en 64-bit.
Je me poserais donc la question de l'intérêt de 4GB+ qui ne seraient donc
pas adressables...
Par contre, à certains moments plus ou moins proches, il y a de gros
problèmes de performances en écriture disque. En gros, dès qu'il y a la
saisie d'une ligne de compta, parfois le système met 5 secondes à répondre
à l'action de validation de la ligne de compta.
Cobien de disques physique? Logiques? Quels types de disques? De
controleurs?
Ou se trouve le ou les pagefile?
En regardant les compteurs de performances sur le serveur 2003, je me suis
rendu compte qu'il y avait fréquemment la long. Moyenne de file d'attente
en écriture ou lecture du disque logique où sont hébergés les fichiers MDB
qui tapait les 100%.
La longueur de la file d'attente n'est pas en % mais bien en nombre
d'opérations -> ne vous fiez donc pas au graphique donc l'échelle est sur
100 par défaut pour correspondre à l'utilisation CPU!
Ma question est la suivante : y a-t-il un moyen de savoir ce qui peut
occasionner de telles demandes d'écritures (quelle application ?) et si
c'est un processus Windows, lié à un utilisateur, quel utilisateur (et
quelle application) fait ce genre de demande d'écriture ?
Par recoupement, on peu identifier des application gourmandes en I/O. Voici
une manière de procéder:
Configurez une capture de performance de longue durée (une journée, voire
une semaine) avec les compteur suivants:
Processes -> All instances -> Processot Time + tous les compteur contenant
"Operations/Second"
Physical disk - > All instances -> Current disk Queue Length
Logical disk -> All instances -> Current disk Queue Length
Sauvegardez les résultats sous forme de CSV sur un disque peu utilisé et qui
ne serait pas à l'origine su problème. note: vous pouvez également prendre
cette capture d'une machine distante afin d'éviter toute interférence.
Une fois la capture terminée, ouvrez le CSV dans Excel. Avec des graphes,
tentez de trouver un corrélation entre Current disk Queue Length et un
nombre d'IOPS pour un ou plusieurs processus donné. Si le processus est
"SYSTEM", il est très probable que cette activité disque soit de la
pagination.
Par contre, tracer l'utilisateur exact sera plus compliqué car les I/O ne
sont pas toujours directement générés par les utilisateur. Les système les
groupe pour plus d'efficacité.
Vous comprendrez qu'en ces temps de bilan pour les entreprises, il y a une
petite urgence dans la résolution de ce problème :)
Si l'urgence est telle, je vous conseille d'ouvrir un incident au support MS
et chez votre fournisseur logiciel. Ici , c'est un NG, pas d'obligation de
résultats ni de SLA ;)
PS : Avec mon client, nous sommes également en train de voir avec
l'éditeur du logiciel.
C'est à mon avis votre meilleure option, car lui seul connait en détails le
comportement de son application.
--
Marc [MCSE, MCTS, MVP]
[Heureux celui qui a pu pénétrer les causes secrètes des choses]
[Blog: http://www.marc-antho-etc.net/blog/]
Sans connaitre la configuration exacte du serveur et le type d'application, il est difficile de répondre précisément, toutefois, voici qq commentaires/conseils ci dessous.
Un client a installé une application de comptabilité sur un de ses serveurs 2003. Cette application contrôle par l'intermédiaire de PIPE (je suppose) l'accès à certains fichiers .MDB (fichiers access). Les applications clientes sont soit sur les postes et accèdent aux fichiers .MDB par l'intermédiaire d'un partage, soit directement sur le serveur car il fait également office de serveur TSE. Correctement dimensionné (4+ Go de RAM, Quadri processeur, ...)
Si l'application est effectivement basée sur Access, elle a peu de chance d'être compilée en 64-bit. Je me poserais donc la question de l'intérêt de 4GB+ qui ne seraient donc pas adressables...
Par contre, à certains moments plus ou moins proches, il y a de gros problèmes de performances en écriture disque. En gros, dès qu'il y a la saisie d'une ligne de compta, parfois le système met 5 secondes à répondre à l'action de validation de la ligne de compta.
Cobien de disques physique? Logiques? Quels types de disques? De controleurs? Ou se trouve le ou les pagefile?
En regardant les compteurs de performances sur le serveur 2003, je me suis rendu compte qu'il y avait fréquemment la long. Moyenne de file d'attente en écriture ou lecture du disque logique où sont hébergés les fichiers MDB qui tapait les 100%.
La longueur de la file d'attente n'est pas en % mais bien en nombre d'opérations -> ne vous fiez donc pas au graphique donc l'échelle est sur 100 par défaut pour correspondre à l'utilisation CPU!
Ma question est la suivante : y a-t-il un moyen de savoir ce qui peut occasionner de telles demandes d'écritures (quelle application ?) et si c'est un processus Windows, lié à un utilisateur, quel utilisateur (et quelle application) fait ce genre de demande d'écriture ?
Par recoupement, on peu identifier des application gourmandes en I/O. Voici une manière de procéder: Configurez une capture de performance de longue durée (une journée, voire une semaine) avec les compteur suivants: Processes -> All instances -> Processot Time + tous les compteur contenant "Operations/Second" Physical disk - > All instances -> Current disk Queue Length Logical disk -> All instances -> Current disk Queue Length Sauvegardez les résultats sous forme de CSV sur un disque peu utilisé et qui ne serait pas à l'origine su problème. note: vous pouvez également prendre cette capture d'une machine distante afin d'éviter toute interférence.
Une fois la capture terminée, ouvrez le CSV dans Excel. Avec des graphes, tentez de trouver un corrélation entre Current disk Queue Length et un nombre d'IOPS pour un ou plusieurs processus donné. Si le processus est "SYSTEM", il est très probable que cette activité disque soit de la pagination.
Par contre, tracer l'utilisateur exact sera plus compliqué car les I/O ne sont pas toujours directement générés par les utilisateur. Les système les groupe pour plus d'efficacité.
Vous comprendrez qu'en ces temps de bilan pour les entreprises, il y a une petite urgence dans la résolution de ce problème :)
Si l'urgence est telle, je vous conseille d'ouvrir un incident au support MS et chez votre fournisseur logiciel. Ici , c'est un NG, pas d'obligation de résultats ni de SLA ;)
PS : Avec mon client, nous sommes également en train de voir avec l'éditeur du logiciel.
C'est à mon avis votre meilleure option, car lui seul connait en détails le comportement de son application.
-- Marc [MCSE, MCTS, MVP] [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
