。

读写的数据可以提前或者异步载入缓存#xff0c;再由客户端在后台与远端服务交互执行异步上传或预取数据。

相比直接与远端服务交互#xff0c;采用缓存技…缓存

对于一个由对象存储和数据库组合驱动的文件系统缓存是本地客户端与远端服务之间高效交互的重要纽带。

读写的数据可以提前或者异步载入缓存再由客户端在后台与远端服务交互执行异步上传或预取数据。

相比直接与远端服务交互采用缓存技术可以大大降低存储操作的延时并提高数据吞吐量。

JuiceFS

等对随机读性能要求更高的应用建议将缓存路径设置在速度更快的存储介质上并分配更大的缓存空间。

然而缓存能提升性能的前提是你的应用需要反复读取同一批文件。

如果你确定你的应用对数据是「读取一次然后再也不需要」的访问模式比如大数据的数据清洗常常就是这样可以关闭缓存功能省去缓存不断建立又反复淘汰的开销。

数据一致性​

由于其元数据分离架构需要从元数据、文件数据对象存储、文件数据本地缓存三方面来思考一致性问题

对于元数据缓存JuiceFS

默认的挂载设置满足「关闭再打开close-to-open」一致性也就是说一个客户端修改并关闭文件之后其他客户端重新打开这个文件都会看到最新的修改。

与此同时默认的挂载参数设置了

秒的内核元数据缓存满足了一般场景的需要。

但如果你的应用需要更激进的缓存设置以提升性能可以阅读下方章节对元数据缓存进行针对性的调优。

特别地发起修改的客户端挂载点能享受到更强的一致性阅读一致性例外详细了解。

对于对象存储JuiceFS

并上传至对象存储服务。

文件的任何修改操作都将生成新的数据块原有块保持不变所以不用担心数据缓存的一致性问题因为一旦文件被修改过了JuiceFS

会从对象存储读取新的数据块。

而老的失效数据块也会随着回收站或碎片合并机制被删除避免对象存储泄露。

本地数据缓存缓存也是以对象存储的数据块做为最小单元。

一旦文件数据被下载到缓存盘一致性就和缓存盘可靠性相关如果磁盘数据发生了篡改客户端也会读取到错误的数据。

对于这种担忧可以配置合适的

元数据缓存​

API以内核元数据缓存的形式进行管理同时也直接在客户端内存中维护。

内核元数据缓存​

客户端可以控制这些内核元数据缓存文件属性attribute包含文件名、大小、权限、修改时间等信息、文件项entry

direntry用来区分文件和目录类型的文件在挂载时可以使用下方参数通过

FUSE

--dir-entry-cache1让以上元数据默认在内核中缓存

秒能显著提高

进行区分设置如果确实要精细化调优在目录极少变动、而文件频繁变动的场景可以令

--dir-entry-cache

操作即打开一个文件时其文件属性会被自动缓存在客户端内存中这里的属性缓存不仅包含内核元数据中的文件属性比如文件大小、修改时间信息还包含

JuiceFS

写入完成并关闭之后在任何一个客户端重新打开该文件都可以保证能访问到最新写入的数据不论是否在同一个节点。

文件的属性缓存也不一定要通过

open

会不断查询文件属性在这种情况下无需重新打开文件也能获得最新文件变动。

--open-cache指定缓存的有效时长。

在缓存有效期间执行的

getattr

信息。

有了这些信息就能省去每次打开文件都重新访问元数据服务的开销。

--open-cache

一致性了不过与内核元数据类似发起修改的客户端同样能享受到客户端内存元数据缓存主动失效其他客户端就只能等待缓存自然过期。

因此为了保证文件系统语义--open-cache

模型训练则推荐根据情况设置

商业版提供更丰富的客户端内存的元数据缓存功能并且支持主动失效阅读商业版文档以了解。

一致性例外​

当文件发生变动时发起修改的挂载点能够享受到更强的一致性具体而言

发起修改的挂载点自身的内核元数据缓存能够主动失效。

但对于多个挂载点访问、修改同一文件的情况只有发起修改的客户端能享受到内核元数据缓存主动失效其他客户端就只能等待缓存自然过期。

调用

write

查看文件大小可能会注意到文件不断变大——但这并不意味着修改已经成功提交在

flush

成功前是不会将这些改动同步到对象存储的其他挂载点也看不到文件的变动。

调用

fsync,

flush让修改得以持久化、对其他客户端可见。

作为上一点的极端情况如果调用

write

因为某种原因失败了比方说到达了文件系统配额上限文件长度会立刻发生回退比如从

10M

清空了你的数据而是写入自始至终就没有成功只是由于发起修改的挂载点能够提前预览文件长度的变化让人误以为写入已经成功提交。

发起修改的挂载点能够监听对应的文件变动比如使用

fswatch

Watchdog。

但范畴也仅限于该挂载点发起修改的文件也就是说

FUSE

MiB。

读和写产生的数据都会途经这个缓冲区。

所以缓冲区的作用非常重要在大规模场景下遇到性能不足时提升缓冲区大小也是常见的优化方式。

预读和预取​

客户端的工作机制文档中会用「预读」和「预取」来特指客户端的两种不同提前下载数据、优化读性能的行为。

顺序读文件时JuiceFS

客户端会进行预读readahead也就是提前将文件后续的内容下载下来。

事实上同样的行为也早已存在于内核读取文件时内核也会根据具体的读行为和预读窗口算法来提前将文件读取到内核页缓存。

考虑到

JuiceFS

是个网络文件系统内核的预读窗口对他来说太小无法有效提升顺序读的性能因此在内核的预读之上JuiceFS

客户端也会发起自己的预读根据更激进的算法来“猜测”应用接下来要读取的数据范围然后提前将对象存储对应的数据块下载下来。

readahead

客户端还存在着另一种相似的机制称作预取prefetch随机读取文件某个块Block的一小段客户端会异步将整个对象存储块下载下来。

预取的设计是基于「假如文件的某一小段被应用读取那么文件附近的区域也很可能会被读取」的假设对于不同的应用场景这样的假设未必成立——如果应用对大文件进行偏移极大的、稀疏的随机读那么不难想象prefetch

会带来明显的读放大。

因此如果你已经对应用场景的读取模式有深入了解确认并不需要

--prefetch0

预读和预取分别优化了顺序读、随机读性能也会带来一定程度的读放大阅读「读放大」了解更多信息。

写入​

会将数据写入缓冲区写入完毕以后你甚至会注意到当前挂载点已经看到文件长度有所变化不要误会这并不代表写入已经持久化这点也在一致性例外话题上有更详细介绍。

总而言之在

flush

缓冲区是读写共用的显然「写」具有更高的优先级这隐含着「写会影响读」的可能性。

举例说明如果对象存储的上传速度不足以支撑写入负载会发生缓冲区拥堵

Slice侵占了缓冲区用于预读的空间因此读文件会变慢。

不仅如此由于对象存储上传速度不足写也可能会因为

flush

上方小节介绍了缓冲区对读、写都有关键作用因此在面对高并发读写场景的时候对

--buffer-size

进行相应的扩容能有效提升性能。

但一味地扩大缓冲区大小也可能产生其他的问题比如

--buffer-size

过大但对象存储上传速度不足导致上方小节中介绍的缓冲区拥堵的情况。

因此缓冲区的大小需要结合其他性能参数一起科学地设置。

在调整缓冲区大小前我们推荐使用

来观察当前的缓冲区用量大小这个命令能直观反映出当前的读写性能问题。

--buffer-size来放大预读窗口窗口内尚未下载到本地的数据块会并发地异步下载。

同时注意单个文件的预读不会把整个缓冲区用完限制为

1/4

用量已经接近一半说明该文件的预读额度已满此时虽然缓冲区还有空闲但也需要继续增加

--buffer-size

MiB。

读写缓冲区的大小决定了读取文件以及预读readahead的内存数据量同时也控制着写缓存pending

--buffer-size

增大了上传并发度但并没有观察到上行带宽用量有明显增加那么此时可能就需要相应地调大

--buffer-size让并发线程更容易申请到内存来工作。

这个排查原理反之亦然如果增大

--buffer-size

操作的上传数据量大小因此如果客户端处在一个低带宽的网络环境下可能反而需要降低

--buffer-size

对数据也提供多种缓存机制来提高性能包括内核中的页缓存和客户端所在机器的本地缓存以及客户端自身的内存读写缓冲区。

读请求会依次尝试内核分页缓存、JuiceFS

进程的预读缓冲区、本地磁盘缓存当缓存中没找到对应数据时才会从对象存储读取并且会异步写入各级缓存保证下一次访问的性能。

内核页缓存​

Cache下次再打开的时候如果文件没有被更新就可以直接从内核页缓存读取获得最好的性能。

JuiceFS

客户端会跟踪所有最近被打开的文件要重复打开相同文件时它会根据该文件是否被修改决定是否可以使用内核页数据如果文件被修改过则对应的页缓存也将在再次打开时失效这样保证了客户端能够读到最新的数据。

当重复读

支持内核回写writeback-cache模式内核会把高频随机小

IO例如

字节的写请求合并起来显著提升随机写入的性能。

但其副作用是会将顺序写变为随机写严重降低顺序写的性能。

开启前请考虑使用场景是否匹配。

writeback_cache

选项来开启内核回写模式。

注意内核回写与「客户端写缓存」并不一样前者是内核中的实现后者则发生在

JuiceFS

客户端会根据应用读数据的模式自动做预读和缓存操作以提高顺序读的性能。

数据会缓存到本地文件系统中可以是基于硬盘、SSD

JuiceFS

大小的数据写入到缓存目录中不做压缩和加密。

如果希望保证应用程序首次访问数据的时候就能获得已缓存的性能可以使用

juicefs

如果缓存所在的文件系统异常时体现为读操作卡死如某些内核态的网络文件系统那么

JuiceFS

也会随之一起卡住这就要求你对缓存目录底层的文件系统行为进行调优做到快速失败。

juicefs

1。

所谓预读prefetch就是随机读取文件任意一小段都会触发对应的整个对象存储块异步完整下载。

预读往往能改善随机读性能但如果你的场景的文件访问模式无法利用到预读数据比如

offset

跨度极大的大文件随机访问预读会带来比较明显的读放大可以考虑设为

JuiceFS

还内置着另一种类似的预读机制在顺序读时会提前下载临近的对象存储块这在

JuiceFS

0.1。

这两个参数任意一个达到阈值均会自动触发缓存淘汰使用的是类似于

LRU

实际缓存数据占用空间大小可能会略微超过设置值这是因为对同样一批缓存数据很难精确计算它们在不同的本地文件系统上所占用的存储空间JuiceFS

累加所有被缓存对象大小时会按照

只缓存小文件和随机读的部分适合对象存储的吞吐比缓存盘还高的情况。

默认为

读一般有两种模式连续读和随机读。

对于连续读一般需要较高的吞吐。

对于随机读一般需要较低的时延。

当本地磁盘的吞吐反而比不上对象存储时可以考虑启用

--cache-partial-only这样一来连续读虽然会将一整个对象块读取下来但并不会被缓存。

而随机读例如读

Parquet

footer所读取的字节数比较小不会读取整个对象块此类读取就会被缓存。

充分地利用了本地磁盘低时延和网络高吞吐的优势。

客户端写缓存​

开启客户端写缓存能提升特定场景下的大量小文件写入性能请详读本节了解。

JuiceFS

fsync()时才会触发数据上传对象存储。

为了确保数据安全性客户端会等数据上传完成才提交到元数据服务。

由于默认的写入流程是「先上传再提交」可想而知大量小文件写入时这样的流程将影响写入性能。

启用客户端写缓存以后写入流程将改为「先提交再异步上传」写文件不会等待数据上传到对象存储而是写入到本地缓存中的文件数据会在后台异步上传至对象存储。

如果你的场景需要写入大量临时文件不需要持久化和分布式访问也可以用

--upload-delay

参数来设置延缓数据上传到对象存储如果在等待的时间内数据被应用删除则无需再上传到对象存储既提升了性能也节省了成本。

相较于本地硬盘而言JuiceFS

提供了后端保障在缓存目录容量不足时依然会自动将数据上传确保在应用侧不会因此而感知到错误。

挂载时加入

本地缓存本身的可靠性与缓存盘的可靠性直接相关如果在上传完成前本地数据遭受损害意味着数据丢失。

因此对数据安全性要求越高越应谨慎使用。

待上传的文件默认存储在

/var/jfsCache/UUID/rawstaging/只要该下的文件否则将造成数据丢失。

写缓存大小由

--free-space-ratio

的磁盘空间。

写缓存和读缓存共享缓存盘空间因此会互相影响。

例如写缓存占用过多磁盘空间那么将导致读缓存的大小受到限制反之亦然。

如果本地盘写性能太差带宽甚至比不上对象存储那么

--writeback

会带来更差的写性能。

如果缓存目录的文件系统出错客户端则降级为同步写入对象存储情况类似客户端读缓存。

如果节点到对象存储的上行带宽不足网速太差本地写缓存迟迟无法上传完毕此时如果在其他节点访问这些文件则会出现读错误。

低带宽场景的排查请详见「与对象存储通信不畅」。

也正由于写缓存的使用注意事项较多使用不当极易出问题我们推荐仅在大量写入小文件时临时开启比如

解压包含大量小文件的压缩文件软件编译大数据任务的临时存储场景比如

Spark

juicefs_staging_block_delay_seconds

46116860185.95535

Linux/var/jfsCachemacOS$HOME/.juicefs/cacheWindows%USERPROFILE%\.juicefs\cache

Linux

建议缓存目录尽量使用独立的高性能盘不要用系统盘也不要和其它应用共用。

共用不仅会相互影响性能还可能导致其它应用出错例如磁盘剩余空间不足。

如果无法避免必须共用那一定要预估好其它应用所需的磁盘容量限制缓存空间大小--cache-size避免

JuiceFS

的缓存路径使用它的容量一般是内存的一半可以根据需要手动调整容量例如将缓存盘的容量调整为

32GB

相比好处是简单不依赖外部设备但相应地也无法持久化一般在测试评估的时候使用。

共享目录​

等共享作为缓存路径可以有效缓解多个设备重复预热缓存的带宽压力。

SMB/CIFS

~/jfscache:/mnt/jfscache:/dev/shm/jfscache

/mnt/myjfs当设置了多个缓存中的数据总大小。

客户端会采用哈希策略向各个缓存路径中均匀地写入数据无法对多块容量或性能不同的缓存盘进行特殊调优。

--cache-dir

0.1。

因为缓存的写入策略是均匀写入所以分配给每个缓存的缓存空间最大为

2GiB