能确认是哪一条SQL导致的吗？
可以，挺简单的，就是一个insert into xxx select xxx sql语句
我上面的日志就是这三个日志文件在be挂了后的日志
8BE是挂了其中一个 还是挂了多个？
insert into xxx select xxx，能详细提供一下具体SQL吗？
请问数据量大概多少？
insert into das.dm_skincare_makeup_hf_2021_fr_bmfs select * from das.dm_skincare_makeup_hf_2021_fr;
两个表结构一模一样
CREATE TABLE dm_skincare_makeup_hf_2021_fr (
id varchar(65533) NULL COMMENT “”,
field_a varchar(65533) NULL COMMENT “”,
field_b varchar(65533) NULL COMMENT “”,
mission varchar(65533) NULL COMMENT “”,
pred varchar(65533) NULL COMMENT “”,
xqsk varchar(65533) NULL COMMENT “”,
platform_id varchar(65533) NULL COMMENT “”,
month varchar(65533) NULL COMMENT “”
) ENGINE=OLAP
DUPLICATE KEY(id)
COMMENT “OLAP”
DISTRIBUTED BY HASH(id) BUCKETS 32
PROPERTIES (
“replication_num” = “3”,
“in_memory” = “false”,
“storage_format” = “DEFAULT”
);
数据量：14112411
是多个be都挂了，应该和sql没有多大关系。
宕机是由这个引起，通常是SQL导致。数据量1500万也是正常范围内。麻烦提供一下 select语句和表结构有助于我们分析，谢谢！
嗯，上面已经提供了哈，感谢。
看到了，我们正在排查，请稍等。
Linux服务器执行以下 ulimit -u 和 ulimit -n
是不是-u太小了？
是的，请设置
ulimit -u 65535
建议持久生效配置：
cat >> /etc/security/limits.conf << EOF
* soft nproc unlimited
* hard nproc unlimited
* soft nofile 524288
* hard nofile 524288
* soft stack unlimited
* hard stack unlimited
* hard memlock unlimited
* soft memlock unlimited
EOF
我刚刚的截图里是用的starrocks用户查看的，我在root用户下查看还是蛮大的，是40960，为啥在root下设置好了在starrocks用户下看还是那么小？
root设置了，starrocks是不生效的，而且ulimit -u 65535 是一个临时设置，机器重启或者会话杀掉就会很容易丢失了。所以建议用持久化设置。
要用starrocks用户执行ulimit -u 65535 或者用持久化配置
好的，持久化设置要生效的话需要重启服务器吧。
要的，先用starrocks用户执行ulimit -u 65535 ，把持久化配置好，等你们下次服务器重启就好了，不用特意为了这个重启服务器。