On Sun, Jul 12, 2015 at 07:56:37PM +0930, Jack Burton wrote: > > It is possible I simply failed to provision sufficient capacity -- > which could easily be fixed by adding a login class for www with a > higher limit on open fds -- but I fear that might just be hiding the > problem rather than addressing it: exhausting a 512 fd limit with with > peak load of only 48 req/sec (and average load of 2 req/sec) just > doesn't feel right (especially when that peak load is all 303s > generated internally by httpd, which each take only a tiny fraction of > a second to process). >
I don't pretend to know httpd (at all), but I'm wondering, what should fstat(1) say, over time, for the httpd processes? Of the (2) processes that have streams related to remote hosts, there are several IP addresses that are never logged to the SSL access log. For example, this one from umich.edu, which is more than 2 days old*: $ fstat -p 29431 | grep 141.212.122.50 www httpd 29431 5* internet stream tcp 0x0 193.214.208.180:443 <-- 141.212.122.50:29801 $ fstat -p 17244 |grep 141.212.122.50 $ $ grep 141.212.122.50 /local/www/logs/ssl-access.log $ Is this normal behaviour? Tor * This one, from shadowserver.org, which does exist in the ssl-access.log, was opened on 10 July, same day the server was rebooted: www httpd 29431 12* internet stream tcp 0x0 193.214.208.180:443 <-- 184.105.247.196:35517 www.bogus.net 184.105.247.196 - - [10/Jul/2015:03:41:05 +0200] "GET / HTTP/1.1" 200 67 "" ""
