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部分三篇内容就分享完了。
- Leetcode 275. H-Index II
- Leetcode 274. H-Index
- 值得 .NET 开发者了解的15个特性
- Angular和Vue.js 深度对比
- 前端开发者常用的9个JavaScript图表库
- 1000多个项目中的十大JavaScript错误以及如何避免
- SoapUI实践:自动化测试、压力测试、持续集成
- 如何把kotlin+spring boot开发的项目部署在tomcat上
- 使用开源项目Alipay.AopSdk.Core完成支付宝网页登录
- vhost-user 简介
- 把玩爬虫框架Gecco
- ASP.NET MVC5+EF6+EasyUI 后台管理系统(55)-Web打印
- ASP.NET MVC5+EF6+EasyUI 后台管理系统(75)-微信公众平台开发-用户管理
- ASP.NET MVC5+EF6+EasyUI 后台管理系统(89)-EF执行SQL语句与存储过程
- 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 数组属性和方法
- 一天一大 leet(通配符匹配)难度:困难-Day20200705
- 日志框架,选择Logback Or Log4j2?
- django-rest-framework配置json web token进行接口的认证
- spring中的SpEL表达式
- 京喜小程序首页无障碍优化实践
- 几种排序算法
- 一天一大 leet(转变数组后最接近目标值的数组和)难度:中等 DAY-14
- 推荐一个生成后端模拟数据的懒人工具:lazy-mock
- django-rest-framework框架学习
- 弄懂这 5 个问题,拿下 Python 迭代器!
- 一天一大 leet(跳水板)难度:简单-Day20200708
- 百度一二三面!喜提提起批offer!别问,问就是牛逼!
- 一天一大 leet(计算右侧小于当前元素的个数)难度:困难-Day20200711
- Spring 下,关于动态数据源的事务问题的探讨
- 面试再问 HashMap,求你把这篇文章发给他!