读缓存不太智能呀

交流 PrimoCache软件使用过程中遇到的问题以及心得等
这里提供官方的技术支持
回复
GDSSSSST
2级用户
2级用户
帖子: 7
注册时间: 周日 2月 14, 2021 2:35 am

读缓存不太智能呀

帖子 GDSSSSST »

我给冷数据盘也分了大概20g缓存,目的是给目录做二缓
实际中的问题:冷数据盘一次顺序读取1tb的文件,然后缓存就整个1tb文件再读一次,过程中丢弃几乎所有文件。然后我校验读一遍,缓存又再读再丢弃所有文件一遍。
但是呢,无论我读多大的文件,读缓存都是可以等到硬盘空闲再开始采集(我都是设置成仅空闲的)。
那么,为什么不能把丢弃的动作放到读取动作的前面,限制一次读取量不大于缓存容量?

没对我造成什么影响,就是觉得这应该挺容易改进的。
头像
Support
技术支持组
技术支持组
帖子: 2329
注册时间: 周日 12月 21, 2008 10:42 am
联系:

Re: 读缓存不太智能呀

帖子 Support »

这个问题我们之前已经注意到了,看上去很好解决,但实际上涉及到淘汰算法,以及区分的热度或者追踪短时间内的连续数据等,还要考虑追踪这些数据的额外开销问题。不能满了就不采集,否则缓存热度就不会更新,但丢弃放在前面又需要对全盘数据进行追踪,如果数据量大的话,额外开销会很高。
不过我们也在想其它方法,应该会对这个问题进行改进。谢谢。
Primo Ramdisk | PrimoCache
Romex Software 技术支持组
GDSSSSST
2级用户
2级用户
帖子: 7
注册时间: 周日 2月 14, 2021 2:35 am

Re: 读缓存不太智能呀

帖子 GDSSSSST »

Support 写了: 周一 12月 27, 2021 10:00 am 这个问题我们之前已经注意到了,看上去很好解决,但实际上涉及到淘汰算法,以及区分的热度或者追踪短时间内的连续数据等,还要考虑追踪这些数据的额外开销问题。不能满了就不采集,否则缓存热度就不会更新,但丢弃放在前面又需要对全盘数据进行追踪,如果数据量大的话,额外开销会很高。
不过我们也在想其它方法,应该会对这个问题进行改进。谢谢。
我说的是非常固定的条件,不是整个读缓存的算法。
我说的读1tb文件是一次连续的读取1tb数据,这段连续时间假如20分钟内硬盘是占满的,缓存是忙时不更新的暂停状态。然后20分钟后,硬盘空闲了,缓存开始写入了,缓存只会再读1tb数据,即使缓存远远小于1tb。

忙时间隔采集的读取数据量大于缓存容量时,丢弃放到读取前面,限制一次读取数据量不大于缓存容量。


并不是断断续续的读1tb冷数据造成的污染问题。
头像
Support
技术支持组
技术支持组
帖子: 2329
注册时间: 周日 12月 21, 2008 10:42 am
联系:

Re: 读缓存不太智能呀

帖子 Support »

这是因为采集时不是一次就采集很多数据的,也不是预先定义好这次或这批采集需要采集多少数据量。每次都是采集一小部分数据,在这期间可能会不断有新数据进来。而且根据系统忙碌程度,每次采集的数据量和采集间隔也在变化。您看到的是一次读写1TB数据,但是Windows首先就会把这个读写分成很多个IO请求,PrimoCache识别这些IO并采集时,又可能分成很多次采集操作。而且很多情况下,这些IO请求中又会混入系统或其它应用程序发出的读写IO请求,特别是服务器应用环境中,系统基本一直处于忙碌状态中,场景就会变得很复杂。
Primo Ramdisk | PrimoCache
Romex Software 技术支持组
GDSSSSST
2级用户
2级用户
帖子: 7
注册时间: 周日 2月 14, 2021 2:35 am

Re: 读缓存不太智能呀

帖子 GDSSSSST »

Support 写了: 周三 12月 29, 2021 10:21 am 这是因为采集时不是一次就采集很多数据的,也不是预先定义好这次或这批采集需要采集多少数据量。每次都是采集一小部分数据,在这期间可能会不断有新数据进来。而且根据系统忙碌程度,每次采集的数据量和采集间隔也在变化。您看到的是一次读写1TB数据,但是Windows首先就会把这个读写分成很多个IO请求,PrimoCache识别这些IO并采集时,又可能分成很多次采集操作。而且很多情况下,这些IO请求中又会混入系统或其它应用程序发出的读写IO请求,特别是服务器应用环境中,系统基本一直处于忙碌状态中,场景就会变得很复杂。
我看到的不止是一次读写,关键是不同步的采集,也就是识别io以后并不是直接进行采集,而是记录下来根据系统忙碌程度分次采集的。

那么如果记录下来的“读写io”大于缓存容量时,先不做io请求,直接按算法丢弃掉多出缓存容量的“读写io”,再实际发出io请求。



这如果很难,忙时采集的策略能不能更实时一些,现有的“即时”策略并不适合配合l1读缓存用,我测试了一下,l1读缓存到l2是不需要读盘的,但是“即时”速度不知道为什么远低于硬盘速度,能不能达到和不开延写的写缓存一样的同步缓存。
头像
Support
技术支持组
技术支持组
帖子: 2329
注册时间: 周日 12月 21, 2008 10:42 am
联系:

Re: 读缓存不太智能呀

帖子 Support »

GDSSSSST 写了: 周三 12月 29, 2021 8:41 pm 那么如果记录下来的“读写io”大于缓存容量时,先不做io请求,直接按算法丢弃掉多出缓存容量的“读写io”,再实际发出io请求。
这就是前面提到的需要追踪信息才可以。否则如果一直超过缓存容量,缓存里的数据就不会更新了。这个方面我们会进行进一步研究优化。
GDSSSSST 写了: 周三 12月 29, 2021 8:41 pm 我测试了一下,l1读缓存到l2是不需要读盘的,但是“即时”速度不知道为什么远低于硬盘速度,能不能达到和不开延写的写缓存一样的同步缓存。
L2采集时,如果数据已经在L1了,就直接从L1读取。否则就从硬盘采集。之所以采用异步缓存而不采用同步缓存,是为了不增加原IO的读写时间。
Primo Ramdisk | PrimoCache
Romex Software 技术支持组
GDSSSSST
2级用户
2级用户
帖子: 7
注册时间: 周日 2月 14, 2021 2:35 am

Re: 读缓存不太智能呀

帖子 GDSSSSST »

Support 写了: 周四 12月 30, 2021 9:44 am
这就是前面提到的需要追踪信息才可以。否则如果一直超过缓存容量,缓存里的数据就不会更新了。这个方面我们会进行进一步研究优化。
Support 写了: 周四 12月 30, 2021 9:44 am L2采集时,如果数据已经在L1了,就直接从L1读取。否则就从硬盘采集。之所以采用异步缓存而不采用同步缓存,是为了不增加原IO的读写时间。
我好像理解了,如果只开l2应该是没法改进的。


同时开l1l2情况下:
l1容量有限,数据的保存时间等同于即时。io读写时间的短板应该是硬盘而不是内存吧,同步缓存直接读l1会增加原io的读写时间吗?

追踪信息是不是和l1的作用重合了,如果开了l1读缓存还需要额外追踪信息吗?
头像
Support
技术支持组
技术支持组
帖子: 2329
注册时间: 周日 12月 21, 2008 10:42 am
联系:

Re: 读缓存不太智能呀

帖子 Support »

GDSSSSST 写了: 周四 12月 30, 2021 11:05 pm 同时开l1l2情况下:
l1容量有限,数据的保存时间等同于即时。io读写时间的短板应该是硬盘而不是内存吧,同步缓存直接读l1会增加原io的读写时间吗?
会增加一些处理时间,对于4K性能影响会明显一些。如果考虑到L1缓存不足的场景(即出现缓存淘汰的情形),情况会更加复杂。
GDSSSSST 写了: 周四 12月 30, 2021 11:05 pm 追踪信息是不是和l1的作用重合了,如果开了l1读缓存还需要额外追踪信息吗?
一般L1容量远小于L2容量,L1追踪的信息通常是不够的。
Primo Ramdisk | PrimoCache
Romex Software 技术支持组
huxim
3级用户
3级用户
帖子: 16
注册时间: 周六 9月 10, 2011 3:32 pm

Re: 读缓存不太智能呀

帖子 huxim »

我倒是觉得缓存连续I/O是没有意义的, 连续复制大文件必然会被HDD的速率限制,缓存的意义在于提升随机I/O,群晖nas上的缓存配置就是默认开启跳过连续 I/O的
头像
Support
技术支持组
技术支持组
帖子: 2329
注册时间: 周日 12月 21, 2008 10:42 am
联系:

Re: 读缓存不太智能呀

帖子 Support »

对于连续IO的缓存算法我们也还在优化中。
Primo Ramdisk | PrimoCache
Romex Software 技术支持组
回复