- Log -----------------------------------------------------------------
commit 0ab841598ffb490f4246f892248f0b409e411cc1 Author: Howard Chuhyc@symas.com Date: Sun Sep 18 16:39:18 2011 -0700
Fix 09006ccec7928c9cf53bca6abe741e8d4d466c98 Check for stale DBs was in the wrong place.
Since back-mdb does no caching, it's OK to run slapadd while slapd is running; slapd will see the new data immediately. In fact you can run multiple slapds on the same database and they will stay perfectly in sync. I'm not sure that that's actually a useful thing to do, but you can do it if you want...
Howard Chu wrote:
- Log -----------------------------------------------------------------
commit 0ab841598ffb490f4246f892248f0b409e411cc1 Author: Howard Chuhyc@symas.com Date: Sun Sep 18 16:39:18 2011 -0700
Fix 09006ccec7928c9cf53bca6abe741e8d4d466c98 Check for stale DBs was in the wrong place.Since back-mdb does no caching, it's OK to run slapadd while slapd is running; slapd will see the new data immediately. In fact you can run multiple slapds on the same database and they will stay perfectly in sync. I'm not sure that that's actually a useful thing to do, but you can do it if you want...
To answer my own question - apparently it's useful to get around bottlenecks in the slapd connection manager. Over 123,000 searches/second using two slapds on the same mdb database. At this point core#0 was at 99.5% busy in soft interrupts. The slapds were only using (combined) 1250% CPU.
http://highlandsun.com/hyc/slamd-mdb/jobs/job_20110918191657-463348391.html
Howard Chu wrote:
- Log -----------------------------------------------------------------
commit 0ab841598ffb490f4246f892248f0b409e411cc1 Author: Howard Chuhyc@symas.com Date: Sun Sep 18 16:39:18 2011 -0700
Fix 09006ccec7928c9cf53bca6abe741e8d4d466c98 Check for stale DBs was in the wrong place.Since back-mdb does no caching, it's OK to run slapadd while slapd is running; slapd will see the new data immediately. In fact you can run multiple slapds on the same database and they will stay perfectly in sync. I'm not sure that that's actually a useful thing to do, but you can do it if you want...
To answer my own question - apparently it's useful to get around bottlenecks in the slapd connection manager. Over 123,000 searches/second using two slapds on the same mdb database. At this point core#0 was at 99.5% busy in soft interrupts. The slapds were only using (combined) 1250% CPU.
http://highlandsun.com/hyc/slamd-mdb/jobs/job_20110918191657-463348391.html
... which goes back to LDAP's original purpose: lots of reads, occasional writes. Sounds like back-mdb is LDAP's holy graal :)
p.
-
Howard Chu -
masaratiļ¼ aero.polimi.it