NFSv4 idmapd memory consumption problem

pierre_stephane.baton at alcatelaleniaspace.com pierre_stephane.baton at alcatelaleniaspace.com
Wed Aug 30 11:30:40 UTC 2006


Hello everybody.

I have a little problem with NFSv4 : The NFSv4 ID <-> Name Mapper daemon 
(rpc.idmapd) uses lots of memory but I don't use nfsv4 mounts, only simple 
nfs mounts : 

Client nfs v3:
null            getattr                 setattr         lookup access  
readlink 
0       0%      6022199 41%     69694   0%      1234880 8%      2722353 
18%     1604    0%
read            write                   create          mkdir symlink 
mknod
802231  5%      2706720 18%     155868  1%      13      0%      3       0% 
0       0%
remove  rmdir           rename  link            readdir readdirplus
786     0%      0       0%      611     0%      0       0%      48      0% 
8780    0%
fsstat          fsinfo          pathconf        commit
6036    0%      392796  2%      0       0%      294568  2%

This is the rpc.idmapd memory usage (8 Go installed) :

PID     USER    PR      NI      VIRT    RES     SHR     S       %CPU %MEM 
TIME+   COMMAND
1825    root    16      0       2075m   1.1g    868     S       0.0     
14.2    2:08.36 rpc.idmapd

This service isn't even configured :

# cat /etc/idmapd.conf 
[General]
Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = localdomain
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody
[Translation]
Method = nsswitch

There's a lot of directories in  /var/lib/nfs/rpc_pipefs :

clnt0      clnt5f0f9  clnt5fe46  clnt5fe4c  clnt5fe52  clnt5fe58 clnt5fe88 
 clnt5fe8e  clnt5fe94  clnt5fe9a
clnt2ba1d  clnt5fe41  clnt5fe47  clnt5fe4d  clnt5fe53  clnt5fe59 clnt5fe89 
 clnt5fe8f  clnt5fe95  clntad8e
clnt2fccb  clnt5fe42  clnt5fe48  clnt5fe4e  clnt5fe54  clnt5fe5a clnt5fe8a 
 clnt5fe90  clnt5fe96  clntad95
clnt5aaa6  clnt5fe43  clnt5fe49  clnt5fe4f  clnt5fe55  clnt5fe5b clnt5fe8b 
 clnt5fe91  clnt5fe97  clntad97
clnt5f029  clnt5fe44  clnt5fe4a  clnt5fe50  clnt5fe56  clnt5fe86 clnt5fe8c 
 clnt5fe92  clnt5fe98  clntb2a8
clnt5f045  clnt5fe45  clnt5fe4b  clnt5fe51  clnt5fe57  clnt5fe87 clnt5fe8d 
 clnt5fe93  clnt5fe99  clntb2c7

each has a single empty file in : 

/var/lib/nfs/rpc_pipefs/nfs/clnt5feb5:
total 0
-r--------  1 root root 0 Aug 30 13:23 info

/var/lib/nfs/rpc_pipefs/nfs/clntad8e:
total 0
-r--------  1 root root 0 Aug 16 13:33 info

I should do a /etc/init.d/rpcidmapd stop, which would stop nfs server, as 
I have no exported fs, this should be ok, but the different fs mounted 
with autofs (Clearcase again...) should be very desapointed... 

So, is there a way to reset idmapd memory usage?

A way to stop the service within autofs and fstab mounted security?

Of course I can't reboot the workstations until next planned reboot..

Any idea to get back this giga?

Thanks

________________________________
Pierre-Stéphane BATON
DI - OI/IT
Consultant Trasys-OSI
Support informatique Unix/Linux
E01-H14-L44 - Tel :+32 (0)71 442797

Alcatel Alenia Space ETCA (DI/SYS)
Rue Chapelle BEAUSSART, 101
B-6032  Mont-sur-Marchienne


This message and any attachments (the "message") is intended solely for 
the addressees and is confidential. If you receive this message in error, 
please delete it and immediately notify the sender. Any use not in accord 
with its purpose, any dissemination or disclosure, either whole or 
partial, is prohibited except formal approval. The internet can not 
guarantee the integrity of this message. ALCATEL ALENIA SPACE ETCA shall 
not therefore be liable for the message if modified.

Ce message et toutes les pieces jointes (ci-apres le "message") sont 
etablis a l'intention exclusive de ses destinataires et sont 
confidentiels. Si vous recevez ce message par erreur, merci de le detruire 
et d'en avertir immediatement l'expediteur. Toute utilisation de ce 
message non conforme a sa destination, toute diffusion ou toute 
publication, totale ou partielle, est interdite, sauf autorisation 
expresse. L'internet ne permettant pas d'assurer l'integrite de ce 
message, ALCATEL ALENIA SPACE ETCA decline toute responsabilite au titre 
de ce message, dans l'hypothese ou il aurait ete modifie.


More information about the redhat-list mailing list