I have been told that there are performance issues when using a lot of vhosts w/ individual error logs/access logs due to a large number of open file descriptors. I understand that one approach is to periodically parse a single universal access log into individual transfer logs. What about using "tail -f" (or something similar) on the central log, and then parse each line, and have it write the transfer data to an sql database. This way, you could have real-time transfer data, and no problem w/ open file descriptors.

Does this make any sense? Anyone see any huge glaring problems before i start on this?

Jake29

Its easy enough to recompile apache with a higher file descriptor limit as well as increasing the servers FD limit, with RH 7.2 (the 2.4 kernel version) has a higher and more flexible limit than does the 2.2 kernel version, but you can change the limits in the 2.2 kernel source and recompile to increase overall FD's.

Do you find that your server performance is adversely effected by a large number of open file descriptors?

Jake29

So far i've not encountered any issues with increasing any of the limits, most of the limits in the 2.2 kernel and even some in apache seems to be geared towards smaller hardware, but the limits are well under the capability of todays servers.