starrocks2.2.2 be宕机

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 ，把持久化配置好，等你们下次服务器重启就好了，不用特意为了这个重启服务器。

好的，非常感谢你的协助。

不客气，感谢您对StarRocks的关注！

还有点问题想问下：我在starrocks用户下设置了ulimit -u 65535，然后查看生效了，然后我切换到root，再切换到starrocks用户，查看ulimit -u发现还是原来的数值，请问这个是怎么回事？

麻烦提供以下 这两个文件的配置
cat /etc/security/limits.d/20-nproc.conf
cat /etc/security/limits.conf

第一个：

第二个：