如果遇到了性能问题,在使用debug之前分析问题较为不错的一个工具就是perfmon.解决问题最好的方法是思考,这也是熊力大哥在其书中一直在强调的.
如果您的网站遇到下面的几种情形,那还是先看看perfmon里GC相关的东西吧:
- cpu占用高,内存占用不高.
- cpu和内存占用都比较高
- cpu和内存占用都不高,但是网站响应很慢
打开perfmon找到.NET CLR Memory后下面有好几个counter,从哪个开始看呢?
1) % Time in GC
这个值是说从上一次GC结束到当前这次GC的时间的百分比. 比如上次GC结束时经历了100w个循环,当前的GC消耗是50w个循环,这个计数器的值就是50%. 看perfmon的各个counter来推测究竟是什么问题,主要有两类情况,第一类需要看counter到变化趋势,第二类需要看到是counter到值.这里对待第2类情况引入阅读全文>
发表于 @ 2008年08月06日 01:41:00|评论(loading...)|收藏
刚才被它唬了一把,幸好后来意识到了.
在性能计数器里的.net clr memory下有个# gc handles计数器, 这个计数器的值相比其他的是比较特殊的. 关于gc的计数器,绝大多数都是在gc结束的时候值才改变,但是这个却不是这样的. 比如当我们通过托管代码去请求创建一个handle,这时候这个值就加1了. 但是出于性能的考虑.net对它没有interlocked这样机制,所以这个值可能会在多个线程的并发情况下发生改变. 所以这个值其实是不可靠的.
那么怎么找到一个可靠的值呢？用SOS吧,它提供的gchandles命令能够准确的返回你要的结果.原理很简单,它遍历handle table.
阅读全文>发表于 @ 2008年08月06日 01:40:00|评论(loading...)|收藏
前段时间项目遇到一些问题，抓了一个dump后拿回家里的机器上分析。按着方法一步一步走，走到!clrstack的时候，问题出现了——看不到托管环境下的method name。我觉得这这!clrstack看不到method name可真没什么作用了。随后请教了几个朋友，都说没碰到过着情况。
第二天去了公司先打开windbg，open这个dump，载入sos后先来一个~*e!clrstack。邪门，method name都出来了。
从操作系统，windbg版本，symbols等几个方面都下手分析了一下，未果。问人吧，问了一圈都没有解决。问了熊力，他说他可以看到，说明问题肯定不奇怪，而且肯定是某个细节的问题。挂虚拟机，测之，问题依旧，大悦，终于出问题了。
后来我把我公司机器上的sos和家里机器的sos拿过来比较，大小不一样，用!eeversion来看，版本号确实不一样。问题解决——选用合适的版本！
但是为什么出现这种情况呢？
发了email问tess，可惜的是tess大姐渡假期去了，但是庆幸的是Tom假期结束阅读全文>
发表于 @ 2008年08月06日 01:39:00|评论(loading...)|收藏
2008年01月14日
Internal .Net Framework Data Provider error 6阅读全文>
发表于 @ 2008年01月14日 13:28:00|评论(loading...)|收藏
2007年08月05日
IronRuby是Ruby语言在.net上的实现，该产品的负责人John Lam的博客在国内是不容易被访问到的，在联系了John后开始了其博客翻译的工作，如果您对Ruby语言和DLR感兴趣的话欢迎您的参与。在过去的几周里很高兴看到的许许多多对IronRuby的反映。阅读全文>
发表于 @ 2007年08月05日 11:47:00|评论(loading...)|收藏