我刚刚花了一天时间为 kyotodb 创建一个抽象层以从我的代码中删除全局锁，当我发现这scan_parallel并不是真正的并行时，我正忙着将我的算法移植到这个新的抽象层。它只最大化了一个核心——为了快乐，我在我的代码中陷入了一个十亿整数的倒计时自旋循环（我移植时是空的存根）来尝试模拟一些处理时间。仍然只有一个核心最大化。我需要搬到 berkley db 或 leveldb 吗？我认为kyotodb 是为了解决互联网规模问题：/。我一定是做错了什么或遗漏了一些问题。
top或iostat从未超过 100% / 25%（iostat 一个 CPU 最大值 = 1/核心数 * 100）：/ 在四核 i5 上。
source db 是 10gigs 的协议缓冲区编码数据 (treedb) 语料库，具有以下标志（从文档中获取）。
index_db.tune_options(TreeDB::TLINEAR | TreeDB::TCOMPRESS);
index_db.tune_buckets(1LL * 1000);
index_db.tune_defrag(8);
index_db.tune_page(32768);
编辑
请勿移除 IR TAG。在你挥动 detag 蝙蝠之前，请三思。
这是一个与 IR 相关的问题，它关于在线创建 GINORMOUS (40 gig +) 倒排文件，倒排索引是 IR 数据访问方法的基础，倒排索引创建具有独特的事务配置文件。通过删除 IR 标签，你剥夺了我使用数据库库创建如此大数据库文件的 IR 研究人员的智慧。