Forum Linux.débutant nscd : indispensable ?

Posté par  .
Étiquettes : aucune
0
30
jan.
2005
Bonjour,
Voulant savoir qui me prenait le plus de RAM j'ai regardé dans un petit logiciel comme gnome-monitor; et je constate avec effaremment qu'un petit truc que je ne connais ni des lèvres ni des dents occupe 42 Mo ! ça s'appelle nscd. J'ai googeulisé le nom comme disent les anglophones et les pages que j'ai consulté ne m'ont pas trop indiqué la pertinence du bidule.
Alors, peut-être que vous aller pouvoir éclairer mon lampion:
Est-ce que nscd est indispensable, ou bien je peux cliquer sur "kill process" ?

merci d'avance

  • # nscd

    Posté par  . Évalué à 5.

    Description: GNU C Library: Name Service Cache Daemon
    A daemon which handles passwd, group and host lookups
    for running programs and caches the results for the next
    query. You should install this package only if you use
    slow Services like LDAP, NIS or NIS+


    Donc a priori, si tu n'appartiens pas à un domaine LDAP, NIS ou NIS+, tu peux tuer l'application, et la désinstaller.

  • # man nscd

    Posté par  . Évalué à 3.

    La page de manuel de nscd est assez explicite. Chez moi c'est désactivé et ma machine se porte bien merci.

    • [^] # Re: man nscd

      Posté par  . Évalué à 1.

      OK merci de vos conseils...

      Mais j'ai une autre préoccupation: mon gnome-monitor m'indique que X
      prend 150 Mo !!!
      est-ce qu'il y a un problème ?
      chez vous c'est pareil ?

      • [^] # Re: man nscd

        Posté par  . Évalué à 4.

        man top

        en gros : considère uniquement la colonne RES
        MAJ+M pour trier par occupation mémoire.

      • [^] # Re: man nscd

        Posté par  . Évalué à 1.

        rhaaa, un utilisateur de procman :)
        idem colonne RES/RSS (également dans le panneau plus d'info.)

        • [^] # Re: man nscd

          Posté par  . Évalué à 0.

          et en clair tu as entré quelle option avec top ?

          • [^] # Re: man nscd

            Posté par  . Évalué à 2.

            aucune : tu lances top ou gnome-system-monitor, et tu regardes la colonnes RES

      • [^] # explication partielle.

        Posté par  (site web personnel) . Évalué à 2.

        Linux gere les fichiers de maniere tres complexe; je vaus resumer le cas de X:
        X se lance, il charge en memoire toutes les bibliotheques necessaires a son fonctionnement. entre 20 et 80M. Tout est mappe en RAM pour que ce soit accessible directement par tout programme graphique. Mais tout n est pas utilise tout le temps ... donc pour soulager ta RAM, le noyeaux deplace les librairies inutilisees en SWAP.

        150M, c est l espace memoire virtuel utilise. Tres probablement plus 100M de SWAP, et moins 50M de RAM.

        C est cette maniere de gerer les chose qui fait que tu peut faire sous Linux:
        rm -rf /*
        et perdre tout ton system, chose impossible sous Windows ...
        mais c est aussi ce system qui te permet d ecraser a la volee une librairie meme si elle est utilisee: quand tu met a jour ta machine, le gestionaire de packages substitues les librairies, puis redemarre les services; le tout peut s effectuer sans interruption de service.

        Sous windows, tu ne peut pas ouvrire en ecriture une librairie en cours acces. Tu est donc oblige de tuer les services avant de commencer tesmises a jour. Et tous tes services sont down tout le temps de la mise a jour.

        Choisi ce que tu prefere: perenite du server, ou perenite du service.

        Ce qui est inquietant, c est quand un process prends plus de 5% du CPU sur une machine moderne, ou si une appli arrive a pomper plus de 40% de la memoire: une demon qui consomme est un demon mal code. Une apli qui consomme de la RAM as forcement des fuites.

        Quand je vois X qui prends 25% d une AMD1.4G, j ai peur, mais mozilla qui prends 60% de 250M(RAM)+1G(SWAP)=650M d espace memoire, la je cries. Ils ont tous les deux des fuites, mais j assumes.

        • [^] # Re: explication partielle.

          Posté par  . Évalué à 1.

          bien essayé mais tu te trompes. la taille de la VM, ce n'est pas du tout RAM + SWAP. D'ailleurs tu le vois bien, sur des systèmes sans swap RES <= VM.

          La taille de la VM, c'est la taille de l'espace d'addressage virtuel. Difficile à interpréter à moins de savoir ce que ça veut dire.

          Donc même si firefox fuit, t'es pas prêt de le voir à 650Mo de mémoire ...

          (et si t'es pas convaincu, fait la somme de 'VM' et tu verras, ça fera peut être 10 ou 50 fois que toute ta RAM+Swap

          • [^] # Re: explication partielle.

            Posté par  . Évalué à 1.

            pour moi, un process ne libere peut pas liberer sa MV (un malloc de 100 megs puis un free ne va pas reduire la VM occuppee par un process). La MV d'un process inclut egalement l'adressage des lib partagees entre plusieurs process ..

            Donc faire la somme des VM ne peut etre egale a swap + ram, sauf si il n'y a qu'un process qui n'a encore rien libere.

            Le cas du serveur X est particulier, puisqu'il faut prendre en compte la memoire de la CG.

            Moi je prefere vmstat a top pour connaitre l'activite de ma machine. La seul colonne importante est l'activite du disque. "top" ne montre pas l'activite du system, c'est extrement complexe a interpreter (sauf la colonne temps CPU). pour s'en convaincre, faire 20 CTRL + N sur une fenetre de firefox.

          • [^] # Re: explication partielle.

            Posté par  (site web personnel) . Évalué à 1.

            marrant ce que tu me dit: quand FF plante de facon delirante, ma swap monte a 50% ou 60% d occupation, et des que je le tues, hop moins de 10% de swap accupee ... 400M-500M de swap liberee juste en tuant un process ... ( evidement cote RAM, c est beaucoup plus difficile a mesurer, donc je n aborde pas le sujet)

            (et si t'es pas convaincu, fait la somme de 'VM' et tu verras, ça fera peut être 10 ou 50 fois que toute ta RAM+Swap

            oui je sais: si une lib est chargee par deux aplis, le system ne la copie qu une seule fois un RAM, mais d un poin de vue virtuel, elle est presente dans toutes les aplis qui s en servent. Ta remarque est bonne pour un utilisateur de Gnome ou KDE, ou tu as 30 palis qui accedent a la meme collectien de libs.

            C est faux pour mon FF: toutes les aplis que j utilisent n ont en commun que la libc; rox-filer, FF, gaim, xmms ... aucune lib commune entre ces trucs la. Enfin, je sais ou sont les fuites de FF: j utilise INTENSIVEMENT TBE, et il cache enormement de choses; c est tres pratique/indispensable d un point de vue travail, mais je sais que je dois le tuer une fois par jour. Et l espace memoire alloue par FF n est pas des libs, mais majoritairement des infos TBE sur des pages web ... [c est la 2e raison pour laquelle ton explication n est pas valable pour moi]

            • [^] # Re: explication partielle.

              Posté par  (site web personnel) . Évalué à 1.

              ah ah ... tu m'interesse. je me demandai quelle pouvait etre cette putain d'extension qui
              me foutait la zone au boulot.
              Merci ;)

              Meme si je vais avoir du mal a faire sans :-(

              • [^] # Re: explication partielle.

                Posté par  (site web personnel) . Évalué à 1.

                Roh ben c est connu: perso, je peux pas vivre sans TBE, mais si tu viens sur IRC de moz, dit que t as un bug, et TBE installe, ils te kikent direct.

                Et l experience prouve qu effectivement, 90% de mes bugs de FF sont dus a TBE. Moi j ai decide de vivre avec: je reload FF une fois par jour.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.