Re: _cl5CompactDBs: failed to compact

Andrey Ivanov <andrey.ivanov@xxxxxxxxxxxxxxxx> · Sat, 20 Jun 2015 13:22:43 +0200

Thank you, Ludwig and Rich.

Yes, i'm sure that the changes were effective. When starting the server says smth like
resizing max db lock count: 20000 -> 100000

And db_stat shows the correct new number of locks. Ok, i'll try to increase the locks further and see when the problem disappears.

2015-06-19 15:35 GMT+02:00 Ludwig Krispenz <lkrispen@xxxxxxxxxx>:

    On 06/19/2015 03:25 PM, Rich Megginson
      wrote:

      On 06/19/2015 04:29 AM, Ivanov Andrey
        (M.) wrote:

          Hi Noriko,

                There are three MMR replicating servers. It's one
                  month of uptime and the servers wanted to trim the
                  replication log. Here is what i've found in error log
                  on each of them :

                1st server:

                [18/Jun/2015:08:04:31 +0200] - libdb: BDB2055 Lock
                  table is out of available lock entries

            May not matter, but could you please try increasing the
            value of this db config parameter?  The default value is
            10000.

            dn: cn=config,cn=ldbm
              database,cn=plugins,cn=config

              nsslapd-db-locks: 10000

          Ok. I've increased nsslapd-db-locks to 20000 and reduced
            nsslapd-changelogcompactdb-interval to 3600 in
            cn=changelog5,cn=config to see the changelog free event more
            frequently. No change. I have still :

          [19/Jun/2015:10:36:46 +0200] - libdb: BDB2055 Lock table
            is out of available lock entries

            [19/Jun/2015:10:36:46 +0200] NSMMReplicationPlugin -
            changelog program - _cl5CompactDBs: failed to compact
            a45fa684-f28d11e4-af27aa63-5121b7ef; db error - 12 Cannot
            allocate memory

                [18/Jun/2015:08:04:31 +0200] NSMMReplicationPlugin
                  - changelog program - _cl5CompactDBs: failed to
                  compact a45fa684-f28d11e4-af27aa63-5121b7ef; db error
                  - 12 Cannot allocate memory

            I don't thing there is any problem even if the DBs are not
            compacted.  It was introduced just to release the free pages
            in the db files.  But I'd also like to learn why the compact
            fails with ENOMEM here.
          Ok, thanks.

      I'm guessing that bdb returns ENOMEM when it runs out of locks.

      I think the only remedy is to just keep increasing the number of
      locks until this error goes away.  I don't know how to estimate
      how many locks are required ahead of time.

    I think compact can be consuming many locks, maybe for each of the
    pages in the cldb, and then there is this bug:
    https://fedorahosted.org/389/ticket/47934

    did you verify that your changes have been effective ? try the
    db_stat: 

    db_stat -c -h /var/lib/dirsrv/slapd-<INSTANCE>/db/ | grep
    locks

        --
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users

      --
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users

--

389 users mailing list

389-users@xxxxxxxxxxxxxxxxxxxxxxx

https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users