 |
 |
Hi Fulvio, My understanding was that the xrootd version being used was imcompatible with the particular Linux version being used. Once that problem was resolved, things were working fine. Are you sure this isn't the problem here? > More specifically, I'd be also interested to hear about: > - is there a rough formula which allows to compute, given a machine > with N GB of RAM and M GB of swap, the maximum number of connections > which can be tolerated? Apart from performance issues, is it only the > sum of physical memory and swap space which matters? It's really onlythe sum of memory and swap that matters. I recommend 16GB of swap space in a mindless way (i.e., just give it 16GB no matter what the memory size). Yes, you can fine tune it but it's hardly worth it since 16GB of disk space is a pretty small impact for the normal sized server. Can somebody > - related to point above... In order to avoid having xrootd go in a > funny state, would it be possible/advisable to limit the number of > incoming connections? What will happen once the limit is hit? The > extra incoming connections will just wait (I guess, sent back to the > load-balancer) without complaining? Would this cause too much traffic > around the load-balancer at some point? Normally, I don't recommend lowering the limit. You'll probably get more problems than not from the client's side. What happens is simply that the client cannot connect, immediately times out, and goes to the load balancer that then sends the client back to the same machine. Not pretty, and yes, can put a big strain on the load balancer. > > At CNAF we are planning for next week a massive sparsification of > files across our data servers to help reduce the chance of a single > machine being hit too hard, yet it would still be nice to improve our > xrootd configuration. We are fine-tuning some algorithms in xrootd in order to improve memory managment. The current developement release looks very hopeful (I'm doing the analysis of a memory trace right now). The latest test release has significantly reduced the xrootd memory footprint without significantly increasing the overhead. I'd say that would be your best bet (once we sign off on it). Andy