使用OpenDS有多糟糕，它没有积极维护，并且在 2010 年有最后一个补丁，并且在生产环境中需要 JDK6（它也已经过时）？（虽然在后端并没有直接暴露给最终用户） ）。
如果它已经存在，那么寻找替代品、运行集成测试等所需的时间和金钱通常是否值得？对于一般生产中的过时软件，采取此步骤的通用标准是什么？
今天我注意到我的 LDAP 服务器 (OpenDS) 在每个可用内核上消耗 100% 的 CPU。快速诊断显示我在 futex 锁定期间有很多 ETIMEDOUT。
我如何调试它以找出发生了什么以及如何修复它？
futex(0x7f7ecf9053a4, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1540779077, {1342114766, 309244206}, ffffffff) = -1 ETIMEDOUT (Connection timed out)
futex(0x7f7ecf9053d0, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7f7ecf9053a4, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1540779079, {1342114766, 309528293}, ffffffff) = -1 ETIMEDOUT (Connection timed out)
futex(0x7f7ecf9053d0, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7f7ecf9053a4, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1540779081, {1342114766, 309812186}, ffffffff) = -1 ETIMEDOUT (Connection timed out)
futex(0x7f7ecf9053d0, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7f7ecf9053a4, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1540779083, {1342114766, 310107537}, ffffffff) = -1 ETIMEDOUT (Connection timed out)
futex(0x7f7ecf9053d0, FUTEX_WAKE_PRIVATE, 1) = 0 …