[Date Prev][Date Next]
Re: (ITS#6243) back-monitor fails to report entry cache usage
--On Thursday, August 06, 2009 7:25 PM +0200 email@example.com wrote:
>> --On August 5, 2009 7:17:43 PM +0000 firstname.lastname@example.org wrote:
>>>> This may be specific to glued databases (databases rooted at "").
>>> The problem could be partially addressed by telling back-bdb (who's
>>> maintaining this data in the monitor backend) to check subordinates as
>>> soon as it discovers it's a glue instance. However, this poses two
>>> different problems:
>>> - is the aggregate information resulting from adding all glued databases
>>> cache usage still useful?
>>> - what happens if heterogeneous databases are glued? Significantly,
>>> if the superior database is not bdb/hdb?
>>> Probably, the monitor database should also present subordinate databases
>>> as separate entries.
>> Interestingly, in my case, there's only one real database in play for the
>> glue as it is, since it's rooted at "". All other database definitions
>> come before it (cn=config, cn=accesslog, cn=monitor).
> but... are you actually gluing something? In any case, this is not
> specific to the case of empty suffix in the glue database. I could easily
> reproduce it with a "normal" glued setup, and I was about to start fixing
> things when the two above questions came to my mind.
>> I'm also curious why back-monitor develops stats for the other caches but
>> specifically not for entry cache.
> I haven't looked in detail, but it makes sense that some operation occurs
> within the glue database which requires caching something, but not
> - The entry cache monitor shows the value of bdb->bi_cache.c_cursize;
> - the DN cache monitor shows the value of bdb->bi_cache.c_eiused, which
> should be the number of entryinfo structures used;
> - the IDL cache monitor shows the value of bdb->bi_idl_cache_size.
> In my very simple tests, I only saw something populating the DN cache,
> which means some internal operation required to allocate some entryinfo
> structures that remain 'round.
> In any case, it's only showing information related to its database
> structure, it is by no means collecting info from the glued databases.
Any chance we can get this fixed for 2.4.18 for the real backends? I think
making it so you can see the counters per-real backend should definitely be
in place. How to handle the frontend is interesting and definitely should
be addressed as well but isn't (to me at least) quite as crucial at this
Principal Software Engineer
Zimbra :: the leader in open source messaging and collaboration