Bug#310532: rpc.mountd dies: Debian Bug report logs - #310532
Solution: downgrade to woody for nfs-utils: As I mentioned earlier: On our file server, AMD Opteron(tm) Processor 852, running Sarge, we have something like 300 clients (PCs on Debian Sarge and Xterminals, based on Sarge servers) and ~ 1000 users. When under big load, the rpc.mountd from sarge becomes unresponsive: As top shows, its %CPU then switches between more than 95% and something like 60%, and it won't give any answer anymore until it is rebooted. (/etc/init.d/nfs-kernel-server restart won't help.) Apparently, this happens already, when the server gets a mount request every two seconds. (I am not sure how many requests it is supposed to handle.) However, we never observed a segfault of rpc.mountd. I should mention that under testing conditions with few users (up to 10 or so) or under little load, the sarge system worked quite well. After downgrading both nfs-common and nfs-kernel-server (version 1:1.0.6-3.1, from sarge) to version 1:1.0-2woody3 from woody the rpc.mountd worked well (though not very fast under big load). Downgrading just nfs-kernel-server (which contains the rpc.mountd program) seemed to work at first glance, but developed a lot of stale file handles after a couple of hours, so we also had to downgrade nfs-common (which belongs to the same software package nfs-utils) in order to obtain a stable system. Ulf Rehmann -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310532: rpc.mountd dies: Debian Bug report logs - #310532
Thanks for your quick answer, Yes, the phenomena are different, but if a bug is involved, that could have different consequences in different environments. But of course that's some speculation. We are just trying a downgrade to the woody version of the nfs-kernel-server, as there are several reports about problems with some sarge versions. The funny thing is that our setup worked well in an experimental setting with 20 users for about two months, but when we went into production with the whole system (300 clients, ~1000 users), we experienced significant problems. Best regards, Ulf Rehmann -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311491: slapd stops functioning almost completely if a CPU consuming process runs at the same time
| Talking about severities: We will not delay sarge because slapd has a | performance problem for one user.=20 I guess this is a disputable decision. This makes sarge unusable for an ldap server. Our whole ldap system (a few hundred users involved) was repeatedly blocked by this bug, because of minor cpu consuming processes on that server caused by some erroneously terminated login processes to that server. We had to switch to freebsd for the ldap server because of this. Please reconsider. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
