search

cch123 / blog_comment

comments of xargin.com
8 stars 0 forks source link

为什么 Go 模块在下游服务抖动恢复后，CPU 占用无法恢复 #126

Open cch123 opened 5 years ago

cch123 commented 5 years ago

http://xargin.com/cpu-idle-cannot-recover-after-peak-load/

caibirdme commented 5 years ago

我们去年就发现了，连着压测几次，压测结果一次不如一次…最后换fasthttp了，创建g逻辑动不了，只能在应用层加判断了

tiancaiamao commented 5 years ago

给 Go 官方提 issue 吧，应该会处理的

cch123 commented 5 years ago

@tiancaiamao 给 Go 官方提 issue 吧，应该会处理的

提啦~ https://github.com/golang/go/issues/34457

choleraehyq commented 5 years ago

goroutine 池子大法好。我们基本上没有直接用裸的 go func(){} 了

cch123 commented 5 years ago

@choleraehyq ，我们这外部服务基本都是 sdk，要是别人在 sdk 里干坏事，挡不住哎

changkun commented 5 years ago

很有意思。似乎真正的元凶并非 checkdead。 checkdead 会在检查完 m 的数量后直接返回，很少能进入后续的 allgs 检查阶段，对其产生依赖的 sysmon 会保持相对轻量的性能；实际线程的状态也会在运行较为稳定的情况下不会发生太大变化。

相反真正会频繁对 allgs 进行扫描的只有 GC 的 gcResetMarkState。

cch123 commented 5 years ago

@changkun ，确实实际看 pprof 也是 gc 的成本高了些~

contestjia commented 4 years ago

这个在创建线程时不会checkdead吧，貌似是checkmcount

cch123 commented 4 years ago

@contestjia ，这里说的确实不严谨，当时看是 templateThread 进来会有一个检查，我简单改一下