我想询问下StarRcoks 3.2版本的缓存机制主要是靠操作系统的PageCache还是StarRocks自身的storage_page_cache？我在本地测试发现一个有趣的现象，在tpch1t数据集下，每次执行sql前清空OS的pagecache性能和不清空性能分别在165s和140s，随后我尝试将use_page_cache这个变量全局设置成false（目的是为了测试StarRocks的storage_page_cache对性能的影响），测试下来对性能几乎没有什么影响，我能否认为目前StarRocks内表对数据的Cache主要依赖OS的pagecache呢
1T下瓶颈不在scan
1T的瓶颈应该主要就在Cache里吧，100g这种纯内存的瓶颈应该才在CPU上吧
总数据量1T不代表每个查询都要scan 1T的数据，感兴趣的话你可以看下profile瓶颈点
这个我明白，我的意思是如果不用操作系统的pagecache，按照我部署的环境，6个be，每个64G，storage_page_cache给30%的内存，总共Cache就是115G的Cache大小，但是测试下来有没有这115G Cache latency没什么区别，这是我奇怪的点，按理来说SR应该尽可能命中自身的Cache性能会更好，因为里面的数据是解压缩的，而OS的PageCache里的数据是压缩前的，感觉这里有点反直觉。。。
SSB 这类查询比较容易出现scan瓶颈，这时候容易看出scan的优势
好的，后面也会测试一下1T的SSB，这个问题主要还是想了解下SR的pagecache对比OS的pagecache的优势，理论上来说应该是有好处的，毕竟数据都是解压后的，读上来就可以直接用。刚刚又测了一轮，关闭storage_page_cache 延迟是是150s，开启storage_page_cache是160s，也就是说全部走OS的pagecache反而性能是最好的，有一种可能是storage_page_cache的命中率完全是0，那就是额外的开销，但是之后我又对每一条query预热了五遍在跑，延迟也没区别，还是160s