我们的Mnesia DB运行缓慢,我们认为它应该更快一些。
所以我们需要分析它并找出正在发生的事情。
有一些备选方案表明它们自己:
然而,这两个工具都是相当标准的性能监视风格工具。问题是我如何实际进行查询分析--这些查询所花费的时间最长。如果我们是甲骨文或MySQL商店,我们只需运行一个查询分析器,它将返回需要很长时间才能运行的各种查询。这不是一个似乎可以用于Mnesia的工具。
所以问题是:
从讨论的角度展开
fprof作为分析工具的一个问题是,它只告诉您正在查看的特定查询。所以fprof告诉我X是慢的,我调整它来加速它。然后,低和看,操作Y(这是足够快)现在是狗慢。所以我分析了Y,并意识到使Y变快的方法是使X变慢。所以我最后做了一系列的双边交易.
我真正需要的是一种管理多边权衡的方法。我现在有2公制棚负载的实际用户活动记录,我可以重放。这些日志代表了我想要优化的内容。
SQL数据库上的“适当”查询分析器将能够分析SQL语句的结构,例如所有带有表单的语句:
SELECT [fieldset] FROM [table] WHERE {field = *parameter*}, {field = *parameter*}比如说,这个表单的285个查询平均运行了0.37ms
它们神奇的答案是:这个表单的17个查询运行了6.34s,并在表X上做了一个完整的表扫描,您应该在字段Y上添加一个索引。
当我在一组具有代表性的用户活动上有这样的结果集时,我就可以开始考虑在整个过程中的权衡,并设计一个测试模式。
测试模式如下所示:
我已经使用Erlang很久了,我知道没有这样的查询分析器,我想知道的是其他人(他们肯定有这个问题)关于mnesia优化的“原因”。
发布于 2009-12-08 03:18:57
我犹豫不决是因为我对Erlang或Mnesia不太了解,但我对性能调优了解很多,而且从目前的讨论来看,这听起来相当典型。
这些工具fprof等听起来就像大多数从gprof获得基本方法的工具,即检测函数、计数调用、采样程序计数器等。长期以来,很少有人有这种做法的检查地基。对于那些工具的用户来说,你的挫折感听起来很典型。
在此概述,有一种不太为人所知的方法。它是基于随机获取少量(10-20)程序状态的样本,并理解每个样本,而不是总结。通常,这意味着检查调用堆栈,但您也可能希望检查其他信息。有不同的方法可以做到这一点,但我只是在调试器中使用暂停按钮。我不是想得到精确的计时或调用计数。这些最多只是间接的线索。相反,我问每个样本“它在做什么,为什么?”如果我发现它在做一些特定的活动,比如执行X查询,在这里它为z寻找y类型的答案,并且它在多个样本上执行,那么它所做的样本的一部分是对它所做时间的一部分的粗略而可靠的估计。机会是很好的,它是我可以做一些事情,并得到一个良好的加速。
发布于 2009-12-13 20:45:22
迈克·邓拉维的建议让我想起了红虫,它允许你在生产系统中对调用进行采样。把它想象成一个易于使用的erlang:trace,它没有给你足够的绳子来悬挂你的生产系统。
使用类似的调用应该会为您提供大量堆栈跟踪,以确定从何处调用mnesia事务:
redbug:start(10000,100,{mnesia,transaction,[stack]}).但是,不可能获得这些跟踪的调用持续时间。
如果您已经将所有mnesia查找组织到导出api以执行它们的模块中,则还可以使用redbug来获得特定查询的呼叫频率。
https://stackoverflow.com/questions/1850191
复制相似问题