Many thanks to all who replied: Darren Dunham Michael Hocke Nasser K. Manesh After some discussion with Nasser it really seems like a kernel memory leak. Well maybe not exactly a leak but growing nfs attribute caches with no bounds. One detail was missing in the orginal post: we started to backup 20gb of many small files sitting on two older suns via nfs v3 just a month ago. After stopping nfs backups kernel memory still grows, but an order of magnitude slower - about 1mb/day. Maybe we see something related to bug 4409175, as we also see big numbers for rnode_cache and nfs_access_cache. This should be fixed with kernel patch 106541-20 (or is it 106541-21, strange numbering ;-) As Nasser pointed out, kernel memory is not pageable (with some minor exceptions). We will reboot the box immediately, and as hopefully longer time solution update the kernel in the near future. Michael On Wed, 19 Jun 2002, Michael Hase wrote: > Hi all, > > lately our E250 with 2gb running solaris 7 (kernel 106541-16) runs a > bit slowly. The box is quite loaded with oracle, mysql, some > apache/php processes, samba and nfs serving. We noticed the slowdown > when we loaded some webobjects java apps onto the box eating about > 300-700mb of ram (dependent on number of app instances), Oracle is > configured at about 200mb (just development). About 36 days uptime. > > Some days ago we started virtual-adrian.se and it sometimes reports > slow disks, thats ok with our workload. But since we loaded those > webobjects apps it reports ram shortage quite often, although there > should be some memory left if we sum up user space ram usage. > > Today I learned about memtool and I think there are some strange > numbers: > > # prtmem > > Total memory: 1970 Megabytes > Kernel Memory: 642 Megabytes > Application: 1070 Megabytes > Executable & libs: 83 Megabytes > File Cache: 99 Megabytes > Free, file cache: 56 Megabytes > Free, free: 18 Megabytes > > Imho the solaris kernel should not occupy 642 Megabytes, at least not > on a 2gb box. Thats nearly 1/3 of all available ram. > > echo kmastat | crash > > gives the following suspicious line (full listing below): > > kmem_alloc_1120 1120 29818 336826 394182656 672801271 0 > > thats 375mb occupied by those 1120 bytes buffers. I don't know any > solaris kernel internals, but this seems a little high. The other > numbers look reasonable, at least to me. > > Now the questions: could this be a kernel memory leak? how can we > avoid this excessive kernel memory usage? > > Any ideas? > > cheers, > Michael -- Michael Hase Six Offene Systeme GmbH michael@six.de Sielminger Str. 63 http://www.six.de 70771 Leinfelden-Echterdingen phone +49 711 99091 62 Germany _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Wed Jun 26 06:04:59 2002
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:42:47 EST