Hagedorn at uni-koeln.de
Fri May 28 08:07:29 EDT 2004
--On Donnerstag, 27. Mai 2004 19:54 Uhr +0100 Colin Bruce
<ccx004 at coventry.ac.uk> 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 wgops.com> 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: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
More information about the Info-cyrus