DragonFly kernel List (threaded) for 2005-11
DragonFly 1.2.6 diskless kernel hang
I have a FreeBSD 4.10 based webserver cluster/farm thang
on Intel SMP hardware and am looking for a migration path to a threaded
kernel. We are considering a DragonFly solution when it becomes production
ready and would like to participate in its development/testing.
So .. I built a DragonFly 1.2.6 diskless webserver that
boots off of a DragonFly Boot server and put it into our front end
server pool. It NFS mounts all data readonly from FreeBSD 4.10 file
It ran fine for 2 weeks then it hung and became unresponsive.
In the log I saw this begining about 1 day before the server
Nov 8 14:42:32 <1.2> 10.1.6.2 kernel: [diagnostic] cache_lock: blocked on 0xd3949bf8 "wedding_pic1.jpg"
[snip] (every few minutes)
Nov 9 13:29:29 <1.2> 10.1.6.2 kernel: [diagnostic] cache_lock: blocked on 0xd3949bf8 "wedding_pic1.jpg"
Nov 9 15:46:08 <1.2> 10.1.6.2 kernel: All mbuf clusters exhausted, please see tuning(7).
Nov 9 15:47:32 <1.2> 10.1.6.2 kernel: All mbuf clusters exhausted, please see tuning(7).
I have seen some logging of
Nov 9 13:29:29 <1.2> 10.1.6.2 kernel: [diagnostic] cache_lock: blocked on 0x??????? "some_file"
ocassionally, during the previous weeks, but it was always
followed by a matching "unblocked" log entry. This time the file is
never "unblocked" and the server spirals down.
The server is still up though inaccessable. I have compiled
in a debugger and have serial console access. If there is any useful
information that can be gained/salvaged from this situation I could
get it with some instruction.
Or if there are any ideas about DragonFly versions to test
I would consider them. Eventually, as a first step I would like
to run DFly with Apache 2.x. on some of our front ends. These are
completely diskless machines with 3 network interfaces.
Is DFly ready yet for this type of testing? I know the
filesystem/disk stuff is still quite new, but what about in
a simple diskless readonly webserver with 3 NICs? We are
looking for greater performance than FBSD in an SMP context.
thanx - steve