 |
 |
Hi Andy, Oops, I meant to mention the release version but didn't. We are using the vdt version packaged as: Xrootd 20091028-1003 (reported with vdt-version) I will look at increasing the FD limit, but I am not sure if this is just delaying the onset of the problem. Patrick Andrew Hanushevsky wrote: > Hi Patrick, > > Please tell me the release you are running. We did put in a CLOSE_WAIT > fix recently. That aside, we always recommed setting the FD limit to as > high as practical for your OS (at least 8K and preferably 16K to 32K). > 1K is not recommended and will likely lead to problems regardless of any > extant bugs. > > Andy > > ----- Original Message ----- From: "Patrick McGuigan" <[log in to unmask]> > To: <[log in to unmask]> > Cc: <[log in to unmask]> > Sent: Monday, April 12, 2010 2:08 PM > Subject: Overloaded Xrootd dataserver? > > >> Hi, >> >> I am having an issue with one of our data servers and it may be >> getting overloaded with requests from clients. >> >> The symptoms are that the load on the SRM machine will get very large >> because threads there are talking through XrootdFS for various >> connections to the dataserver. Various activities related to Xrootd >> will fail (SRM get's hung, gridftp servers won't send data). >> >> When logged into the dataserver and running strace on the xrootd >> service I see that it has a problem in accept() because of too many >> open files. >> >> If I do a netstat I see that xrootd is holding a large number of >> sockets in a CLOSE_WAIT state. >> >> I am trying to understand if the problems that I am seeing are because >> the limits (1024 open FD's) given to xrootd are too small or if the >> problem with xrootd is that the service is too overloaded and this is >> causing xrootd to hang on to too many sockets. >> >> Regards, >> >> Patrick >> >