whoops本尊

MRE 该代码会导致以下问题 疑问点 代码的 58 行已经加锁了，为什么还是触发了 Data Race? 解决方法

背景: golang自带的json序列化和反序列化涉及到反射,在性能消耗方面有些严重。 采用esayjson来提高序列化和反序列化速度 ①安装 esayjson 首先采用go get 拉取easyjs

前提条件 redis版本 >= 4.0.0 1.RedisBloom  官方介绍地址 安装方式: 编译打包.so文件 修改redis的配置文件 【redis.conf】 2.TairHash 安装方式

借助wrk压测命令获取结果集: 借助wrk压测 post 接口 -t 线程数 -c 连接数 -d 持续时间 --latency 延迟 --timeout 超时时间 -s lua脚本内容 method

事情的起因是因为 自己之前的 记一次go项目协程泄露问题排查, 然后了解到了 goleak 这个项目，于是记录一下吧，方便之后写代码时可以提前预测。 首先准备环境 redis go redis可借助d

一、查看 go env 😶‍🌫️ （1）首先可以查看被排除的 Go 文件是否启用了条件编译，通常的形式为在文件的首行添加（以 Linux 为例）： // +build 会逐渐取代 //go:build

平时遇到的数据为了存储方便一般均是时间戳形式存储，而当用于分析时，为了看起来方便需要转换为标准格式。于是乎，找寻了转换时间戳的方法 首先第一步在时间戳这一列旁边新建一列，选中新建的这一列中第二行或者平

背景 日常维护的ADX项目突然发生了协程报警线。日常 goroutine 数量为 3k左右，而报警线为 8k，而CPU,延迟等观测指标正常，内存30% 左右了【正常20%】。行叭，是发生了协程泄露。

背景 日常维护的ADX项目，8G内存。某天内存使用率达到了 80%，触发了预警，考虑到平时内存使用也就是 20% 左右，因此八九不离十是发生了内存泄露。 排查思路 1、最近是否有影响系统稳定性的业务代