On Tue, 2004-05-25 at 13:26, Balazs Scheidler wrote:
There's a --threads command line argument for Zorp. It will not create more than that number of threads. As it seems you might also have more than the maximum number of file descriptors. You might need to increase your resource limits.
I thought the resource limits were adjusted by zorpctl. I edited the script to print them, and they looked fine.
The thread limit of 1024 per process is inherent to libc 2.2.5, later libcs (at least 2.3.2) with NPTL support and kernel 2.6 (or 2.4 with backported O1/futex patch) can run with more than this limit.
Right. I have --threads set to 1000. And when I reach the maximum, I see a log message that says "Too many running threads, ...". So that's fine. The thing I think is a problem is that it falls over even though it's limited in this way. Why do I get these errors (which cause the entire instance to die) when I've limited the number of threads per instance to 1000? (Log thread): GLib-ERROR **: Cannot create pipe main loop wake-up: Too many open files That's why I asked about your glib patches.
I think the better solution is to use as many instances for the same traffic as you need (separating the load using packet filter rules).
Yes, I've already taken your advice here.
hmm. that system load is quite high, it should not be more than 20-30% How many interrupts/context switches do you have?
I'll take a look, but I'm really not so worried about the CPU. I'm worried about being unable to limit the number of threads a single Zorp instance will start. If I can't do that, an attacker can easily DOS the Zorp cluster by creating lots of TCP connections. So this GLib-ERROR seems quite serious to me. Ciao, Sheldon.