一次CephFS性能分析

最新推荐文章于 2024-07-09 10:19:01 发布
原创 最新推荐文章于 2024-07-09 10:19:01 发布
· 1.4k 阅读 · 2 ·
版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#linux #ceph

一次CephFS性能分析

1. 背景

小明在使用文件系统的过程中发现上传一个文件夹花了半个小时，下载一个文件夹要花更长的时间，不可思议，确实下载速度应该远远大于上传速度的，我们来分析下问题出在哪

文件的情况:

  • 文件大小: 6.3G
  • 文件个数: 252494
  • 小明使用文件系统作为容器的持久化存储

2. 性能分析思路

2.1. 理论值计算

一切分析从数据出发，首先看下正常应该是怎么样的

hdd 下一般磁盘 4k 随机写 iops为1000左右

  • 测算依据
    • 文件个数
    • 文件大小
    • 4k的iops 1000左右
  • 测算过程
    • 6.3G / 252494 平均每个文件大小 26k
    • 对应的26k的iops 26/4=6.5 1000/6.5 = 153

也就是说理论上传时间需要28分钟 252494 / 153 / 60 = 28

2.2. 实际操作下看能不能复现

将文件系统挂载到跟有问题的环境网络环境差不多的虚拟机上

拷贝文件

2.2.1. 性能分析关注点

一切性能问题，要么是CPU计算不过来了，要么是内存满了(使用swap)，要么是磁盘慢、网络繁忙

加粗的指标重点关注

  • CPU、内存
    文件系统的话服务端是MDS，传输过程中查看MDS的内存占用和CPU占用
  • 磁盘压力
    • ceph层面的io性能指标
      • ceph -s输出中的 client.io
      • ceph osd perf|sort -rnk 20 有没时延特别高的上百的
    • 本地磁盘的io性能
      • iostat
        • r/s 读ops
        • w/s 写ops
        • rMB/s 读带宽
        • wMB/s 写带宽
        • await 时延
        • %util 利用率

2.2.2. 开始分析

上传文件的过程中分析

2.2.2.1. ceph -s
    client:   0 B/s rd, 3.5 MiB/s wr, 72 op/s rd, 461 op/s wr

关注这行，正常的hdd集群有压力的时候前两个数值其中一个在100以上，后面两个数值至少在1000以上，在上传过程都没超过，说明集群本身没问题

2.2.2.2. 查看mds服务

ceph fs status 可以看到哪个是主mds，请求只到主mds上

cephfs - 11 clients
======
+------+--------+--------+---------------+-------+-------+
| Rank | State  |  MDS   |    Activity   |  dns  |  inos |
+------+--------+--------+---------------+-------+-------+
|  0   | active | ceph01 | Reqs:    0 /s |  408k |  408k |
+------+--------+--------+---------------+-------+-------+

查看主mds cpu 内存等等信息 top 进去按大P 按cpu排序，按大M 按内存排序，一般单进程CPU使用率超过100就是不正常的表现，内存超过10%就是不正常的表现

实际环境CPU没超过百分之10 内存没超过百分之10

top -p 2727890 -H -b
top - 19:24:56 up 75 days,  2:37,  1 user,  load average: 0.43, 0.66, 0.70
Threads:  23 total,   0 running,  23 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.3 us,  0.2 sy,  0.0 ni, 99.4 id,  0.1 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem : 39541984+total, 33606768+free, 42129292 used, 17222856 buff/cache
KiB Swap: 33554428 total, 33554428 free,        0 used. 35048332+avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
2727890 ceph      20   0 6290512   1.3g  14148 S  0.0  0.4   0:00.11 ceph-mds
2727952 ceph      20   0 6290512   1.3g  14148 S  0.0  0.4  13:30.88 log
2728015 ceph      20   0 6290512   1.3g  14148 S  0.0  0.4  75:51.41 msgr-worker-0
2728016 ceph      20   0 6290512   1.3g  14148 S  0.0  0.4  71:19.25 msgr-worker-1
2728017 ceph      20   0 6290512   1.3g  14148 S  0.0  0.4  67:40.65 msgr-worker-2
2728080 ceph      20   0 6290512   1.3g  14148 S  0.0  0.4   0:26.70 service
2728081 ceph      20   0 6290512   1.3g  14148 S  0.0  0.4   0:00.00 admin_socket
2728082 ceph      20   0 6290512   1.3g  14148 S  0.0  0.4   0:00.00 signal_handler
2728083 ceph      20   0 6290512   1.3g  14148 S  0.0  0.4  65:18.79 ms_dispatch
2728084 ceph      20   0 6290512   1.3g  14148 S  0.0  0.4   0:00.00 ms_local
2728085 ceph      20   0 6290512   1.3g  14148 S  0.0  0.4   0:27.69 safe_timer
2728086 ceph      20   0 6290512   1.3g  14148 S  0.0  0.4   0:00.00 fn_anonymous
2728089 ceph      20   0 6290512   1.3g  14148 S  0.0  0.4   7:20.45 safe_timer
2728090 ceph      20   0 6290512   1.3g  14148 S  0.0  0.4   1:10.62 ceph-mds
2728953 ceph      20   0 6290512   1.3g  14148 S  0.0  0.4   3:30.28 safe_timer
2730059 ceph      20   0 6290512   1.3g  14148 S  0.0  0.4   0:21.43 ms_dispatch
2730060 ceph      20   0 6290512   1.3g  14148 S  0.0  0.4   7:16.65 OpHistorySvc
2730061 ceph      20   0 6290512   1.3g  14148 S  0.0  0.4 390:42.70 ms_dispatch
2730063 ceph      20   0 6290512   1.3g  14148 S  0.0  0.4   7:26.51 mds_rank_progr
2730064 ceph      20   0 6290512   1.3g  14148 S  0.0  0.4   5:37.53 PQ_Finisher
2730065 ceph      20   0 6290512   1.3g  14148 S  0.0  0.4   0:59.75 safe_timer
2730066 ceph      20   0 6290512   1.3g  14148 S  0.0  0.4 653:34.07 fn_anonymous
2730068 ceph      20   0 6290512   1.3g  14148 S  0.0  0.4  18:55.23 md_submit
2.2.2.3. 查看ceph osd perf

osd perf是osd时延的展示ceph集群的网络时延+磁盘时延，正常在100之内，实际在10以内

ceph osd perf |sort -rnk 3
osd commit_latency(ms) apply_latency(ms)
  9                  0                 0
  8                  0                 0
  7                  0                 0
  6                  0                 0
  5                  0                 0
  4                  0                 0
  3                  0                 0
 23                  0                 0
2.2.2.4. 查看磁盘iostat

利用率很高 百分之90以上就算压力特别大，时延高于100就算比较高，实际环境都很小

iostat -hmx 2
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.27    0.00    0.11    0.03    0.00   99.59

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda
                  0.00     0.00    0.00    6.00     0.00     0.56   190.00     0.00    0.00    0.00    0.00   0.00   0.00
sdb
                  0.00     0.50    3.50   37.00     0.01     0.38    19.95     0.00    0.05    0.00    0.05   0.02   0.10
sde
                  0.00     0.00    2.00   14.00     0.01     0.12    16.75     0.01    0.62    5.00    0.00   0.62   1.00

以上几个点说明集群没问题了 问题只能出在客户端或者客户端与集群之间的网络

2.2.2.5. 网络

网络可以通过交换机监控，网口监控等方式，或者sar命令查看(粒度比较粗)，实际操作比较麻烦，放在后面在查

2.2.2.6. 客户端磁盘

iostat 查看到磁盘利用率百分百了，破案！ 整个链路的瓶颈就是这里了
请添加图片描述

3. 总结

  • 通过理论数值判断快慢是否合适
  • 通过io链路排查找出io瓶颈

最后，小明说的下载了半天没有复现，从服务端来看，如果太慢集群会有满请求，集群有满请求ceph-mgr会有记录，查看集群一切正常，所以问题应该出在客户端/网络，下次再出现就可以在这两块优先下手排查了

CephFS性能基准测试与集群优化 | 万字总结
NewTyun的博客
09-16 1935
新钛云服已为您服务1256天本次测试的目的是通过使用 INTEL SSD PEYKX040T8 NVMe 驱动器从而在 Ceph 集群（特别是 CephFS）中实现最大的性能。同时为了保证...
Ceph性能瓶颈分析与优化(混合盘篇)
NetEaseResearch的博客
07-14 4715
背景 企业级存储中，SSD+HDD的混合盘是一种典型应用场景，可以兼顾成本、性能与容量。 但网易数帆存储团队经过测试(4k随机写)发现，加了NVMe SSD做Ceph的WAL和DB后，性能提升不足一倍且NVMe盘性能余量较大。所以我们希望通过瓶颈分析，探讨能够进一步提升性能的优化方案。 测试环境 Ceph性能分析一般先用单OSD来分析，这样可以屏蔽很多方面的干扰。 我们的测试环境如下所示，1个OSD： usrname@hostname:~/cluster$ sudo ceph osd tree ID CLA
对CephFS进行性能测试
weixin_39132936的博客
07-24 1409
对CephFS进行性能测试 cephfs 内核： 3.10.0-327.el7.x86_64 内存：256g 操作系统版本：centos 7.2.1511 OSD_count=3 每个osd容量5.5T，共16.5T Pool 副本数：3 stripe_unit=4M stripe_count=1 object_size=4M 一 . iozone测试 1. iozone安装 wget http://www.iozone.org/src/current/iozone3_486.
Ceph文件系统FS性能测试
weixin_34384557的博客
04-25 1088
2019独角兽企业重金招聘Python工程师标准>>> ...
Ceph性能测试（RBD、CephFS、NFS、Cache Tier）
热门推荐
刘康的专栏
08-19 1万+
本文是以下两篇文章的后续： 探索fio参数如何选择以及全方位对比HDD和SSD性能：部署Ceph前测试磁盘性能，同时基于fio测试参数的变化深入了解fio原理和磁盘IO特点。 CentOS8使用cephadm部署和配置Ceph Octopus：在CentOS8上使用cephadmin进行Ceph Octopus版本的部署，以及RBD、CephFS、NFS、RGW等的配置。 准备工作 首先，单独准备一台测试节点，起一个CentOS8的虚拟机，配好地址和万兆网络。 确保网络带宽 使用iperf3工具测试.
【ceph】cephfs内核客户端到MDS的Lookup流程分析--未消化
小鱼菜鸟的博客
07-22 539
在文件系统中读写文件时，一般需要先得到操作对象的索引inode信息，在客户端未缓存的情况下，除了调用open外，客户端也会下发lookup或者getattr命令到服务端去获取操作对象的inode。Lookup和getattr IO的mds端流程几乎一致，所以以lookup流程为例进行介绍。 客户端以linux 4.18内核源码(cephfs的内核客户端...
分布式存储Cephfs读取优化方案.docx
10-13
Cephfs是一个基于Ceph的、可扩展的、高可用的文件系统，它为用户提供了一种在分布式环境中存储和访问大量数据的方式。然而，随着数据量的增长，读取效率成为了影响系统性能的关键因素。本方案旨在探讨Cephfs的读取...
在高密服务器上对 CephFS 的性能与成本进行评估
NewTyun的博客
03-03 2429
新钛云服已为您服务1418天摘要CephFS 是建立在可靠自主分布式对象存储 (RADOS) 之上的网络文件系统。在 CERN，我们已经在几个运行 100 到 1000TB 的集群上展示了...
cephfs slow request 解决
Terry Tsang
07-09 717
cephfs slow request 分析方法
CephFS 文件布局性能测试对比
weixin_44389885的博客
01-09 1168
1. 设置不同的object size进行测试 1.1 object size 4M #上传到挂载目录 $ ll -lh /mnt/object_size_4M/ total 2.7G -rw-r--r-- 1 root root 832M Jun 21 11:09 alchemy-api.error.log._test_1G -rw-r--r-- 1 r...
Ceph IO 路径和性能分析-王豪迈
09-21
独立开源软件开发者王豪迈分享《Ceph IO 路径和性能分析》
GlusterFS与Ceph 性能测试报告
09-17
GlusterFS与Ceph是不一样的存贮系统，GlusterFS更加针对分布式文件系统，虽然目前开发者也正在努力增加块与对象存贮服务。 由于两者在设计理念等各个方面有所不同，单纯的测试比较从功能应用的角度来说意义不大（如人们需要块及对象存贮时，目前GlusterFS只能部分提供或没有，块存贮也只能用于非生产环境，对象存贮还没有），但很多人使用时均会考虑将此两者文件服务作为其中一个重要应用，而同时，市场上流传着各类关于GlusterFS与Ceph对比的各类性能数据，实际情况倒底如可，我们不得而知，但我确实想知道真实的情况如何，或者大概的也行
CephFS 异常测试
weixin_44389885的博客
12-21 521
1. Cephfs 异常测试方案 CephFS允许客户端缓存metadata 30s，所以这里测试对MDS stop/start的时间间隔取为：2s，10s，60s。 测试组件 测试场景 挂载方式 测试方法 MDS 单MDS fuse/kernel 单个MDS挂掉情况 2s/10s/60s IO情况 主从MDS时 fuse/kernel 单主挂掉情况 2s/10...
cephfs调优 & 性能测试 & 监控 & 常用命令
ywq935的博客
09-15 9732
前言 k8s对ceph rbd模式不支持ReadWriteMany（RWX）,为了满足k8s的灵活性需求,采用支持多点挂载的cephfs工作模式.网上少有针对cephfs调优的文章,因此在本篇,将针对cephfs进行一些参数调优及性能测试 硬件规划 配置调优 经过多次的对参数反复调整,将ceph.conf修改成如下配置,比较适合我们的使用场景: # cat /etc/ceph/c...
ceph性能统计实现
sefaxiaoji的博客
04-29 465
https://www.jianshu.com/p/0ddfc9992a79
分布式存储Cephfs读取优化方案
weixin_44389885的博客
09-30 1754
1.背景说明 继上次分享的 Ceph介绍及原理架构分享 和 分布式存储Ceph之PG状态详解 ，这次分享点干货。 用户需要从cephfs存储系统中检索一个大文件指定关键字的一行信息， 并且对延迟和性能要求比较高。 2. 原始方案 2.1 流程图 image.png 2.2 说明 假如用户拉取的文件大小是16M, 文件按照4M切分，散落到四个数据片上 用户首先请求ce...
Linux IO实时监控iostat命令详解
weixin_33904756的博客
01-13 642
简介 iostat主要用于监控系统设备的IO负载情况，iostat首次运行时显示自系统启动开始的各项统计信息，之后运行iostat将显示自上次运行该命令以后的统计信息。用户可以通过指定统计的次数和时间来获得所需的统计信息。   语法 iostat [ -c ] [ -d ] [ -h ] [ -N ] [ -k | -m ] [ -t ] [ -V ] [ -x ] [ -z ] [ ...
ceph性能估算
weixin_45437959的博客
04-10 781
ceph读写性能估算
Kubernetes Cephfs & Ceph RBD 在k8s中的适用场景讨论及数据库性能压测
小楼一夜听春雨，深巷明朝卖杏花
08-24 1565
测试发现cephfs的小文件读写性能一般,且写入延迟偏高,性能不甚满意,但是满足于日常应用环境的读写是没有问题的,但是在面对数据库的应用场景,是否能满足性能要求呢? 本篇主要结合kubernetes,针对数据库应用场景,对cephfs 和 ceph rbd这两种ceph存储接口来进行性能对比测试. 适用场景讨论 Cephfs: 优点: 1.读取延迟低,I/O带宽表现良好,尤其是block size较大一些的文件2.灵活度高,支持k8s的所有接入模式 缺点: 1.写入延迟相对较高且延迟时间不稳定 适
juicefs cubefs cephfs
最新发布
01-24
### 不同分布式文件系统的特性和差异 #### JuiceFS 特性 JuiceFS 是一种高性能的分布式文件系统，专为云环境设计。其主要特点包括支持多种存储后端、高可用性和弹性扩展能力。通过集成对象存储服务作为底层数据持久化层，JuiceFS 提供了良好的性能和成本效益平衡。 - 支持 POSIX 文件接口访问方式。 - 可配置元数据引擎来优化读写操作效率[^1]。 #### CubeFS 特性 CubeFS 同样是一个分布式的文件系统解决方案，专注于大规模数据分析场景下的高效处理需求。它具备如下优势： - 高效的数据压缩机制有助于减少磁盘占用并提升传输速度。 - 自动化的分片管理简化运维工作量的同时提高了集群稳定性。 - 内置冗余保护措施保障数据安全可靠[^2]。 #### CephFS 特性 CephFS 构建于 Ceph 存储平台之上，提供了一个兼容POSIX标准的文件系统界面给应用程序使用。该方案具有以下亮点： - 完整实现了 POSIX 协议栈使得传统应用无需修改即可无缝迁移至云端部署模式下运行。 - 动态调整副本数量以适应不同业务负载变化情况下的SLA要求。 - 强大的社区支持以及丰富的插件生态体系方便二次开发定制功能模块[^3]。 #### 性能对比分析 从查询性能角度来看，在某些特定条件下 Pinot 的排序特性可能优于 Druid ，这可能是由于前者提供了开箱即用的支持而后者则需手动实现复杂逻辑所致；然而这种差异并不适用于上述三种文件系统之间直接比较因为它们各自面向的应用领域有所区别[^4]。 对于空间消耗而言，Pinot 中有效的数据排列可以带来更佳的压缩效果从而节省更多资源——这一点同样不是衡量这三个目标时的关键考量因素之一[^5]。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值