我理解的CPU目前对cpu的了解停留在这个水平查看CPU型号： 12cat /proc/cpuinfo |grep model |tail -n 1model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz 查看有多少processor： 12cat /proc/cpuinfo |grep processor|tail -n 1processor

在jewel版本下默认开启了rbd的一些属性 12[root@lab8106 ~]# ceph --show-config|grep rbd|grep features rbd_default_features = 61 RBD属性表：61的意思是上面图中的bit码相加得到的值 对rbd进行内核的map操作 12345[root@lab8106 ~]# rbd map mytestrbd: s

ceph是目前开源分布式存储里面最好的一个，但是在高负载下会有很多异常的情况会发生，有些问题无法完全避免，但是可以进行一定的控制，比如：在虚拟化场景下，重启osd会让虚拟机挂起的情况 重新启动osd会给这个osd进程所在的磁盘带来额外的负载，随着前面业务的需求的增长，会增加对存储的I/O的需求，虽然这个对于整个业务系统来说是好事，但是在某些情况下，会越来越接近存储吞吐量的极限，通常情况下

前情介绍SPDKSPDK的全称为Storage Performance Development Kit ，是Intel发起的一个开源驱动项目，这个是一个开发套件，可以让应用程序在用户态去访问存储资源，具体做能做什么可以去官网看一下 SPDK官网 NVMENVMe其实与AHCI一样都是逻辑设备接口标准，NVMe全称Non-Volatile Memory Express，非易失性存储器标准，是使用PC

如果是在做ceph的配置，我们会经常遇到这几个问题 问：ceph需要配置几个mon答：配置一个可以，但是坏了一个就不行了，需要配置只是三个mon，并且需要是奇数个 问：ceph的mon能跟osd放在一起么，需要配置很好么？答：能跟放在一起，但是建议在环境允许的情况下一定独立机器，并且mon的配置能好尽量好，能上ssd就上ssd 这两个问题的答案不能说是错的，但是为什么这么说，这么说有没有问题，

jewel版本新增加了一个驱动NBD，允许librbd实现一个内核级别的rbd NBD相比较于kernel rbd： rbd-ko是根据内核主线走的，升级kernel rbd需要升级到相应的内核，改动太大 rbd-ko的开发要慢于librbd，需要很多的时间才能追赶上librbd rbd-nbd是通过librbd这个用户空间通过nbd的内核模块实现了内核级别的驱动，稳定性和性能都有保障 怎么理

之前测试了下，发现calamari不支持jewel版本的，是因为接口了有了一些变化，在提出这个问题后，作者给出了回答，说肯定会支持的，并且做了一点小的改动，就可以支持了，这个作者merge了到了github的一些分支当中，但是还没有merge到最新的1.4的分支合master分支当中，这个可能是因为1.4还在做一些功能的开发 我使用作者的修改好的分支打好了包，直接可以使用，测试了ubuntu14.

最近看到了有人的环境出现了出现了卡在active+remapped状态，并且卡住不动的状态，从pg的状态去看，这个pg值分配了主的pg，没有分配到副本的osd，集群的其他设置一切正常 这个从网上搜寻到的资料来看，大多数都是由于不均衡的主机osd引起的，所谓不平衡的osd 一台机器上面的磁盘的容量不一样，有的3T，有的1T 两台主机上面的OSD个数不一样，有的5个，有的2个 这样会造成主机的cr

在工作当中，很多时候我们在去分析一个性能的时候，会产生大量的数据，面对数据的时候我们一般应该会有以下几个处理过程 直接肉眼看这个属于第一个级别，比如监控系统负载的时候去用top观察，这个方法是我最开始经常使用的一种方法，这个适合异常的时候使用，但是实际上获取的数据是有偏差的 有监控系统使用数据监控系统对需要监控的数据进行监控，这个前提是有一个监控系统，并且方便的去增加数据，可以根据需求去设定数据

MON的稳定性问题： mon的选举风暴影响客户端IO LevelDB的暴涨 频繁的客户端请求的DDOS mon选举风暴：monmap会因为mon之间或者mon与客户端之间网络的影响或者消息传递的异常发生变化,从而触发选举会造成客户端的请求变慢或者锁住 LevelDB的暴涨：LevelDB的大小会涨到几十GB然后影响了osd的请求会造成客户端的请求变慢或者锁住 频繁的客户端请求的DDOS：mon的