 |
 |
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