Sergio Devojno Bruder
bruder at haxent.com.br
Tue May 9 11:55:34 EDT 2006
Bernhard Reiter wrote:
> On Mon, May 08, 2006 at 03:33:11PM -0300, Sergio Devojno Bruder wrote:
>> We already saw this 'dying process corrupting skiplist db' a lot, you
>> reproduce it with a really big db (>5-7M mailboxes) with little memory
>> (<= 1GB) in a linux box easily, some mmap operations will fail ENOMEM
>> and the process will give up with a resulting broken db.
>> NOTE: mmap will fail with ENOMEM in linux with free memory and lots of
>> swap free.
> Are you in a position to try our experimental patch for this problem?
> See patch.2 attached to https://intevation.de/roundup/kolab/issue840
That happened with our production server, ouch, it aches only
I'll see what can We do to test it.
>> We already saw another type of problem with SMP (2 x Xeon with HT, 4
>> 'processors' for linux) (Cyrus 2.2.10), resulted in corruption too (and
>> all problems with sincronization between frontends, mupdate and
>> backends). We "solved" it running a UP kernel on that same box, mupdate
>> doesnt need all that cpu power. IE: There is a race there.
> Running an SMP linux raised the chances to get a corruption, too.
> Is there a chance that this is the same bug,
> e.g. a memory locking failure?
Earlier we used a one way Xeon with HT and periodically saw corruption.
When we upgraded to 2 way Xeon with HT the rate of corruption went way
up, so we reverted to an UP kernel.
More information about the Cyrus-devel