Having lots of "127.0.1.1 OPTIONS * HTTP/1.0" apache connections?!

[Greg]

My extended server status has like 100 of these right now


Srv PID Acc M CPU SS Req Conn Child Slot Client VHost Request
0-0 - 0/0/474 . 1.40 12760 0 0.0 0.00 1.98 EDI.TED.IP.XX 127.0.1.1 OPTIONS * HTTP/1.0

Short google on OPTIONS * HTTP/1.0 shows many people having those (but with 127.0.0.1 VHOST instead of mine 127.0.1.1) and general opinion is they are not a concern.

But mine stay there for days and apache would use 100% CPU eventually and make the server useless and need a restart. Right now it takes few days for this to get at this point.

And thhose requests are like 95% of all.

 

[zzrok]

The . under M and the - under PID indicate that there is no current process associated with that line.  This is a natural part of Apache creating new processes to service requests and then killing them when the number of requests goes down.  StartServers, MinSpareServers, MaxSpareServers, and MaxRequestWorkers are used to configure that behavior.  You will notice there will never be more status lines than the number defined in MaxRequestWorkers (at least for prefork, which I'm pretty sure is the MPM you are using).

The upshot is that, yes, you can ignore those lines.  They do not represent resources currently being consumed on your system.  They are empty slots that may be used in the future if request volume goes high enough.

 

[mojeda]

Debian based distros will put 127.0.0.1 as localhost, while 127.0.1.1 will be your actual hostname.

It's still a loopback ip and works the same as 127.0.0.1 however it won't resolve the same.

 

[Greg]

So, I have to look for the reasons for the CPU usage by apache somewhere else?

But if none of the other apache slots is anything significant what else it might be?

 

[al3xt]

what kind of web app/services you hosted on apache? The more service request from the apps itself will create more of these apache processes overtime.

 

[Greg]

well mostly WP sites

they were causing problems before but before i narrowed it down to wp-login.php and xmlrpc.php whcih are now server wide blocked in the nginx template

before they were filling up the processes in extended status and it was obvious

now i really can't narrow it down

before it was crashing up to twice per day (before blocking the files above), now like once per week but still.....not nice

 

[HalfEatenPie]

Has this increased recently?

Because wordpress recently released two updates to their platform that were mostly security fixes.  

 

[Greg]

No, those WPs haven't been updated for  a while.

 

[al3xt]

You should try update your WP sites to the latest version to avoid any potential fixed exploits. Then monitor again. This might not solved 100%, but atleast it narrowed down your scope of problem until you find the root cause.

 

[Greg]

Nah, it will break too much stuff. Those haven't been updated for a while and have plenty of plug-ins. It will be a nightmare. and we are talking about 100 sites here.

And still it will be a shot in the dark. I would prefer to identify the problem and fix just that. Not break 100 other things

 

[Greg]

Do you guys think adding a cron job to restart apache once per day or so is viable solution at all?
I mean it feels more like masking the problem instead of fixing it but at this point i'm out of options?

as a side note vestacp reports the LoadAverage: 3.27 with 2 days uptime

uptime in terminal gives this

 09:22:01 up 2 days,  5:38,  2 users,  load average: 0.71, 5.06, 5.10
 

it's a 2 core vps

i'm not sure how read LoadAverage but kinda have the feeling this is high?