临淄建设局网站网站设计合同模板

临淄建设局网站,网站设计合同模板,dw网站开发与设计实训总结,ppt设计网站有哪些一#xff1a;背景1. 讲故事上个月有位朋友找到我#xff0c;说他们公司的程序当内存达到一定阈值(2g)之后#xff0c;业务逻辑明显变慢导致下位机超时报警#xff0c;想让我看下到底怎么回事#xff0c;这种问题其实抓dump比较难搞#xff0c;但朋友也说了有一个增长阈值…一背景1. 讲故事上个月有位朋友找到我说他们公司的程序当内存达到一定阈值(2g)之后业务逻辑明显变慢导致下位机超时报警想让我看下到底怎么回事这种问题其实抓dump比较难搞但朋友也说了有一个增长阈值那就让朋友抓一个 2g 的dump发过来看看吧当然越大越好。二内存洞察分析1. 内存里都有什么高级调试就是一门侦查学需要根据发现到的多处零碎信息整合出一条合理可信的证据链先用 !address -summary 观察内存布局。0:000 !address -summary--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotalFree 648 7ff6475ce000 ( 127.962 TB) 99.97%unknown 1642 8a5283200 ( 34.581 GB) 88.93% 0.03%Heap 5255 0d170f000 ( 3.273 GB) 8.42% 0.00%Image 1922 02906ee00 ( 656.433 MB) 1.65% 0.00%Stack 277 010d40000 ( 269.250 MB) 0.68% 0.00%Other 61 008228000 ( 130.156 MB) 0.33% 0.00%TEB 92 0000b8000 ( 736.000 kB) 0.00% 0.00%PEB 1 000001000 ( 4.000 kB) 0.00% 0.00%--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotalMEM_FREE 648 7ff6475ce000 ( 127.962 TB) 99.97%MEM_RESERVE 3011 8d5107000 ( 35.329 GB) 90.86% 0.03%MEM_COMMIT 6239 0e391b000 ( 3.556 GB) 9.14% 0.00%...从卦中可以看到当前提交内存是 3.5G, 其中 heap 吃了 3.2G这就说明内存都被非托管给吃掉了接下来就是用老办法让朋友开启 ust再次抓到dump之后使用 !heap -s 观察NT堆的分布。0:000 !heap -s************************************************************************************************************************NT HEAP STATS BELOW************************************************************************************************************************NtGlobalFlag enables following debugging aids for new heaps:stack back tracesLFH Key : 0xfadda8b94efde698Termination on corruption : ENABLEDHeap Flags Reserv Commit Virt Free List UCR Virt Lock Fast(k) (k) (k) (k) length blocks cont. heap-------------------------------------------------------------------------------------00000160dead0000 08000002 939860 804212 939080 112851 4562 406 279 17556 LFHExternal fragmentation 14 % (4562 free blocks)Virtual address fragmentation 14 % (406 uncommited ranges)...000001608b690000 08001002 1845428 1058576 1844648 16053 2856 1243 0 1786 LFHVirtual address fragmentation 42 % (1243 uncommited ranges)...-------------------------------------------------------------------------------------从卦中可以看到 heap000001608b690000 这个堆吃了 1.8G抽了一些样本之后发现大多都是和 cogxsd 有关比如其中一张截图然后观察对应的托管方法。最后就是让朋友注意图片的分配方法 Allocate 的实现比如升级 cogxsd 之类的。2. 问题到此结束了吗接下来的几天朋友在这条路上没有闯出来毕竟他的程序需要批量实时的处理图片图片资源多是正常的也用了很多的手段但为什么会导致程序卡慢呢 其实也没有完整可信的证据链毕竟作为调试者一切都要让数据说话。问题没有弄出来所以我决定直击问题而不是在内存上纠结不清接下来就是让朋友在程序卡慢(下位机超时报警)的时候开启 perfview 跟踪观察下程序的整体情况朋友也是位动手能力强的能人三下五除二就弄出来了。3. perfview 里的真相托管程序里有一个术语叫 STW它是拖慢程序的一个很大的因素所以在卡慢期间跟踪下GC情况朋友跟踪了 12分钟接下来打开 perfview 选择 Memory - GCStats 选项卡截图如下从卦中可以看到跟踪期间程序触发了 7363 次GCfullgc 是 116次接下来观察这 7363 次GC的触发详情截图如下尼玛简直是晕倒所有的GC触发原因都是 InducedNotForced 即 诱导GC说简单点就是有人在故意调用 GC.Collect在调试训练营里面跟大家介绍过 gc 触发的18种原因其中 诱导GC 就是重中之重反正也是无语了。接下来切到 Event 事件选项卡观察 Triggered 的调用栈发现大量的和 Avl.Image 及 Avl.Region 的初始化有关截图如下接下来寻找 ProcessImageOne 方法的源码实现发现有不少这样的临时变量。Avl.ImageAvl.Region再回过头看下看托管堆上的 Avl.Image 和 Avl.Region 的数量分别是 3w 和 11W参考如下0:000 !dumpheap -statStatistics:MT Count TotalSize Class Name...00007ff890744ca8 32837 1313480 Avl.Image...00007ff89077b6f8 117356 4694240 Avl.RegionTotal 851246 objectsFragmented blocks larger than 0.5 MB:Addr Size Followed by0000016120b3eb70 0.6MB 0000016120bd7be8 Free到这里基本上整个证据链就串起来了当 Image 和 Region 达到一定阈值时GC触发的越来越频繁并附带着其中的 STW 越来越多导致程序越来越卡引发下位机超时报警。4. 如何解决这种问题的常规思路就是池化处理尽量减少临时 new Image 的发生导致内部的 GC 触发。三总结