Archived

This forum has been archived. Please start a new discussion on GitHub.

Slow in Freeze Evictor add operation

:confused:
We use Freeze Evictor manage our some permenent objects. Recently we found the evictor add() method become slower when actived objects in evictor increasing. The follow is the slowest codes in Freeze/EvictorI.cpp
Ice::ObjectPrx
Freeze::EvictorI::addFacet(const ObjectPtr& servant, const Identity& ident, const string& facet)
{
    ....
    //line:522
    EvictorElementPtr oldElt = store->putIfAbsent(ident, element); //sometimes very slow
    ....
At the same time a lot of log.0000xxxx files can be found in the evictor database enviroment. We have tried to increase the server thread pool size but no effect can be found.
Thanks for any reply!

Yours sincerely
YinYunqiao

Comments

  • bernard
    bernard Jupiter, FL
    Hi Yin Yunqiao,

    putIfAbsent is a fairly simple operation: it checks if an object with this identity is in the Evictor cache or in the database. If it is, the existing object is returned; otherwise, "element" is inserted in the cache.

    In particular, this function does not write anything to the database, so it should not be slow.

    One possibility is that you're adding (or changing) lots of objects; from time to time the evictor saves these changes to the database (in a background thread), and when this occurs various database pages are locked. This may block the database lookup performed by addFacet/putIfAbsent.

    If that's the issue, you could save more often -- this way, each save would take less time and would not block lookups/reads for long.
    For some applications, the solution could also be to save less. Say you're creating 1000 objects at start-up: the best strategy in this case could be to save every x minutes or when the number of modified objects reaches some value > 1000.

    Now, the log files: these are transaction log files created by Berkeley DB. If you want perform backups of your database, you need to manage these log files carefully (back them up and delete them when they are no longer needed); see for example the Freeze/backup demo.

    Otherwise, Freeze can delete them automatically with the configuration property:
    Freeze.DbEnv.<env-name>.OldLogsAutoDelete=1
    (the default is 1, so you don't need to set it)

    If you have OldLogsAutoDelete set and the number of log files keeps increasing, then there is a bug.

    Cheers,
    Bernard
  • It works,thank you for your help!