经常会碰到这样的场景,自测及单单点的测试时没有任何问题,但在并发环境或生产环境下有时出现没规律的异常.报错等情况.在代码中增加日志是其中一种解决方式:抓取指定异常时的dump,通过windbg也可以快速定位问题.       Procdump命令示例:procdump -ma -e 1 –f SqlException w3wp.exe 貌似ProcDump无法抓取Crash的dump文件,看来有时还得回归到windbg带的命令行---adplus adplus -crash -pn…

windbg简介 Windbg是在windows平台下,强大的用户态和内核态调试工具.相比较于Visual Studio,它是一个轻量级的调试工具,所谓轻量级指的是它的安装文件大小较小,但是其调试功能,却比VS更为强大.它的另外一个用途是可以用来分析dump数据.哈哈,这是我们最需要的,可以用来分析并发测试场景或生产环境的性能及稳定性问题.它能够通过dump文件轻松的定位到问题根源,学会使用它,将有效提升我们的问题解决能力和效率. windbg版本和符合表 不同版本的程序需要对应版本的抓取工具及…

在做产品的某个核心模块的性能优化时,发现压到100并发时应用服务器的CPU就飙升至90%以上,50并发以后TPS就基本定格在一个数值上.使用性能监视器收集应用服务器的数据,发现每秒的.NET CLR Exceptions数据特别高,且异常数量与CPU使用率的曲线呈正比例的关系. 并发测试的业务结果是正确的,LoadRunner也没有发现大量的错误,那么大量的内部异常从哪儿来的呢?使用windbg输出所有异常信息,查阅Log日志. 打开windbg,attach到指定进程,设置捕获异常并输出的命令…

此前遇到一个项目反馈系统宕机问题,摘要描述如下: 系统不定期出现卡死现象,在多个模块不同功能上都出现过,未发现与特定功能相关的明显规律: 当系统出现卡死现象时,新的用户无法登陆系统: 跟踪应用服务器,未发现资源不足的情况(CPU.内存使用正常) 数据库服务器资源占用也正常(CPU不高,也未发现死锁.SQL阻塞等情况) 在问题再次发生时,使用ProcDump联系抓取多个dump文件:procdump -ma -s 20 -n 3 w3wp.exe 使用windbg命令(!tp)查看线程池发现,10…

简单整理一个测试Demo,抓取dump并验证,步骤如下: Symbol File Path:SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols Procdump每20秒抓取一次,连续抓三个:procdump -ma -s 20 -n 3 TestCPU.exe Ctrl + D 打开刚才收集的dump文件: 加载sos,命令:.loadby sos clr 检查所有线程的堆栈:~* e!clrstack 查看线程阻塞:!syncbl…

http://blog.csdn.NET/ghj1976/article/details/27996095 典型的两个现实案例: 我们先看两个用Go做消息推送的案例实际处理能力. 360消息推送的数据: 16台机器,标配:24个硬件线程,64GB内存 Linux Kernel 2.6.32 x86_64 单机80万并发连接,load 0.2~0.4,CPU 总使用率 7%~10%,内存占用20GB (res) 目前接入的产品约1280万在线用户 2分钟一次GC,停顿2秒 (1.0.3 的 GC…

2014-06-25 Created By BaoXinjian…

ConcurrentHashMap 参考: http://www.cnblogs.com/chengxiao/p/6842045.html https://my.oschina.net/hosee/blog/639352 https://www.cnblogs.com/study-everyday/p/6430462.html JDK5中添加了新的concurrent包,相对同步容器而言,并发容器通过一些机制改进了并发性能.因为同步容器将所有对容器状态的访问都 串行化了,这样保证了线程的安全性,…

Fiddler fiddler是最强大最好用的Web调试工具之一,它能记录所有客户端和服务器的http和https请求,允许你监视,设置断点,甚至修改输入输出数据. 使用Fiddler无论对开发还是测试来说,在诊断分析问题时,都有很大的帮助. 下载地址:http://www.telerik.com/download/fiddler 工作原理和使用说明可参考:http://www.cnblogs.com/TankXiao/archive/2012/02/06/2337728.html 当然我们如果…

上一篇我们简单的对客户前端和数据库后端的性能问题进行了定位,如果排除了这两块,问题基本就确定在应用服务器上.但是我们往往对应用服务器,或者说应用程序的性能最陌生,一旦出现性能问题往往有无所适从的感觉,虽然我们的对应用程序的代码最熟悉. 原因有这么几项: 系统庞大.业务复杂时,如果从代码审查入手,主观性因素影响较大:如果在各处代码中增加log统计响应时间,很不方便.也不科学,且工作量很大: 自己维护的代码调用了其他模块的接口,无从下手:与其他模块同事交流时,描述复杂.沟通困难: Oracle环境不…