Ceph性能优化总结(v0.94)

如需转载请标明作者，原文地址：http://xiaoquqi.github.io/blog/2015/06/28/ceph-performance-optimization-summary/

最近一直在忙着搞Ceph存储的优化和测试，看了各种资料，但是好像没有一篇文章把其中的方法论交代清楚，所以呢想在这里进行一下总结，很多内容并不是我原创，只是做一个总结。如果其中有任何的问题，欢迎各位喷我，以便我提高。

优化方法论

做任何事情还是要有个方法论的，“授人以鱼不如授人以渔”的道理吧，方法通了，所有的问题就有了解决的途径。通过对公开资料的分析进行总结，对分布式存储系统的优化离不开以下几点：

1. 硬件层面

  • 硬件规划
  • SSD选择
  • BIOS设置

2. 软件层面

  • Linux OS
  • Ceph Configurations
  • PG Number调整
  • CRUSH Map
  • 其他因素

硬件优化

1. 硬件规划

  • Processor

ceph-osd进程在运行过程中会消耗CPU资源，所以一般会为每一个ceph-osd进程绑定一个CPU核上。当然如果你使用EC方式，可能需要更多的CPU资源。

ceph-mon进程并不十分消耗CPU资源，所以不必为ceph-mon进程预留过多的CPU资源。

ceph-msd也是非常消耗CPU资源的，所以需要提供更多的CPU资源。

  • 内存

ceph-mon和ceph-mds需要2G内存，每个ceph-osd进程需要1G内存，当然2G更好。

  • 网络规划

万兆网络现在基本上是跑Ceph必备的，网络规划上，也尽量考虑分离cilent和cluster网络。

2. SSD选择

硬件的选择也直接决定了Ceph集群的性能，从成本考虑，一般选择SATA SSD作为Journal，Intel? SSD DC S3500 Series基本是目前看到的方案中的首选。400G的规格4K随机写可以达到11000 IOPS。如果在预算足够的情况下，推荐使用PCIE SSD，性能会得到进一步提升，但是由于Journal在向数据盘写入数据时Block后续请求，所以Journal的加入并未呈现出想象中的性能提升，但是的确会对Latency有很大的改善。

如何确定你的SSD是否适合作为SSD Journal，可以参考SéBASTIEN HAN的Ceph: How to Test if Your SSD Is Suitable as a Journal Device?，这里面他也列出了常见的SSD的测试结果，从结果来看SATA SSD中，Intel S3500性能表现最好。

3. BIOS设置

  • Hyper-Threading(HT)

基本做云平台的，VT和HT打开都是必须的，超线程技术(HT)就是利用特殊的硬件指令，把两个逻辑内核模拟成两个物理芯片，让单个处理器都能使用线程级并行计算，进而兼容多线程操作系统和软件，减少了CPU的闲置时间，提高的CPU的运行效率。

  • 关闭节能

关闭节能后，对性能还是有所提升的，所以坚决调整成性能型(Performance)。当然也可以在操作系统级别进行调整，详细的调整过程请参考链接，但是不知道是不是由于BIOS已经调整的缘故，所以在CentOS 6.6上并没有发现相关的设置。

for CPUFREQ in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do [ -f $CPUFREQ ] || continue; echo -n performance > $CPUFREQ; done

简单来说，NUMA思路就是将内存和CPU分割为多个区域，每个区域叫做NODE,然后将NODE高速互联。 node内cpu与内存访问速度快于访问其他node的内存，NUMA可能会在某些情况下影响ceph-osd。解决的方案，一种是通过BIOS关闭NUMA，另外一种就是通过cgroup将ceph-osd进程与某一个CPU Core以及同一NODE下的内存进行绑定。但是第二种看起来更麻烦，所以一般部署的时候可以在系统层面关闭NUMA。CentOS系统下，通过修改/etc/grub.conf文件，添加numa=off来关闭NUMA。

kernel /vmlinuz-2.6.32-504.12.2.el6.x86_64 ro root=UUID=870d47f8-0357-4a32-909f-74173a9f0633 rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto  KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM   biosdevname=0 numa=off

软件优化

1. Linux OS

  • Kernel pid max
echo 4194303 > /proc/sys/kernel/pid_max
  • Jumbo frames, 交换机端需要支持该功能，系统网卡设置才有效果
ifconfig eth0 mtu 9000

永久设置

echo "MTU=9000" | tee -a /etc/sysconfig/network-script/ifcfg-eth0
/etc/init.d/networking restart
  • read_ahead, 通过数据预读并且记载到随机访问内存方式提高磁盘读操作，查看默认值
cat /sys/block/sda/queue/read_ahead_kb

根据一些Ceph的公开分享，8192是比较理想的值

echo "8192" > /sys/block/sda/queue/read_ahead_kb
  • swappiness, 主要控制系统对swap的使用，这个参数的调整最先见于UnitedStack公开的文档中，猜测调整的原因主要是使用swap会影响系统的性能。
echo "vm.swappiness = 0" | tee -a /etc/sysctl.conf
  • I/O Scheduler，关于I/O Scheculder的调整网上已经有很多资料，这里不再赘述，简单说SSD要用noop，SATA/SAS使用deadline。
echo "deadline" > /sys/block/sd[x]/queue/scheduler
echo "noop" > /sys/block/sd[x]/queue/scheduler
  • cgroup

这方面的文章好像比较少，昨天在和Ceph社区交流过程中，Jan Schermer说准备把生产环境中的一些脚本贡献出来，但是暂时还没有，他同时也列举了一些使用cgroup进行隔离的原因。

  • 不在process和thread在不同的core上移动(更好的缓存利用)
  • 减少NUMA的影响
  • 网络和存储控制器影响 - 较小
  • 通过限制cpuset来限制Linux调度域(不确定是不是重要但是是最佳实践)
  • 如果开启了HT，可能会造成OSD在thread1上，KVM在thread2上，并且是同一个core。Core的延迟和性能取决于其他一个线程做什么。

这一点具体实现待补充！！！

2. Ceph Configurations

[global]

参数名 描述 默认值 建议值
public network 客户端访问网络 192.168.100.0/24
cluster network 集群网络 192.168.1.0/24
max open files 如果设置了该选项，Ceph会设置系统的max open fds 0 131072

  • 查看系统最大文件打开数可以使用命令
    cat /proc/sys/fs/file-max

[osd] - filestore

参数名 描述 默认值 建议值
filestore xattr use omap 为XATTRS使用object map，EXT4文件系统时使用，XFS或者btrfs也可以使用 false true
filestore max sync interval 从日志到数据盘最大同步间隔(seconds) 5 15
filestore min sync interval 从日志到数据盘最小同步间隔(seconds) 0.1 10
filestore queue max ops 数据盘最大接受的操作数 500 25000
filestore queue max bytes 数据盘一次操作最大字节数(bytes) 100 << 20 10485760
filestore queue committing max ops 数据盘能够commit的操作数 500 5000
filestore queue committing max bytes 数据盘能够commit的最大字节数(bytes) 100 << 20 10485760000
filestore op threads 并发文件系统操作数 2 32

  • 调整omap的原因主要是EXT4文件系统默认仅有4K
  • filestore queue相关的参数对于性能影响很小，参数调整不会对性能优化有本质上提升

[osd] - journal

参数名 描述 默认值 建议值
osd journal size OSD日志大小(MB) 5120 20000
journal max write bytes journal一次性写入的最大字节数(bytes) 10 << 20 1073714824
journal max write entries journal一次性写入的最大记录数 100 10000
journal queue max ops journal一次性最大在队列中的操作数 500 50000
journal queue max bytes journal一次性最大在队列中的字节数(bytes) 10 << 20 10485760000

  • Ceph OSD Daemon stops writes and synchronizes the journal with the filesystem, allowing Ceph OSD Daemons to trim operations from the journal and reuse the space.
  • 上面这段话的意思就是，Ceph OSD进程在往数据盘上刷数据的过程中，是停止写操作的。

[osd] - osd config tuning

参数名 描述 默认值 建议值
osd max write size OSD一次可写入的最大值(MB) 90 512
osd client message size cap 客户端允许在内存中的最大数据(bytes) 524288000 2147483648
osd deep scrub stride 在Deep Scrub时候允许读取的字节数(bytes) 524288 131072
osd op threads OSD进程操作的线程数 2 8
osd disk threads OSD密集型操作例如恢复和Scrubbing时的线程 1 4
osd map cache size 保留OSD Map的缓存(MB) 500 1024
osd map cache bl size OSD进程在内存中的OSD Map缓存(MB) 50 128
osd mount options xfs Ceph OSD xfs Mount选项 rw,noatime,inode64 rw,noexec,nodev,noatime,nodiratime,nobarrier

  • 增加osd op threads和disk threads会带来额外的CPU开销

[osd] - recovery tuning

参数名 描述 默认值 建议值
osd recovery op priority 恢复操作优先级，取值1-63，值越高占用资源越高 10 4
osd recovery max active 同一时间内活跃的恢复请求数 15 10
osd max backfills 一个OSD允许的最大backfills数 10 4

[osd] - client tuning

参数名 描述 默认值 建议值
rbd cache RBD缓存 true true
rbd cache size RBD缓存大小(bytes) 33554432 268435456
rbd cache max dirty 缓存为write-back时允许的最大dirty字节数(bytes)，如果为0，使用write-through 25165824 134217728
rbd cache max dirty age 在被刷新到存储盘前dirty数据存在缓存的时间(seconds) 1 5

关闭Debug

3. PG Number

PG和PGP数量一定要根据OSD的数量进行调整，计算公式如下，但是最后算出的结果一定要接近或者等于一个2的指数。

Total PGs = (Total_number_of_OSD * 100) / max_replication_count

例如15个OSD，副本数为3的情况下，根据公式计算的结果应该为500，最接近512，所以需要设定该pool(volumes)的pg_num和pgp_num都为512.

ceph osd pool set volumes pg_num 512
ceph osd pool set volumes pgp_num 512

4. CRUSH Map

CRUSH是一个非常灵活的方式，CRUSH MAP的调整取决于部署的具体环境，这个可能需要根据具体情况进行分析，这里面就不再赘述了。

5. 其他因素的影响

在今年的(2015年)的Ceph Day上，海云捷迅在调优过程中分享过一个由于在集群中存在一个性能不好的磁盘，导致整个集群性能下降的case。通过osd perf可以提供磁盘latency的状况，同时在运维过程中也可以作为监控的一个重要指标，很明显在下面的例子中，OSD 8的磁盘延时较长，所以需要考虑将该OSD剔除出集群：

ceph osd perf
osd fs_commit_latency(ms) fs_apply_latency(ms)
  0                    14                   17
  1                    14                   16
  2                    10                   11
  3                     4                    5
  4                    13                   15
  5                    17                   20
  6                    15                   18
  7                    14                   16
  8                   299                  329

ceph.conf

[global]
fsid = 059f27e8-a23f-4587-9033-3e3679d03b31
mon_host = 10.10.20.102, 10.10.20.101, 10.10.20.100
auth cluster required = cephx
auth service required = cephx
auth client required = cephx
osd pool default size = 3
osd pool default min size = 1

public network = 10.10.20.0/24
cluster network = 10.10.20.0/24

max open files = 131072

[mon]
mon data = /var/lib/ceph/mon/ceph-$id

[osd]
osd data = /var/lib/ceph/osd/ceph-$id
osd journal size = 20000
osd mkfs type = xfs
osd mkfs options xfs = -f

filestore xattr use omap = true
filestore min sync interval = 10
filestore max sync interval = 15
filestore queue max ops = 25000
filestore queue max bytes = 10485760
filestore queue committing max ops = 5000
filestore queue committing max bytes = 10485760000

journal max write bytes = 1073714824
journal max write entries = 10000
journal queue max ops = 50000
journal queue max bytes = 10485760000

osd max write size = 512
osd client message size cap = 2147483648
osd deep scrub stride = 131072
osd op threads = 8
osd disk threads = 4
osd map cache size = 1024
osd map cache bl size = 128
osd mount options xfs = "rw,noexec,nodev,noatime,nodiratime,nobarrier"
osd recovery op priority = 4
osd recovery max active = 10
osd max backfills = 4

[client]
rbd cache = true
rbd cache size = 268435456
rbd cache max dirty = 134217728
rbd cache max dirty age = 5

总结

优化是一个长期迭代的过程，所有的方法都是别人的，只有在实践过程中才能发现自己的，本篇文章仅仅是一个开始，欢迎各位积极补充，共同完成一篇具有指导性的文章。

版权声明：本文为博主原创文章，未经博主允许不得转载。

时间： 2024-08-04 07:20:06

Ceph性能优化总结(v0.94)的相关文章

几个 Ceph 性能优化的新方法和思路（2015 SH Ceph Day 参后感）

一周前,由 Intel 与 Redhat 在10月18日联合举办了 Shanghai Ceph Day.在这次会议上,多位专家做了十几场非常精彩的演讲.本文就这些演讲中提到的 Ceph性能优化方面的知识和方法,试着就自己的理解做个总结. 0. 常规的 Ceph 性能优化方法 (1). 硬件层面 硬件规划:CPU.内存.网络 SSD选择:使用 SSD 作为日志存储 BIOS设置:打开超线程(HT).关闭节能.关闭 NUMA 等 (2). 软件层面 Linux OS:MTU.read_ahead 等

Ceph性能优化 之 配置参数调优

该文同时发表在盛大游戏G云微信公众号,粘贴于此,方便各位查阅 Ceph,相信很多IT朋友都听过.因为搭上了Openstack的顺风车,Ceph火了,而且越来越火.然而要用好Ceph却也不是件易事,在QQ群里就经常听到有初学者抱怨Ceph性能太烂,不好用.事实果真如此吗!如果你采用Ceph的默认配置来运行你的Ceph集群,性能自然不能如人意.俗话说,玉不琢,不成器:Ceph也有它的脾性,经过良好配置优化的Ceph性能还是不错的.下文简单分享下,盛大游戏G云在Ceph优化上的一些实际经验,如有错误之

Node.js V0.12新特性之性能优化

v0.12悠长的开发周期(已经过去九个月了,并且还在继续,是有史以来最长的一次)让核心团队和贡献者们有充分的机会对性能做一些优化.本文会介绍其中最值得注意的几个. 支持塞住模式的可写流 现在可写流可以支持“塞住(corked)”模式,类似于你执行man tcp时见到的socket选项TCP_CORK和TCP_NOPUSH. 当被塞住时,写到流中的数据会排队直到流被重新开塞(uncorked).这样Node.js可以将比较小的写操作合并成比较大的,从而减少系统调用和TCP往返. http模块已经升

【译】 Node.js v0.12的新特性 -- 性能优化

Performance Optimizations性能优化 原文: https://strongloop.com/strongblog/performance-node-js-v-0-12-whats-new/ January 21, 2014/in Community, Node.js v0.12, StrongNode /by Ben Noordhuis Node.js v0.12版本如此长的研发周期(9个月并且还在继续,目前为止最长的)使得核心团队和贡献者有足够的机会来介绍一些性能优化.本

使用Html5+C#+微信 开发移动端游戏详细教程:（六）游戏界面布局与性能优化

本篇教程我们主要讲解在游戏界面上的布局一般遵循哪些原则和一些性能优化的通用方法. 接着教程(五),我们通过Loading类一次性加载了全部图像素材,现在要把我们所用到的素材变成图片对象显示在界面上,由上而下,首先是top层,top里面包涵了玩家(微信)头像,关卡信息,怪物血条信息,玩家金币,玩家宝石,玩家总攻击力. 定义函数 setTop 来初始化top层: function setTop() { TopDiv = new LSprite();//定义top层 var Topshape = ne

架构设计：系统存储（8）——MySQL数据库性能优化（4）

================================ (接上文<架构设计:系统存储(7)--MySQL数据库性能优化(3)>) 4-3.InnoDB中的锁 虽然锁机制是InnoDB引擎中为了保证事务性而自然存在的,在索引.表结构.配置参数一定的前提下,InnoDB引擎加锁过程是一样的,所以理论上来说也就不存在"锁机制能够提升性能"这样的说法.但如果技术人员不理解InnoDB中的锁机制或者混乱.错误的索引定义和同样混乱的SQL写操作语句共同作用,那么导致死锁出现的

mysql 性能优化方案 （转）

网 上有不少MySQL 性能优化方案,不过,mysql的优化同sql server相比,更为麻烦与复杂,同样的设置,在不同的环境下 ,由于内存,访问量,读写频率,数据差异等等情况,可能会出现不同的结果,因此简单地根据某个给出方案来配置mysql是行不通的,最好能使用 status信息对mysql进行具体的优化. mysql> show global status; 可以列出mysql服务器运行各种状态值,另外,查询mysql服务器配置信息语句: mysql> show variables; 一

mysql性能优化-慢查询分析、优化索引和配置

一.优化概述 二.查询与索引优化分析 1性能瓶颈定位 Show命令 慢查询日志 explain分析查询 profiling分析查询 2索引及查询优化 三.配置优化 1)      max_connections 2)      back_log 3)      interactive_timeout 4)      key_buffer_size 5)      query_cache_size 6)      record_buffer_size 7)      read_rnd_buffer

网站性能优化：动态缩略图技术实现思路

在网站开发过程中,大家都是如何解决多尺寸图片缩略图问题的呢?犹为典型的是电商网站,据了解,淘宝的图片缩略图是直接存储多张缩略图的方式,以满足各种情况下使用,因为它有牛逼的开源+自主开发的海量图片存储架构作支撑.但是,我们在做网站时,并不可能直接搬牛逼的架构过来,就可以达到预期的效果,况且各种成本投入也是有限的.所以一般性能优化的原则大都是这样:先考虑软件的优化,再考虑硬件的升级,当然土豪客户则除外. 很多网站可能没有对图片进行缩略图处理,上传时图片可能几百KB,在页面也是直接加载几百KB的图片大