These blocks are reserved to the super user to recover from situations where user processes fill up filesystems.
It is absolutely safe to reduce this space to one hundred or so MB.

• check disk space of our filesystem:

$ df -h /dev/sda4
/dev/sda4             813G  418G  354G  55% /home

Before the tuning, we have 354G free.

• check the current number of reserved blocks:

$ tune2fs -l /dev/sda4
...
Reserved block count:     10816865
...

Change this number to 20000.
The blocksize is 4096, 20000 blocks represent about 80MB.

$ tune2fs -r20000 /dev/sda4
...
Reserved block count:     20000
...

• check disk space of our filesystem:

$ df -h /dev/sda4
/dev/sda4             813G  418G  395G  52% /home

We now have a gain of 40GB of free space!

I needed to calculate this total for a set of javascript files, I used this command line:

$ find App/ -name '*.js' -exec ls -l \{\} \; | awk '{sum+=$5} END {print sum}'
1929403

For a human readable result, you can divide your result and use printf to format it:

$ find App/ -name '*.js' -exec ls -l \{\} \; | awk '{sum+=$5} END {printf("%.2fM\n", sum/1024/1024)}'
1.84M

Playing with memory_limit in PHP, we wanted to know the average memory usage per php-cgi process. This is easily calculated with our best friend awk.

First, get the number of php running processes:

# ps aux | grep php-cgi | grep -v grep | wc -l
126

Then, use awk to calculate the average memory usage for these processes:

# ps aux | grep --exclude=grep php-cgi | grep -v grep | awk 'BEGIN{s=0;}{s=s+$6;}END{print s/126;}'
33987.8

The number used in the calculation is the field RSS given by ps. The ps manual page says:

rss: resident set size, the non-swapped physical memory that a task has used (in kiloBytes)

You can also calculate the total memory used by all php-cgi processes:

# ps aux | grep --exclude=grep php-cgi | grep -v grep | awk 'BEGIN{s=0;}{s=s+$6;}END{print s;}'
4302028

If you need to watch the trend of this average memory usage, a little shell loop does the trick:

# while [ 1 ]; do ps aux | grep --exclude=grep php-cgi | grep -v grep | awk 'BEGIN{s=0;}{s=s+$6;}END{print s/126;}'; sleep 2; done
34401.3
34405.1
34408.4
34409.4
34414.2
34417

The man page of the module is here, where you can read:

The utility of accf_http is such that a server will not have to context switch several times before performing the initial parsing of the request.

To load this module, use the following command:

# kldload accf_http

To load it at boot time, add the following line in /boot/loader.conf:

accf_http_load="YES"

To check if the module is loaded, use the command kldstat:

# kldstat
Id Refs Address    Size     Name
 1    4 0xc0400000 906518   kernel
 2    1 0xc0d07000 6a32c    acpi.ko
 3    1 0xc5e65000 2000     accf_http.ko

Use of uninitialized value in eval {block} exit at /usr/sbin/munin-node line 456, <CHILD> line 8.

What a great error message

After digging into Google results, I found it was just a problem with host_name variable in the configuration. Default value is hostname.localdomain. I’ve replaced it with a valid hostname and it works!

2009/03/09 21:23:19 [warn] 26827#0: 4096 worker_connections are more than open file resource limit: 1024

A solution is to use the command ulimit in nginx start script, just before lunching nginx:

[...]
ulimit  -n 65536
[...]

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LANG = "fr_FR.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

To get rid of these annoying messages, I’ve just reconfigured locales with the command:

# dpkg-reconfigure locales

Choose your locale when you’re asked for your “Default locale for the system environment”.

You should have a message like:

Generating locales (this might take a while)...
  en_US.UTF-8... done
Generation complete.

Then, logout, login and your perl installation works fine!

Nothing was written in the logs to say that there was a problem.

To avoid future problems, I wrote an alert for monit.

In my crontab, I’ve added the following job:

*/5 * * * *       root    touch /tmp/check_cron

This job will update the timestamp of the file /tmp/check_cron every 5 minutes.

And in monit configuration (/etc/monit/monitrc), I’ve added the following alert:

check file check_cron with path /tmp/check_cron
        if timestamp > 10 minutes then alert

If the crontab is not working, monit will send you an alert email like this:

Subject: monit alert --  Exists check_cron

Exists Service check_cron 

	Date:        Thu, 27 Nov 2008 21:21:53 +0100
	Action:      alert
	Host:        myhost
	Description: 'check_cron' file exist

Your faithful employee,
monit

Some Content Delivery Network providers

• Akamaï
  • Akamaï on Crunchbase
• BitGravity
  • BitGravity on Crunchbase
• EdgeCast Networks
  • EdgeCast Networks on Crunchbase
• Limelight Network
  
  • Limelight Network on Crunchbase
• Panther Express
  • Panther Express on Crunchbase