Buchan,

I have a 32bit system so I can only allocate 3GB for slapd. The machines have 12GB each but I can only allocate 3GB for a single process in a 32bit system with CentOS5.3.

The tuning is done based on memory constraints and I think it should be more than enough since the traffic I have is low; only DB is a little large(4 million entrances).

In the end of the day I think that I cannot have dncache with a smaller number than records in your DB. This means I cannot have a DB that cannot have all dncache allocated in memory. I was wondering if this is the case so I will about to use search or replication. The DB can run only in single system with these restrictions.

Thanks,

Rodrigo.

Buchan Milne wrote: 
On Tuesday, 18 August 2009 21:30:31 Rodrigo Costa wrote:
  
openldap software community,

I'm facing some difficulties to have database synchronized with
syncrepl. I'm running the latest openldap 2.4.17 version which after
these issues I compiled with gdb.

I have a DB(divided really in 2 DBs) where each one has around 4 million
entrances. Based in memory limitations I have a dncachesize configured
with around 3000000, or smaller than the maximum number of entrances in
DBs.

I loaded both server with all indexes and the same data. Starting both
there isn't any need for syncrepl(thread from slapd) to make any search
and then both mirrors are in sync and consuming each other. If a new
entrance is create the other consumes since both are listening right on
when it happens.

If I stop one mirror and create even small number of entrances in the
other, like 10, when I try to start the other provider the syncrepl
enters in conventional syncrepl replication which search the DB for
synchronization.

This never ends causing mirrors not in synchronization. What I can see is :

1) Stop the Second mirror, like for slapcat(calling second and first as
reference);
2) Add a few entrances in First mirror(kept on-line);
3) Second mirror start again after First mirror had some new entrances
added by normal operation;
4) Syncrepl in second mirror enters in the conventional syncrepl
replication since it detects that something is different between mirrors;
5) Until dncache is not filled the First mirror slapd cpu consumption is
below 100%(around 50%) and search happens in a good manner since monitor
shows it;
6) After dncache is filled(oscillates above 3mi) the First mirror cpu
consumption enter in 100% consumption, oscillating between 98% to 102%;
7) The search never ends and then systems are never in sync. Cpu is
permanently in high consumption, almost always in 100%.

I let days this process running and I could see only a one or two
entrances in sync. By the CPU looks like something is hanging the search
where some loop is keeping the thread consuming one full cpu processing.

I could collect some GDB information which I'm sending attached. Not
sure how to interpret this overlay_walk.

The idea is to stop one mirror for backup releasing this task from the
primary server. For this replication would need to happen.

Your comments are very welcome.
    

You have provided absolutely no configuration information. There may well be 
other explanations for this behaviour than the dncachesize. I can think of at 
least two.

You also haven't provided information on the systems you are using. E.g., you 
may be trying on systems with too little memory (e.g., <1GB), which might be 
totally inadequate for the amount of data you have.

Regards,
Buchan