2KB项目,专业的源码交易网站 帮助 收藏 每日签到

Ceph 性能调优

  • 时间:2020-03-03 23:56 编辑:2KB 来源:2KB.COM 阅读:1149
  • 扫一扫,手机访问
  • 分享
摘要:
Ceph 英文原文:Ceph Bobtail JBOD Performance Tuning

介绍

一个让ceph强大的原因就是ceph提供了一系列的可调整的选项。你可以控制ceph管道中的多少数据以及多少操作被缓存。你可以定制不同的清除策略,或者更改文件存储操作的线程数。不利的一面是,要深入研究可能有点吓人,甚至让人不知道如何下手。在Inktank我们得到了很多关于这些选项如何影响性能的问题。答案往往是视情况而定。不同的硬件和软件配置将有利于不同Ceph选项。为了让人们知道什么东西可能值得看,我们决定过一遍一些最有可能会对性能产生影响的选项。本文中,使用磁盘JBOD配置时,我们将看到不同的ceph参数。

因为Inktank是愿意支付我画网络漫画(嗨伙计们!),我看到的一切就相当于下面这幅画。

在我们继续之前,如果你不是很很熟悉ceph的配置,这是关于ceph的配置文档。 一旦你对此有所了解,你要查看的可调参数在这里: here。 

系统设置

我们将使用SAS2208 控制器进行这个测试。这支持JBOD,多重RAID0,单RAID0配置。不幸的是不同的控制器上的表现也不同,所以这些结果可能并不代表其他控制器。希望他们至少会提供一个初始的起点,或许想类似的配置如何执行。

硬件配置包括:

  • Chassis: Supermicro 4U 36-drive SC847A

  • Motherboard: Supermicro X9DRH-7F

  • Disk Controller: On-board SAS2208

  • CPUS: 2 X Intel XEON E5-2630L (2.0GHz, 6-core)

  • RAM: 8 X 4GB Supermicro ECC Registered DDR1333 (32GB total)

  • Disks: 8 X 7200RPM Seagate Constellation ES 1TB Enterprise SATA

  • NIC: Intel X520-DA2 10GBE

软件配置:

  • OS: Ubuntu 12.04

  • Kernel: 3.6.3 from Ceph’s GitBuilder archive

  • Tools: blktrace, collectl, perf

  • Ceph: Ceph “next” branch from just before the 0.56 bobtail release.

测试设置

写了一个python工具来读取YAML配置文件,以及根据不同的参数设置自动生成ceph.conf配置文件。然后我们使用基准测试工具对每个配置文件进行测试。一些参数配置将被组合在一起以减少总的测试数量。以下YAML文件片段展示了不同的设置。

default:
  global:
    log_to_syslog: "false"
    log_file: "/var/log/ceph/$name.log"
    auth_cluster_required: "none"
    auth_service_required: "none"
    auth_client_required: "none"
    filestore_xattr_use_omap: "true"

  mon:
    mon_osd_data: "/srv/mon.$id"
  mon.a:
    host: "burnupiX"
    mon_addr: "127.0.0.1:6789"

parametric:
  debugging_off:
    debug_lockdep: "0/0"
    debug_context: "0/0"
    debug_crush: "0/0"
    debug_mds: "0/0"
    debug_mds_balancer: "0/0"
    debug_mds_locker: "0/0"
    debug_mds_log: "0/0"
    debug_mds_log_expire: "0/0"
    debug_mds_migrator: "0/0"
    debug_buffer: "0/0"
    debug_timer: "0/0"
    debug_filer: "0/0"
    debug_objecter: "0/0"
    debug_rados: "0/0"
    debug_rbd: "0/0"
    debug_journaler: "0/0"
    debug_objectcacher: "0/0"
    debug_client: "0/0"
    debug_osd: "0/0"
    debug_optracker: "0/0"
    debug_objclass: "0/0"
    debug_filestore: "0/0"
    debug_journal: "0/0"
    debug_ms: "0/0"
    debug_mon: "0/0"
    debug_monc: "0/0"
    debug_paxos: "0/0"
    debug_tp: "0/0"
    debug_auth: "0/0"
    debug_finisher: "0/0"
    debug_heartbeatmap: "0/0"
    debug_perfcounter: "0/0"
    debug_rgw: "0/0"
    debug_hadoop: "0/0"
    debug_asok: "0/0"
    debug_throttle: "0/0"

  osd_op_threads: [1, 4, 8]
  osd_disk_threads: [2, 4, 8]
  filestore_op_threads: [1, 4, 8]

  flush_true:
    filestore_flush_min: 0
    filestore_flusher: "true"

  flush_false:
    filestore_flush_min: 0
    filestore_flusher: "false"

  journal_aio: ["true"]
  ms_nocrc: ["true"]

  big_bytes:
    filestore_queue_max_bytes: 1048576000
    filestore_queue_committing_max_bytes: 1048576000
    journal_max_write_bytes: 1048576000
    journal_queue_max_bytes: 1048576000
    ms_dispatch_throttle_bytes: 1048576000
    objecter_infilght_op_bytes: 1048576000

  big_ops:
    filestore_queue_max_ops: 5000
    filestore_queue_committing_max_ops: 5000
    journal_max_write_entries: 1000
    journal_queue_max_ops: 5000
    objecter_inflight_ops: 8192

  small_bytes:
    filestore_queue_max_bytes: 10485760
    filestore_queue_committing_max_bytes: 10485760
    journal_max_write_bytes: 10485760
    journal_queue_max_bytes: 10485760
    ms_dispatch_throttle_bytes: 10485760
    objecter_infilght_op_bytes: 10485760

  small_ops:
    filestore_queue_max_ops: 50
    filestore_queue_committing_max_ops: 50
    journal_max_write_entries: 10
    journal_queue_max_ops: 50
    objecter_inflight_ops: 128

类似于以前的文章,我们运行测试直接在SC847a使用本机t TCP套接字连接。我们在每块磁盘的起始部分设置10G的日志分区。本文章只对 SAS2208的JBOD模式进行测试,这种模式不使用主板缓存。其他模式可能在后面的文章进行测试。CFQ用作所有测试IO调度器。

我们使用的是Ceph的可靠的内置基准测试命令:“RADOS bench” 来生成结果。(我今后将写一篇用smalliobench来测试的文章)。rados bench 有一定的好处有缺点。一方面它将明确地显示不同大小的对象读写速度。但它并不显示小IO大对象执行的速度有多快。出于这个原因,这些结果并不一定反映RBD如何最终执行。

类似之前的文章,我们将执行8个并发的 RADOS bench来合并结果,以确保这不是一个瓶颈。我们让每个RADOS bench 实例分别往自己的pool写2048个pg。这样做是为了确保后面的测试实例读取到独一无二的对象,而不是之前读取的对象的缓存。您可能还注意到,我们使用的每个池的PG数量是2的整数幂个。由于Ceph的方式实现PG分裂行为,有一个2的整数幂的后卫(尤其是在低PG计数!)可以改善数据均匀分布在osd。在较大的PG计数这可能不是那么重要。

RADOS bench给你一些灵活性的运行设置,对于对象应该是多大,有多少并发,测试应该运行多久。我们已经选定了5分钟测试使用下面的排列:

  • 4KB Objects, 16 Concurrent Operations (2 per rados bench instance)

  • 4KB Objects, 256 Concurrent Operations (32 per rados bench instance)

  • 128KB Objects, 16 Concurrent Operations (2 per rados bench instance)

  • 128KB Objects, 256 Concurrent Operations (32 per rados bench instance)

  • 4M Objects, 16 Concurrent Operations (2 per rados bench instance)

  • 4M Objects, 256 Concurrent Operations (32 per rados bench instance)

对于每种组合,我们运行相同的测试分别在 BTRFS, XFS, 或者 EXT4的osd 文件系统上。每次测试都会重新格式化文件系统以及重新运行mkcephfs以确保个先前的测试碎片不会影响后面的测试结果。请记住,试图使用这些结果来判断一个ceph集群是如何执行将是一个误导。每个文件系统在不同的阶段可能运行的机制完全不同。尽管如此,每个测试重新格式化文件系统是必要的,以确保不同的测试之间比较公平。每个文件系统的格式化命令和挂载选项如下:

  • mkfs.btfs options: -l 16k -n 16k

  • btrfs mount options: -o noatime

  • mkfs.xfs options: -f -i size=2048

  • xfs mount options: -o inode64,noatime

  • mkfs.ext4 options:

  • ext4 mount options: -o noatime,user_xattr

在测试期间,collectl用于记录各种系统的性能统计数据。

4KB RADOS BENCH 写入测试结果

好吧,希望这个图表展示是不言而喻的,但如果不是,基本上这里的想法是,我们有3个样品为每个文件系统,大量的不同的参数,我们画一个彩色圈表示性能高于或低于默认配置。可能这里最需要注意的是当 filestore flusher 显示启用的时候,BTRFS和XFS的性能变低。除此之外,看起来是授权 journal_aio_true 性能提升最为明显。

 

就像16个并发操作的结果一样,当启用filestore flusher 的时候BTRFS和XFS性能变低。授权 Journal AIO依然性能提升最为明显。在256个并发操作的情况下,我们可以看到,增加并发操作可以提升性能,减少并发数统一会降低性能。

4KB RADOS BENCH 读取测试结果

在这里启用 flusher 的性能依然表现不佳,这明显地降低了XFS和EXT4文件系统的读取性能。禁用调试看起来和增加并发线程操作数一样对提升性能有帮助。

 

这一点上,我们非常确定,启用flusher对小IO读取性能一点帮助都没有。禁用调试看起来依然有积极作用,这可能对大量的小IO操作生产的大量消息日志处理很有帮助。有趣的是增加并发操作数似乎降低了EXT4文件系统的性能,否则我们就可以得出一个规律,越多的并发操作数,性能越高。还要注意有多少不同的参数似乎在这些结果增加XFS的性能。我有一种感觉,默认的配置对XFS文件系统来说,性能是最好配置性能和最差配置性能的平均水平。

128KB RADOS BENCH 写入测试结果

默认情况下,filestore flusher只是支持操作大于64 k。通过显式禁用它,我们看到BTRFS不错的性能提升,但对XFS相反的效果。授权Journal AIO再次提升了性能。

 

在这种情况下禁用flusher给EXT4的性能提升。更有趣的是,多所有的IO大小操作都显示地禁用flusher会降低性能,尽管我们在做128k的操作。journal AIO再次提高性能,有少数增加或减少性能的其他选项。

128KB RADOS BENCH 读取测试结果

又有一些不同的选项,可以提供一些性能改进(看似BTRFS),但最明显的影响读取性能似乎是OSD 操作线程的数量就像在4 k阅读测试中的一样。

 

我们再次看到“默认”配置的情况下,性能很低。在这种情况下,也许有点偏高(即很多其他事物看起来低)。已经说过,OSD OP线程的数量又似乎有一个非常明显的效果。

本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。


2KB项目(www.2kb.com,源码交易平台),提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务

  • 全部评论(0)
资讯详情页最新发布上方横幅
最新发布的资讯信息
【计算机/互联网|互联网】深入理解 Rust 的动态分派模型(2020-03-30 04:08)
【计算机/互联网|】mysql 索引过长1071-max key length is 767 byte(2020-03-16 04:01)
【计算机/互联网|】maven build卡死在Downloading的解决方法(2020-03-08 12:13)
【计算机/互联网|】Eclipse里的Java项目按住Ctrl + 左键不能进行跳转问题(2020-03-06 15:32)
【计算机/互联网|互联网】Ceph 性能调优(2020-03-03 23:56)
【计算机/互联网|】百度推送返回状态说明(2020-02-22 18:38)
【计算机/互联网|】tomcat建立示例java web项目(2020-02-15 11:27)
【计算机/互联网|】springboot打包成war,部署到tomcat访问404的问题 (2020-02-13 10:54)
【行业动态|】CES 2020教会了我们关于今年手机的知识:更便宜的可折叠材料,5G及更多(2020-02-10 01:32)
【行业动态|】谷歌Chrome的隐私变化将在今年晚些时候登陆网络(2020-02-10 01:28)
联系我们

Q Q: 7090832

电话:400-0011-990

邮箱:7090832@qq.com

时间:9:00-23:00

联系客服
商家入住 服务咨询 投拆建议 联系客服
0577-67068160
手机版

扫一扫进手机版
返回顶部