背景
在做流量回放时有一块代码是通过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
解决问题
确定问题后，考虑分断查询，启用多线程查询，每个线程只查询一定量的数据，分担压力。
