标签: 性能排查 - 文章列表
共 2 页 · 清除标签筛选
-
Go报错fatal error: concurrent map read and map write的排查与解决方法(go run -race定位、sync.RWMutex与sync.Map选型)
map并发读写触发的不是普通panic,defer里的recover拦不住它,进程直接退出。这篇把整条排查链路写清楚:从hashWriting标志位说明为什么recover无效,到用go run -race与go test -race复现定位,再到Windows下mingw-w64版本不足导致-race编不过的处理办法,最后给出sync.Mutex、sync.RWMutex、sync.Map与channel四种写法的取舍,以及struct内嵌map、range期间写入这类容易被漏掉的并发入口。
-
PostgreSQL慢查询定位与索引失效的排查方法(pg_stat_statements抓取、EXPLAIN ANALYZE看执行计划与索引不命中的常见写法)
接口越用越慢却查不出原因时,先把SQL抓出来再看执行计划。文章讲pg_stat_statements的安装与排序查法、log_min_duration_statement与auto_explain的配置、EXPLAIN ANALYZE的三处读法,以及函数包裹列、隐式类型转换、前导模糊、复合索引前导列缺失这些让索引失效的写法,还有random_page_cost与统计信息过期的处理。
-
Java报错java.lang.OutOfMemoryError: Java heap space的排查方法(jmap与jcmd导出堆快照、MAT定位泄漏点与-Xmx调整)
Java heap space只说明堆分配不下了,谁占着堆要看堆快照。用-XX:+HeapDumpOnOutOfMemoryError留现场,jcmd与jstat判断是泄漏还是-Xmx给小了,再用MAT的Dominator Tree追引用链,顺带说清容器里UseContainerSupport与OOMKilled的关系。
-
Nginx报错502 Bad Gateway的排查方法(connect() failed与upstream prematurely closed connection定位、proxy_read_timeout与keepalive配置)
502 Bad Gateway基本都出在nginx与后端之间这一段。按error.log里的报错串分成四种情况定位:connect refused、upstream prematurely closed、upstream timed out、no live upstreams,再配keepalive与三个proxy超时参数,附上ss、curl与文件描述符的检查命令。
-
Java进程CPU占用过高的排查方法(top -H与jstack定位到具体代码行)
Java进程CPU打满时先分清us高还是sy高,再用top -Hp找出高CPU线程,把线程id转十六进制后到jstack输出里搜nid定位到具体代码行。文中包含连续三次抓栈对比、容器内jstack失效的两种原因、GC线程占高的判断方法,以及正则回溯、JSON序列化等常见代码原因。