【性能诊断】七、并发场景的性能分析（windbg案例，线程阻塞）

简单整理一个测试Demo，抓取dump并验证，步骤如下：

  1. Symbol File Path：SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols
  2. Procdump每20秒抓取一次，连续抓三个：procdump -ma -s 20 -n 3 TestCPU.exe
  3. Ctrl + D 打开刚才收集的dump文件；
  4. 加载sos，命令：.loadby sos clr
  5. 检查所有线程的堆栈：~* e!clrstack
  6. 查看线程阻塞：!syncblk
  7. 查找具体的阻塞程序，问题解决。

时间： 2024-10-09 15:12:03

【性能诊断】七、并发场景的性能分析（windbg案例，线程阻塞）的相关文章

Golang适合高并发场景的原因分析

典型的两个现实案例: 我们先看两个用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 不给力,直接升级到 tip,再次吃螃蟹) 15亿个心跳包/天,占大多数. 京东云消息推送系统 (团队人数:4

PLSQL_性能优化效能跟踪工具SQL Trace分析（案例）

2014-06-25 BaoXinjian 一.摘要 SQL TRACE是Oracle提供的用于进行SQL跟踪的手段,是强有力的辅助诊断工具.在日常的数据库问题诊断和解决中,SQL TRACE是非常常用的方法.一般,一次跟踪可以分为以下几步:1.界定需要跟踪的目标范围,并使用适当的命令启用所需跟踪.2.经过一段时间后,停止跟踪.此时应该产生了一个跟踪结果文件.3.找到跟踪文件,并对其进行格式化,然后阅读或分析. 另文已介绍了其他的跟踪工具DBMS_PROFILER, Form Trace, Re

【性能诊断】六、并发场景的性能分析（windbg案例，大量的内部异常造成CPU飙升）

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

【性能诊断】九、并发场景的性能分析（windbg案例，Fist Chance Exception/Crash dump）

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

【性能诊断】八、并发场景的性能分析（windbg案例，连接泄露）

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

[转]Golang适合高并发场景的原因分析

来源: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

高并发场景下请求合并的实践

前言 项目中一般会请求第三方的接口,也会对外提供接口,可能是RPC,也可能是HTTP等方式.在对外提供接口时,有必要提供相应的批量接口,好的批量实现能够提升性能. 高并发场景中,调用批量接口相比调用非批量接口有更大的性能优势.但有时候,请求更多的是单个接口,不能够直接调用批量接口,如果这个接口是高频接口,对其做请求合并就很有必要了.比如电影网站的获取电影详情接口,APP的一次请求是单个接口调用,用户量少的时候请求也不多,完全没问题:但同一时刻往往有大量用户访问电影详情,是个高并发的高频接口,如果

【性能诊断】二、单功能场景的性能分析（fiddler、SQL Profiler）

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

【性能诊断】三、单功能场景的性能分析（RedGate Profiler）

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