SUMMARY: kernel memory usage, strange kmem_alloc_1120

From: Michael Hase <michael_at_six.de>
Date: Wed Jun 26 2002 - 05:34:54 EDT
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/sunmanagers
Received 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