Hi, all,
Well, that was fast! :^)
Thanks to Casper Dik, I have a better understanding of what is going on.
Essentially, there IS no problem currently with the system, I do still have
lots of free memory (13 MB), and was not aware of the way that kernel buffers
were reclaimed...
Casper's response:
> >I'm sitting here running the 'kmastat' command in crash, and I can see
> >the amount of memory the kernel's using is growing... 136 MB at the
> >moment. Here's a couple of pertinent lines from kmastat showing the
> >largest allocations:
>
> >streams_msg_1560 1632 43 45 73728 44842696 0
> >streams_msg_1976 2048 28 55512 113688576 4058998467 0
> >streams_msg_2648 2720 3 3 8192 10806883 0
>
> Note that the heading for the "55512" column is "buf avail".
>
> This means that there was a peak allocations of a lot of buffers but that
> they have since all been freed.
>
> The buffers will be returned to the free pool of pages if the memory becomes
> low, apparently you still have enough memory.
>
> How much freemem do you have? If there's no memory pressure, memory
> will not be reclaimed from the caches.
The original question:
> I've got an Ultra 2 with Solaris 2.5.1 installed, acting as our primary
> internal DNS server and one of two internal web proxy servers (Apache
> 1.3), main NTP time server, etc.
>
> The system has 256 MB of memory, and hme 100 Mb ethernet.
>
> I'm sitting here running the 'kmastat' command in crash, and I can see
> the amount of memory the kernel's using is growing... 136 MB at the
> moment. Here's a couple of pertinent lines from kmastat showing the
> largest allocations:
>
> ...
> kmem_alloc_6816 6816 1 6 40960 1482 0
> kmem_alloc_8192 8192 4 488 3997696 77019001 0
> kmem_alloc_9536 9536 4 6 57344 1332 0
> kmem_alloc_12288 12288 0 16 196608 2238 0
> kmem_alloc_16384 16384 0 12 196608 2476 0
> sfmmu8_cache 232 6297 10608 2555904 8323892 0
> ...
> streams_msg_1560 1632 43 45 73728 44842696 0
> streams_msg_1976 2048 28 55512 113688576 4058998467 0
> streams_msg_2648 2720 3 3 8192 10806883 0
> ...
> snode_cache 128 828 1320 180224 231419331 0
> ufs_inode_cache 320 1716 8760 2990080 16519318 0
> fas0_cache 188 140 210 40960 227792166 0
> ...
>
> The issue here is obviously with the streams_msg_1976 cache. Note no
> failed allocations (yet).
>
> When I was looking around yesterday, I found a huge number of TCP
> connections in TIME_WAIT state - over 600 of them. To combat this I have
> set the tcp_close_wait_interval to 120000 (2 minutes) down from a
> default of 4 minutes, and have cut back on some Apache connection timing
> variables.
>
> As of this morning, I'm down to 115 connections in TIME_WAIT, but
> kernel memory is still growing. Obviously this can't continue forever!
>
> This system has been up for 468 days as of today. I just installed
> Apache on it last week - we had a problem with our other internal proxy
> server (very similar memory issue, but it killed the system) so now
> they share the load. The other proxy is in good shape with NO growth in
> kernel memory usage.
Cheers!
Ross
--
Ross Parker | UNIX Sys Admin, Perl and C toolsmithing,
Systems/Network Admin | Networking and security, CGI applications.
BC Tel Mobility |
| A "Frisbeterian" believes that when you die, your soul
parker@bctm.com | goes up on the roof and you can't get it back down...
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:13:24 CDT