MemCache UBS_IO功能使用文档
1. 功能介绍
MemCache的UBS_IO功能是一种扩展存储能力的特性,允许系统在内存池空间不足时将数据迁移到SSD存储,从而构建"HBM + DRAM + SSD"三级内存池架构。
1.1 核心优势
- 扩展存储容量:通过SSD提供海量存储空间,突破内存容量限制
- 保持性能体验:热数据保留在内存中,冷数据自动迁移到SSD
- 统一操作接口:使用与内存操作完全一致的API,无需修改应用代码
- 智能数据管理:根据访问频率自动在不同层级存储间迁移数据
1.2 工作原理
- 数据淘汰:当DRAM池空间不足时,触发淘汰机制,将冷数据写入SSD
- 数据查询:使用exist接口时,先查询内存池,未命中则查询SSD
- 数据读取:使用get接口时,先尝试从内存池读取,未命中则从SSD读取并异步写回内存池
- 数据写入:使用put接口时,数据先写入内存池,后续根据热度可能迁移到SSD
2. 架构设计
2.1 系统架构
MemCache的SSD功能基于UBS_IO(Unified Block Storage IO)子系统实现,整体架构如下:
┌─────────────────┐
│ 应用层 │
│ (MemCache API) │
└────────┬────────┘
│
┌────────▼────────┐
│ UBS_IO代理层 │
│ (MmcUbsIoProxy) │
└────────┬────────┘
│
┌────────▼──────────────┐
│ UBS_IO KV Cache接口层 │
│ (DlUbsioKvcApi) │
└────────┬──────────────
│
┌────────▼──────────────────┐
│ 存储层 │
│ (UBS_IO KV Cache库 + SSD) │
└──────────────────────────┘
2.2 核心组件
| 组件 | 职责 | 实现文件 |
|---|---|---|
| MmcUbsIoProxy | UBS IO代理,提供统一的存储接口 | src/memcache/csrc/under_api/ubs_io/mmc_ubs_io_proxy.h/cpp |
| DlUbsioKvcApi | 动态加载UBS_IO KV Cache库的接口封装 | src/memcache/csrc/under_api/ubs_io/dl_UbsioKvc_api.h/cpp |
| UBS_IO KV Cache库 | Unified Block Storage KV Cache缓存库,处理SSD存储操作 | 外部依赖:libubsio_kvc.so |
2.3 数据流向
- 写入路径:应用 → MemCache API → 内存池 → (淘汰) → UBS_IO代理 → UBS_IO KV Cache库 → SSD
- 读取路径:应用 → MemCache API → 内存池(命中) → 返回
- 未命中:应用 → MemCache API → 内存池 → UBS_IO代理 → UBS_IO KV Cache库 → SSD → 内存池 → 返回
3. 环境准备
3.1 硬件要求
- SSD存储:需要至少一块SSD用于存储冷数据
- 内存:建议配置足够的DRAM作为热数据缓存
3.2 软件依赖
-
UBS_IO KV Cache库:需要安装UBS_IO KV Cache库
- 安装方法:参考UBS IO
- 库文件:libubsio_kvc.so
-
MemCache:确保使用支持SSD功能的版本
- 从MemCache仓库获取最新代码
3.3 环境检查
在启用SSD功能前,确保:
- SSD已正确安装并挂载
- UBS_IO KV Cache库已正确安装且可被系统找到
- MemCache已正确编译和安装
4. 配置说明
4.1 配置文件修改
需要修改以下配置文件以启用SSD功能:
4.1.1 LocalService配置
编辑config/mmc-local.conf文件,修改以下配置:
# 启用UBS IO功能
ock.mmc.ubs_io.enable = true
4.1.2 MetaService配置
编辑config/mmc-meta.conf文件,修改以下配置:
# 启用UBS IO功能
ock.mmc.ubs_io.enable = true
4.2 配置参数说明
| 配置项 | 默认值 | 说明 |
|---|---|---|
| ock.mmc.ubs_io.enable | false | 是否启用UBS IO功能,true为启用,false为禁用 |
5. 使用示例
5.1 基本使用
启用SSD功能后,用户无需修改任何应用代码,完全无感知使用:
- 自动数据管理:当DRAM池空间达到阈值时,系统会自动触发淘汰机制,将冷数据写入SSD存储
- 透明读取路径:使用get接口时,系统会先从DRAM池中读取数据,若未命中则自动从SSD中读取,并异步将数据写回DRAM池
- 统一操作接口:所有API调用与未启用SSD功能时完全一致,包括Put、Get、Exist、Remove等操作
5.2 批量操作
SSD功能同样支持批量操作,使用方式与原逻辑完全一致,系统会自动处理不同存储层级的数据:
- 批量写入:数据先写入DRAM池,后续根据热度可能迁移到SSD
- 批量读取:系统会自动从合适的存储层级读取数据
- 批量检查:系统会自动在多个存储层级中检查数据存在性
5.3 调用方式
启用SSD功能后,调用方式与原MemCache完全一致,无需任何修改。具体调用方式请参考MemCache的原始使用文档和示例代码。
6. 性能优化建议
6.1 内存配置优化
- DRAM大小:根据应用访问模式和数据量,设置合适的DRAM大小,建议至少为活跃数据集的2-3倍
- HBM使用:如果有Ascend硬件,充分利用HBM存储最热数据
6.2 访问模式优化
- 批量操作:尽量使用批量操作API,减少IO次数
- 数据局部性:优化应用访问模式,提高数据局部性,减少跨层级访问
- 缓存预热:对于重要数据,可在系统启动时进行缓存预热
6.3 SSD使用优化
- SSD选择:选择高性能SSD,尤其是IOPS和延迟表现好的型号
- SSD配置:确保SSD有足够的空间,建议预留20%以上的空闲空间
- 文件系统:选择适合SSD的文件系统,如ext4或xfs
7. 监控与维护
7.1 监控指标
启用SSD功能后,建议监控以下指标:
- 内存使用率:DRAM和HBM的使用情况
- SSD使用率:SSD存储空间的使用情况
- IO延迟:不同层级的读写延迟
- 数据命中率:内存命中率,反映数据热度分布是否合理
7.2 常见问题排查
| 问题 | 可能原因 | 解决方案 |
|---|---|---|
| SSD写入失败 | UBS_IO KV Cache库未正确安装 | 检查UBS_IO KV Cache库安装情况,确保libubsio_kvc.so可被找到 |
| 性能下降 | 内存配置过小 | 增加DRAM内存池大小,减少SSD访问频率 |
| 数据丢失 | SSD故障 | 确保SSD健康状态良好,考虑使用RAID配置 |
| 初始化失败 | 配置错误 | 检查配置文件中ock.mmc.ubs_io.enable是否正确设置 |
8. 注意事项
- 功能状态:SSD功能目前处于"支持中"状态,可能存在一些功能限制
- 性能差异:SSD的读写性能比内存低,主要用于存储冷数据
- 数据一致性:系统确保数据一致性,但在极端情况下可能需要额外的数据备份策略
- 依赖管理:确保UBS_IO KV Cache库版本与MemCache版本兼容
- 配置同步:LocalService和MetaService的配置需要保持一致,特别是UBS_IO相关配置
9. 总结
MemCache的UBS_IO功能为大模型推理等内存密集型应用提供了一种扩展存储容量的有效方案。通过构建"HBM + DRAM + SSD"三级内存池,系统能够在保持高性能的同时,显著提升存储容量,满足更大规模数据处理的需求。
使用SSD功能时,只需修改配置文件启用UBS_IO,无需修改应用代码,即可享受扩展存储带来的好处。通过合理的内存配置和访问模式优化,可以进一步提升系统性能,为应用提供更好的使用体验。
随着SSD功能的不断完善,MemCache将成为大模型推理场景下更加强大和灵活的存储解决方案。