前言 之前写过一篇关于查询OSD的运行的CPU的情况的分享,本篇是讲的获取内存占用的,代码包括两种输出,一种是直接的表格,一种是可以方便解析的json 代码 直接上代码,python才用不久,所以可能代码实现比较低级,主要是看实现的方法 #!/usr/bin/env python # -*- coding: UTF-8 -*- import os import sys import json import psutil import commands from prettytable impor

前言 这个工具我第一次看到是在填坑群里面看到,是由研发-北京-蓝星同学分享的,看到比较有趣,就写一篇相关的记录下用法 火焰图里面也可以定位内存方面的问题,那个是通过一段时间的统计,以一个汇总的方式来查看内存在哪个地方可能出了问题 本篇是另外一个工具,这个工具的好处是有很清晰的图表操作,以及基于时间线的统计,下面来看下这个工具怎么使用的 本篇对具体的内存函数的调用占用不会做更具体的分析,这里是提供一个工具的使用方法供感兴趣的研发同学来使用 环境准备 目前大多数的ceph运行在centos7系列上面

前言 本篇来源于群里一个人的问题,有没有办法让ceph的磁盘不自动挂载,一般人的问题都是怎样让ceph能够自动挂载,在centos 7 平台下 ceph jewel版本以后都是有自动挂载的处理的,这个我之前也写过两篇文章<ceph在centos7下一个不容易发现的改变>和<Ceph数据盘怎样实现自动挂载>,来讲述这个自动挂载的 这里讲下流程: 开机后 udev 匹配 95-ceph-osd.rules 规则,触发 ceph-disk trigger,遍历磁盘,匹配到磁盘的标记后就触

在Ceph的osd节点上,启动osd进程失败,查看其日志/var/log/ceph/ceph-osd.{osd-index}.log日志,报错如下: 2017-02-14 16:26:13.558535 7fe3883f58c0 0 filestore(/var/lib/ceph/osd/ceph-1) mount: enabling WRITEAHEAD journal mode: checkpoint is not enabled 2017-02-14 16:26:13.558712 7fe

直接上干货: ceph自动挂载原理 系统启动后,ceph 通过扫描所有磁盘及分区的 ID_PART_ENTRY_TYPE 与自己main.py中写死的osd ready 标识符来判断磁盘(及其分区)是否准备好自动挂载(journal ,block, osd 同是一个道理) main.py中记载的状态标志 /usr/lib/python2./site-packages/ceph_disk/main.py 'osd': { 'ready': '4fbd7e29-9d25-41b8-afd0-062c

正常状态:

ceph osd 批量删除,注意删除的是当前节点正在使用的osd,数据删除有风险,所以最后一步没有去format磁盘,给你留下一剂后悔药. #!/bin/bash osd_list=`mount|grep osd|awk '{print $3}'|awk -F'-' '{print $2}'` for var in $osd_list; do echo "ceph osd out $var" ceph osd out $var echo "service ceph-osd s

1  调高osd的日志等级 加上红框那一行就可以了 osd的日志路径:/var/log/ceph/ceph-osd.3.log 注意:加上了这一行后日志会刷很多,所以要特别注意日志容量的变化,以防把var目录写满了 2  缺少osdmap或者错误的osdmap 从osd日志中发现这两种错误都是属于osdmap不正常,可以从其它正常osd上拷贝osdmap到对应启动错误的osd上,假设不正常的osdmap序号是816,上图的是27601和671651 如以下图: 在一个正常osd上如osd.4上用

正常状态: 故障状态: 实施更换步骤: (1)关闭ceph集群数据迁移: osd硬盘故障,状态变为down.在经过mod osd down out interval 设定的时间间隔后,ceph将其标记为out,并开始进行数据迁移恢复.为了降低ceph进行数据恢复或scrub等操作对性能的影响,可以先将其暂时关闭,待硬盘更换完成且osd恢复后再开启: for i in noout nobackfill norecover noscrub nodeep-scrub;do ceph osd set $

前言 很久没有处理很大的集群,在接触一个新集群的时候,如果集群足够大,需要比较长的时间才能去理解这个集群的结构,而直接去看ceph osd tree的结果,当然是可以的,这里是把osd tree的结构进行了一个结构化输出,也可以理解为画出一个简单的结构图,比较适合给其它人讲解你对crush做了哪些改变,这个如果指着文字来讲估计很多人会听的云里雾里,如果有比较方便的方式出图就比较好了 为此写了一个小工具自己用,正好也可以看看我们对结构做简单调整后的效果 创建一个模拟集群 环境就一台机器,不需要用到

前言 如果看到标题,你是不是第一眼觉得写错了,这个怎么可能,完全就是两个不相关的东西,最开始我也是这么想的,直到我发现真的是这样的时候,也是很意外,还是弄清楚下比较好,不然在某个操作下,也许就会出现意想不到的情况 定位 如果你看过我的博客,正好看过这篇 <<ceph在centos7下一个不容易发现的改变>> ,那么应该还记得这个讲的是centos 7 下面通过udev来实现了osd的自动挂载,这个自动挂载就是本篇需要了解的前提 [root@lab101 ~]# df -h|grep

前言 前段时间看到豪迈的公众号上提到了这个离线转换工具,最近看到群里有人问,找了下没什么相关文档,就自己写了一个,供参考 实践步骤 获取代码并安装 git clone https://github.com/ceph/ceph.git cd ceph git submodule update --init --recursive ./make-dist rpm -bb ceph.spec 生成rpm安装包后进行安装,这个过程就不讲太多,根据各种文档安装上最新的版本即可,这个代码合进去时间并不久,大

前言 之前有一篇文章介绍的是,在centos7的jewel下面如果自己做的分区如何处理自动挂载的问题,当时的环境对journal的地方采取的是文件的形式处理的,这样就没有了重启后journal的磁盘偏移的问题 如果采用的是ceph自带的deploy去做分区的处理的时候,是调用的sgdisk去对磁盘做了一些处理的,然后deploy能够识别一些特殊的标记,然后去做了一些其他的工作,而自己分区的时候,是没有做这些标记的这样就可能会有其他的问题 我们看下如何在部署的时候就处理好journal的uuid的

机房操作失误导致机架或主机掉电是偶尔发生的事情,那么怎么在这种情况下,让Ceph服务随OS启动而快速启动呢 ? 如下是一个简单方法: 在OSD主机上执行如下命令: sudo ln -s /usr/lib/systemd/system/ceph-osd@.service /etc/systemd/system/multi-user.target.wants/ceph-osd@.service sudo systemctl enable ceph-osd@.service sudo systemct

总体思路就是客户端写入要查询的数据到管道中,服务器端从管道读取,然后写入随机文件,再把文件名写入管道,然后客户端再读取文件 服务器端 设置缓冲区大写,设置管道名字,以及标识有多少个线程等 //设置缓存区大小 #define SIZE 4096 //最多有多少线程 #define MAX_CONNECT 128 //一开始有10个线程存在 ; //管道名字 ] = "\\\\.\\Pipe\\cloudpipe"; //文件路径 #define path "C:\\Progra

目录 一.前言 二.关于服务器基本配置 2.1 操作系统基本配置查询 2.2 CPU基本配置查询 2.3 内存基本配置查询 2.4 硬盘基本配置查询 一.前言 ​ 当我们接手了一台或者几台服务器的时候,首先我们有必要对服务器的基本配置有所认识,这样才可以对症下药,对以后的软件部署,系统运维会有事半功倍的效果. 二.关于服务器基本配置 ​ 查询服务器的基本配置一般查询操作系统,CPU,内存,硬盘,下面进行逐一讲解. 2.1 操作系统基本配置查询 查看操作系统版本 #cat /etc/redhat-

通过cgroup将ceph-osd进程与某一个 CPU core 绑定脚本: mkdir -p /sys/fs/cgroup/cpuset/ceph # cup number : ,,, = - echo , > /sys/fs/cgroup/cpuset/ceph/cpuset.cpus # NUMA node echo > /sys/fs/cgroup/cpuset/ceph/cpuset.mems osd-pid-list=$(ps aux | grep osd | grep -v gr

前言 服务器上面的服务会因为各种各样的原因失败,磁盘故障,权限问题,或者是服务过载引起超时,这些都可能引起 这个在ceph里面systemctl unit 默认有个on-fail restart,默认的可能并不适合所有的场景,所以自动化的服务应该是尽量去适配你手动处理的过程,手动怎么处理的,就怎么去设置 启动分析 如果有osd失败了,一般上去会先启动一次,尽快让服务启动,然后去检查是否有故障,如果失败了,就开启调试日志,再次重启,在问题解决之前,是不会再启动了,所以这里我们的自动启动设置也这么设

CPU占有率            adb shell dumpsys cpuinfo :获取本机CPU占有率            adb shell dumpsys  cpuinfo | findstr +包名  :获取应用的CPU占有率   内存使用情况           adb shell getprop | findstr dalvik :本机内存的使用情况           adb shell dumpsys meminfo +包名:应用的内存使用情况 fps       adb

低级集群运维包括启动.停止.重启集群内的某个具体守护进程:更改某守护进程或子系统配置:增加或拆除守护进程.低级运维还经常遇到扩展.缩减 Ceph 集群,以及更换老旧.或损坏的硬件. 一.增加/删除 OSD 如果您的集群已经在运行,你可以在运行时添加或删除 OSD . 增加 OSD 你迟早要扩容集群, Ceph 允许在运行时增加 OSD .在 Ceph 里,一个 OSD 一般是一个 ceph-osd 守护进程,它运行在硬盘之上,如果你有多个硬盘,可以给每个硬盘启动一个 ceph-osd 守护进程.

引言 ceph自从到了L版本以后,L版本的启用,对性能本身有了极大的提高,一直对这个比较不放心的就是内存的占用,刚开始的时候记得大量dd就可以把内存搞崩掉,这个应该是内部的设计逻辑需要更多的内存的占用 最近在做ARM版本的服务器的测试,机器为36盘位的机器,内存需要自然多,但是36盘位的机器,按之前想法是4G预留,那得需要144G内存了,这个还没有算迁移的时候的内存消耗,而很多时候,我们并不需要速度,只需要稳定就好 测试环境说明 测试环境比较简单,一台36盘位的arm机器,一台X86机器,通过万