Orientdb GC 开销限制超出/内存不足错误和性能缓慢答案

【问题标题】：Orientdb GC overhead limit exceeded/out of memory error and slow performanceOrientdb GC 开销限制超出/内存不足错误和性能缓慢
【发布时间】：2016-11-07 15:53:35
【问题描述】：

我的 orientdb 数据库有大约 230 万条记录。我正在尝试使用语句查询所有重复记录（其中大约有 750,000 条）- SELECT FROM (select PROP1, PROP2, count(*) as c from vin_data group by PROP1 ) where c > 1。当我将限制设置为 200 左右时，查询大约需要 180 秒（我认为这很慢）。但是当我将限制设置为 750000 时，它给了我内存不足的错误。我的内存是 4GB，我设置了 Xms64m 和 Xmx3600m。我在 PROP1 和 PROP1+PROP2（复合）上设置了索引。我的问题是 - 4GB 内存足以容纳 230 万条记录的数据库吗？

【问题讨论】：

标签： mysql garbage-collection orientdb orientdb-2.1 orientdb2.2

【解决方案1】：

对于上面的查询，两个索引都没有价值，因为它们没有在GROUP BY 中使用。在没有任何“where”条件的情况下，将扫描整个类。您可以尝试通过在语句末尾添加 PARALLEL 关键字来优化它。如果你有多个核心，它应该会更快。

无论如何，随着即将发布的 v3.0 版本（仍处于 pre-alpha 阶段），新的 SQL 引擎已经投入了大量精力，像您这样的查询应该会更快。

【讨论】：

我明白了。感谢您的回复。不过，我出于不同的目的为我的班级编制了索引。那么，考虑到这种查询，230 万条记录占用 4GB 内存是正常的吗？我现在的目的是从我的数据库中删除重复项。您可能会建议任何可以加快查询速度的技巧？
顺便说一句，我在具有 24 GB 内存的系统上执行了查询，为 Xmx 分配了 20GB，在 8 个内核和 SSD 上并行化（如果重要的话）。我仍然超出了 GC 开销限制。我很确定这不正常。有什么故障排除建议吗？ v3.0 什么时候发布？
不幸的是 group by 和 order by 在 RAM 中工作。最终结果集中有多少条记录有超过 1 条记录分组？你能执行这个SELECT count(*) FROM (select PROP1, PROP2, count(*) as c from vin_data group by PROP1 ) where c > 1吗？
结果是 501417