Cyrus dies

Sebastian Hagedorn Hagedorn at
Fri May 28 08:07:29 EDT 2004


--On Donnerstag, 27. Mai 2004 19:54 Uhr +0100 Colin Bruce 
<ccx004 at> wrote:

> I have found out the cause of this problem but I don't know what the
> solution is. The good news from your point of view is that it isn't
> anything to do with Cyrus - its our backup software.
> The backup cycle starts at 9PM and the problem we are experiencing starts
> about 17 minutes later and finishes 20 minutes after that. The backup
> is still running at that point and continues for another 30 minutes or
> so. It didn't seem to be strongly related. However, I tried doing a manual
> full backup and that didn't cause a problem so I tried a manual
> incremental backup and that killed the server. I had top running at the
> time with 1 second delays between updates but it froze. However, it was
> showing kswapd at the top with 99% CPU time and bpkar second with 56%.
> When I killed the backup the imap system continued happily.

we have seen similar problems using TSM (Tivoli Storage Manager) backup 
software. See also below.

--On Donnerstag, 27. Mai 2004 13:19 Uhr -0600 Michael Loftis 
<mloftis at> wrote:

> Linux has a LOT of known problems with huge amounts of memory...try
> reducing your memsize to 3Gb or 4Gb either by physically pulling chips or
> memsize=<blah> on the boot line Lilo you can say something like 'linux
> memsize=4096M' in GRUB you have to use 'e' to edit one of the options,
> then scroll down to the line containing kernel.... and add memsize= to
> the end of it by 'e' editing that line, then you can use b to boot.  See
> if that helps your performance.

This I can confirm. We have Dell 6450 systems with 8GB of RAM and the 
caching has caused us no end of problems. Recentyl we reduced the memory to 
2 GB and things are better. However, now, after two years of problems we 
reported to Red Hat, they finally came up with a suggestion about how to 
tune the kernel, albeit somewhat vague: they recommended we lower the 
values in /proc/sys/vm/pagecache. On RH AS 2.1 they default to:

2       50      90

We have now reduced them to:

2       10      60

Hmm, I just noticed that the RH AS 3 values default to:

1       15      100

Things *seem* to be working better this way, but we'll have to see ...

Cheers, Sebastian Hagedorn
Sebastian Hagedorn M.A. - RZKR-R1 (Gebäude 52), Zimmer 18
Zentrum für angewandte Informatik - Universitätsweiter Service RRZK
Universität zu Köln / Cologne University - Tel. +49-221-478-5587

Cyrus Home Page:
Cyrus Wiki/FAQ:
List Archives/Info:

More information about the Info-cyrus mailing list