Ceph 性能调优 已翻译 100%

Yashin 投递于 2014/09/09 16:09 (共 22 段, 翻译完成于 09-10)
阅读 11930
收藏 72
4
加载中

介绍

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

Yashin
Yashin
翻译于 2014/09/09 16:42
2

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

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

Yashin
Yashin
翻译于 2014/09/09 16:48
1

系统设置

我们将使用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.

Yashin
Yashin
翻译于 2014/09/09 17:55
1

测试设置

写了一个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调度器。

Yashin
Yashin
翻译于 2014/09/09 18:13
1

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

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

Yashin
Yashin
翻译于 2014/09/09 18:59
1

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用于记录各种系统的性能统计数据。

Yashin
Yashin
翻译于 2014/09/09 19:11
1

4KB RADOS BENCH 写入测试结果

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

 

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

Yashin
Yashin
翻译于 2014/09/10 10:36
1

4KB RADOS BENCH 读取测试结果

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

 

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

Yashin
Yashin
翻译于 2014/09/10 10:59
1

128KB RADOS BENCH 写入测试结果

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

 

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

Yashin
Yashin
翻译于 2014/09/10 11:07
1

128KB RADOS BENCH 读取测试结果

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

 

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

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

评论(9)

itfanr
itfanr
好稳 收藏了
易小云
易小云
为啥btrfs的好那么多?
heiing
heiing
收藏了,然后再也不会看
水牛叔叔
水牛叔叔
以前想用ceph,但是编译了一个星期都没过,不知道为啥
郭士禄
郭士禄
好文章
spark8103
spark8103
很不错!
RoseRougE
RoseRougE
+1
char1st
char1st
mark先
加油2018
加油2018
很好的文章,对ceph的调优有些参考价值!
返回顶部
顶部