annotations.db corruption

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 
remembering it.

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?
> 
> 	Bernhard

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.

Dunno. perhaps?

--
Sergio Bruder
Haxent Consultoria


More information about the Cyrus-devel mailing list