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