vserver and failcnts in the beancounters, what to tune?

[Ovidiu]

I moved a friend of mine off my root server onto another vserver as he was eating too many resources.

The vserver is using a minimal Debian 5.0 32bit image from server4you which I have upgraded to 6.0

He is on the smallest vserver available from server4you and CPU and RAM consumption is negligible. Traffic is minimal but it seems that his periodical newsletter is making him hit some limits. And I need to add, I haven't even started sending the newsletter, currently still configuring and tweaking, sending some test emails, etc.

currently it looks like this:

grep -v ' 0$' /proc/user_beancounters
Version: 2.5

       uid  resource                     held              maxheld              barrier                limit              failcnt
            lockedpages                     0                  336                  344                  344                  560
            tcpsndbuf                  160984              2446744              2449232              3598712                  142
            othersockbuf               244440               748296               744366              1481926                  392
            numothersock                  140                  288                  288                  288                23398

there isn't much running on the machine, I tried to keep it lightweight:

pstree
init-+-cron
|-dovecot-+-4*[dovecot-auth]
| |-imap-login
| `-pop3-login
|-master-+-pickup
| |-qmgr
| `-tlsmgr
|-mysqld_safe-+-logger
| `-mysqld---4*[{mysqld}]
|-nginx---4*[nginx]
|-ntpd
|-php-cgi---4*[php-cgi]
|-postgrey
|-saslauthd
|-screen---bash---pstree
|-syslogd
`-xinetd---dropbear---bash---screen

Resource usage is minimal:

top - 17:22:56 up 8:25, 1 user, load average: 0.00, 0.00, 0.00
Tasks: 37 total, 1 running, 36 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 2097152k total, 199836k used, 1897316k free, 0k buffers
Swap: 0k total, 0k used, 0k free, 0k cached

there are hardly any visitors to the website and its running on nginx so I think that is not the problem. Same goes for mysql.

I tried lowering postfix, dovecot and saslauthd to minimal processes/threads as far down as I could but I am not sure I am succeeding...

Is there any way to figure out, what makes me hit the limits I see in the beancounters?

[falko]

You can try munin to find out what's causing the problem.

[Ovidiu]

Ok, I set up munin trying to check everything I could, here is hte stats page: http://zice.ro/munin/startvps.com/eu...com/index.html

- anything missing?

still, not sure how to use this output, since my failcounts have gone up since last time:

root@euve24187:/etc/munin/plugins# grep -v ' 0$' /proc/user_beancounters
Version: 2.5
       uid  resource                     held              maxheld              barrier                limit              failcnt
            lockedpages                     0                  336                  344                  344                  560
            tcpsndbuf                  225048              2446744              2449232              3598712                  265
            tcprcvbuf                  163840              2457512              2449232              3598712                    5
            othersockbuf               260736               748296               744366              1481926                  392
            numothersock                  150                  288                  288                  288                23398
root@euve24187:/etc/munin/plugins#

[falko]

Can you install munin also on the host system? I think that maybe your problem has to do with long I/O wait times of the hard drive.

[Ovidiu]

Unfortunately not.
ts a rented vserver from server4you.
I wasn't aware of these limits when choosing this solution. I tried to remain within the RAM and CPU bounds and that works but I do have these failcounts.

I just need to know more or less what causes these so I can configure the server to avoid them :-(

for now its kind of not changing...

as I said earlier, I reduced a lot! I think the disk I/O usually happens when sending the huge newsletter... so I limited postfix for now... will soon send out the first one and see what happens...