 |
 |
Thanks Wilko! 314920 read calls gives you roughly 75kB of data retrieved from the socket per read syscall which is incredibly expensive. This gives some backing to my hypothesis about epoll returns and explains why the system scales well with larger number of active sockets but not when there is only few of them. Michal, a way to test if it's a valid explanation would be to put a `nanosleep` in the poller loop between epoll calls and experiment with sleeping time. If the test is successful, you could think of fixing it in two ways: 1) Put a `nanosleep` in the poller depending on the number of active sockets. This is super ugly and will likely backfire. 2) Linux apparently supports the `FIONREAD` ioctl which tells you how many bytes are immediately readable from the socket. This likely means that the reason that Alan Cox gave 10 years ago for not supporting `SO_RCVLOWAT` is no longer valid and the kernel actually now gathers all the required statistics to implement watermarking. If so, this may be a fairly trivial patch. --- Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/issues/20#issuecomment-158744021 ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1