版本2.4.1 be 节点全部cpu 升高，重启后下降

💬 StarRocks 用户问答
#1

【详述】问题详细描述
【背景】做过哪些操作？
【业务影响】
【StarRocks版本】例如：2.4.1
【集群规模】例如：3fe（1 follower+2observer）+5be（fe与be混部）
【机器信息】CPU虚拟核/内存/网卡，例如：48C/64G/万兆
【附件】

  • fe.log/beINFO/相应截图
  • 慢查询：
    • Profile信息
    • 并行度：show variables like ‘%parallel_fragment_exec_instance_num%’;
    • pipeline是否开启：show variables like ‘%pipeline%’;
    • be节点cpu和内存使用率截图
  • 查询报错：
  • be crash
    • be.out

版本2.4.1 be 节点 下午5点多开始 cpu 升高，21点多重启后下降，集群上没有在运行的大sql

图片
图片998×250 134 KB

fe有报错日志：

async_delta_writer.cpp:118] Fail to execution_queue_execute: 22
binary_converter.cpp:50] Column [binary]'s length exceed max varchar length.

请问上面的binary 这个是什么字段 我们的表里没有这种字段

#2

1.通过fe.audit.log查看一下当时有没有查询很慢的SQL，或者大量的查询。
2.be.warn和be.out查看有没有异常的日志。

#3

be.WARNING 有这种日志

图片
图片798×164 4.82 KB

tail -f -n4000 be.INFO | grep erro
be.INFO 有这种日志

图片
图片1369×207 59.7 KB

perf top 查看cpu占用最高的是 starrocks::BitmapValue::BitmapValue
昨天也是这个，这个是查询的 还是构建的

#4

收到，我们确认一下。

#5

麻烦把故障时间列一下，把对应的be.INFO日志发给我们分析一下，谢谢！

#6

日志 我看没有最早的了
故障时间的be.INFO 都是这个

I1128 21:21:23.188709 182700 executor.cpp:18] async_delta_writer is busy, retry after 50ms
I1128 21:21:23.188716 182703 executor.cpp:18] async_delta_writer is busy, retry after 50ms
I1128 21:21:23.188719 182700 executor.cpp:18] async_delta_writer is busy, retry after 50ms
I1128 21:21:23.188724 182703 executor.cpp:18] async_delta_writer is busy, retry after 50ms
I1128 21:21:23.188726 182700 executor.cpp:18] async_delta_writer is busy, retry after 50ms
I1128 21:21:23.188730 182703 executor.cpp:18] async_delta_writer is busy, retry after 50ms
I1128 21:21:23.188733 182700 executor.cpp:18] async_delta_writer is busy, retry after 50ms
I1128 21:21:23.188737 182703 executor.cpp:18] async_delta_writer is busy, retry after 50ms
I1128 21:21:23.188741 182700 executor.cpp:18] async_delta_writer is busy, retry after 50ms
I1128 21:21:23.188745 182703 executor.cpp:18] async_delta_writer is busy, retry after 50ms

#8

dmesg -T
/var/log/message
看下有什么报错吧，或者咱们来个腾讯会议看看如何？

#9

抱歉现在才注意到
/var/log/message 的日志

Dec 2 18:36:25 be05 kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-0.slice/session-1380.scope,task=starrocks_be,pid=1887762,uid=0
Dec 2 18:36:25 be05 kernel: Out of memory: Killed process 1887762 (starrocks_be) total-vm:97747984kB, anon-rss:51883244kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:146292kB oom_score_adj:0
Dec 2 18:36:30 be05 kernel: oom_reaper: reaped process 1887762 (starrocks_be), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

dmesg -T
[Fri Dec 2 18:05:09 2022] [1905829] 0 1905829 3384 233 65536 0 0 sshd
[Fri Dec 2 18:05:09 2022] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-0.slice/session-1380.scope,task=starrocks_be,pid=1887762,uid=0
[Fri Dec 2 18:05:09 2022] Out of memory: Killed process 1887762 (starrocks_be) total-vm:97747984kB, anon-rss:51883244kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:146292kB oom_score_adj:0
[Fri Dec 2 18:05:15 2022] oom_reaper: reaped process 1887762 (starrocks_be), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

感觉 跟大批量数据导入有关。 最近几天 后续 只要千万级别的数据导入，总有节点的cpu （16核）升到80%到90%，这种有办法可以限制吗

#10

oom，如果BE与其他服务混部，需要配置mem_limit=(机器总内存-FE JVM-其他服务占用内存-1~2g(系统预留))

#11

导入压力大，少点任务并行导入吧。

#12

现在还会出现这个问题吗？

京ICP备2022026421号-1