Dav*_*ers 1 mysql optimization benchmarking ruby-on-rails
在客户端站点的管理部分中有一个操作,例如Admin :: Analytics(我没有构建但必须维护),它通过执行几十个相当密集的数据库查询来编译站点使用情况分析.在编译分析报告时,此功能始终是应用程序性能的瓶颈.但是,最近瓶颈已经变得非常糟糕,当访问时,网站会突然停止并无限期挂起.直到昨天我才有理由在服务器上运行"top"命令,但这样做我意识到Admin :: Analytics#index导致mysqld在四核,生产VPS上以高达350 +%的CPU功率旋转.
我已经下载了生产数据的新副本和生产日志.但是,当我在开发盒上本地访问Admin :: Analytics#index时,在使用生产数据时,它会在大约10-12秒内加载(并且利用我的双核CPU的~150 +%),这很遗憾.我想在mysql设置中可能会有一个突然发挥作用的差异.此外,数据库的mysqldump现在是531 MB,28天前只有336 MB.无论如何,我没有VPS上的root访问权限,所以调整mysqld性能会很麻烦,我真的很想知道这个问题的确切原因.但是,生产日志不包含信息.关于查询; 他们只是报告这些请求的长度,
我想我可以尝试提高生产中的日志级别来征求信息.关于由Admin :: Analytics#index执行的数据库查询,但同时我害怕在生产中复制这种行为,因为我不想再调用我们的主机来重新启动mysqld!此操作在其控制器中包含单个数据库请求,并在其视图中嵌入了几十个预准备语句!
您将如何进行基准测试/诊断和优化/修复此操作？!
(旁白:显然我想用Google Analytics或类似的解决方案完全取代此功能,但我需要在继续之前解决此问题.)
我建议你看一下这篇文章:http: //axonflux.com/building-and-scaling-a-startup
特别是,query_reviewer和newrelic对我来说是一个救生员.