背景

在做流量回放时有一块代码是通过es进行流量查询的，在业务使用时出现了接口timeout的问题。借此开始排查具体问题。首先是review了一下代码逻辑，减少了部分轮训和变量变量的操作，缩短程序运行时间，但发现并没有解决问题，开始怀疑是es查询超时导致的。

定位es查询

添加日志，发现在取回es查询迭代器后一直运行直到超时，确认是es查询问题。登录kibana进行相同流量查询，发现偶尔也会有超时线上。一方面可能是不同人物触发的程查询并发导致的es线程池压力过大，另一方面发现符合查询条件的数据量过大（在5w条左右），因为程序会针对检索回来的数据一条条进行匹配（因为业务需求，这里没办法利用es查询直接查回结果），数据量太大。

定位问题

登录线上机器执行对应代码单测，发现程序执行过程中进程被杀掉。通过linux指令sudo dmesg | tail -7 查询到执行程序oom导致被系统杀掉。具体日志如下：

root@zhongkui-web--box-8471--290597-59456c95f5-86jgt:/data/apps/zhongkui--box-8471# dmesg | tail -7
[46881128.803587] [  22237]     0 22237     6563      903    90112        0           992 bash
[46881128.803588] [  47083]     0 47083   113946     1830   151552        0           992 zhsh
[46881128.803590] [  47093]     0 47093     6564      972    90112        0           992 bash
[46881128.803592] [  62943]     0 62943   522518   480635  4132864        0           992 python
[46881128.803593] oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=18f962771ca4c441cbc53bc4d91a793fcb5de437223c841362a8b30d2d08f043,mems_allowed=0-1,oom_memcg=/kubepods/burstable/poda41c610c-dc4d-47b6-96a2-f96bd75b51e5/18f962771ca4c441cbc53bc4d91a793fcb5de437223c841362a8b30d2d08f043,task_memcg=/kubepods/burstable/poda41c610c-dc4d-47b6-96a2-f96bd75b51e5/18f962771ca4c441cbc53bc4d91a793fcb5de437223c841362a8b30d2d08f043,task=python,pid=62943,uid=0
[46881128.803617] Memory cgroup out of memory: Killed process 62943 (python) total-vm:2090072kB, anon-rss:1914972kB, file-rss:7568kB, shmem-rss:0kB, UID:0 pgtables:4036kB oom_score_adj:992
[46881129.021772] oom_reaper: reaped process 62943 (python), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

解决问题

确定问题后，考虑分断查询，启用多线程查询，每个线程只查询一定量的数据，分担压力。