apache2buddy.pl

the script

The script is a perl script that provides a great dashboard about apache memory consumption, and is especially useful for tuning apache so that you do not exhaust your memory and either swap heavily, invoke oomkiller, or cause your server to completely crash (kernel panic) because of no memory.

It can also be used as a diagnostic tool for post mortem troublshooting of out of memory errors where you suspect apache is to blame.

Apache2buddy.pl is a fork of apachebuddy.pl and has been released under the apache 2.0 license.

independent reviews and articles

These reviews were completely independent, I have no idea who wrote them or how they came to be, they were certainly not solicited by me…..but…..welcome all the same 🙂

Tech republic:

http://www.techrepublic.com/article/how-to-tune-apache-in-seconds-with-apache2buddy-pl/

the domain

the domain used to point directly at the script for easy curl & perl operations, however, due to some security concerns, you now need to hit the script by using this URL:

https://raw.githubusercontent.com/richardforth/apache2buddy/master/apache2buddy.pl

This allows one to execute it on the server easily with

# curl -sL https://raw.githubusercontent.com/richardforth/apache2buddy/master/apache2buddy.pl | perl

Notes on the curl & perl method:

-s      silent (dont show the curl download header)
-L      follow redirects (very important as you get a 301)

You can also wget it but this is frowned upon (especially by me) however you can do it like so:

# cd
# wget -O apache2buddy.pl https://raw.githubusercontent.com/richardforth/apache2buddy/master/apache2buddy.pl
# perl apache2buddy.pl

 

Reasons I frown when you do this wget method:

1. Youre downloading the file. This file is never going to get updated, unless you wget it again.

2. I do regular bugfixes, feature requests and cleanups of code.

3. With curl and perl, you always pull the latest version.

 

Risk Factors

Running arbitrary code as root (Dangerous) – Compromised script could result in root level compromise of your server – Runaway processes doing not what they are supposed to (this actually happened in testing, thankfully all of the known exceptions have been caught)

About, and heritage information

apache2buddy.pl is a reporting tool and onetime run dashboard for assisting with tuning and troubleshooting apache webservers.

# curl -sL https://raw.githubusercontent.com/richardforth/apache2buddy/master/apache2buddy.pl | perl

It is a fork of the original project ‘apachebuddy.pl’.

# curl -sL apachebuddy.pl | perl # note this one still uses the domain name, mine doesnt!

Its’ continued development has included support for Debian and Ubuntu, whereas the original script only used to support RedHat / CentOS Systems

New features have been added and if you compared the two outputs above you will notice a vastly more intuitive and informational dash.

As you may see, there are some similarities between the new and the old, but the NEW has undergone some incerdible changes and is an entirely new beast, one of the most killer features is that it nows takes into consideration a number of services BEFORE calculating a maxcients value, this includes:

       - MySQL
       - Java
       - Varnish
       - Redis
       - Memcache
       - PHP-FPM
       - Gluster

Logging

On every execution, an entry is made in a log file: /var/log/apache2buddy.log on your server.

Example log line:

2016/05/24 10:14:15 Model: "Prefork" Memory: "490 MB" Maxclients: "50" Recommended: "54" Smallest: "8.49 MB" Avg: "8.49 MB" Largest: "8.49 MB" Highest Pct Remaining RAM: "91.84%" (86.64% TOTAL RAM)

 

This is to help you get an idea of changes over time to your apache tuning requirements. Maybe this will help you decide when you need more RAM, or when you need to start streamlining your code. Tracking when performance started degrading. Remember it only puts a new entry in the log file on each new execution. Its not designed to be run as a cron job or anything. # Log Rotation Log rotation should not be necessary because this script is NOT designed to be run as a cron job so it should never really fill your disks, if you ran this on your server a year or six months ago, maybe its just nice to see what the results were from back then? You get the idea.