谷歌网站管理员账号网站外部链接添加方式

当前位置： 首页 > news >正文

谷歌网站管理员账号,网站外部链接添加方式,图片展示网站模板,有哪个网站是成都中科大旗做的一#xff1a;背景

1. 讲故事 前几个月有位朋友找到我#xff0c;说他们的的web程序没有响应了#xff0c;而且监控发现线程数特别高#xff0c;内存也特别大#xff0c;让我帮忙看一下怎么回事#xff0c;现在回过头来几经波折#xff0c;回味价值太浓了。 二#…一背景
2. 讲故事 前几个月有位朋友找到我说他们的的web程序没有响应了而且监控发现线程数特别高内存也特别大让我帮忙看一下怎么回事现在回过头来几经波折回味价值太浓了。 二程序到底经历了什么
3. 在线程上找原因 这个程序内存高线程高无响应尼玛是一个复合态问题那怎么入手呢按经验推测大概率是由于高线程数引发的相信大家都知道每个线程都有自己的栈空间所以众人拾柴火焰高可以用 !address -summary 观察下线程栈空间。 0:000 !address -summary— Usage Summary —————- RgnCount ———– Total Size ——– %ofBusy %ofTotal Free 329 7df9d4b93000 ( 125.976 TB) 98.42% unknown 994 2052ae2e000 ( 2.020 TB) 99.81% 1.58% Stack 7215 0e0d00000 ( 3.513 GB) 0.17% 0.00% Heap 956 01695f000 ( 361.371 MB) 0.02% 0.00% Image 1468 007b34000 ( 123.203 MB) 0.01% 0.00% TEB 2405 0012ca000 ( 18.789 MB) 0.00% 0.00% Other 10 0001d1000 ( 1.816 MB) 0.00% 0.00% PEB 1 000001000 ( 4.000 kB) 0.00% 0.00% …— State Summary —————- RgnCount ———– Total Size ——– %ofBusy %ofTotal MEM_FREE 329 7df9d4b93000 ( 125.976 TB) 98.42% MEM_RESERVE 3132 203e925c000 ( 2.015 TB) 99.56% 1.57% MEM_COMMIT 9917 242201000 ( 9.033 GB) 0.44% 0.01% 从卦中可以清晰的看到提交内存是9G同时Stack吃掉了3.5G一般来说 Stack 不会有这么大所以此事必有妖在 TEB 中可以看到线程数高达 2405 个这个确实不少哈可以用 !t 做一个验证。 0:000 !t ThreadCount: 2423 UnstartedThread: 0 BackgroundThread: 2388 PendingThread: 0 DeadThread: 34 Hosted Runtime: noLock DBG ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception0 1 3344 00000032972B2D90 202a020 Preemptive 0000000000000000:0000000000000000 0000003297125a30 -00001 MTA 11 2 1d28 00000037A43B9140 2b220 Preemptive 000000364BC5AD90:000000364BC5C328 0000003297125a30 -00001 MTA (Finalizer) 12 5 2a00 00000037A52BF4D0 102a220 Preemptive 00000036527EBDE8:00000036527EDD90 0000003297125a30 -00001 MTA (Threadpool Worker) 13 7 3168 00000037A52C1B40 302b220 Preemptive 00000034D1136688:00000034D1137FD0 0000003297125a30 -00001 MTA (Threadpool Worker) 15 14 13b8 00000037A542EA50 202b220 Preemptive 00000036527EBCA8:00000036527EBD90 0000003297125a30 -00001 MTA … 有了这个入口点接下来观察每一个线程的线程栈使用 ~*e !clrstack发现有大量的线程在 PostMethod 方法中的 Task.Result 上等待看样子是在做网络请求这里做了一下提前截断截图如下 由于是知名券商这里就尽量模糊了哈。。。请见谅知道了在 Task.Result 上一下子就开心起来了自此也被误入歧途。。。。
4. 误入歧途 是上下文导致的吗 过往经验告诉我很多时候的 Task.Result 卡死是因为上下文的关系所致所以重点看下是不是 Asp.NET 的程序使用 !eeversion 观察便知。 0:000 !eeversion 6.0.422.16404 free 6,0,422,16404 Commit: be98e88c760526452df94ef452fff4602fb5bded Server mode with 8 gc heaps SOS Version: 7.0.8.30602 retail build 从卦中数据看当前是 .net6 写的程序就不存在上下文一说了这个情况可以排除只能继续寻找其他突破口。。。 下游处理过慢导致的吗 是不是下游处理过慢一个突破点就是观察下 线程池队列 是不是有任务积压这个可以用 !tp 观察下队列即可。 从卦中数据看当前队列无任何积压说明也不是下游处理过慢导致的我去太难了。。。 代理或者服务器有问题吗 既然无上下文无积压接下来只能怀疑是不是server方有问题或者用了什么代理软件要想找这个信息需要用 !dso 观察线程栈中的对象。 0:000 ~34s ntdll!NtWaitForMultipleObjects0xa: 00007ffe115c0cba c3 ret 0:034 !dso OS Thread Id: 0x1ef4 (34) RSP/REG Object Name 00000037B56AC688 000000351f9e4918 System.Threading.Thread 00000037B56AC700 0000003317bb6160 System.Net.Http.DiagnosticsHandler 00000037B56AC708 000000351f9e4918 System.Threading.Thread 00000037B56AC748 0000003617b743c8 System.Net.Http.HttpWindowsProxy … 00000037B56AD0D0 00000034c8283750 System.String http://xxx/Article/xxx 00000037B56ACF30 0000003317bb5ad8 System.Net.Http.HttpClient … 看了下卦中的请求地址http://xxx/Article/xxx 同时在 HttpWindowsProxy 和 HttpClient 中也没有看到所谓的代理IP这就陷入了迷茫。 事已至此只能怀疑是网络的问题让朋友在程序卡死的那个期间段用 wireshark 或者 tcpdump 去抓下包看看是不是网络出了问题tcp握手挥手怎么样事情也就这样不了了之了。
5. 迷途知返 前些天在给训练营的朋友准备课件时优化了一个例子来演示 线程池队列 的堆积情况结果意外发现 sos 吐出来的数据是假的尼妈如梦初醒分析dump已经够难了为什么 sos 还要欺骗我天真的塌下来了。。。 其实在分析 .net core 的dump时每每发现线程池队列都是 0 虽然有一丝奇怪但也不敢怀疑sos吐出来的数据权威性。 既然 sos 吐出来的数据是假的只能自己去线程池中把队列挖出来即 ThreadPoolWorkQueue.workItems 字段如下所示 0:034 !DumpObj /d 0000003517b9c1c0 Name: System.Threading.ThreadPoolWorkQueue MethodTable: 00007ffd8416d260 EEClass: 00007ffd84196ab8 Tracked Type: false Size: 168(0xa8) bytes File: C:\Program Files\dotnet\shared\Microsoft.NETCore.App\6.0.4\System.Private.CoreLib.dll Fields:MT Field Offset Type VT Attr Value Name 00007ffd83ddbf28 4000c61 18 System.Boolean 1 instance 0 loggingEnabled 00007ffd83ddbf28 4000c62 19 System.Boolean 1 instance 0 _dispatchTimeSensitiveWorkFirst 00007ffd8416dc78 4000c63 8 …Private.CoreLib]] 0 instance 0000003517b9c268 workItems 00007ffd8416e458 4000c64 10 …Private.CoreLib]] 0 instance 0000003517b9eea0 timeSensitiveWorkQueue 00007ffd8416d1f0 4000c65 20 …acheLineSeparated 1 instance 0000003517b9c1e0 _separated…0:034 !ext dcq 0000003517b9c268 System.Collections.Concurrent.ConcurrentQueueSystem.Object1 - dumpobj 0x00000032c93b7ce02 - dumpobj 0x00000032c93b8ae83 - dumpobj 0x00000032c93b98d8… 54346 - dumpobj 0x00000034d12fb2e8 54347 - dumpobj 0x0000003652805b40 ——————————————— 54347 items 从卦中数据看当前线程池堆积了 5.3w 的任务很显然是属于第二种情况即下游处理不及既然处理不急是不是遇到了什么高峰期呢这个可以用 .time 观察下当前时段。 从卦中数据看看样子是快到 收盘时间 了结合今年的大盘形式看样子是出现了暴跌股民们在发泄情绪哈哈。。。 找到了问题的根解决方案就比较多了。 做 PostMethod 请求的异步化不要用 Result 去硬等待。 尽量做批量化提交降低请求接口的单次时间。
   三总结 这次生产事故的分析峰回路转本来是一个很容易就能定位出的问题可我认为权威的sos居然吐出了假数据欺骗了我让我误入歧途浪费了很多的人力物力真的很无语。。。再也不相信 sos 了