(Illustration by Gaich Muramatsu)
On Wed, Jun 04, 2003 at 11:42:18PM -0700, Steve Simitzis wrote: > i'm still getting these, which i hoped would go away. :( I don't remember saying it was fixed ;) What we have is about 100 apache processes hitting Coda, which are being handled by about 20 worker threads (maybe more if you've upped maxworkers) which are hitting rpc2 with on most 9 connections per userid, for which we have 8 'MultiRPC contexts'. We can up the number of contexts in rpc2, but by how much? Upping it to 9 contexts would probably help your case. On the other hand, the hoard daemon is running with it's own uid, and there might be 1 or 2 user processes that access Coda (administrator and updatedb/cronjobs). If we account for the worst case with this, we already need 36 contexts. But as you already noticed, 9 RPCs per userid is really not enough to service all those apache processes that are getting about 100 hits/s when the cache is still ramping up after a reinit. If we bump that to 20, we already need 80 MultiRPC contexts. But we only have 20 worker threads and some other daemon threads running. So we can never really have more than 20 + a couple concurrent RPC requests at the same time. What I'm trying to say is, all these arbitrary limits seem to be stupid. These MultiRPC contexts seem like just another pool allocator that doesn't scale. I'm tempted to just rip out and remove the 9 RPCs per user limit. But this is not a change that I wanted to mix in with the 6.0.0 stuff at the last minute. JanReceived on 2003-06-05 11:18:42