记一次 .NET某酒店后台服务 卡死分析

net · 浏览次数 : 0

小编点评

**1. 线程池底层了解** 线程池底层是一个异步执行框架，用于执行并行任务。它使用 GateThread 和 Task 来管理线程的创建和调度。在 .NET Framework 时代，线程池内部会根据配置的线程数量动态调整线程数量，以满足应用程序的性能需求。 **2. GateThread 注入速度** GateThread 注入速度取决于线程池的配置和应用程序的负载。通常，在 .NET Framework 中，GateThread 注入速度约为 1-2 个线程每秒。 **3. 代码分析** 您提供的代码显示，每个 `Created` 事件之间延迟约 1 秒，这意味着每个 `GateThread` 注入一个新线程花费 1 秒的时间。这可能是由于线程池底层动态调整线程数量导致的，或可能是其他因素造成的。 **4. 解决方案** * 升级 .NET 版本到 .NET 8 或更高版本，该版本优化了线程池底层，可以提升 GateThread 注入的速度。 * 优化应用程序的性能，以减少线程创建所需的资源。 * 考虑使用异步编程框架，例如 Async.NET 或 Task.Run，这些框架允许您更灵活地控制线程创建和执行。

正文

一：背景

1. 讲故事

停了一个月没有更新文章了，主要是忙于写 C#内功修炼系列的PPT，现在基本上接近尾声，可以回头继续更新这段时间分析dump的一些事故报告，有朋友微信上找到我，说他们的系统出现了大量的http超时，程序不响应处理了，让我帮忙看下怎么回事，dump也抓到了。

二：WinDbg分析

1. 为什么会出现请求超时

既然超时说明server端不响应这个请求，继而达到了超时时间的一种异常情况，所以首先要想到的就是 线程池的健康度，可以用 !tp 命令观察，输出如下：


0:000> !tp
CPU utilization: 0%
Worker Thread: Total: 537 Running: 537 Idle: 0 MaxLimit: 32767 MinLimit: 12
Work Request in Queue: 82
    Unknown Function: 00007fff566a17d0  Context: 0000020f08cbd658
    Unknown Function: 00007fff566a17d0  Context: 0000020f09acfa80
    Unknown Function: 00007fff566a17d0  Context: 0000020f08702198
    Unknown Function: 00007fff566a17d0  Context: 0000020f09ad9068
    Unknown Function: 00007fff566a17d0  Context: 0000020f09abffe8
    Unknown Function: 00007fff566a17d0  Context: 0000020f093c9948
    Unknown Function: 00007fff566a17d0  Context: 0000020f093cfd28
    Unknown Function: 00007fff566a17d0  Context: 0000020f093d9358
    Unknown Function: 00007fff566a17d0  Context: 0000020f093c34e8
    Unknown Function: 00007fff566a17d0  Context: 0000020f093dc568
    ...
--------------------------------------
Number of Timers: 2
--------------------------------------
Completion Port Thread:Total: 2 Free: 2 MaxFree: 24 CurrentLimit: 2 MaxLimit: 1000 MinLimit: 12

从上面的卦象看异常非常明显，线程池总共有 537个工作线程都是处于运行状态，相信有经验的朋友应该一眼就知道是怎么回事，专业术语叫：线程饥饿，并且线程池队列也积压了 82个 待处理的任务。

2. 线程为什么会饥饿

线程饥饿的原因有更多，我特意问了下 chatgpt，列举如下：

  1. 优先级倾斜：如果某些线程的优先级设置过高，而其他线程的优先级设置过低，高优先级的线程可能会长时间占用CPU资源，导致低优先级线程无法获得执行机会。
  2. 死锁：当多个线程相互等待对方释放资源时，可能会导致死锁。在死锁情况下，所有线程都无法继续执行，从而导致线程饥饿。
  3. 资源竞争：多个线程竞争有限的资源（如共享内存、文件、网络连接等）时，可能会导致某些线程长时间无法获取到所需的资源而处于饥饿状态。
  4. 不公平的调度策略：调度器可能存在不公平的调度策略，导致某些线程无法获得公平的CPU时间片，从而长时间无法执行。
  5. 线程阻塞：某些线程可能由于等待I/O操作、锁或其他原因而被阻塞，如果阻塞时间过长，可能导致其他线程饥饿。
  6. 线程池配置不当：如果线程池中的线程数量设置不当，可能会导致某些任务长时间等待执行，从而引发线程饥饿。

那到底是哪一种情况呢？可以用 ~*e !clrstack 看一下各个线程此时正在做什么，输出如下：


0:000> ~*e !clrstack
...
OS Thread Id: 0x2924 (74)
        Child SP               IP Call Site
000000e0ef47dc30 00007fff60fd6974 [GCFrame: 000000e0ef47dc30] 
000000e0ef47dd58 00007fff60fd6974 [HelperMethodFrame_1OBJ: 000000e0ef47dd58] System.Threading.Monitor.ObjWait(Boolean, Int32, System.Object)
000000e0ef47de70 00007ffef33e7269 System.Threading.ManualResetEventSlim.Wait(Int32, System.Threading.CancellationToken)
000000e0ef47df00 00007ffef33e6b58 System.Threading.Tasks.Task.SpinThenBlockingWait(Int32, System.Threading.CancellationToken)
000000e0ef47df70 00007ffef33e69e1 System.Threading.Tasks.Task.InternalWait(Int32, System.Threading.CancellationToken)
000000e0ef47e040 00007ffef60cce33 System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task)
000000e0ef47e070 00007ffef9df2c73 Exceptionless.Submission.DefaultSubmissionClient.SendHeartbeat(System.String, Boolean, Exceptionless.ExceptionlessConfiguration)
000000e0ef47e110 00007ffef109f03f System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
000000e0ef47e1e0 00007ffef109e784 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
000000e0ef47e210 00007ffef15b670b System.Threading.TimerQueueTimer.CallCallback()
000000e0ef47e270 00007ffef15b644d System.Threading.TimerQueueTimer.Fire()
000000e0ef47e2e0 00007ffef15b5613 System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
000000e0ef47e320 00007ffef10b8319 System.Threading.ThreadPoolWorkQueue.Dispatch()
000000e0ef47e7a0 00007fff4fa06993 [DebuggerU2MCatchHandlerFrame: 000000e0ef47e7a0] 
000000e0ef47e908 00007fff4fa06993 [ContextTransitionFrame: 000000e0ef47e908] 
000000e0ef47eb40 00007fff4fa06993 [DebuggerU2MCatchHandlerFrame: 000000e0ef47eb40] 
...

发现有 473 个线程都在 Exceptionless.Submission.DefaultSubmissionClient.SendHeartbeat 方法上进行等待，这就有意思了，原来是开源的日志收集组件发送的心跳检测方法，接下来赶紧看一下这个方法的源码。


public void SendHeartbeat(string sessionIdOrUserId, bool closeSession, ExceptionlessConfiguration config)
{
	if (!config.IsValid)
	{
		return;
	}
	string requestUri = $"{GetHeartbeatServiceEndPoint(config)}/events/session/heartbeat?id={sessionIdOrUserId}&close={closeSession}";
	try
	{
		_client.Value.AddAuthorizationHeader(config.ApiKey);
		_client.Value.GetAsync(requestUri).ConfigureAwait(continueOnCapturedContext: false).GetAwaiter()
			.GetResult();
	}
	catch (Exception exception)
	{
		config.Resolver.GetLog().Error("Error submitting heartbeat: " + exception.GetMessage());
	}
}

从源码看，居然用同步的方式发送 http请求，在这异步方法满天飞的世界里，上面的写法实属异类。

3. 该如何解决呢？

既然是 Exceptionless 内部写的 SendHeartbeat 方法，我们程序员基本上无法干预，能做到的无非如下两点：

  • 升级框架

看下了用的还是超老的 4.3 版本，可以升级到目前最新的 6.0.4 观察试试。


[assembly: AssemblyTitle("Exceptionless")]
[assembly: AssemblyProduct("Exceptionless")]
[assembly: AssemblyCompany("Exceptionless")]
[assembly: AssemblyTrademark("Exceptionless")]
[assembly: AssemblyCopyright("Copyright (c) 2017 Exceptionless.  All rights reserved.")]
[assembly: AssemblyConfiguration("Release")]
[assembly: AssemblyFileVersion("4.3.2027.0")]
[assembly: AssemblyInformationalVersion("4.3.2027$(VERSION_SUFFIX) f8d73f2fd7")]
[assembly: TargetFramework(".NETFramework,Version=v4.5", FrameworkDisplayName = ".NET Framework 4.5")]
[assembly: AssemblyVersion("4.3.2027.0")]

  • 使用替代品，或者不用

哈哈，不用它，这是万能的治根之法。

三：对线程注入速度的解答

1. 朋友提了一个疑问

我现在知道这个 url 某个时段可能响应出了问题，但我线程池里的线程增速应该很快呀，多余的线程不是可以响应客户端请求吗？为什么我发现的情况是全部卡死呢？

2. 疑问的简单解答

这个问题其实是考察对线程池底层的了解，尤其是多久会向线程池注入一个活线程，在 .NET Framework 时代，在线程饥饿的情况下线程池内部的 GateThread线程 会 1s 注入一个活线程，那如何验证呢？ 我们观察后续的线程创建时间即可，使用 ~*e .ttime 。


0:000> ~*e .ttime
...
Created: Thu Nov 16 11:10:21.582 2023 (UTC + 8:00)
Kernel:  0 days 0:00:00.000
User:    0 days 0:00:00.000
Created: Thu Nov 16 11:10:22.593 2023 (UTC + 8:00)
Kernel:  0 days 0:00:00.000
User:    0 days 0:00:00.000
Created: Thu Nov 16 11:10:23.562 2023 (UTC + 8:00)
Kernel:  0 days 0:00:00.000
User:    0 days 0:00:00.000
Created: Thu Nov 16 11:10:24.062 2023 (UTC + 8:00)
Kernel:  0 days 0:00:00.000
User:    0 days 0:00:00.000
Created: Thu Nov 16 11:10:24.577 2023 (UTC + 8:00)
Kernel:  0 days 0:00:00.000
User:    0 days 0:00:00.000
Created: Thu Nov 16 11:10:25.562 2023 (UTC + 8:00)
Kernel:  0 days 0:00:00.000
User:    0 days 0:00:00.000
Created: Thu Nov 16 11:10:26.562 2023 (UTC + 8:00)
Kernel:  0 days 0:00:00.000
User:    0 days 0:00:00.015
Created: Thu Nov 16 11:10:27.562 2023 (UTC + 8:00)
Kernel:  0 days 0:00:00.000
User:    0 days 0:00:00.015
Created: Thu Nov 16 11:10:28.562 2023 (UTC + 8:00)
Kernel:  0 days 0:00:00.000
User:    0 days 0:00:00.015
Created: Thu Nov 16 11:10:29.577 2023 (UTC + 8:00)
Kernel:  0 days 0:00:00.000
User:    0 days 0:00:00.015
Created: Thu Nov 16 11:10:30.562 2023 (UTC + 8:00)
Kernel:  0 days 0:00:00.000
User:    0 days 0:00:00.000

从卦中的输出来看，每一个 Created 大概差 1s 钟，这也是 GateThread 的功劳，这种注入速度在 .NET8 中已经做了优化，比如上面这种情况，Task 内部会主动唤醒 GateThread 线程让其立即注入新线程，从而提升程序的响应速度。

四：总结

很多时候分析下来发现是 第三方组件 拖垮了程序，自己又没有太多的介入能力，真的很无奈，框架都用了那么久，现在看到了一只苍蝇，已是食之无味，弃之可惜。
图片名称

net

与记一次 .NET某酒店后台服务 卡死分析相似的内容：

记一次 .NET某酒店后台服务 卡死分析

一：背景 1. 讲故事 停了一个月没有更新文章了，主要是忙于写 C#内功修炼系列的PPT，现在基本上接近尾声，可以回头继续更新这段时间分析dump的一些事故报告，有朋友微信上找到我，说他们的系统出现了大量的http超时，程序不响应处理了，让我帮忙看下怎么回事，dump也抓到了。 二：WinDbg分析

net
0
记一次 .NET某账本软件 非托管泄露分析

一：背景 1. 讲故事 中秋国庆长假结束，哈哈，在老家拍了很多的短视频，有兴趣的可以上B站观看：https://space.bilibili.com/409524162 ，今天继续给大家分享各种奇奇怪怪的.NET生产事故，希望能帮助大家在未来的编程之路上少踩坑。 话不多说，这篇看一个.NET程序集泄

一次 net 账本 软件
0
记一次 .NET 某拍摄监控软件 卡死分析

一：背景 1. 讲故事 今天本来想写一篇 非托管泄露 的生产事故分析，但想着昨天就上了一篇非托管文章，连着写也没什么意思，换个口味吧，刚好前些天有位朋友也找到我，说他们的拍摄监控软件卡死了，让我帮忙分析下为什么会卡死，听到这种软件，让我不禁想起了前些天 在程序员桌子上安装监控 的新闻，参考如下： 我

一次 net 拍摄 监控
11
记一次 .NET某新能源MES系统 非托管泄露

一：背景 1. 讲故事 前些天有位朋友找到我，说他们的程序有内存泄露，跟着我的错题集也没找出是什么原因，刚好手头上有一个 7G+ 的 dump，让我帮忙看下是怎么回事，既然找到我了那就给他看看吧，不过他的微信头像有点像 二道贩子，不管到我这里是不是 三道，该分析的还得要分析呀。😄😄😄 二：Wi

一次 net 新能源 mes
289
记一次 .NET 某仪器测量系统 CPU爆高分析

一：背景 1. 讲故事 最近也挺奇怪，看到了两起 CPU 爆高的案例，且诱因也是一致的，觉得有一些代表性，合并分享出来帮助大家来避坑吧，闲话不多说，直接上 windbg 分析。 二：WinDbg 分析 1. CPU 真的爆高吗 这里要提醒一下，别人说爆高不一定真的就是爆高，我们一定要拿数据说话，可以

一次 net 仪器 测量
21
记一次 .NET 某企业OA后端服务 卡死分析

一：背景 1.讲故事 前段时间有位朋友微信找到我，说他生产机器上的 Console 服务看起来像是卡死了，也不生成日志，对方也收不到我的httpclient请求，不知道程序出现什么情况了，特来寻求帮助。 哈哈，一般来说卡死的情况在窗体程序（WinForm，WPF） 上特别多，在 Console，We

一次 net 企业 oa
3520
记一次 .NET 某娱乐聊天流平台 CPU 爆高分析

一：背景 1.讲故事 前段时间有位朋友加微信，说他的程序直接 CPU=100%，每次只能手工介入重启，让我帮忙看下到底怎么回事，哈哈，这种CPU打满的事故，程序员压力会非常大, 我让朋友在 CPU 高的时候抓 2 个 dump 下来，然后发给我分析。 二：WinDbg 分析 1. CPU 真的被打满

一次 net 娱乐 聊天
1377
记一次 .NET 某医疗器械 程序崩溃分析

一：背景 1.讲故事 前段时间有位朋友在微信上找到我，说他的程序偶发性崩溃，让我帮忙看下怎么回事，上面给的压力比较大，对于这种偶发性崩溃，比较好的办法就是利用 AEDebug 在程序崩溃的时候自动抽一管血出来，看看崩溃点是什么，其实我的系列文章中，关于崩溃类的dump比较少，刚好补一篇上来，话不多说

一次 net 医疗器械 程序
2538
记一次.NET某工控图片上传CPU爆高分析

一：背景 1.讲故事 今天给大家带来一个入门级的 CPU 爆高案例，前段时间有位朋友找到我，说他的程序间歇性的 CPU 爆高，不知道是啥情况，让我帮忙看下，既然找到我，那就用 WinDbg 看一下。 二：WinDbg 分析 1. CPU 真的爆高吗 其实我一直都在强调，要相信数据，口说无凭，一定要亲

一次 net 工控 图片
3722
记一次 .NET 某自动化采集软件 崩溃分析

一：背景 1.讲故事 前段时间有位朋友找到我，说他的程序在客户的机器上跑着跑着会出现偶发卡死，然后就崩掉了，但在本地怎么也没复现，dump也抓到了，让我帮忙看下到底怎么回事，其实崩溃类的dump也有简单的，也有非常复杂的，因为大多情况下都是非托管层面出现的各种故障，非常考验对 C, C++, Win

一次 net 自动化 采集
1443
# 热门排行
微软 New Bing AI 申请与使用保姆级教程（免魔法） ChatGPT API使用介绍 ChatGPT开发实战 一篇带你了解如何使用纯前端类Excel表格构建现金流量表 手把手教你玩转 Excel 数据透视表 为什么 C# 可能是最好的第一编程语言 .NET 入门到高级路线 提高工作效率的神器：基于前端表格实现Chrome Excel扩展插件 React + Springboot + Quartz，从0实现Excel报表自动化 用Echarts实现前端表格引用从属关系可视化
© PmDaddy. 2023 PmDaddy教程网 All rights reserved.