[Date Prev] [Date Index] [Date Next] [Thread Prev] [Thread Index] [Thread Next]
Bryan Stansell bryan@conserver.com
Tue, 4 Jul 2006 09:16:27 -0700 (PDT)
On Tue, Jul 04, 2006 at 05:16:25AM -0500, Travis Campbell wrote: > Thanks. I'll try that. What's the downside to going high on this? I > see the faq mentions the possibility of a "lock up" delaying activity. > What would cause a lock up? well, back when that part of the faq was written, i don't believe conserver was using non-blocking i/o in all places. for quite a while it has been, so the problem of "locking up" isn't even on my radar any more (which also means that faq should be updated). > > the HUP processing is certainly not ideal. it seems to work decently > > (a livable, but quite noticable, delay) on a sparc t1 with just over > > 1000 consoles (using --with-maxmemb=32). that's the only hard datapoint > > i have beyond yours. with the machine you're talking about, i'd think > > you *should* be able to support 3500 consoles. > > Oh, it'll certainly support it once it's up and running. We only have a > problem when we go and reload the configuration. yeah, my comment meant to say more explicitly that the "wedge" a hup causes was a few seconds (no more than 10?) on the t1. still not ideal, but livable. so, hopefully the increase in number of consoles per process will help you get it down to something livable as well. Bryan