> > > > kmdb ::memstat showed that almost 100% of memory was in use by the > > > > kernel, so most likely there is a memory leak somewhere. > > > Shot in the dark here, but maybe 6786794? > > could be. The bug's submit date matches > > the date when I first observed the problem (IIRC) ... > If you have a dump it can easily be verified but first see below
No dumps, that's the problem. I did use $<systemdump from kmdb, but somehow that failed half way through the dump. (disk driver in use for the dump was nv_sata) When it happened a second time I tried to collect some facts directly from kmdb before trying to get the dump, but kmdb got some internal error and all I could do was reset the machine... > > That box is transferring lots of backup data over > > tcp, and is also used as an nfs client. > The above bug only happens if you are using a > protocol that does not have it's own flow control like UDP/ICMP etc. Most of the data should be transferred over TCP (nfs & amanda). > If you provide a crash dump I can look at it and verify if you are > seeing the same problem, or you can easily do so by verifying if the > socket is UDP socket , it has lots of data in it's queue and if it's > in a drain list or not (conn_idl != NULL). Sorry, no dump is available. > It would be helpful to know which cache is using up > the memory. IIRC it was the kmem_va_4096 cache... -- This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
