Bonjour,
Le 01/10/2010 14:03, Yves Martin a écrit :
> Bonjour,
>
> Le serveur Subversion dont je m'occupe souffre de lenteurs "aléatoires".
>
> - Serveur Apache2 mod_auth_kerb + mod_authnz_ldap + mod_svn
> (SSO SPNEGO Kerberos avec ActiveDirectory, contrôle de groupe par LDAP)
> - Serveur svnserve
> - Dépôts sur iSCSI
>
> À priori les accès disques sont rapides, un checkout local ou par svn:// est rapide.
>
> Seul l'accès sur http et https sur un dépôt protégé par des directives
> Require ldap-group "CN=..."
> prennent un temps certain - de 10 à 20 secondes.
>
> J'ai ajouté la mesure "%D" dans mon CustomLog:
> CustomLog /var/log/apache2/https-svn-access.log "%t %u %U %{SVN-ACTION}e %s %B %D" env=SVN-ACTION
> et le serveur me donne des ordres de grandeur de 3 millisecondes...
>
> Je soupçonne que cette mesure ne prend pas en compte les chaînes d'authentification/authorisation.
> Est-ce juste ?
>
> D'après le "ldap-status", le cache n'est pas plein et le taux de hit frôle les 100%.
> Le cache LDAP a des valeurs de TTL de 10 minutes par défaut.
> Une fois les valeurs en cache, l'accès est rapide (< 3 sec). Mais le problème revient rapidement.
>
> En suivant les requêtes LDAP (pas de SSL) avec wireshark, les réponses de l'AD sont très rapides.
>
> Par contre, après un "graceful" (donc cache ldap vide), je constate qu'il peut s'écouler 6-9 secondes
> entre la recherche du DN de l'utilisateur à partir de son login (searchRequest) et la requête d'interrogation du
> groupe (compareRequest) !!
> Ça ne me semble pas normal du tout - verrouillage sur le shm ? collision processus/thread ?
>
> Comment investiguer plus loin ? Est-ce que ce module "mod_authnz_ldap" est connu pour ce genre
> de problèmes de performance ?
>
> Merci d'avance pour votre aide
Je ne suis pas sûr que cela puisse t'aider, mais il y a une piste à
suite : Peut-être que l'un des serveurs (LDAP, Apache, autre), tente une
résolution DNS ou "auth" vers un autre serveur, et que cette connexion
n'aboutie jamais.
J'ai eu ce type de problème là il y a quelques années, sur 2 exemples :
- dans la configuration d'un serveur FTP, j'avais demandé à faire un
reverse-DNS sur les connexions entrantes. Or, certains des "clients" FTP
qui s'y connectaient étaient sur des adresse IP qui n'avaient pas de
reverse-DNS. Le temps que la requête DNS échoue, il se perdait quelques
secondes. En désactivant le reverse-DNS dans la configuration du démon,
le log s'écrivait immédiatement, et le serveur activait tout de suite le
transfert de données
- toujours pour un serveur FTP, mais en configuration mixte avec
"xinetd", j'avais activé dans dans xinetd les logs un "USERID":
<extrait>
log_on_failure += DURATION USERID
</extrait>
Cette simple configuration faisait qu'à chaque connexion au serveur FTP,
celui-ci envoyait une requête tcp/113 (voir "grep auth /etc/services")
au client FTP, qui bien sûr n'activait pas ce service, ou qui le
protégeait derrière son firewall. Là encore, quelques secondes de perdue
à chaque connexion.
Afin d'isoler ce type de problème, je te conseille de surveiller avec
wireshark les connexions entrantes et sortantes de tes serveurs, afin de
trier avec précision quelles sont les données qui rentrent et qui sortent.
Analyse aussi ce qu'il se passe du coté des clients, pour voir si ce ne
sont pas eux qui font des tentatives de connexion autres que ce qu'elles
devraient faire.
Enfin, mais c'est moins facile à observer, il faut aussi analyser le
trafic sur l'interface loopback des serveurs et des clients.
Wireshark a un mode d'écoute sur toutes les interfaces à la fois, cela
pourrait t'aider à cher un "trou temporel" dans les enchaînements de
connexions.
Tu peux recherche des activités tcp/113 ou udp/53, mais ce n'est pas
exclusif.
Cordialement,
Olivier
--
~~~~~~~ _____/\_____ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phoenix / _ \/ _ \ Olivier Allard-Jacquin
/ / \ / \ \ Web: http://olivieraj.free.fr/
/___/ / \ \___\ Mail: olivieraj@???
~~~~ ///// ///\\\ \\\\\ ~~~~~~~~~~~~~~~~~~~~~~~ Linux Powered !!
