tidb设置了oom-action=cancel但还是oom了

pangyana · 2020 年3 月 10 日 03:31

为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。

【TiDB 版本】：3.0.9
【问题描述】：

配置文件

mem-quota-query = 8589934592

oom-action = “cancel”

执行了一个sql后报错

sql：

SELECT …
FROM … WHERE 1=1 AND pay_type in (‘1’) GROUP BY out_trade_no,pay_type_name,op_order_id,account_belong,settle_cycle,supply_finish_amount,supply_category_names,supply_trade_type_names limit 1000000

没有用到索引，全表扫描，表有40G

报错：

执行SQL查询失败, ErrorCode: 0, SQLState: 08S01, detail: Communications link failure

The last packet successfully received from the server was 46,485 milliseconds ago. The last packet sent successfully to the server was 46,485 milliseconds ago.

tidb.log里的日志如下：

引用

yilong · 2020 年3 月 10 日 04:04

您好： [问题澄清] TiDB 版本： 3.0.9 问题描述：配置文件后执行sql报错

[信息收集]
1. 请问有如何修改参数的？在中控机修改后重启tidb吗？
2. 这个报错的tidb服务器上，搜索下操作系统/var/log/message日志，确认下那个时候是不是oom了？

pangyana · 2020 年3 月 10 日 04:15

1、在中控机修改后重启tidb

1.1 在中控机上执行修改

cd /home/tidb/tidb-ansible

vi conf/tidb.yml

1.2 修改完配置后，滚动更新tidb节点

ansible-playbook rolling_update.yml --tags=tidb

2、11：10 和11：19 确实是oom-killer

yilong · 2020 年3 月 10 日 05:40

[问题分析]
1. 从您的message日志看确实是OOM
2. 从tidb报错截图看包含了未知的配置参数，请查看下，修改后重启tidb，再试试

pangyana · 2020 年3 月 10 日 05:59

[pessimistic-txn]
enable = true
max-retry-count = 256
ttl = "30s"

这个有问题吗我没有动过是默认的

yilong · 2020 年3 月 10 日 06:15

请帮忙确认俩个问题:

3.0.9是新安装还是从低版本升级上来的？
tidb是单独部署，还是和和其他组件共部署？sql配置的8G，看下硬件使用情况，tidb能否分到8G
检查监控overview面板，当OOM时，是否有足够的内存，是否都是被tidb使用了，有没有其他服务抢占资源。

pangyana · 2020 年3 月 10 日 06:43

1、之前新安装的3.0.9

2、tidb单独部署

3、是被tidb使用了，tidb节点机器资源是16G

yilong · 2020 年3 月 10 日 06:49

您好：我觉得可能是这种情况，您可以测试一下：

   1. tidb中有几个比较占用内存的sql，假设您的tidb服务器内存未16g，除去操作系统使用的内存，只要有多个耗费内存的sql同时运行，就会导致每个sql都没有到达8G时，总的内存OOM

  2. 您可以尝试将mem-quota-query的值调小到几十M，测试一下，是否会在达到几十M时，被cancel

  3. 麻烦上传下tidb.log和 slow_tidb日志，stderr，我再看下是否有记录，多谢

pangyana · 2020 年3 月 10 日 08:38

tidb0310.log (496.5 KB)

slow_tidb太大了，stderr没有今天的记录

pangyana · 2020 年3 月 10 日 08:42

想问一下，

1、为啥这个sql 会在tidb节点占用这么高的内存？
2、如果配置了mem-quota-query ，是不是这种sql就永远无法执行成功，因为要么就是oom，要么就是被cancel

yilong · 2020 年3 月 10 日 09:10

从你反馈的tidb日志看，从11：19 tidb启动到15：23分左右重新启动，这部分日志里记录了一些expensive的sql，但是看最大内存都没有占用到可以超过8g，

image2273×343 102 KB
这个服务器的配置是怎么样的？多少cpu，多大内存？
df -h ; free -h ; lscpu 我看下. 在执行下 top 信息看下当前占用内存多的进程有什么，多谢

pangyana · 2020 年3 月 10 日 09:14

11：19 和15：23 都是这个大sql跑挂了重新启动在此之间没有执行过这个大sql。

[tidb@prod-tidb-tidb001 log]$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G  9.5G   28G  26% /
devtmpfs        7.8G     0  7.8G   0% /dev
tmpfs           7.8G     0  7.8G   0% /dev/shm
tmpfs           7.8G  580K  7.8G   1% /run
tmpfs           7.8G     0  7.8G   0% /sys/fs/cgroup
/dev/vdb1       197G   11G  177G   6% /alidata
tmpfs           1.6G     0  1.6G   0% /run/user/1002
[tidb@prod-tidb-tidb001 log]$ free -h
              total        used        free      shared  buff/cache   available
Mem:            15G        1.4G         12G        1.2M        1.7G         13G
Swap:            0B          0B          0B
[tidb@prod-tidb-tidb001 log]$ lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                8
On-line CPU(s) list:   0-7
Thread(s) per core:    2
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 85
Model name:            Intel(R) Xeon(R) Platinum 8163 CPU @ 2.50GHz
Stepping:              4
CPU MHz:               2499.984
BogoMIPS:              4999.96
Hypervisor vendor:     KVM
Virtualization type:   full
L1d cache:             32K
L1i cache:             32K
L2 cache:              1024K
L3 cache:              33792K
NUMA node0 CPU(s):     0-7
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch ibrs ibpb stibp fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx avx512f avx512dq rdseed adx smap avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 spec_ctrl intel_stibp

top - 17:14:34 up 53 days, 49 min,  2 users,  load average: 2.18, 2.07, 2.14
Tasks: 169 total,   1 running, 168 sleeping,   0 stopped,   0 zombie
%Cpu(s): 25.7 us,  2.0 sy,  0.0 ni, 72.1 id,  0.0 wa,  0.0 hi,  0.2 si,  0.0 st
KiB Mem : 16265764 total, 13034988 free,  1477740 used,  1753036 buff/cache
KiB Swap:        0 total,        0 free,        0 used. 14465576 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                                                                                
15073 tidb      20   0 1726584 557100  21412 S 216.7  3.4 167:13.62 tidb-server                                                                                                                                                            
 1015 tidb      20   0 7210364 305392   7276 S   2.0  1.9   1144:12 prometheus                                                                                                                                                             
 1398 root      20   0  951640 215048   2680 S   0.7  1.3  24:37.84 rsyslogd                                                                                                                                                               
  642 root      20   0  240424  52916  52436 S   0.0  0.3  29:58.61 systemd-journal                                                                                                                                                        
12050 tidb      20   0 2449656  42092   8376 S   0.0  0.3 259:02.82 grafana-server                                                                                                                                                         
 1170 root      20   0 1950296  30564   4988 S   0.0  0.2 222:34.38 exe                                                                                                                                                                    
 1394 root      20   0  659796  15508   2060 S   0.7  0.1  87:25.51 node_exporter                                                                                                                                                          
 7403 tidb      20   0  124168  13592   3056 S   0.0  0.1  84:23.04 alertmanager                                                                                                                                                           
 1563 root      20   0  245280  12384   1488 S   0.3  0.1 124:21.74 ilogtail                                                                                                                                                               
 1392 root      20   0  573920  11244    180 S   0.0  0.1   7:12.92 tuned                                                                                                                                                                  
10407 root      20   0  687156   9396   1916 S   0.0  0.1  31:06.23 falcon-agent                                                                                                                                                           
 1086 root      20   0  309724   9112      0 S   0.0  0.1   0:02.09 CmsGoAgent.linu                                                                                                                                                        
 7605 tidb      20   0  114380   8592   2072 S   0.0  0.1  19:41.75 pushgateway                                                                                                                                                            
15204 root      10 -10  129272   8576   3464 S   3.0  0.1 329:19.02 AliYunDun                                                                                                                                                              
 1080 polkitd   20   0  612352   8040    364 S   0.0  0.0   0:18.36 polkitd                                                                                                                                                                
 6961 tidb      20   0   22184   7544    692 S   0.3  0.0 296:10.99 blackbox_export                                                                                                                                                        
18546 root      20   0  154656   5448   4148 S   0.0  0.0   0:00.00 sshd                                                                                                                                                                   
24031 root      10 -10 2176704   5172    936 S   0.0  0.0   5:42.58 AliHips                                                                                                                                                                
19408 root      20   0  241172   4616   3452 S   0.0  0.0   0:00.00 sudo                                                                                                                                                                   
18576 root      20   0  241172   4612   3452 S   0.0  0.0   0:00.00 sudo                                                                                                                                                                   
18672 tidb      20   0  116628   3392   1820 S   0.0  0.0   0:00.05 bash

yilong · 2020 年3 月 10 日 10:12

您好：您这边是生产环节吗？如果是的话，是否方便扩容一个tidb，单独测试一下。初步猜测聚合函数中存中间数据的aggPartialResultMapper结构没有被trace

1. 在新扩容的tidb上单独执行这条大sql

2. 同时在另一个session抓取火焰图，反馈此heap.profile文件给我们查看.
   curl -G "ip:port/debug/pprof/heap" > heap.profile 
   ip地址为tidb服务器的ip，端口为tidb_status_port的端口

收集完成后，同时反馈explain sql 的执行计划，多谢

pangyana · 2020 年3 月 11 日 05:42

heap.profile (31.7 KB)

这个火焰图收集一下子就结束了？
sql如下：

执行计划如下：

yilong · 2020 年3 月 11 日 06:32

根据火焰图可以确认，aggPartialResultMapper阶段分配了大量的内存，但是没有trace到，导致OOM后没有Kill，这部分会在后续修复；

image1507×429 233 KB
当前建议改写sql，尝试降低sql内存占用，例如，感觉当前的条件是全表group by吧，能否and条件再多一些，每次取出的值更少，占用内存更小，之后再将这些值汇总。

pangyana · 2020 年3 月 11 日 06:54

好的，了解了，谢谢

来了老弟 · 2020 年3 月 11 日 08:14

感谢您的回复，如果问题已经解决，可以将关键的回复设置为最佳解决方案。
新问题麻烦另开新帖哦。

pangyana · 2020 年3 月 12 日 02:38

再问下这个大概什么时候能修复，在什么版本，谢谢

yilong · 2020 年3 月 12 日 03:18

您好：这个产品同事在排计划了，预期到下半年了，建议您先改写sql，或者加大内存硬件，麻烦了，多谢

pangyana · 2020 年3 月 12 日 03:19

那是这个oom-action=cancel 是整体都不可用了吗，还是部分sql可能不可用？