我们的 Mnesia DB 运行缓慢,我们认为它应该更快一些。
因此,我们需要对其进行分析并找出正在发生的事情。
有许多选项可以自我暗示:
- 运行 fprof 并查看时间在哪里
- 运行 cprof 看看哪些函数被调用了很多
然而,这些都是相当标准的性能监控风格工具。问题是我如何实际进行查询分析 - 哪些查询花费的时间最长。如果我们是 Oracle 或 MySQL 商店,我们只需运行一个查询分析器,它会返回需要很长时间才能运行的各种查询。这似乎不是 Mnesia 可用的工具。
所以问题是:
- 有哪些技术可以描述 Mnesia
- 有哪些工具可以用来描述 Mnesia - 我认为没有,但证明我错了 :)
- 你是如何分析你的查询和优化你的 mnesia 数据库安装的
根据讨论展开
fprof 作为分析工具的问题之一是它只告诉您正在查看的特定查询。所以 fprof 告诉我 X 很慢,我将其调低以加快速度。然后,低,看,操作 Y(足够快)现在变得很慢。所以我分析了 Y 并意识到让 Y 快的方法就是让 X 慢。所以我最终做了一系列双边权衡......
我真正需要的是一种管理多边权衡的方法。我现在记录了 2 个度量标准的实际用户活动负载,我可以重播这些活动。这些日志代表我想要优化的内容。
SQL 数据库上的“适当”查询分析器将能够分析 SQL 语句的结构,例如所有具有以下形式的语句:
SELECT [fieldset] FROM [table] WHERE {field = *parameter*}, {field = *parameter*}
并且说这种形式的 285 个查询平均需要 0.37 毫秒才能运行
他们神奇的答案是当它说:这种形式的 17 个查询运行了 6.34 秒并对表 X 进行了全表扫描,你应该在字段 Y 上放置一个索引
当我在一组具有代表性的用户活动上得到这样的结果集时,我就可以开始全面考虑权衡取舍 - 并设计一个测试模式。
测试模式将类似于:
- 活动 X 将使查询 A、C 和 C 更快,但查询 E 和 F 更慢
- 测试和测量
- 然后批准/不批准
我已经使用 Erlang 足够长的时间来“知道”没有像这样的查询分析器,我想知道其他人(他们一定有这个问题)是如何对 mnesia 优化的“原因”。