[Date Prev][Date Next]
> The high write concurrency in back-hdb has been largely defeated by the
> syncrepl entryCSN update code, which serializes all modifications in both
> back-bdb and back-hdb.
This seems inevitable if we store the context CSN in the database,
because the DB pages containing the context CSN entry will be a hot spot.
One option would be to make it optional to maintain the context CSN.
Another option would be to maintain the context CSN only in memory
(not in database) to relieve the contention, but even in this case
the BDB locking for the memory location would still remain contended.
BTW, I didn't observe a noticeable performance difference when I ran test008.
Also, I want to see how much performance degradation the current
context CSN design is imposing on the update performance, because
the context CSN update code is placed at a point close to the transaction
commit so the performance impact may not be as large as it seems to.
It would be very helpful to see performance data if you have some.