RGW Bucket Shard设计与优化-下
时间:2022-04-25
本文章向大家介绍RGW Bucket Shard设计与优化-下,主要内容包括OMAP过大的OSD服务恢复、启动OSD进程、择机释放内存、OSD服务恢复过程中的监测、收尾工作、基本概念、基础应用、原理机制和需要注意的事项等,并结合实例形式分析了其使用技巧,希望通过本文能帮助到大家理解应用这部分内容。
OMAP过大的OSD服务恢复
当bucket index所在的OSD omap过大的时候,一旦出现异常导致OSD进程崩溃,这个时候就需要进行现场"救火",用最快的速度恢复OSD服务,于是有了下面这篇文章。
先确定对应OSD的OMAP大小,这个过大会导致OSD启动的时候消耗大量时间和资源去加载levelDB数据,导致OSD无法启动(超时自杀)。特别是这一类OSD启动需要占用非常大的内存消耗,一定要注意预留好内存。(物理内存40G左右,不行用swap顶上)
root@demo:/# du -sh /var/lib/osd/ceph-214/current/omap/
22G /var/lib/osd/ceph-214/current/omap/
2017-08-11 11:52:46.601938 7f298ae2e700 1 heartbeat_map is_healthy 'FileStore::op_tp thread 0x7f2980894700' had suicide timed out after 180
0> 2017-08-11 11:52:46.605728 7f298ae2e700 -1 common/HeartbeatMap.cc: In function 'bool ceph::HeartbeatMap::_check(ceph::heartbeat_handle_d*, const char*, time_t)' thread 7f298ae2e700 time 2017-08-11 11:52:46.601952
common/HeartbeatMap.cc: 79: FAILED assert(0 == "hit suicide timeout") #超时自杀
1
启动OSD服务之前调整osd超时设置
在故障节点ceph.conf配置中加上
[osd]
debug osd = 20 #调整debug级别
[osd.214]
...
filestore_op_thread_suicide_timeout = 7000 #设置对应的osd超时,防止osd自杀
2
启动OSD进程
观察日志
tailf /home/ceph/log/ceph-osd.214.log
启动服务
/etc/init.d/ceph start osd.214
后台多启动一个top观察进程的资源消耗,目前OMAP在16G左右的OSD,需要大概37G的内存。恢复过程中OSD进程会占用非常高的内存和CPU,如下图
3
择机释放内存
当观察到日志中有下面的记录就可以启动内存的释放操作(也可以放到最后去做)
2017-08-11 15:08:14.551305 7f2b3fcab900 0 osd.214 29425 load_pgs opened 181 pgs
释放内存命令如下
ceph tell osd.214 heap release
4
OSD服务恢复过程中的监测
经过上面的操作以后osd会持续进行Omap数据的恢复,整个过程比较漫长,可以同时开 watch ceph -s 进行观察,一般恢复速率为每秒14MB,恢复时长估算公式
恢复时长(单位:秒) = OMAP总容量 / 14
注意:其中OMAP总容量是前面du命令得到的
恢复过程中的日志如下
2017-08-11 15:11:25.049357 7f2a3b327700 10 osd.214 pg_epoch: 29450 pg[76.2b6( v 29425'5676261 lc 29425'5676260 (29296'5672800,29425'5676261] local-les=29449 n=4 ec=20531 les/c 29449/29447 29448/29448/28171) [70,23,214] r=2 lpr=29448 pi=20532-29447/35 luod=0'0 crt=29425'5676261 lcod 0'0 active m=1] handle_message: 0x651131200
2017-08-11 15:11:25.049380 7f2a3b327700 10 osd.214 pg_epoch: 29450 pg[76.2b6( v 29425'5676261 lc 29425'5676260 (29296'5672800,29425'5676261] local-les=29449 n=4 ec=20531 les/c 29449/29447 29448/29448/28171) [70,23,214] r=2 lpr=29448 pi=20532-29447/35 luod=0'0 crt=29425'5676261 lcod 0'0 active m=1] handle_push ObjectRecoveryInfo(6f648ab6/.dir.hxs1.55076.1.6/head//76@29425'5676261, copy_subset: [], clone_subset: {})ObjectRecoveryProgress(!first, data_recovered_to:0, data_complete:false, omap_recovered_to:0_00001948372.1948372.3, omap_complete:false)
2017-08-11 15:11:25.049400 7f2a3b327700 10 osd.214 pg_epoch: 29450 pg[76.2b6( v 29425'5676261 lc 29425'5676260 (29296'5672800,29425'5676261] local-les=29449 n=4 ec=20531 les/c 29449/29447 29448/29448/28171) [70,23,214] r=2 lpr=29448 pi=20532-29447/35 luod=0'0 crt=29425'5676261 lcod 0'0 active m=1] submit_push_data: Creating oid 6f648ab6/.dir.hxs1.55076.1.6/head//76 in the temp collection
2017-08-11 15:11:25.123153 7f2a3b327700 10 osd.214 29450 dequeue_op 0x651131200 finish
2017-08-11 15:11:25.138155 7f2b357a1700 5 osd.214 29450 tick
2017-08-11 15:11:25.138186 7f2b357a1700 20 osd.214 29450 scrub_should_schedule should run between 0 - 24 now 15 = yes
2017-08-11 15:11:25.138210 7f2b357a1700 20 osd.214 29450 scrub_should_schedule loadavg 3.34 >= max 0.5 = no, load too high
2017-08-11 15:11:25.138221 7f2b357a1700 20 osd.214 29450 sched_scrub load_is_low=0
2017-08-11 15:11:25.138223 7f2b357a1700 10 osd.214 29450 sched_scrub 76.2a9 high load at 2017-08-10 11:39:35.359828: 99109.8 < max (604800 seconds)
2017-08-11 15:11:25.138235 7f2b357a1700 20 osd.214 29450 sched_scrub done
2017-08-11 15:11:25.138237 7f2b357a1700 10 osd.214 29450 do_waiters -- start
2017-08-11 15:11:25.138239 7f2b357a1700 10 osd.214 29450 do_waiters -- finish
2017-08-11 15:11:25.163988 7f2aaef77700 20 osd.214 29450 share_map_peer 0x66b4e0260 already has epoch 29450
2017-08-11 15:11:25.164042 7f2ab077a700 20 osd.214 29450 share_map_peer 0x66b4e0260 already has epoch 29450
2017-08-11 15:11:25.268001 7f2aaef77700 20 osd.214 29450 share_map_peer 0x66b657a20 already has epoch 29450
2017-08-11 15:11:25.268075 7f2ab077a700 20 osd.214 29450 share_map_peer 0x66b657a20 already has epoch 29450
当OSD对应的PG状态都恢复正常就可以进行下面的收尾操作了。
5
收尾工作
- 清理内存 OSD完成数据恢复以后,CPU会下降,但是内存不会释放,必须使用前面的命令去释放内存。
- 调整日志级别 ceph tell osd.214 injectargs "--debug_osd=0/5"
- 删除ceph.conf里面之前临时新加的内容
至此bucket shard部分三篇内容就分享完了。
- C/C++——生成随机数
- PHP基础——PHP数组
- 使用shell抽取html数据之二(r2笔记75天)
- Python爬取链家网数据:新房楼盘价格分析
- 【编程基础】Java里面如何对字符串排序?
- 计算广告——广告定向实践
- 通过shell抓取html数据(r2笔记74天)
- 通过shell脚本分析足彩(r2笔记74天)
- 通过shell脚本得到数据字典的信息 (r2笔记72天)
- 机器学习算法实践——K-Means算法与图像分割
- 利用 Python、SciKit 和文本分类来构建客户行为描述模型
- 使用Python爬取社交网络数据分析
- PHP爬虫源码:百万级别知乎用户数据爬取与分析
- 使用Python抓取欧洲足球联赛数据
- JavaScript 教程
- JavaScript 编辑工具
- JavaScript 与HTML
- JavaScript 与Java
- JavaScript 数据结构
- JavaScript 基本数据类型
- JavaScript 特殊数据类型
- JavaScript 运算符
- JavaScript typeof 运算符
- JavaScript 表达式
- JavaScript 类型转换
- JavaScript 基本语法
- JavaScript 注释
- Javascript 基本处理流程
- Javascript 选择结构
- Javascript if 语句
- Javascript if 语句的嵌套
- Javascript switch 语句
- Javascript 循环结构
- Javascript 循环结构实例
- Javascript 跳转语句
- Javascript 控制语句总结
- Javascript 函数介绍
- Javascript 函数的定义
- Javascript 函数调用
- Javascript 几种特殊的函数
- JavaScript 内置函数简介
- Javascript eval() 函数
- Javascript isFinite() 函数
- Javascript isNaN() 函数
- parseInt() 与 parseFloat()
- escape() 与 unescape()
- Javascript 字符串介绍
- Javascript length属性
- javascript 字符串函数
- Javascript 日期对象简介
- Javascript 日期对象用途
- Date 对象属性和方法
- Javascript 数组是什么
- Javascript 创建数组
- Javascript 数组赋值与取值
- Javascript 数组属性和方法
- 迈出加入 Apache IoTDB 社区的第一步!(订阅邮件、调试代码)
- kali下一些代理工具的简单描述
- 树莓派基础实验26:旋转编码器实验
- java web Session会话技术(原理图解+功能+与Cookie的区别+基本使用)
- JAVA创建对象有哪几种方式
- Apache IoTDB 系列教程-7:时序数据文件格式 TsFile
- XSS原理及代码分析
- 树莓派基础实验27:温湿度传感器DHT11 实验
- org.apache.jasper.JasperException: Unable to compile class for JSP
- 树莓派基础实验28:红外避障传感器实验
- Java Filter过滤器(拦截路径的配置+拦截方式的配置+生命周期+多个过滤器的先后执行顺序)
- Java Redis系列1 关系型数据库与非关系型数据库的优缺点及概念
- 树莓派基础实验29:I2C LCD1602实验
- Java Redis系列2 (redis的安装与使用+redis持久化的实现))
- Apache IoTDB 系列教程-1:数据模型