如何使用python profile 工具工具来解决程序中的瓶颈

使用Chrome DevTools的Timeline和Profiles提高Web应用程序的性能 - zeromike - ITeye技术网站
博客分类:
我们都希望创建高性能的Web应用程序。由于我们的应用程序变得越来越复杂,我们可能想要支持丰富的画面以及理想的60帧/秒,这能保证我们的应用程序响应灵敏且生动流畅。
知道如何衡量和提高性能,是一个有用的技能,在这短短的文章中,我会带您简单回顾关于如何通过 Chrome DevTools的 和做到这一点。 看!这是一个美丽的GIF动画。这标志着这篇文章这里开始展开:)
Timeline工具栏提供了对于在装载你的Web应用的过程中,时间花费情况的概览,这些应用包括处理DOM事件, 页面布局渲染或者向屏幕绘制元素。
它可以让你深入得到三个层面的数据,来帮助你明白问什么你的应用很缓慢:事件, 框架和实时的内存用量。开始,浏览你的应用,并在DevTools中切换到Timeline工具栏。
默认情况下Timeline不会显示任何数据,但是你可以这样开始一个记录会话,打开你的应用并点击灰色圆圈?,它在工具栏的底部——使用Cmd/Ctrl+E 快捷键也能开始一个记录。
这个记录按钮会从灰色变成红色,而Timeline将开始从你的页面获取时间线(timeline)。在你的应用中完成一些操作,记录到一些数据之后,再一次点击按钮来停止记录。
请注意:会清除你现有的记录会话,以便开始一个新的会话。将会强迫V8完成一轮的垃圾回收,在调试中它很有用。将会对显示的详细信息进行过滤,只显示那些完成耗时超过15ms的记录。
接下来,我们着手检查一下记录的数据。对影响性能的成本要素按优先级排序。是JavaScript吗?还是渲染?我们先看一看Timeline Events 模式,它能帮助回答这些问题。
在这个模式中,Summary视图(在Timeline的顶部)显示了一些水平的栅栏,分别代表页面中的网络和HTML解析(蓝色),JavaScript(黄色),样式重计算和布局(紫色)以及绘画和合成(绿色)事件。重绘是浏览器事件,是为响应诸如窗口大小改变或者滚动之类的视觉变化而调用的。
CSS属性的修改会对样式重新进行计算,而布局事件(即重排)是由元素位置的改变引起的。别担心记不住这些,在Timeline面板下方有图例告诉你。
在Summary视图下面是Details视图,包含了某个会话被记录后,相关类别的记录的详细内容。
每一个记录在左侧有用于说明的标题,右侧是时间轴区域。鼠标移到一个记录之上,会显示更多的提示信息,其中包括从开始录制到结束的时间 - 这非常有用,有必要多关注一下,特别是其中的调用栈信息。
点击调用栈(Call Stack)或者气泡提示中的超链接,会跳转到相应的Javascript代码行。如果你发现一个浏览器时间花费了过多的时间(可以从详细的气泡提示中的‘Duration’知道),你也许会进一步去研究其原因。
回到记录列表,点击某个记录将其展开,可以看到更进一步的记录,描述了这个记录是由哪些事件组成的。
如果你只对某个特段的数据感兴趣,在Summary视图中通过点击和拖拽可以选择放大的区域。
改善帧率、动画及响应性能
Chrome把你的应用展示到屏幕上需要生成每一幅帧,而 可以让你可以深入到每一帧生成的内部细节。
作为平滑的体验,你看到的帧率最好一直保持在30-60fps,如果太低了,你的应用就会因为丢帧看上去
或者抖动。
在帧模式下,带阴影的竖条对应正在重计算样式、正在组合等等情况。每个竖条的透明区域对应于空闲时间,至少对于你的页面是空闲的。例如,假设第一帧用了15ms,下一帧用了30ms。通常每一帧都会按刷新率进行同步,这个例子中第二帧的渲染多花了15ms,导致第三帧错失了”真正“的硬件帧的时间,直接跳到下一帧的渲染。这样,第二帧的实际生效时间就加倍了。
正如Andrey Kosyakov
的博客中提到的,即使你的程序没有很多动画,帧的概念也是有用的,因为浏览器在处理输入事件时会生成重复动作的序列。如果你在一帧中留有足够的时间处理这些事件,就会使你的程序看上去有更好的响应性,这意味着更好的用户体验。
如果我们的目标是60fps, 那么最多有
去做所有的事情。这个时间并不多,所以尽可能从动画中挤出时间来提高性能还是很重要的。
让我们再次放大Summary视图,看一下那些不满足帧率的帧,你就会发现浏览器(以及程序的行为)对此的影响了。
举个例子,最近我们使用帧视图(以及事件视图)发现我们的程序有过多的图像解码,这是因为浏览器需要不断的实时的调整图片的大小。
作为替代方案,为图片预先准备好所有需要的尺寸,我们就避免了这些开销,从而达到60fps的目标,对于最终用户来说更为平滑。
相关提示:通过在Settings菜单打开Show FPS meter选项,你可以在DevTool中打开实时的FPS计数器。
这可以在程序的右上角显示一个仪表盘,像下面这样,这使得你可以在程序的帧率低于预期的时候看到直观的反馈。
注意在移动端,如同Paul在Breakpoint Ep 4
的那样,动画和帧率都与桌面上大不一样,可以差几个数量级。要达到更高的帧率要更困难一些,而像Timeline的帧模式这样的工具(通过
连接)可以帮你发现瓶颈所在。
检查耗时的绘制,是困难的
要想检查一段时间内的绘制(paint)是另一个挑战。如果你打算知道为什么某个特定的元素绘制的比较慢,你可以把DOM树中的部分元素设置成display:none将它们从布局/内容树中移除,并且设置visibility:hidden不让它们绘制。然后你可以用Timeline进行录制以便测量,看一下绘制时间,在强制重绘模式中可以观察(实验性的)绘制率(感谢Paul提供的窍门)。
减少内存使用与避免锯齿形曲线
你的应用有可能会遭受内存泄露问题,Memory 模式对于侦测这种问题的初期症状非常有用。
为使用这个功能,再花几分钟记录你与应用之间的交互,之后停止记录并检查。在 Summary 视图中,你会看到随着你在应用不同部分之间的跳转,这些动作引起的内存使用情况。其中既有内存使用的攀升,也有普通的垃圾回收发生。
浅蓝色的区域代表一个给定时间里,你的应用所使用的内存大小,而白色的区域是已经分配的内存总量。
如果你观察到Summary视图中有一个 ,这便是代表了应用的成本费用。例如,一个无参的 函数将带来垃圾,不管怎么说,你需要关注锯齿的陡峭度。如果它变得非常陡峭,说明你制造了太多的垃圾。
你可以进一步的在新的会话记录中,通过与应用之间的交互来测试这一点,空闲几分钟之后停止并再次查看结果。当应用处于空闲(或者你刚刚制造了许多垃圾),V8引擎会执行一系列的垃圾收集过程。如果在你空闲之后,内存似乎从没有真正的降下来,那么说明你创造了太多的垃圾。
通过几个周期的垃圾回收,理想情况下内存视图的轮廓应该是扁平的。如果在两个GC周期间隔中它持续不断的上升(你看到会说它是一个阶梯函数),那么你可能会发生内存泄漏。
在Memory模式Detail视图的左侧,你能发现三个选项:文档计数(Document count),DOM节点计数 (DOM node count)以及事件侦听计数 (Event listener count)。
DOM节点计数 图显示了保存在内存中的已创建DOM节点的数量(即尚有待垃圾回收的那些节点),而另外两个选项类似的显示了事件侦听与documents/iframe的实例数。要是你只想看特定的计数类型,可以在Details视图取消其它的选择以便将它们隐藏。
我们现在知道了有潜在内存泄漏的可能,但是我们应该定位它们的源头。我们可以使用另外的堆分析仪(Heap Profiler)功能,它就在Profiles面板中。
在确定使用什么性能分析工具(profile)之前,你要知道是什么导致程序的瓶颈,这一点很重要。例如,如果你看到在Timeline上有很多黄色的部分,那可能是脚本产生的问题,可以选择JavaScript CPU 分析工具。如果问题是CSS selector产生的,那就选择CSS Selector 分析工具。
对于我们的例子,我们打算使用堆的性能分析工具,因为我们关心的是 ,但是正如下面列出的建议,也可以选择其他的性能分析工具。
性能分析工具中,Take Heap Snapshot的选项可以让我们在怀疑点之前和之后获取内存的快照,得到当时程序中活动的Javascript对象(以及DOM节点)在内存中的分布。
要使用这个功能,点击‘Start’,重复你怀疑(出现你发现的那些信息的时刻)会引起内存泄露的动作,这时记录下第一个快照。 接下来点击record按钮 ? 来记录第二个快照,这次不需要与程序进行交互。
我们现在‘Heap Snapshots’下至少能看到两个快照,让我们比较一下它们。
在DevTools窗口的下方,可以看到‘Summary’下拉框,可以让你在可见的快照之间切换。Summary 视图适用于 DOM泄漏,而Comparison 视图擅长于发现 内存泄漏的原因。 选择Comparison ,然后点击‘Snapshot 2'。
现在你看到的信息是在profile之间创建的对象。信息的差集可以让你对比垃圾收集所删除的内存是否匹配上对象的创建所花费的内存。点击特定的构造函数可以在面板下面的对象的retaining tree视图看到更多信息。
我知道这可能看起来有点可怕,但请忍受一下。一个典型的应用场景是试图中发现一个你已经删除或者断开关联的一个DOM节点是否任然存在。一旦你发现了造成内存占用的代码,你就可以添加必要的代码来清除那么你不在需要的相关对象。
例如,在应用中我们发现一个我们已经卸载的HTMLImageElement元素任然存在。通过点击构造函数,同时一直向下分析,直到我们发现了那个任然包含了这个图片引用的Window(高亮的) ,现在我们知道了如何寻找那些不利于窗口对象的事件监听器。
衡量和提升你应用程序的性能会需要花费一点事件。不幸的是,到目前为止并没有一颗银弹能解决掉所有的问题。但是,DevTools中的Timeline和Profiles能帮助减轻你在发现这些主要问题时的痛苦。你在你的优化工作流中你可以尝试用这些工具,看它是否能帮助到你。
我们总是在寻找一些能提升他们易用性的一些方法,如果你有什么反馈的话,请在下面任意浏览,或者在 上面建立bug投票
zhangzhaoaaa
浏览: 612235 次
来自: 北京
this.mockMvc = webAppContextSet ...
Ajaxfileupload异步上传隐藏“选择提交”,不同浏览 ...
document.ready 是页面加载完成的时候执行的。wi ...
楼主你好,现在测试发现有个问题,modifyParameter ...温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!&&|&&
LOFTER精选
网易考拉推荐
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
阅读(1237)|
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
历史上的今天
在LOFTER的更多文章
loftPermalink:'',
id:'fks_',
blogTitle:'matlab中profile函数的优化处理方法',
blogAbstract:'matlab中profile函数的优化处理方法,具体如下:随着matlab功能的强大,matlab的用途越来越广泛。现在通过几篇文章与大家分享下,如何优化matlab程序。在讲如何优化matlab程序之前,有几点需要大家注意:',
blogTag:'profile,tic,toc',
blogUrl:'blog/static/',
isPublished:1,
istop:false,
modifyTime:4,
publishTime:0,
permalink:'blog/static/',
commentCount:0,
mainCommentCount:0,
recommendCount:0,
bsrk:-100,
publisherId:0,
recomBlogHome:false,
currentRecomBlog:false,
attachmentsFileIds:[],
groupInfo:{},
friendstatus:'none',
followstatus:'unFollow',
pubSucc:'',
visitorProvince:'',
visitorCity:'',
visitorNewUser:false,
postAddInfo:{},
mset:'000',
remindgoodnightblog:false,
isBlackVisitor:false,
isShowYodaoAd:true,
hostIntro:'',
hmcon:'0',
selfRecomBlogCount:'0',
lofter_single:''
{list a as x}
{if x.moveFrom=='wap'}
{elseif x.moveFrom=='iphone'}
{elseif x.moveFrom=='android'}
{elseif x.moveFrom=='mobile'}
${a.selfIntro|escape}{if great260}${suplement}{/if}
{list a as x}
推荐过这篇日志的人:
{list a as x}
{if !!b&&b.length>0}
他们还推荐了:
{list b as y}
转载记录:
{list d as x}
{list a as x}
{list a as x}
{list a as x}
{list a as x}
{if x_index>4}{break}{/if}
${fn2(x.publishTime,'yyyy-MM-dd HH:mm:ss')}
{list a as x}
{if !!(blogDetail.preBlogPermalink)}
{if !!(blogDetail.nextBlogPermalink)}
{list a as x}
{if defined('newslist')&&newslist.length>0}
{list newslist as x}
{if x_index>7}{break}{/if}
{list a as x}
{var first_option =}
{list x.voteDetailList as voteToOption}
{if voteToOption==1}
{if first_option==false},{/if}&&“${b[voteToOption_index]}”&&
{if (x.role!="-1") },“我是${c[x.role]}”&&{/if}
&&&&&&&&${fn1(x.voteTime)}
{if x.userName==''}{/if}
网易公司版权所有&&
{list x.l as y}
{if defined('wl')}
{list wl as x}{/list}查看xdebug profile文件的几个程序- php编程_php教程 黑帽网
&>&&>&&>& > 正文
查看xdebug profile文件的几个程序
在优化php代码执行效率过程中,有个好办法是利用xdebug生成profile文件,然后查看整个程序的瓶颈在哪里。现在xdebug profile的查看程序有好几个,在这里罗列一下.WincachegrindWincachegrind是windows下的profile查看程序,使用起来感觉还不错,profile文件太大的话偶尔会崩溃。今天在高春辉的博客上看到这些:最近又开始拿 Xdebug 和 wincachegrind 对项目的 PHP 代码进行分析和优化,但是发现和自己输出的执行时间总是相差十倍,差的不是零头,而是十倍。上网搜索了一下,原来在 Xdebug 2.0.0RC4 版本开始,对 profiler 日志中的时间单位进行了修改。(&Use & seconds instead of a tenths of & seconds to avoid confusion in profile information. &)而 wincachegrind 又不再升级维护了,所以凡是用 2.0.0RC4 以及之后版本的 Xdebug 输出的 profiler 日志用 wincachegrind 来分析的话,都会有十倍的时间差距。他已经提供了hack后的版本,可以解决时间差距的问题,有兴趣的同学可以试试。CachegrindVisualizerCachegrindVisualizer是一个xdebug的profile文件查看客户端,采用Adobe的AIR制作。更详细的介绍可以看以前写的关于CachegrindVisualizer的介绍。KcachegrindKcachegrind是linux下的一个图形化profile查看工具,功能很强劲。Callgrind uses runtime instrumentation via the Valgrind framework for its cache simulation and call-graph generation. This way, even shared libraries and dynamically opened plugins can be profiled. The data files generated by Callgrind can be loaded into KCachegrind for browsing the performance results.webgrindwebgrind和wincachegrind的功能差不多,但是webgrind是基于web的,采用php写的查看工具。看了一下代码,跑在linux的服务器比较好。Webgrind is an Xdebug profiling web frontend in PHP5. It implements only a minimal subset of the features of kcachegrind, but installs in seconds and works on all platforms. For quick&n'dirty optimizations it does the job.下面是用webgrind查看phpmyadmin的profile抓图:
您对本文章有什么意见或着疑问吗?请到您的关注和建议是我们前行的参考和动力&&MySQL性能分析工具profile使用教程
来源:易贤网&& 阅读:389 次&&日期:
温馨提示:易贤网小编为您整理了“MySQL性能分析工具profile使用教程”,方便广大网友查阅!
分析SQL执行带来的开销是优化SQL的重要手段。在MySQL数据库中,可以通过配置profiling参数来启用SQL剖析。该参数可以在全局和session级别来设置。对于全局级别则作用于整个MySQL实例,而session级别紧影响当前session。该参数开启后,后续执行的SQL语句都将记录其资源开销,诸如IO,上下文切换,CPU,Memory等等。根据这些开销进一步分析当前SQL瓶颈从而进行优化与调整。本文描述了如何使用MySQL profile,不涉及具体的样例分析。
1、有关profile的描述
--当前版本
]& show variables like 'version';
+---------------+---------------------------------------+
| Variable_name | Value |
+---------------+---------------------------------------+
| version | 5.6.17-enterprise-commercial-advanced |
+---------------+---------------------------------------+
--查看profiling系统变量
]& show variables like '%profil%';
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| have_profiling | YES | --只读变量,用于控制是否由系统变量开启或禁用profiling
| profiling | OFF | --开启SQL语句剖析功能
| profiling_history_size | 15 | --设置保留profiling的数目,缺省为15,范围为0至100,为0时将禁用profiling
+------------------------+-------+
profiling [539]
If set to 0 or OFF (the default), statement profiling is disabled. If set to 1 or ON, statement prof
is enabled and the SHOW PROFILE and SHOW PROFILES statements provide access to prof
information. See Section 13.7.5.32, “SHOW PROFILES Syntax”.
This variable is deprecated in MySQL 5.6.8 and will be removed in a future MySQL release.
profiling_history_size [539]
The number of statements for which to maintain profiling information if profiling [539] is
enabled. The default value is 15. The maximum value is 100. Setting the value to 0 effectively
disables profiling. See Section 13.7.5.32, “SHOW PROFILES Syntax”.
This variable is deprecated in MySQL 5.6.8 and will be removed in a future MySQL release.
--获取profile的帮助
Name: 'SHOW PROFILE'
Description:
SHOW PROFILE [type [, type] ... ]
[FOR QUERY n]
[LIMIT row_count [OFFSET offset]]
ALL --显示所有的开销信息
| BLOCK IO --显示块IO相关开销
| CONTEXT SWITCHES --上下文切换相关开销
| CPU --显示CPU相关开销信息
| IPC --显示发送和接收相关开销信息
| MEMORY --显示内存相关开销信息
| PAGE FAULTS --显示页面错误相关开销信息
| SOURCE --显示和Source_function,Source_file,Source_line相关的开销信息
| SWAPS --显示交换次数相关开销的信息
The SHOW PROFILE and SHOW PROFILES statements display profiling
information that indicates resource usage for statements executed
during the course of the current session.
*Note*: These statements are deprecated as of MySQL 5.6.7 and will be
removed in a future MySQL release. Use the Performance S
--上面描述从5.6.7开始该命令将会被移除,用Performance Schema instead代替
--在Oracle数据库中,是通过autotrace来剖析单条SQL并获取真实的执行计划以及其开销信息
2、开启porfiling
--启用session级别的profiling
]& set profiling=1;
Query OK, 0 rows affected, 1 warning (0.00 sec)
--验证修改后的结果
]& show variables like '%profil%';
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| have_profiling | YES |
| profiling | ON |
| profiling_history_size | 15 |
+------------------------+-------+
--发布SQL查询
]& select count(*)
+----------+
| count(*) |
+----------+
+----------+
--查看当前session所有已产生的profile
+----------+------------+--------------------------------+
| Query_ID | Duration | Query |
+----------+------------+--------------------------------+
| 1 | 0. | show variables like '%profil%' |
| 2 | 0. | select count(*) from customer |
+----------+------------+--------------------------------+
2 rows in set, 1 warning (0.01 sec)
--我们看到有2个warning,之前一个,现在一个
]& --下面的结果表明SHOW PROFILES将来会被Performance Schema替换掉
+---------+------+--------------------------------------------------------------------------------------------------------------+
| Level | Code | Message |
+---------+------+--------------------------------------------------------------------------------------------------------------+
| Warning | 1287 | 'SHOW PROFILES' is deprecated and will be removed in a future release. Please use Performance Schema instead |
+---------+------+--------------------------------------------------------------------------------------------------------------+
3、获取SQL语句的开销信息
--可以直接使用show profile来查看上一条SQL语句的开销信息
--注,show profile之类的语句不会被profiling,即自身不会产生Profiling
--我们下面的这个show profile查看的是show warnings产生的相应开销
+----------------+----------+
| Status | Duration |
+----------------+----------+
| starting | 0.000141 |
| query end | 0.000058 |
| closing tables | 0.000014 |
| freeing items | 0.001802 |
| cleaning up | 0.000272 |
+----------------+----------+
--如下面的查询show warnings被添加到profiles
+----------+------------+--------------------------------+
| Query_ID | Duration | Query |
+----------+------------+--------------------------------+
| 1 | 0. | show variables like '%profil%' |
| 2 | 0. | select count(*) from customer |
| 3 | 0. | show warnings |
+----------+------------+--------------------------------+
--获取指定查询的开销
]& show profile for query 2;
+----------------------+----------+
| Status | Duration |
+----------------------+----------+
| starting | 0.000148 |
| checking permissions | 0.000014 |
| Opening tables | 0.000047 |
| init | 0.000023 |
| System lock | 0.000035 |
| optimizing | 0.000012 |
| statistics | 0.000019 |
| preparing | 0.000014 |
| executing | 0.000006 |
| Sending data | 0.000990 |
| end | 0.000010 |
| query end | 0.000011 |
| closing tables | 0.000010 |
| freeing items | 0.000016 |
| cleaning up | 0.000029 |
+----------------------+----------+
--查看特定部分的开销,如下为CPU部分的开销
]& show profile cpu for query 2 ;
+----------------------+----------+----------+------------+
| Status | Duration | CPU_user | CPU_system |
+----------------------+----------+----------+------------+
| starting | 0.000148 | 0.000000 | 0.000000 |
| checking permissions | 0.000014 | 0.000000 | 0.000000 |
| Opening tables | 0.000047 | 0.000000 | 0.000000 |
| init | 0.000023 | 0.000000 | 0.000000 |
| System lock | 0.000035 | 0.000000 | 0.000000 |
| optimizing | 0.000012 | 0.000000 | 0.000000 |
| statistics | 0.000019 | 0.000000 | 0.000000 |
| preparing | 0.000014 | 0.000000 | 0.000000 |
| executing | 0.000006 | 0.000000 | 0.000000 |
| Sending data | 0.000990 | 0.001000 | 0.000000 |
| end | 0.000010 | 0.000000 | 0.000000 |
| query end | 0.000011 | 0.000000 | 0.000000 |
| closing tables | 0.000010 | 0.000000 | 0.000000 |
| freeing items | 0.000016 | 0.000000 | 0.000000 |
| cleaning up | 0.000029 | 0.000000 | 0.000000 |
+----------------------+----------+----------+------------+
--如下为MEMORY部分的开销
]& show profile memory for query 2 ;
+----------------------+----------+
| Status | Duration |
+----------------------+----------+
| starting | 0.000148 |
| checking permissions | 0.000014 |
| Opening tables | 0.000047 |
| init | 0.000023 |
| System lock | 0.000035 |
| optimizing | 0.000012 |
| statistics | 0.000019 |
| preparing | 0.000014 |
| executing | 0.000006 |
| Sending data | 0.000990 |
| end | 0.000010 |
| query end | 0.000011 |
| closing tables | 0.000010 |
| freeing items | 0.000016 |
| cleaning up | 0.000029 |
+----------------------+----------+
--同时查看不同资源开销
]& show profile block io,cpu for query 2;
+----------------------+----------+----------+------------+--------------+---------------+
| Status | Duration | CPU_user | CPU_system | Block_ops_in | Block_ops_out |
+----------------------+----------+----------+------------+--------------+---------------+
| starting | 0.000148 | 0.000000 | 0.000000 | 0 | 0 |
| checking permissions | 0.000014 | 0.000000 | 0.000000 | 0 | 0 |
| Opening tables | 0.000047 | 0.000000 | 0.000000 | 0 | 0 |
| init | 0.000023 | 0.000000 | 0.000000 | 0 | 0 |
| System lock | 0.000035 | 0.000000 | 0.000000 | 0 | 0 |
| optimizing | 0.000012 | 0.000000 | 0.000000 | 0 | 0 |
| statistics | 0.000019 | 0.000000 | 0.000000 | 0 | 0 |
| preparing | 0.000014 | 0.000000 | 0.000000 | 0 | 0 |
| executing | 0.000006 | 0.000000 | 0.000000 | 0 | 0 |
| Sending data | 0.000990 | 0.001000 | 0.000000 | 0 | 0 |
| end | 0.000010 | 0.000000 | 0.000000 | 0 | 0 |
| query end | 0.000011 | 0.000000 | 0.000000 | 0 | 0 |
| closing tables | 0.000010 | 0.000000 | 0.000000 | 0 | 0 |
| freeing items | 0.000016 | 0.000000 | 0.000000 | 0 | 0 |
| cleaning up | 0.000029 | 0.000000 | 0.000000 | 0 | 0 |
+----------------------+----------+----------+------------+--------------+---------------+
--下面的SQL语句用于查询query_id为2的SQL开销,且按最大耗用时间倒序排列
]& set @query_id=2;
]& SELECT STATE, SUM(DURATION) AS Total_R,
-& 100 * SUM(DURATION) /
-& (SELECT SUM(DURATION)
-& FROM INFORMATION_SCHEMA.PROFILING
-& WHERE QUERY_ID = @query_id
-& ), 2) AS Pct_R,
-& COUNT(*) AS Calls,
-& SUM(DURATION) / COUNT(*) AS "R/Call"
-& FROM INFORMATION_SCHEMA.PROFILING
-& WHERE QUERY_ID = @query_id
-& GROUP BY STATE
-& ORDER BY Total_R DESC;
+----------------------+----------+-------+-------+--------------+
| STATE | Total_R | Pct_R | Calls | R/Call |
+----------------------+----------+-------+-------+--------------+
| Sending data | 0.000990 | 71.53 | 1 | 0. |--最大耗用时间部分为发送数据
| starting | 0.000148 | 10.69 | 1 | 0. |
| Opening tables | 0.000047 | 3.40 | 1 | 0. |
| System lock | 0.000035 | 2.53 | 1 | 0. |
| cleaning up | 0.000029 | 2.10 | 1 | 0. |
| init | 0.000023 | 1.66 | 1 | 0. |
| statistics | 0.000019 | 1.37 | 1 | 0. |
| freeing items | 0.000016 | 1.16 | 1 | 0. |
| preparing | 0.000014 | 1.01 | 1 | 0. |
| checking permissions | 0.000014 | 1.01 | 1 | 0. |
| optimizing | 0.000012 | 0.87 | 1 | 0. |
| query end | 0.000011 | 0.79 | 1 | 0. |
| end | 0.000010 | 0.72 | 1 | 0. |
| closing tables | 0.000010 | 0.72 | 1 | 0. |
| executing | 0.000006 | 0.43 | 1 | 0. |
+----------------------+----------+-------+-------+--------------+
--开启profiling后,我们可以通过show profile等方式查看,其实质是这些开销信息被记录到information_schema.profiling表
--如下面的查询,部分信息省略
]& select * from profiling limit 3,3\G;
*************************** 1. row ***************************
QUERY_ID: 1
STATE: init
DURATION: 0.000020
CPU_USER: 0.000000
CPU_SYSTEM: 0.000000
CONTEXT_VOLUNTARY: 0
CONTEXT_INVOLUNTARY: 0
BLOCK_OPS_IN: 0
BLOCK_OPS_OUT: 0
MESSAGES_SENT: 0
MESSAGES_RECEIVED: 0
PAGE_FAULTS_MAJOR: 0
PAGE_FAULTS_MINOR: 0
SOURCE_FUNCTION: mysql_prepare_select
SOURCE_FILE: sql_select.cc
SOURCE_LINE: 1050
--停止profile,可以设置profiling参数,或者在session退出之后,profiling会被自动关闭
]& set profiling=
Query OK, 0 rows affected, 1 warning (0.00 sec)
更多信息请查看
更多信息请查看
【】&&&&&【点此处查询各地各类考试咨询QQ号码及交流群】
易贤网手机网站地址:
由于各方面情况的不断调整与变化,易贤网提供的所有考试信息和咨询回复仅供参考,敬请考生以权威部门公布的正式信息和咨询为准!
相关阅读 & & &
&nbsp&nbsp&nbsp &nbsp&nbsp&nbsp会员注册
本站不参与评论!()
自觉遵守:爱国、守法、自律、真实、文明的原则
尊重网上道德,遵守中华人民共和国各项有关法律法规
严禁发表危害国家安全,破坏民族团结、国家宗教政策和社会稳定,含侮辱、诽谤、教唆、淫秽等内容的评论
承担一切因您的行为而直接或间接导致的民事或刑事法律责任
您在本站发表的评论,本站有权保留、转载、引用或者删除
参与本评论即表明您已经阅读并接受上述条款}

我要回帖

更多关于 生产瓶颈及解决策略 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信