On 08/31/2009 10:00 PM, Rainer Gerhards wrote: >> The limitation of 1000 open file descriptors however (limitation of >> select()) is still there in newer rsyslog releases and >> therefor we are >> probably forced to work around it. Although I find it >> personally strange >> that this limitation is not a more widespread problem. Is >> everybody using >> a database backend ? Or are people segregating syslog messages by >> location/importance ? > > I am not sure tha it is a select() limit. I routinely run tests with 2000 tcp > connections under Fedora and it works well. An issue, of course, is the > per-process file handle limit, which (on many systems) is 1,024. In current > releases, you can simple increase that limit via the $MaxOpenFiles directive:
Part of the problem, based on the log excerpt from one of the bug reports, is that the file descriptor limit for the process is too low; Aug 1 19:10:30 lg2log01 rsyslogd:tcp accept, ignoring error and connection request: Too many open files Aug 1 19:10:34 lg2log01 rsyslogd:last message repeated 49 times Aug 1 19:10:33 lg2log01 rsyslogd:tcp accept, ignoring error and connection request: Too many open files This isn't caused by select(). It should be possible to change the limit with 'ulimit -n <nbr>'. The issue with select() remains, though. It has a hardcoded limit on the number of file descriptors of FD_SETSIZE. I've run a test with rsyslog 2.0.6 and I haven't been able to receive messages from tcp clients with fds > 1024. Tomas _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
