> dkftpbench has helped me isolate a limit in the oftpd server. Right
> now oftpd creates two threads for each client connection: one to
> handle the control channel I/O and one to act as a timeout watchdog.
> Unfortunately, Linux creates a new process for each thread, and
> limits the user to 256 processes.
I suppose I could modify dklimits.c to probe to see how many threads
can be created. (I wonder if that's dangerous?)
> This limit can be avoided by using the setrlimit() command while
> oftpd is still running as root. Further, by moving the timeout
> watchdog to a single thread, the number of threads can be effectively
> cut in half. There's still a built-in limit to number of processes
> in Linux - somewhere around 1000 I believe. oftpd will probably
> never be able to run 5000 clients unless Linux changes its thread
> model. :(
The 2.4 kernel will raise that limit significantly, though each thread
will still take a fair bit of RAM.
> Any thoughts as to when a bakeoff might be held? If there's a date,
> I can try to get a new release with the single watchdog thread and
> a raised RLIMIT_NPROC in place beforehand. This won't let oftpd
> compete with betaftpd, but it should let it stomp wu-ftpd, proftpd,
> and ncftpd. :)
My day job is interfering with my dkftpbench activities these days -
the bakeoff will probably be delayed for a month or so. But don't
let that stop you -- I'll happily accept your fixed up version whenever
you manage to hit a couple hundred users, and measure it here.
Glad dkftpbench helped you!