JuiceFS V1.0 RC1 发布，大幅优化 dump/load 命令性能，深度用户不容错过-低调大师

JuiceFS V1.0 RC1 发布，大幅优化 dump/load 命令性能，深度用户不容错过

2022-06-17 428

JuiceFS v1.0 RC1 今天正式发布了！这个版本中，最值得关注的是对元数据迁移备份工具 dump/load 的优化。

这个优化需求来自于某个社区重度用户，这个用户在将亿级数量文件的元数据从 Redis 迁移至 TiKV 时遇到了内存占用过高的问题，我们接到反馈后着手优化，最终使 dump 所需内存降低 95%，load 所需内存降低 80%。

下面，我们来为你详细解读一下 JuiceFS v1.0 RC1 的主要变化。

元数据迁移备份工具 dump/load 命令的优化

现有的 dump 命令实现中，会先将元数据引擎中的所有数据加载到客户端内存，形成一个类似只读快照的版本，再按照文件系统树型结构输出到指定文件。得益于 Redis 本身的高速随机读性能，v1.0 RC1 优化了 Redis 作为元数据引擎时的 dump 流程，不再做整个快照，而是一边预读一边输出，使其所需内存节省 95%，速度提升 100%。从 SQL 和 TiKV 备份元数据时，会使用单个事务来读数据以确保整个文件系统的一致性。

现有的 load 命令实现中，会先加载整个元数据集合，再并发导入到元数据引擎中。v1.0 RC1 对所有元数据引擎都做了优化，实现了流式加载功能，同样将其所需内存节省 80%，速度提高 25%。

以 Redis 元数据引擎 Dump & Load 一千万文件为例子，v1.0 Beta3 与 v1.0 RC1 的性能对比如下：

很多用户是一开始使用 Redis 作为元数据引擎，随着数据规模的增长，可能需要迁移到 TiKV 或者 SQL 引擎，这些优化可以保证用户在有上亿文件时仍然能够高效地完成元数据引擎的迁移。

后续我们也会详细解析此次 dump/load 命令优化的技术细节，敬请期待。

新增对象存储测试工具 objbench

对象存储是 JuiceFS 的底座，当用户在使用 JuiceFS 遇到问题时经常不确定是 JuiceFS 的问题还是对象存储的问题，所以我们在 v1.0 RC1 中新增 objbench 命令来帮助用户验证某个对象存储是否被 JuiceFS 支持以及测试与其共同使用时的性能表现。具体请参考JuiceFS Objbench 文档

新支持对接持续性能分析平台 Pyroscope

受 Go 圈技术大牛「鸟窝」的一篇可观测性实践博客的启发，我们想到了在 JuiceFS 中对接持续性能分析工具，一改 JuiceFS 过去只能通过 pprof 这个分析工具肉眼排查的窘境。于是在这个版本中，我们对接了 Pyroscope（一个开源的持续性能分析平台），通过这个工具，可以记录分析 JuiceFS 的运行状态，例如某段时间内 JuiceFS 代码中函数的 CPU 耗时、对象分配大小等细节数据。请参考使用 Pyroscope 文档了解如何在 JuiceFS 中使用 Pyroscope。

其它新增

新支持 SQL 数据库、etcd 做数据存储，具体请参考JuiceFS 设置对象存储文档。
新支持 juicefs info 命令中根据文件 inode 找到其完整路径

注意：查找在 v1.0 RC1 之前创建的文件时，可能出现路径查找不到或者路径不全的情况。

新增 juicefs rmr 和 juicefs warmup 命令的进度条，并允许中断操作。

注意：使用 v1.0 RC1 的 JuiceFS 客户端操作 v1.0 RC1 之前的挂载点时，会显示一直没有进度，但实际命令能够正常执行。

其它调整

大幅提升 SQL 元数据引擎的稳定性。我们在对 JuiceFS S3 网关进行压力测试的过程中发现了 SQL 元数据引擎在高负载下的一些问题，其中包括所使用的 ORM 框架的几个 bug，都进行了修复并反馈给上游。
限制了单次清理回收站和文件缓存的数量，提高了在大规模应用下的稳定性。
支持在容器内使用 juicefs warmup 命令
提升 juicefs rmr 命令的性能并减低内存使用
juicefs sync 命令也进行了增强，改进了使用免密登录 SSH 拷贝数据的情况，修复了几个 bug。
支持通过 juicefs config 命令动态修改数据存储的 Access Key 和 Secret Key
大量的错误日志描述优化

支持通过 juicefs config 命令动态修改数据存储的 Access Key 和 Secret Key

Bug 修复

修复了 juicefs sync 读取源端文件失败时未打印错误日志的问题
修复了只读客户端无法执行 warmup 的问题
修复了大量删除文件时因 0 号 Slice 导致事务频繁冲突的问题
修复了 SQL 类数据库作元数据引擎时，操作事务性未完全保证的问题
修复了使用 TiKV 作元数据引擎时，可能因空连接导致 JuiceFS 客户端 panic 的问题
修复了 List 元数据备份失败时，可能导致 JuiceFS 客户端 panic 的问题

升级建议

使用 SQL 类数据库作元数据引擎的文件系统：请务必升级
使用其它元数据引擎的文件系统：建议升级

介绍了这么多，大家赶紧点此上手试试吧～

微信关注我们

原文链接：https://www.oschina.net/news/199878/juicefs-1-0-rc1-released

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

《灯灯》多租户快速开发平台 4.7.0 发布，专注多租户解决方案

4.7.0 - 正式版更新详情: build spring-cloud-dependencies.version>2021.0.3 mybatis.version>3.5.10 mybatis-spring.version>2.0.7 mybatis-plus.version>3.5.2 nacos.version>2.1.0 feat: 新增员工支持填写用户登录名可视化代码生成器生成新项目/新服务时，新增下载功能可视化代码生成器支持批量编辑表生成信息可视化代码生成器支持批量预览代码可视化代码生成器支持批量生成代码可视化代码生成器支持批量下载代码 refactor 前端模板注释和内容优化调整 SuperReadController 泛型在 logback.xml 中生成必要的日志信息机构维护页面Tree结构显示部门类型员工维护&岗位维护页面优化：选中"本级及子级"立即执行查询 & 查询页面默认不可勾选 fix 修复 WebConfiguration.java 类不能同时适配cloud和boot...

2022-06-17

559

1 LRU 缓存介绍 LRU 算法全称是最近最少使用算法（Least Recently Use），是一种简单的缓存策略。顾名思义，LRU 算法会选出最近最少使用的数据进行淘汰。那么什么是缓存呢？缓存专业点可以叫一种提高数据读取性能的技术，可以有效解决存储器性能和容量的矛盾，是一种空间换时间的设计思想，比如我们常见的内存是硬盘的缓存，Cache 是内存的缓存，浏览器本地存储是网络访问的缓存...... LRU 有许多应用场景，例如：操作系统底层的内存管理。缓存服务，例如 Redis，当数据满的时候就要淘汰掉长期不使用的 key，在 Redis 中用了一个类似的 LRU 算法，而不是严格的 LRU 算法。 MySQL 的 Buffer Pool，也就是缓冲池，它的目的是为了减少磁盘 IO。它是一块连续的内存，当 Buffer Pool 满的时候就要淘汰很久没有被访问过的页。 2 Leetcode 真题 146. LRU 缓存 [1]，请你设计并实现一个满足 LRU (最近最少使用) 缓存约束的数据结构。实现 LRUCache 类： LRUCache(int capacity) 以正...

2022-06-17

533

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。