Vous n'êtes pas identifié(e).
Bonjour
Postgresql 9.0 est installé sur un server distant (Windows Web Server 2008 R2).
Chaque connexion se fait en SSL
Un programme minimaliste mesure le temps d'ouverture de la connexion
NpgsqlConnection conn = new NpgsqlConnection("ma chaine de connexion...");
conn.Open();
Durée = .......
Lorsque ce programme est installé sur des machines (Windows XP ou VISTA) appartenant à un groupe de travail (WORKGROUP) la durée d'ouverture de la connexion varie entre 2 et 3 secondes.
Lorsque ce programme est installé sur des machines (XP, VISTA) appartenant à un Domaine, la durée d'ouverture varie entre 5s et 15..20s !
5s pour 2 ouvertures rapprochées
20s pour 2 ouvertures situées à 1mn d'écart.
Le test a aussi été réalisé sur la même machine, en lui modifiant ses paramètres (groupe/domaine), avec le meme écart de résultat (2..20s).
Si l'on autorise une connexion NON SSL, la durée d'ouverture se situe dans tous les cas aux environs de 2s.
Quelqu'un aurait-il une explication sur cet écart de temps, et que devrais-je faire pour l'améliorer
Merci pour la réponse.
Philippe
Hors ligne
Je ne vois vraiment pas d'explication logique, mais bon, quand on parle de domaine microsoft, j'en cherche rarement…
Plus sérieusement, la seule chose qui me vienne à l'idée en voyant ça, c'est un paramétrage DNS différent entre le cas groupe de travail et le cas domaine… peut-être une tentative de résolution DNS inverse à la connexion qui réussit dans un cas et pas dans l'autre ? Mais à diagnostiquer sous Windows, ça ne va pas être simple. Et même la probabilité que ça soit ça me semble assez restreinte.
Marc.
Hors ligne
J'ai activé les traces de npgsql ( NpgsqlEventLog.Level = LogLevel.Debug;) et l'on peut voir que le blocage se trouve dans la classe NpgsqlStartupPacket,
WriteToStream_Ver_3(Stream output_stream)
{
PGUtil.WriteInt32(output_stream, 4 +4 +5...)
....
output_stream.Flush(); c'est cette instruction qui se bloque durant 15..20s
}
Pusique c'est un flush, on peut l'utiliser apres chaque PGUtil.Write... et observer les resultats.
En fait si on place un flush sous le 1er write de cette fonction, celui-ci se bloque mais pas les suivants.
En observant les datagrams sur le réseau on voit que le 1er flush ne se contente pas d'ecricre quelques octets, et je suppose que cela correspond à l'échange des clés pour la mise en oeuvre du SLL.
Hors ligne
Mais dans ce cas, pourquoi l'échange de clé prendrait il plus de temps quand on est dans un domaine ?
Marc.
Hors ligne
Et bien c'est ce que j'aimerais savoir.
cdlt
Hors ligne
Je reviens sur ce problème,
Avec une chaine de connexion contenant "Pooling=false;"
chaque conn.Open() dure 1..2 secondes pour un pc en Workgroup et 20s pour un PC connecté à un domaine.
durant la durée de vie de la connexion on peut voir un process postgres.exe s'executer, consommer de 2 à 5 Mo et disparaitre à la cloture de la connexion.
Avec "Pooling=true;" le process postgres.exe reste toujours présent, il n'y a plus la perte de temps de connexion.
L'application execute TOUJOURS les memes opérations (connection open, select, insert..... close, dispose), seule la chaine de connexion a été modifiée.
Cependant pour chaque opération réalisée, le process postgres.exe s'incrémente de 4 Mo, resultat 15 jours plus tard, le process consomme 100Mo ! Et il n'y a pour le moment qu'un seul poste client avec Pooling= true, tous les autres sont à false.
Donc avec 100 postes client, on a environ 10 process visibles en permance, car tous les process ont une durée de vie de quelques secondes, sauf celui du pooling= true qui a une durée de vie qui semble permante.
Si l'on bascule tous les postes en polling=true alors on va finir par exploser la mémoire.
Hors ligne
C'est, à mon avis, davantage un problème de comptabilisation de la mémoire qu'autre chose. Il y aurait une fuite mémoire de ce genre, ça se saurait.
Sous Linux, par exemple, la colonne mémoire RSS (mémoire résidente) augmente au fur et à mesure de l'utilisation d'un processus postgres. Mais ça n'a rien d'alarmant: la mémoire partagée entre les processus n'est comptabilisée dans ce RSS, pour chaque processus, qu'à partir du moment où elle est accédée, page par page. On voit donc la consommation mémoire des processus augmenter (RSS), dans top par exemple, sans que la consommation mémoire totale sur le système augmente.
Ne vous fiez donc pas trop à ces indicateurs mémoire, ils sont un peu bidons dans le cas d'un programme utilisant de la mémoire partagée, comme PostgreSQL.
Marc.
Hors ligne
Je viens de supprimer ce process, et l'afficheur de performance de windows à diminuer d'autant la mémoire consommée.
Hors ligne
Ce qui ne prouve rien. Il se peut que ce compteur se contente de faire la somme de la mémoire de chaque processus. C'est vraiment très dur à comptabiliser, la mémoire, sur un système d'exploitation moderne. Et ne comptez pas sur moi pour vous aider à interpréter les compteurs Windows, je n'y connais rien 
Je ne faisais qu'un parallèle avec Unix.
Je doute que pour autant que vous ayez une fuite mémoire avec un cas d'utilisation aussi simple que le votre. Ou alors peut être liée à ce qui ralentit votre établissement de session, ça je n'en sais rien. Mais des gens utilisent PostgreSQL, même sous Windows, pendant des mois, sans le redémarrer. S'il y avait une fuite obtenue aussi simplement, et aussi visible, cela aurait été repéré, vous vous en doutez bien.
À moins que vous ayez une fuite d'objet dans votre session, comme des prepared statements par exemple. Aucune idée non plus, .net, ça sort fortement de mon domaine
Marc.
Hors ligne
