是主键模型比较多吧，主键模型建议是SSD。
目前磁盘确实是 SSD 的。就是这些无效的 IO 是否有优化的参数，可以减少这些无效的 IO，或者，在每天某个时间段执行这些无效的 IO？
主键模型实时做compaction，消耗的IO会比较多。
如果不是追求唯一key和实时需求，建议用明细模型。
好吧，那能否再问一个问题，我表中创建了 bitmap 索引，会加重我集群的 IO 占用吗？如何能看我 bitmap 占用多大的磁盘？或者 因为 bitmap 产生的 io 能定位出来吗？
这个问题过几天找个时间一起看下，不太合理
你们有几块盘一个BE? 我看你们IO占用主要集中在pk_index_compact这，这里的io消耗新版本做过优化，方便的话可以升级一下最新的 3.2.4
wget “http://cdn-release.starrocks.com/StarRocks-3.2.4.tar.gz?OSSAccessKeyId=LTAI5tKZwuS2HpmksgUDMDAd&Expires=1710574545&Signature=HrCepIWno5hD4IEwpKFqd2vGsWg%3D” -O StarRocks-3.2.4.tar.gz
麻烦升级后再测试，不行咱们企业微信拉个群。
目前是 be 只用了一块磁盘。我看它 update-apply 占用也很大，想问下这个 update-apply 是什么进程？我这边这几天升级一下 3.2.4 再看看。
好的，我这边升级一下 3.2.4 之后，再看看 IO 是否会降低，如果还不行，我再麻烦你们
apply 是主键表在做一些更新相关的逻辑，好，你先升级，如果还有问题，我们拉个微信群帮你具体看看
我这边升级到 3.2.4 之后，昨天磁盘 IO 貌似稍微降低了一点点，但是今天我看又上来了。我们云上的 starrocks 是 2.3.0 的，这边用 iotop 看了一下，好像 starrocks 的 io 占用不是很厉害。
但是新集群的 3.2.x 的 starrocks 的 io 很厉害
这个可以安排帮忙一起看下吗？
我之前也有一次遇到io高，内存繁忙的情况。后来发现是开启了swap内存，关闭后就降了很多，官方建议关闭swap。给你参考参考
我已经把 swap 关闭了。现在是内存不繁忙，但是 io 很高，一直再频繁的 update_compaction，并且每次的 compaction 都挺大的
你能帮忙看下你们的 update_compaction大吗？用 iotop 看下，我再 2.3.0 里看到 compaction 的很小
be.con update_compaction_size_threshold=67108864 试试
这个不影响使用，我们优化下这个日志