 |
 |
Hmm, good point. THe process limit with 2.4 is 3GB. Not sure if 2.6 changes that at all. On Fri, 4 Feb 2005, Andrew Hanushevsky wrote: > Hi Pete, > > > The fact that that Enrica reports seeing problems only when running > > with many clients probably indicates that there really is some memory > issue > > that comes up with many clients (250-300 jobs). > Can't dispute that. > > > I note that the canonical 16GB number (often for machines with 2GB of > > real memory) came from some stupidity/feature of virtual memory management > > in solaris, no? A priori there is no known reason (yet) why linux needs > such > > a large ratio of swap/real memory, is that correct? (That said, I agree > that > > it isn't a huge amount of swap space for a server these days. Trying to > > increase it would be worthwhile. If that doesn't help, then we know > something > > else is probably wrong.) > If top says that there is no swap space left, then one should increase swap > space. If the process limit in Linux is 2GB (well, actually I think the > limit for a process is equal to the amount of real memory the machine has, > which I think here is 2GB) then you're back is aganst the wall if xrootd has > reached 2GB (top will show that too). Then you *definitely* would need the > memory-tuned xrootd. > > > We really need to get the xrootd testbed hardware set up so that we > > can dream up some real tests instead of deploying the latest development > > version in the production system at CNAF.... One of the machines is > > a linux server, is that correct? We could easily duplicate this sort > > of situation at SLAC (250-300++ clients hitting various versions of xrootd > > with various amounts of swap space). While SLAC still has solaris servers, > > most of the rest of the world is more likely to be running linux servers > > these days... > Agreed. We've been running withy the new xrootd on Solaris x86, 400 clients, > with no ill effects. So, I'd say that it's probably a good release. I still > have to go through the memory trace and make sure the memory trim algorithm > is wiorking as expected. > > > Andy, assuming that the swap space and memory issues are dealt with (and > > ignoring the random I/O and file descriptor limits), is there anything > > else in xrootd itself that you expect will limit the number of clients? > The only thing left is my using some data structure that doesn't scale well. > I dont know of any right now, but that doesn't mean there isn't one (I could > still be in the linear part of the curve). The limits really are controlled > by a) number of allowed file descriptors, b) thread limit, and c) amount of > real memory/swap space.. Everything else is fungible. > > Andy > -- /------------------------------------+-------------------------\ |Stephen J. Gowdy | SLAC, MailStop 34, | |http://www.slac.stanford.edu/~gowdy/ | 2575 Sand Hill Road, | |http://calendar.yahoo.com/gowdy | Menlo Park CA 94025, USA | |EMail: [log in to unmask] | Tel: +1 650 926 3144 | \------------------------------------+-------------------------/