欢迎光临
我的个人博客网站

记一次 .NET 某云采购平台API 挂死分析


一:背景

1. 讲故事

大概有两个月没写博客了,关注我的朋友应该知道我最近都把精力花在了星球,这两个月时间也陆陆续续的有朋友求助如何分析dump,有些朋友太客气了,给了大大的红包,哈哈😅,手里面也攒了10多个不同问题类型的dump,后续也会逐一将分析思路贡献出来。

这个dump是一位朋友大概一个月前提供给我的,由于wx里面求助的朋友比较多,一时也没找到相关截图,不得已破坏一下老规矩。😭😭😭

既然朋友说api接口无响应,呈现了hangon现象,从一些过往经验看,大概也只有三种情况。

  • 大量锁等待

  • 线程不够用

  • 死锁

有了这种先入为主的思想,那就上windbg说事呗。

二: windbg 分析

1. 有大量锁等待吗?

要想看是否锁等待,老规矩,看一下 同步块表

 0:000> !syncblk Index SyncBlock MonitorHeld Recursion Owning Thread Info  SyncBlock Owner ----------------------------- Total           1673 CCW             3 RCW             4 ComClassFactory 0 Free            397  

扑了个空,啥也没有,那就暴力看看所有的线程栈吧。

记一次 .NET 某云采购平台API 挂死分析

不看还好,一看吓一跳,有339个线程卡在了 System.Threading.Monitor.ObjWait(Boolean, Int32, System.Object) 处,不过转念一想,就算有339个线程卡在这里,真的会导致程序hangon吗? 也不一定,毕竟我看过有1000+的线程也不会卡死,只不过cpu爆高而已,接下来继续研判一下是不是线程不够用导致,可以从 线程池任务队列 上面入手。

2. 探究线程池队列

可以用 !tp 命令查看。

 0:000> !tp CPU utilization: 10% Worker Thread: Total: 328 Running: 328 Idle: 0 MaxLimit: 32767 MinLimit: 4 Work Request in Queue: 74     Unknown Function: 00007ffe91cc17d0  Context: 000001938b5d8d98     Unknown Function: 00007ffe91cc17d0  Context: 000001938b540238     Unknown Function: 00007ffe91cc17d0  Context: 000001938b5eec08     ...     Unknown Function: 00007ffe91cc17d0  Context: 0000019390552948     Unknown Function: 00007ffe91cc17d0  Context: 0000019390562398     Unknown Function: 00007ffe91cc17d0  Context: 0000019390555b30 -------------------------------------- Number of Timers: 0 -------------------------------------- Completion Port Thread:Total: 5 Free: 4 MaxFree: 8 CurrentLimit: 4 MaxLimit: 1000 MinLimit: 4  

从输出信息看,线程池中328个线程全部打满,工作队列中还有74位客人在等待,综合这两点信息就已经很清楚了,本次hangon是由于大量的客人到来超出了线程池的接待能力所致。

3. 接待能力真的不行吗?

这个标题我觉得很好,真的不行吗? 到底行不行,可以从两点入手:

  • 是不是代码写的烂?

  • qps是不是真的超出了接待能力?

要想找出答案,还得从那 339 个卡死的线程说起,仔细研究了下每一个线程的调用栈,大概卡死在这三个地方。

<1>. GetModel

 public static T GetModel<T, K>(string url, K content) { 	T result = default(T); 	HttpClientHandler httpClientHandler = new HttpClientHandler(); 	httpClientHandler.AutomaticDecompression = DecompressionMethods.GZip; 	HttpClientHandler handler = httpClientHandler; 	using (HttpClient httpClient = new HttpClient(handler)) 	{ 		string content2 = JsonConvert.SerializeObject((object)content); 		HttpContent httpContent = new StringContent(content2); 		httpContent.Headers.ContentType = new MediaTypeHeaderValue("application/json"); 		string mD5ByCrypt = Md5.GetMD5ByCrypt(ConfigurationManager.AppSettings["SsoToken"] + DateTime.Now.ToString("yyyyMMdd")); 		httpClient.DefaultRequestHeaders.Add("token", mD5ByCrypt); 		httpClient.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json")); 		HttpResponseMessage result2 = httpClient.PostAsync(url, httpContent).Result; 		if (result2.IsSuccessStatusCode) 		{ 			string result3 = result2.Content.ReadAsStringAsync().Result; 			return JsonConvert.DeserializeObject<T>(result3); 		} 		return result; 	} }  

<2>. Get

public static T Get<T>(string url, string serviceModuleName) { 	try 	{ 		T val3 = default(T); 		HttpClient httpClient = TryGetClient(serviceModuleName, true); 		using (HttpResponseMessage httpResponseMessage = httpClient.GetAsync(GetRelativeRquestUrl(url, serviceModuleName, true)).Result) 		{ 			if (httpResponseMessage.IsSuccessStatusCode) 			{ 				string result = httpResponseMessage.Content.ReadAsStringAsync().Result; 				if (!string.IsNullOrEmpty(result)) 				{ 					val3 = JsonConvert.DeserializeObject<T>(result); 				} 			} 		} 		T val4 = val3; 		val5 = val4; 		return val5; 	} 	catch (Exception exception) 	{ 		throw; 	} }  

<3>. GetStreamByApi

 public static Stream GetStreamByApi<T>(string url, T content) { 	Stream result = null; 	HttpClientHandler httpClientHandler = new HttpClientHandler(); 	httpClientHandler.AutomaticDecompression = DecompressionMethods.GZip; 	HttpClientHandler handler = httpClientHandler; 	using (HttpClient httpClient = new HttpClient(handler)) 	{ 		httpClient.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/octet-stream")); 		string content2 = JsonConvert.SerializeObject((object)content); 		HttpContent httpContent = new StringContent(content2); 		httpContent.Headers.ContentType = new MediaTypeHeaderValue("application/json"); 		HttpResponseMessage result2 = httpClient.PostAsync(url, httpContent).Result; 		if (result2.IsSuccessStatusCode) 		{ 			result = result2.Content.ReadAsStreamAsync().Result; 		} 		httpContent.Dispose(); 		return result; 	} }  

4. 寻找真相

上面我罗列的这三个方法的代码,不知道大家可看出什么问题了? 对,就是 异步方法同步化,这种写法本身就很低效,主要表现在2个方面。

  • 开闭线程本身就是一个相对耗费资源和低效的操作。

  • 频繁的线程调度给了cpu巨大的压力

而且这种写法在请求量比较小的情况下还看不出什么问题,一旦请求量稍大一些,马上就会遇到该dump的这种情况。

三:总结

综合来看这次hangon事故是由于开发人员 异步方法不会异步化 导致,改法很简单,进行纯异步化改造 (await,async),解放调用线程,充分利用驱动设备的能力。

这个dump也让我想起了 CLR Via C# 书中(P646,647) 在讲用 await,async 来改造 同步请求 的例子 。

记一次 .NET 某云采购平台API 挂死分析

我觉得这个dump就是该例子的最好佐证! 😄😄😄

更多高质量干货:参见我的 GitHub: dotnetfly

赞(0) 打赏
未经允许不得转载:张拓的天空 » 记一次 .NET 某云采购平台API 挂死分析
分享到: 更多 (0)

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

专业的IT技术经验分享 更专业 更方便

联系我们本站主机

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏