Date: Thu, 13 Jul 1995 14:20:37 -0700 From: Matt Dillon <dillon@blob.best.net> To: bugs@freebsd.org Subject: Think we finally found the 'all processes block' bug Message-ID: <199507132120.OAA09138@blob.best.net>
index | next in thread | raw e-mail
I was finally able to catch it with a little custom ps I
wrote that ran in a loop.
It would appear that in a heavily loaded machine: 130 users,
128 MB of ram, load of 10 or so, a condition can occur where
near-all the processes lock themselves out waiting for new
filesystem buffers (i.e. sleeping on "newbuf", in kern/kern_vfsbio.c).
The ps shows up with a whole bunch of processes waiting on newbuf
and an even larger contingent of processes waiting on ufslk2.
Delving into the nbuf initialization code, in i386/i386/machdep.c,
I noticed:
if (nbuf == 0) {
nbuf = 30;
if( physmem > 1024)
nbuf += min((physmem - 1024) / 12, 1024);
}
nswbuf = min(nbuf, 128);
I believe the min is supposed to be a max, though this does not really
solve the lockout condition... I have no idea how the lockout is occuring,
but I believe that increasing the number of buffers will reduce the
rate of occurance (currently the machine crashes about once a day with
this bug).
gdb'ing a live kernel, our 'nbuf' is 1054. Changing the above min to
a max would increase that number of 2000+.
Could the clustering code have something to do with the lockout? It
could also be that the processes waiting on ufslk2 are creating the buffer
shortfall and causding the 'newbuf' sleep problem.
Thanks,
-Matt
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199507132120.OAA09138>