Alan, >> Yeah, I have recompiled glibc to support over 60000 >> threads/process, so that shouldn't be the problem. I've run a program >> to test thread creating and it goes all the way...
> That may help, but I was talking about the 'thread pool' configuration > in raddb/radiusd.conf. > Ensure that the *server* is allowing you to use many threads. The > limit is there to prevent a high load from effectively doing a "fork > bomb" on the server. Oh, sorry. Misunderstood that one. Yeah definitely, this is the configuration of thread poool that I have: start_servers = 64 max_servers = 512 min_spare_servers = 15 max_spare_servers = 30 Looks reasonable, right? I found that reference on the list: http://lists.cistron.nl/pipermail/freeradius-users/2001-June/001027.html But not "freeing" something sound kinda frightening to me, plus I dont know if that would introduce any inconsistency nor help with the problem. radiusd -X shows a funky behavior. If I increase over 25 the number of connections, the radiusd is able to register/answer just ONE request and them simply stalls waiting for "the next request". Regards, Ed Castro - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
