[Linux-bruxelles] Lenteur sur stations Ubuntu 8.10

[Yves Mairesse]

Suite et fin (?) de l'histoire?

Pour en avoir le coeur net, le serveur NFS a été transféré sur une autre 
machine. La configuration est alors basée sur deux serveurs plutôt 
qu'un. L'intérêt est de voir quelle fonction mange les ressources.
La question a été vite réglée: l'activité du serveur LDAP est à peine 
perceptible aux logins des utilisateurs du réseau. C'est bien le serveur 
NFS qui est engorgé: incapable de répondre à la demande d'envoi de tous 
les fichiers figurant dans les profils des utilisateurs, en même temps 
(.mozilla, .gimp, .openoffice,...). Le facteur limitant n'est pas le 
réseau mais le serveur NFS.

Quelqu'un aurait-il une expérience sur un réseau du même type où tous 
les utilisateurs ont tous leurs fichiers sur le serveur (rien sur les 
stations), dans une structure où 20 à 40 utilisateurs peuvent se logger 
en même temps et recevoir chacun leur profil?
Quel genre de monstre doit alors être envisagé comme serveur NFS? 
Actuellement, c'est un simple Intel Pentium 4 3.00GHz avec un disque 
SATA 250 Go sur une carte mère  P5GV-MX ASUSTeK (rien d'extraordinaire) 
avec 1Go RAM

La solution envisagée serait de déposer un profil "type" sur chaque 
station, de manière qu'aucun accès au serveur NFS ne soit nécessaire au 
login. Le serveur NFS ne servant alors plus qu'à distribuer les 
documents utilisateurs (.odt, .xcf, ...) à la demande.
Bien que l'uniformité ne soit pas ma tasse de thé, l'avantage est aussi 
d'homogénéiser les configurations ("M'sieur, la fenêtre des calques de 
Gimp a disparu toute seule!!"). Adieu les fonds d'écran richement 
décorés ;o)

Yves



Yves Mairesse a écrit :
> Bonjour
> Une petite suite pour cette longue  histoire?
> Le week-end passé, j'ai déplacé le serveur jusque dans ma salle de 
> classe afin de pouvoir le tenir à l'oeil pendant ses baisses de régime.
> De plus, cela limite la longueur de câble Ethernet potentiellement cause 
> de problème (croqué, rongé par une souris,...)
>
> Serge SMEESTERS a écrit :
>   
>> 1°)
>> Il faudrait qu'une personne compétente analyse le trafique réseau. Je
>> n'ai jamais utilisé que wireshark mais il existe d'autres programmes,
>> j'imagine... Il est possible de sauvegarder la capture et de la
>> communiquer par courriel (e-mail) à quelqu'un qui pourrait faire
>> l'analyse...
>>   
>>     
> L'idée reste retenue, mais l'expérience nous envoie a priori vers une 
> tout autre piste.
> Ce lundi, une vingtaine d'utilisateurs ont pu ressentir quelques 
> lenteurs mais rien d'extraordinaire. Travail presque normal. J'étais 
> confiant pour la suite, bien qu'ayant avisé une activité débordante du 
> disque dur du serveur pendant les quinze à vingt premières minutes du 
> cours: LED allumée en permanence.
> Un "top" ne montre qu'une poignée de % d'utilisation du CPU pendant 
> cette période.
>
> Ce mardi, presque les mêmes conditions sauf que nous avions lancé 
> l'enregistrement de "top" vers un fichier sur chacune des stations. Le 
> temps d'expliquer l'expérience aux utilisateurs, ils reçoivent le 
> feu-vert pour se logger.
> Donc, tous exactement au même moment. (d'habitude, certains se loggent 
> en arrivant; d'autres s'assoient puis se loggent; d'autres encore 
> disposent d'abord leurs affaires puis se loggent; et pour certains, 
> c'est d'abord un peu pinaille avec le voisin avant de se logger).
> A nouveau, activité débordante du disque du serveur (authentification 
> LDAP + serveur fichiers). Et, cette fois, il lui a fallu plus d'une 
> heure pour avaler tout ce qu'il avait à faire. Impossible de travailler 
> normalement moins de 60 minutes après le premier login.
>
> Là, maintenant, nous avons séparé la fonction serveur LDAP et la 
> fonction serveur NFS sur deux machines différentes.
> Je verrai donc lundi si c'est l'authentification qui fait problème ou si 
> c'est NFS qui est coupable.
>   
>> 2°)
>> L'heure des ordinateurs. Peut-être que certains "protocoles" ont
>> besoin que les ordinateurs soient bien synchronisés. Pour des machines
>> qui tournent "parfois" sous Windows, je sais que c'est pas forcément
>> évident... Je dis ça aussi parce qu'on est passé à l'heure d'été
>> "récemment"...
>> → http://www.traduc.org/docs/HOWTO/lecture/TimePrecision-HOWTO.html#tz.linux
>>   
>>     
> Ces machines ne tournent jamais sous Windows. Ouf!!
> Toutes utilisent NTP et se calent sur l'heure du serveur. Mais c'était 
> une bonne idée.
>   
>> Je pense que ntp devrait être installé sur le serveur, et que les
>> clients devraient s'y synchroniser... Le BIOS (heure système) des
>> clients devrait être mis automatiquement à jour en tenant compte de
>> l'éventuel utilisation du Windows (→ heure local vs utc)
>>   
>>     
> C'est bien la configuration dans laquelle nous sommes depuis toujours.
>   
>> 3°)
>> Vérifier (j'imagine que c'est déjà bien fait, mais sait-on jamais...) :
>> - L'unicité du serveur DHCP et sa bonne configuration.
>>   
>>     
> Je crois que deux serveurs DHCP sur le même réseau, ça se voit tout de 
> suite. Au moins, ça s'entend par mon GSM assailli par les utilisateurs 
> de l'administration.
> Oui, ça m'est déjà arrivé de faire une fausse manoeuvre sur ce coup-là. 
> Il suffit d'inverser les deux câbles Ethernet sur un serveur LTSP qui 
> fait serveur DHCP pour son sous-réseau :-) .
>   
>> → l'unicité des adresses IP et cohérence avec d'éventuelles règles de routage.
>>   
>>     
> Les adresses IP sont fixées par DHCP en fonction de l'adresse Mac. Je 
> n'ai rien repéré d'anormal dans les "leases" sur le serveur DHCP.
>   
>> - La compatibilité de différentes versions de "protocoles" entre client/serveur.
>>   
>>     
> Serveur = Ubuntu 8.04
> Clients = Ubuntu 8.04, 8.10 et 9.04
> J'imagine qu'entre Ubuntu et Ubuntu, ce ne doit pas être la guerre.
> La compatibilité entre les protocoles doit encore être vérifiée.
>
> Yves (qui admire la patience de celles/ceux qui ont lu jusqu'ici)
>
>   
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: </pipermail/linux-bruxelles/attachments/20090529/9f294948/attachment-0002.html>