如何快速及时释放TIDB、TIKV占用内存

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】
服务器硬件:
10.160.60.18 Cpu 40核,256G内存,机械硬盘
10.160.60.19 Cpu 40核,256G内存,机械硬盘
10.160.60.20 Cpu 40核,256G内存,机械硬盘

【概述】 场景 + 问题概述
TIDB和TIKV,内存一直不断增长,其中TIDB特别严重,每次达到resource_control【memory_limit】阀值后,触发重启,每天至少重启1-2次,有无配置参数可以快速及时释放TIDB、TIKV占用内存

全局配置如下:

global:
  user: jhdcp
  ssh_port: 22
  ssh_type: builtin
  deploy_dir: /jhmk/tidb/tidb-deploy
  data_dir: /jhmk/tidb/tidb-data
  resource_control:
    memory_limit: 96G
  os: linux
  arch: amd64
monitored:
  node_exporter_port: 9100
  blackbox_exporter_port: 9115
  deploy_dir: /jhmk/tidb/tidb-deploy/monitor-9100
  data_dir: /jhmk/tidb/tidb-data/monitor-9100
  log_dir: /jhmk/tidb/tidb-deploy/monitor-9100/log
server_configs:
  tidb:
    performance.txn-entry-size-limit: 125829120
    performance.txn-total-size-limit: 10737418240
    tmp-storage-path: /jhmk/tidb/tidb-tmp
  tikv:
    raftstore.raft-entry-max-size: 125829120
    server.max-grpc-send-msg-len: 125829120
  pd:
    replication.enable-placement-rules: true
  tiflash: {}
  tiflash-learner: {}
  pump: {}
  drainer: {}
  cdc: {}

【业务影响】
数据库非常不稳定,每天重启几次,导致长期数据作业中断,中断又要重来,重来又中断,根本没有办法用

【TiDB 版本】
TIDB 5.2.1

咱们这个情况,可以考虑 添加几个OOM 相关的参数:https://docs.pingcap.com/zh/tidb/stable/configure-memory-usage#tidb-内存控制文档

https://docs.pingcap.com/zh/tidb/stable/tidb-configuration-file

从图中来看,TiDB的内存使用有点不均衡啊


最近1小时,没有业务操作的情况下,20这台服务器内存一直到30多G,无解

这边是通过HAproxy访问的,不知道为什么三台服务器总有一台会飙高的很快

THP关了没,检查下内存被谁占用了

这边参数都是用默认的,主要问题是要内存不停增长,而且不释放,导致重启,即使在没有业务的情况下

看下connection count3个tidb是否均衡

请教一下,怎么看内存被谁占用了

THP这个是什么,怎么关THP,这边参数基本上是默认的

connection count三个节点目前有点不均衡

这里面的检查项都做一下 检查和配置操作系统优化参数

可以使用tiup cluster check命令检查下系统环境是否到最优状态

haproxy是按照官网文档配置的吗

haproxy 基本上按照官网的,之前频繁断开,改了点延时参数

global                                     # 全局配置
   log         127.0.0.1 local0            # 定义全局的 syslog 服务器,最多可以定义两个
   #chroot      /var/lib/haproxy            # 将当前目录为指定目录,设置超级用户权限启动进程,提高安全性
   #pidfile     /var/run/haproxy.pid        # 将 HAProxy 进程写入 PID 文件
   maxconn     4000                        # 设置每个 HAProxy 进程锁接受的最大并发连接数
   user        haproxy                     # 同 uid 参数,使用是用户名
   group       haproxy                     # 同 gid 参数,建议专用用户组
   nbproc      40                          # 启动多个进程来转发请求,需要调整到足够大的值来保证 HAProxy 本身不会成为瓶颈
   #daemon                                # 让 HAProxy 以守护进程的方式工作于后台,等同于“-D”选项的功能。当然,也可以在命令行中用“-db”选项将其禁用。
   #stats socket /var/lib/haproxy/stats    # 定义统计信息保存位置

defaults                                   # 默认配置
   log global                              # 日志继承全局配置段的设置
   retries 3                               # 向上游服务器尝试连接的最大次数,超过此值就认为后端服务器不可用
   timeout connect  30000s                     # HAProxy 与后端服务器连接超时时间,如果在同一个局域网内可设置成较短的时间
   timeout client 30000s                   # 定义客户端与 HAProxy 连接后,数据传输完毕,不再有数据传输,即非活动连接的超时时间
   timeout server 30000s                   # 定义 HAProxy 与上游服务器非活动连接的超时时间

listen admin_stats                         # frontend 和 backend 的组合体,监控组的名称,按需自定义名称
   bind 0.0.0.0:8080                       # 配置监听端口
   mode http                               # 配置监控运行的模式,此处为 `http` 模式
   option httplog                          # 表示开始启用记录 HTTP 请求的日志功能
   maxconn 10                              # 最大并发连接数
   stats refresh 30s                       # 配置每隔 30 秒自动刷新监控页面
   stats uri /haproxy                      # 配置监控页面的 URL
   stats realm HAProxy                     # 配置监控页面的提示信息
   stats auth admin:jhdcp             # 配置监控页面的用户和密码 admin,可以设置多个用户名
   stats hide-version                      # 配置隐藏统计页面上的 HAProxy 版本信息
   stats  admin if TRUE                    # 配置手工启用/禁用,后端服务器(HAProxy-1.4.9 以后版本)

listen tidb-cluster                        # 配置 database 负载均衡
   bind 0.0.0.0:3390                       # 配置浮动 IP 和 监听端口
   mode tcp                                # HAProxy 中要使用第四层的应用层
   balance leastconn                       # 连接数最少的服务器优先接收连接。`leastconn` 建议用于长会话服务,例如 LDAP、SQL、TSE 等,而不是短会话协议,如 HTTP。该算法是动态的,对于实例启动慢的服务器,权重会在运行中作调整。
   server tidb-1 10.160.60.18:4000 check inter 2000 rise 2 fall 3       # 检测 4000 端口,检测频率为 2000 毫秒。如果检测出 2 次正常就认定机器已恢复正常使用,如果检测出 3 次失败便认定该服务器不可用。
   server tidb-2 10.160.60.19:4000 check inter 2000 rise 2 fall 3
   server tidb-3 10.160.60.20:4000 check inter 2000 rise 2 fall 3

这个我试一下

可以使用tiup cluster check命令检查下系统环境是否到最优状态

机械盘很慢满足高度读写要求。之前遇到这么高的压力下会出现这种情况吗。
你的部署拓扑是怎么样的?如果你是每台机器1pd1kv1tidb,你们可能会遇到因为kv耗内存太大导致同一台机器上的tidb内存不够。

tiup cluster display 集群名。看看。

THP已经关闭了

目前使用的是机械硬盘,但是现在问题点在于TIDB的内存不断增长,不释放,即使在低业务的情况,TIKV只是一直占用,增长没有太快

现在connection count均匀的情况下,18这台服务器占用内存也特别高