qq_39015563的博客

问题背景：bytes.Buffer grow panicpanic: runtime error: slice bounds out of range [:1024] with capacity 512goroutine 428529 [running]:bytes.(*Buffer).grow(0xc0001e86f0, 0x200, 0x0)#011/usr/local/go/src/bytes/buffer.go:148 +0x297bytes.(*Buffer).ReadFrom(0xc0

问题背景：基于golang 实现了一个自助化配置的通用命令任务管理模块，这样运营人员可以直接通过修改配置，完成 if do 的命令逻辑：当磁盘满时，做什么？当网卡down 时做什么；并且可以支持各类环境 和规则。确定僵尸进程问题：但是灰度后不久，命令执行报错： fork exec resource temporarily unavailable;进一步查看syslog 报错 fork rejected by pids controller in xxx.service,cat pid limits 查

mosn 中的context、变量 和 内存复用机制在梳理变量机制中，发现与context、对象复用等机制都有一定关联，而context是贯穿始终的关键，所以本来只想记录变量机制，结果对context、对象复用封装都进行了review：（review 相关经验：查看对外接口，传参和返回值；思考使用 环境，与什么有关；跳出细节，找一条线，思考：从 0 到 生命周期结束， 如何使用 以及怎么与接口关联；源码解析文档、issue、历史提交记录、单元测试使用用例；如果没有这个细节会怎么样？结合过往

开发功能对应的roadmaphttps://docs.google.com/spreadsheets/d/1fALompY9nKZNImOuxQw23xtMD-5rCBrXWziJZkj76bo/edit#gid=0主体架构以及性能优化系列http://www.uml.org.cn/wfw/201910224.asphttps://mp.weixin.qq.com/s?__biz=MzA4ODg0NDkzOA==&mid=2247487075&idx=1&sn=87627a1

问题现象：对于测试报告，我们一般应当包含：测试对比环境的软件架构、输入、可视化的对比结果、原因分析&总结从go 自带的profile 图 只能看出 如题所示，对于问题排查，我们从不吝啬更多信息 用于分析：结合 sys-cpu perf 以及 火焰图分析：可以得到更多的调用栈对比的两个软件 V1 有问题 、V2 没有问题。这里看出有问题的 是Read 场景：Read 触发的调度。我们的测试场景是代理和源站在同一个集群，确实会存在大量Read event 唤醒，但是线上 回源响应的数据

golang 变量名和import 名冲突问题

golang-runtime.systemstack 泄漏排查Fetching profile over HTTP from http://:9001/debug/pprof/heapSaved profile in /root/pprof/pprof.testStack.alloc_objects.alloc_space.inuse_objects.inuse_space.004.pb.gzFile: testStackType: inuse_spaceTime: Sep

该模型基于rocketmq 也可以扩展到其他类似任务处理。 使用策略模式 将任务管理 单独 抽出来一个模块。真实应用程序只需实现任务具体处理逻辑 返回成功失败/* Interface Commentimplement it at rocketexe*/type taskDealMsg interface {DealMsg(msgStruct InputMsg, msgDealCoun...