Memory Leak and 100% CPU in slapd process when using Open Directory OS X 10.8.5

Question

Has anyone seen the slapd (LDAP daemon from OpenLDAP which OS X Server uses) run away when running Open Directory? We've tried disabling replication but it doesn't seem to matter. The slapd process will start up and take up about 400MB and then at night will consume all the available memory and crashing the server.
Any thoughts? Any benefit in upgrading to Mavericks' Server app?
Thanks,
John

Answer 1

@Strontium90
Found this in opendirectory.log which seems to just show ldap requests starting to slow down.
2013-12-06 09:54:19.736670 PST - State information (some requests have been active for extended period):
          Sessions: {
              2839 -- opendirectoryd:
                          Session ID: CBAE3152-1A3B-4C7E-89D6-2F836C28F5BA
                          Refs: singleton
                          Type: Default
                          Target: localhost
          Nodes: {
              2839 -- opendirectoryd:
                          Node ID: CC6FC6C3-AD02-4068-9E8F-8FDC228F4C48
                          Nodename: /Search
                          Session ID: <Default>
                          Refs: 3
                          Internal Use: X
              2816 -- automount:
                          Node ID: 8FC03A24-46F2-4DAA-A0EC-3FF98B458FB4
                          Nodename: /Search
                          Session ID: <Default>
                          Refs: 2
              277 -- SystemUIServer:
                          Node ID: FFF97865-2FBE-474A-BD53-43A35DA09D3A
                          Nodename: /Search
                          Session ID: <Default>
                          Refs: 3
                          Internal Use: X
          Requests: {
              2816 -- automount:
                          Nodename: /Search
                          Refs: 5
                          Active Time: 65170959
                          Type: ODNodeCopySubnodeNames
                          Current Module: search
                          Node ID: 8FC03A24-46F2-4DAA-A0EC-3FF98B458FB4
                          Request ID: 5
              2839 -- opendirectoryd:
                          Nodename: /Search
                          Refs: 5
                          Active Time: 65971987
                          Type: ODQueryCreateWithNode
                          Current Module: search
                          Node ID: CC6FC6C3-AD02-4068-9E8F-8FDC228F4C48
                          Request ID: 4
              277 -- SystemUIServer:
                          Current Module: SystemCache
                          Type: getpwuid
                          Request ID: 10
                          Refs: 4
                          Active Time: 13397955
                          Nodename: /Search
                          Parent Request: 10
                          Refs: 5
                          Active Time: 11041999
                          Type: ODQueryCreateWithNode
                          Current Module: search
                          Request ID: 12
                          Node ID: FFF97865-2FBE-474A-BD53-43A35DA09D3A
              68 -- coreservicesd:
                          Current Module: SystemCache
                          Type: getpwuid
                          Request ID: 8
                          Refs: 3
                          Active Time: 13484131
              2832 -- sshd:
                          Current Module: SystemCache
                          Type: getpwnam
                          Request ID: 9
                          Refs: 3
                          Active Time: 13483916
              640 -- SystemUIServer:
                          Current Module: SystemCache
                          Type: getpwuid
                          Request ID: 7
                          Refs: 3
                          Active Time: 13522530
2013-12-06 09:54:19.737704 PST - requesting spindump generation
In slapd.log around the same time:
Dec  6 06:55:23 dms-out-01.int.payoff.com slapd[118]: conn=-1 op=0: attribute "entryCSN" index delete failure
Dec  6 06:58:25 dms-out-01.int.payoff.com slapd[118]: connection_read(46): no connection!
Dec  6 07:00:23 dms-out-01.int.payoff.com slapd[118]: connection_read(48): no connection!
Dec  6 07:27:34 dms-out-01.int.payoff.com slapd[118]: connection_read(47): no connection!
Dec  6 07:56:30 dms-out-01.int.payoff.com slapd[118]: connection_read(47): no connection!
Dec  6 08:10:24 dms-out-01.int.payoff.com slapd[118]: => bdb_idl_delete_key: c_get failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30994)
Dec  6 08:10:24 dms-out-01.int.payoff.com slapd[118]: conn=-1 op=0: attribute "entryCSN" index delete failure
Dec  6 08:10:25 dms-out-01.int.payoff.com slapd[118]: => bdb_idl_delete_key: c_get failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30994)
Dec  6 08:10:25 dms-out-01.int.payoff.com slapd[118]: conn=-1 op=0: attribute "entryCSN" index delete failure
Dec  6 08:18:29 dms-out-01.int.payoff.com slapd[118]: connection_input: conn=12372 deferring operation: binding
Dec  6 08:18:55 dms-out-01.int.payoff.com slapd[118]: connection_input: conn=12373 deferring operation: binding
Dec  6 08:19:50 dms-out-01.int.payoff.com slapd[118]: connection_read(53): no connection!
Dec  6 08:27:16 dms-out-01.int.payoff.com slapd[118]: => bdb_idl_delete_key: c_get failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30994)
Dec  6 08:27:16 dms-out-01.int.payoff.com slapd[118]: conn=-1 op=0: attribute "entryCSN" index delete failure
Dec  6 09:08:00 dms-out-01.int.payoff.com slapd[118]: connection_input: conn=12871 deferring operation: binding
Dec  6 09:16:10 dms-out-01.int.payoff.com slapd[118]: connection_input: conn=12871 deferring operation: pending operations
The deadlock from what I can tell is a more of a warning from OpenLDAP, but it is a common pattern and occurring every few minutes.
Not much useful in slapconfig.log.
Any insights? Thanks so much.
~john