- BerkeleyDB 的 C++ 实现可以合理支持的最佳并发级别是多少？
- 在吞吐量因资源争用而开始受到影响之前，我可以在数据库上敲击多少线程？
我已经阅读了手册并且知道如何设置锁的数量、储物柜、数据库页面大小等，但我只是想从具有 BDB 并发实际经验的人那里得到一些建议。
我的应用程序非常简单，我将获取和放置每个大约 1KB 的记录。没有游标，没有删除。
问问题
2768 次
5 回答
15
这取决于您正在构建什么样的应用程序。创建一个有代表性的测试场景，然后开始尝试。然后你就会知道确定的答案。
除了您的用例之外，它还取决于 CPU、内存、前端总线、操作系统、缓存设置等。
说真的，只是测试你自己的场景。
如果您需要一些数字（这实际上在您的场景中可能没有任何意义）：
于 2008-08-03T12:34:36.060 回答
8
我非常同意 Daan 的观点：创建一个测试程序，并确保它访问数据的方式尽可能地模仿您期望应用程序具有的模式。这对于 BDB 非常重要，因为不同的访问模式会产生非常不同的吞吐量。
除此之外，这些是我发现对吞吐量有重大影响的一般因素：
访问方法（在你的情况下我猜是 BTREE）。
您配置 DBD 的持久性级别（例如，在我的情况下，“DB_TXN_WRITE_NOSYNC”环境标志将写入性能提高了一个数量级，但它会损害持久性）
工作集是否适合缓存？
读取次数与。写。
您的访问范围有多分散（请记住，BTREE 具有页面级锁定 - 因此使用不同线程访问不同页面是一个很大的优势）。
访问模式 - 意味着线程相互锁定甚至死锁的可能性有多大，以及您的死锁解决策略是什么（这可能是一个杀手）。
硬件（用于缓存的磁盘和内存）。
这相当于以下几点：扩展基于 DBD 的解决方案以提供更高的并发性有两种关键方法；要么尽量减少设计中的锁数量，要么添加更多硬件。
于 2008-10-13T21:59:37.117 回答
5
这不取决于硬件以及线程和东西的数量吗？
我会做一个简单的测试，并用越来越多的线程敲击来运行它，看看什么看起来最好。
于 2008-08-02T18:21:21.993 回答
3
在处理性能未知的数据库时，我所做的是测量我的查询的周转时间。我一直在增加线程数，直到周转时间下降，并降低线程数，直到周转时间得到改善（嗯，这是我环境中的进程，但无论如何）。
有移动平均线和各种指标，但从中得到的教训是：只要适应目前的情况即可。您永远不知道 DBA 何时会提高性能或硬件会升级，或者在您运行时可能会出现另一个进程来加载系统。所以适应。
哦，还有一件事：如果可以的话，避免流程切换 - 批量处理。
哦，我应该说清楚：这一切都发生在运行时，而不是在开发期间。
于 2008-08-04T07:45:38.717 回答
3
按照我的理解，Samba 创建tdb以允许任何特定数据库文件的“多个并发写入者”。因此，如果您的工作负载有多个编写器，您的性能可能会很差（例如，Samba 项目选择编写自己的系统，显然是因为它对 Berkeley DB 在这种情况下的性能不满意）。
另一方面，如果您的工作负载有很多读者，那么问题是您的操作系统如何处理多个读者。
于 2008-09-16T17:31:11.087 回答