MogDB/openGauss 故障排查思路

运维 数据库运维
当我们收到反馈说数据库响应慢或者压测过程中数据库有报错,第一步先收集数据库服务器资源使用情况,这一步是处理所有故障的前提。

[[425902]]

本文转载自微信公众号「数据和云」,作者高云龙。转载本文请联系数据和云公众号。

前提

当我们收到反馈说数据库响应慢或者压测过程中数据库有报错,第一步先收集数据库服务器资源使用情况,这一步是处理所有故障的前提。

  1. --负载 
  2. top 命令 
  3. htop 命令 
  4.  
  5. --cpu 
  6. lscpu 命令 
  7.  
  8. --内存大小 
  9. free -g 
  10.  
  11. --磁盘大小 
  12. df-Th  
  13.  
  14. --磁盘使用跟踪 
  15. nohup iostat -xmt 1 > iostat.log 2>&1 & 
  16.  
  17. --网络延时 
  18. 应用程序与数据库之间的网络延时,集群内主库与同步备库之间的网络延时 
  19. nohup ping 目标ip | awk '{ print $0"\t" strftime("%Y-%m-%d %H:%M:%S",systime())}' > ping.log 2>&1 & 

*模拟网络延时小知识*

模拟同城机房网络延迟在0.7ms ~ 0.9ms ;

添加网络延迟模拟:tc qdisc add dev enp23s0f1(网卡) root netem delay 0.8ms 0.1ms ;

删除网络延时模拟:tc qdisc dev dev enp23s0f1(网卡) root netem delay 0.8ms 0.1ms。

常见问题

一.Xlog目录磁盘空间不足

Xlog日志目录满的原因有以下几个:

  • 集群内有宕机的备节点,或者主备节点之间的网络不通;
  • 无效的复制槽未及时清理;
  • 开启归档,但归档失败;
  • Xlog保留数量过多。

备节点故障:

通过网络及数据库日志信息,判断节点故障原因,并尽快恢复主备节点之间的复制关系,当故障无法快速解决时,建议修改数据库参数来改变主库Xlog保留大小。

  1. enable_xlog_prune = on 
  2. max_size_for_xlog_prune:默认是2T,建议修改值为104857600 (100GB),或根据磁盘空间自行调整 

无效复制槽:

查看是否存在无效的复制槽导致Xlog清理不及时,需要将延时最大的复制槽删除。

  1. --查看复制槽 
  2. select slot_name,coalesce(plugin,'_'as plugin, 
  3.        slot_type,datoid,coalesce(database,'_'as database
  4.        active,coalesce(xmin,'_'as xmin, 
  5.        pg_size_pretty(pg_xlog_location_diff(CASE WHEN pg_is_in_recovery() THEN pg_last_xlog_receive_location() ELSE pg_current_xlog_location() END , restart_lsn))  AS retained_bytes 
  6. from pg_replication_slots; 
  7.  
  8. --清理复制槽 
  9. select pg_drop_replication_slot('slot_name'); 

归档失效:

先检查归档目录是否有归档日志,如果没有,需要查看数据库日志归档失效的原因。

Xlog参数不合理:

检查数据库Xlog保留参数值是否合理: wal_keep_segments。

二.CPU使用率高

除了数据库BUG、其他程序耗CPU高影响数据库外,绝大部分原因是SQL执行慢且并发量大引起。

  1. 1、当前正在执行的SQL汇总  
  2. select query,count(*) from pg_stat_activity group by query order by 2 desc limit 5; 
  3.  
  4. 2、查看SQL的执行计划 
  5. explain (analyze,costs,buffers,timing) QUERY  
  6.  
  7. 3、SQL涉及的表是否有表膨胀、索引失效或缺失或重复 的情况,这步可以处理80%的慢SQL 
  8.  
  9. --表结构 
  10. \d+ 表名 
  11.  
  12. --表及索引占空间大小 
  13. SELECT CURRENT_CATALOG AS datname,nsp.nspname,rel.relname, 
  14.         pg_size_pretty(pg_total_relation_size(rel.oid))       AS totalsize, 
  15.         pg_size_pretty(pg_relation_size(rel.oid))             AS relsize, 
  16.         pg_size_pretty(pg_indexes_size(rel.oid))              AS indexsize, 
  17.         pg_size_pretty(pg_total_relation_size(reltoastrelid)) AS toastsize 
  18. FROM pg_namespace nsp 
  19. JOIN pg_class rel ON nsp.oid = rel.relnamespace 
  20. WHERE nspname NOT IN ('pg_catalog''information_schema'AND rel.relkind = 'r' 
  21. order by pg_total_relation_size(rel.oid) desc 
  22. limit 20; 
  23.  
  24. --表膨胀 
  25. select schemaname,relname,n_live_tup,n_dead_tup, 
  26.     round((n_dead_tup::numeric/(case (n_dead_tup+n_live_tup) when 0 then 1 else (n_dead_tup+n_live_tup) end ) *100),2) as dead_rate 
  27. from pg_stat_user_tables 
  28. where n_live_tup > 0 and (n_dead_tup::numeric/(n_dead_tup+n_live_tup))>0 
  29. order by 5 desc limit 50; 
  30.  
  31. --索引使用率 
  32. select schemaname||'.'||relname tablename,schemaname||'.'||indexrelname indexname,idx_scan,idx_tup_read,idx_tup_fetch from pg_stat_user_indexes; 
  33.  
  34. --重复索引 
  35. SELECT pg_size_pretty(SUM(pg_relation_size(idx))::BIGINTAS SIZE
  36.        (array_agg(idx))[1] AS idx1, (array_agg(idx))[2] AS idx2, 
  37.        (array_agg(idx))[3] AS idx3, (array_agg(idx))[4] AS idx4 
  38. FROM ( 
  39.     SELECT indexrelid::regclass AS idx, (indrelid::text ||E'\n'|| indclass::text ||E'\n'|| indkey::text ||E'\n'||COALESCE(indexprs::text,'')||E'\n' || COALESCE(indpred::text,'')) AS KEY 
  40.     FROM pg_index) sub 
  41. GROUP BY KEY HAVING COUNT(*)>1 
  42. ORDER BY SUM(pg_relation_size(idx)) DESC
  43.  
  44. 4、根据执行计划判断SQL是否需要改写 

三.内存不足

①.查看服务器物理内存整体使用情况。

②.检查数据库内存参数设置是否合理:

  • max_process_memory 建议设置物理内存80%;
  • shared_buffers 建议设置为物理内存的40%。

数据库内存使用分布:

查看整体内存使用情况,当dynamic_used_memory 与 max_dynamic_memory 的值接近时说明动态内存可能不足,如果dynamic_peak_memory超过了max_dynamic_memory,说明曾经发生过OOM。

  1. select * from gs_total_memory_detail; 
  • 连接过多耗尽内存

主要排除是连接数过多导致内存不足的场景

  1. 查看连接数分布 
  2. select state,count(*) from pg_stat_activity group by state; 
  3.  
  4. 各状态连接占用总内存情况 
  5. select state,pg_size_pretty(sum(totalsize)) 
  6. from gs_session_memory_detail m,pg_stat_activity a  
  7. where substring_inner(sessid,position('.' in sessid)+1)=a.sessionid 
  8. group by state; 
  9.  
  10. 单会话占用内存排序 
  11. select sessid,pg_size_pretty(sum(totalsize)),pg_size_pretty(sum(freesize)) from gs_session_memory_detail group by sessid order by sum(totalsize) desc limit 10; 
  • 缓存机制

会话的缓存机制不合理,也会导致内存无法快速释放,可能与参数local_syscache_threshold有关系。

  1. 内存上下文使用内存分布 
  2. select contextname,pg_size_pretty(sum(totalsize)),pg_size_pretty(sum(freesize)) from gs_session_memory_detail group by contextname order by sum(totalsize) desc limit 10;动态内存高一般有以下几个原因: 

总结:

①.连接数过多会导致动态内存耗尽,

  • 如果是IDLE连接多,可能是开发端长连接保留数量不合理;
  • 如果是ACTIVE连接多,可能是硬件内存不足,需要扩内存。

②.单个会话占用内存多,需要根据SQL去分析占用内存情况。

关于作者

 

高云龙,云和恩墨服务总监。长期从事PG运维工作,目前在支持openGauss生态发展。

 

责任编辑:武晓燕 来源: 数据和云
相关推荐

2020-09-25 11:10:51

运维故障排查监控

2021-10-28 17:05:11

IT运维故障

2024-02-20 16:55:14

K8S云计算

2023-05-18 08:00:00

2020-07-08 10:36:18

Linux 运维 数据

2021-07-21 16:22:40

运维架构技术

2021-04-25 09:25:25

Linux手工排查

2010-08-30 19:51:08

DHCP故障

2021-04-19 08:02:54

Windows手工入侵

2010-10-14 13:55:24

无线故障排查

2010-09-27 13:25:39

无线信号

2022-04-18 09:07:54

Linux网络延迟

2019-12-09 10:40:15

YAMLBashKubernetes

2021-10-14 07:28:03

Kubernetes通用排查

2015-10-09 16:42:16

GDB 排查Python程序故障

2013-02-28 10:15:14

Ubuntu性能调优故障排查

2017-03-24 09:50:00

2013-05-06 16:36:55

SELinuxSELinux故障

2013-05-22 14:25:17

2022-02-25 11:16:51

故障运维Nginx
点赞
收藏

51CTO技术栈公众号