Large maillog processing causes performance problem

[am115998]

Hi,

I'm and ispCP & Linux newbie (all Solaris & AIX experience!) - please don't flame me for dumb questions. Point me to correct man pages is necessary.

I have ispCP running on CentOS and the maillog processing (running diff between maillog & maillog.prev) causes CentOS to dump MySQL to swap (only 2GB RAM in system) with attendant loss of response from ezPublish.

I am in process of trying different swappiness settings in CentOS but real issue is maillog not being trimmed/truncated. We want maybe weekly or monthly stats only.
[If anyone knows of better diff binary for CentOS or can recommend swappiness=0, please let me know.]

Questions:
1) Is the log trimming a logrotate.d setting? I have never used logrotate before but can read man pages (again!) if need be - not aware how it interacts with other packages e.g. ispCP.

2) What process/subsystem of ispCP generates the maillog? Is this where I need to make changes?

Your help greatly appreciated.
Alex

[root@server3993 rc2.d]# ls -l /var/log/ispcp/mail*
-rw------- 1 root root 912660056 Jul 2 11:00 /var/log/ispcp/maillog
-rw-r--r-- 1 root root 0 Jul 2 11:00 /var/log/ispcp/maillog.diff
-rw------- 1 root root 912482683 Jul 2 10:32 /var/log/ispcp/maillog.prev

[kilburn]

Which ispcp are you using? This is supposedly fixed in the lastest stable...

[am115998]

(07-12-2010 11:09 PM)kilburn Wrote:  Which ispcp are you using? This is supposedly fixed in the lastest stable...

From the control panel:
ispCP 1.0.0 RC7 OMEGA
build: 20081212
Priamos

running on:
CentOS release 5.3 (Final)
Linux XXXX.YYYYY.com 2.6.18-194.8.1.el5PAE #1 SMP Thu Jul 1 19:46:23 EDT 2010 i686 i686 i386 GNU/Linux

I'm running yum check-update to get some more info. and I'll look at the ispCP release page/notes etc. to try and get a clue.

Any specific info you may have, greatly appreciated. This is a standalone production server with no test environment, so changes have to be well understood before they go in!

Questions:
1) Is the statistics generating job in a crontab anywhere? - as a temporary workaround we could disable it, but I think a lot of different activity occurs when this job runs. (Stats generation seems to run every 30 minutes.)

2) When I look on the website for documentation there seem to be a lot of blank pages. Is this right or am I being exceptioanlly blind? !!

Many Thanks.
Alex.

[fluser]

(07-12-2010 11:48 PM)am115998 Wrote:  2) When I look on the website for documentation there seem to be a lot of blank pages. Is this right or am I being exceptioanlly blind? !!

There are a lot of blank pages. But I think they won't be blank in future

[kilburn]

(07-12-2010 11:48 PM)am115998 Wrote:  From the control panel:
ispCP 1.0.0 RC7 OMEGA
build: 20081212
Priamos

So this is an old, pre-stable version. You should think about updating...

Quote:1) Is the statistics generating job in a crontab anywhere? - as a temporary workaround we could disable it, but I think a lot of different activity occurs when this job runs. (Stats generation seems to run every 30 minutes.)

I'm not sure about CentOS, but under debian it's in /etc/cron.d/ispcp. Specifically these lines:

Code:

0,30    *       *       *       *  root /var/www/ispcp/engine/traffic/ispcp-vrl-traff &>/var/log/ispcp/ispcp-vrl-traff.log
15,45  *       *       *       *  root /var/www/ispcp/engine/traffic/ispcp-vrl-traff-correction &>/var/log/ispcp/ispcp-vrl-traff-correction.log

Nevertheless, the traffic counting process has been greatly improved since those days. You could try using a recent "engine/traffic/ispcp-vrl-traff" script (from current trunk) and commenting the ispcp-vrl-traff-correction execution (it's not used anymore). I'm not completely sure if I'll work without any trouble, but the worst thing that could happen is just that you loose some hours of stats...

Code:

2) When I look on the website for documentation there seem to be a lot of blank pages. Is this right or am I being exceptioanlly blind? !!

You're right, there are too many blank pages, but...