使用命令检查ceph集群的监控状态,得到 [root@node1 ~]# ceph -s cluster c4898b1c-7ac1-406d-bb5d-d3c7980de438 health HEALTH_ERR 4 pgs inconsistent; 8 scrub errors; mds cluster is degraded; mds alpha is laggy monmap e5: 1 mons at {node1=172.17.44.22:6789/0}, election epo

优化: PG Number PG和PGP数量一定要根据OSD的数量进行调整,计算公式如下,但是最后算出的结果一定要接近或者等于一个2的指数.调整PGP不会引起PG内的对象的分裂,但是会引起PG的分布的变动三.总结PG是指定存储池存储对象的目录有多少个,PGP是存储池PG的OSD分布组合个数PG的增加会引起PG内的数据进行分裂,分裂到相同的OSD上新生成的PG当中PGP的增加会引起部分PG的分布进行变化,但是不会引起PG内对象的变动 Total PGs = (Total_number_of_OSD

1 PG介绍pg的全称是placement group,中文译为放置组,是用于放置object的一个载体,pg的创建是在创建ceph存储池的时候指定的,同时跟指定的副本数也有关系,比如是3副本的则会有3个相同的pg存在于3个不同的osd上,pg其实在osd的存在形式就是一个目录,可以列出来看下: [root@abc ~]# ll /var/lib/ceph/osd/ceph-/current/ total drwxr-xr-x root root Sep : .11_head drwxr-xr-

前言 性能优化大神Brendan Gregg发明了火焰图来定位性能问题,通过图表就可以发现问题出在哪里,通过svg矢量图来查看性能卡在哪个点,哪个操作占用的资源最多 在查看了原始数据后,这个分析的原理是按层级来对调用进行一个计数,然后以层级去做比对,来看横向的占用的比例情况 基于这个原理,把osd tree的数据和pg数据可以做一个层级的组合,从而可以很方便的看出pg的分布情况,主机的分布情况,还可以进行搜索,在一个简单的图表内汇聚了大量的信息 实践 获取需要的数据,这个获取数据是我用一个脚本解

[mysql@mysqlhq scripts]$ cat /etc/redhat-release Kylin Linux release 3.3.1707 (Core) mysql version Server version: 5.6.15-log MySQL Community Server - (GPL) 1 初始情况 [root@mysqlhq scripts]# free -m total used free shared buff/cache available Mem: 15887

情况 1 镜像的问题 如果你的镜像已经设置,却仍然卡主,那么请参考情况 2 这种情况在中文官网上已经有了,并且有这修改镜像的方法,附上链接: https://flutter.cn/community/china 而我这边是这样设置的: #flutter export FLUTTER_STORAGE_BASE_URL="https://mirrors.tuna.tsinghua.edu.cn/flutter" export PUB_HOSTED_URL="https://pub

今天检查ceph集群,发现有pg丢失,于是就有了本文~~~ 1.查看集群状态 [root@k8snode001 ~]# ceph health detail HEALTH_ERR 1/973013 objects unfound (0.000%); 17 scrub errors; Possible data damage: 1 pg recovery_unfound, 8 pgs inconsistent, 1 pg repair; Degraded data redundancy: 1/29

测试告诉我们定时任务没有执行了,排查相关日志,只有开始执行,没有执行结束.估计是什么地方卡主了. 所以dump分析日志 先检查一下加载情况 !eeversion 线程卡主了,先看线程 !runaway 有两条线程时间挺长的.有一条是我们的调度常驻线程.时间成是对的,另一条应该就是卡主的. 先看第一条 ~15s !clrstack 果然这个最长的是调度线程看另外一条 另外一条好像是在等socket数据. 看这个函数不是我们这边负责的,是更底层的人.底层的人反馈说这个时长不一定是卡主了,他是重复利用

看完 <前端规范之Git工作流规范(Husky + Commitlint + Lint-staged) https://www.cnblogs.com/Yellow-ice/p/15349873.html>,再次修改本文 团队人一多,提交一多,还是要对备注加以区分,好快速找到变更点.这时候就需要对每次提交,需要输入message,对提交的备注进行规范化处理 代码规范落地难:归根结底在于需要工具去强行保证代码必须经过代码开发规范的扫描: 低质量代码带入线上应用:最好的方式本地进行commit的时

本系列文章会深入研究 Ceph 以及 Ceph 和 OpenStack 的集成: (1)安装和部署 (2)Ceph RBD 接口和工具 (3)Ceph 物理和逻辑结构 (4)Ceph 的基础数据结构 (5)Ceph 与 OpenStack 集成的实现 (6)QEMU-KVM 和 Ceph RBD 的 缓存机制总结 (7)Ceph 的基本操作和常见故障排除方法 (8)关于Ceph PGs https://docs.google.com/presentation/d/1_0eIWNYWvJON4Gr

转自:https://www.ustack.com/blog/ceph-pg-fenlie/ 1 pg分裂 Ceph作为一个scalable的分布式系统,集群规模会逐渐增大,为了保证数据分布的均匀性,好的做法是在扩容时根据集群规模适当调整pg_num和pgp_num的值. PG作为Ceph数据流过程的中间层,它的数目pg_num和另一个值pgp_num(二者一般是相等的)直接影响集群的数据分布情况.pgp_num决定了多少pg会拿来存放数据,也就是说并不是所有创建出来的pg都会存放数据.理论上来

在官方网站下载了vs_community.exe自动下载安装的软件进行安装,安装到github时候 卡了1个小时 一直显示正在获取,遂感觉不大对劲,使用了FQ程序,过了2分钟果然正常获取安装,进入了下一步~

偶尔会遇到这样的现象 ssh 登录一台远程机器,显示下面的信息然后hang在那 Connecting to 192.168.137.102:22... Connection established. To escape to local shell, press 'Ctrl+Alt+]'. 这是因为sshd 默认开启了UseDNS. 所以卡在解析dns那里. 解决办法 编辑sshd配置文件,UseDNS no 重启服务

NFS导致df -h无法使用解决 NFS服务意外断开,导致挂载的客户端"df -Th"命令无法使用,及挂载目录无法"cd""ls"解决思路:1.强制取消客户端挂载2.重启NFS服务,客户端和服务端都需要重启3.重新挂载NFS处理方法:1.强制取消客户端挂载cat /etc/mtabumount -lf /mnt2.重启NFS服务,客户端和服务端都需要重启systemctl restart nfssystemctl restart rpcbind3

,在开发过程中,前端的依赖包都是使用bower来进行安装的,但是经常就是下载不了package特别的苦恼,这里顺便要抱怨一下github,不是一般的慢!! 后来在stackoverflow找到一个方法,记录一下,它的思路是用https的协议去访问和下载,而不用bower默认的git协议 对全局的git做如下的配置: git config --global url."https://".insteadOf git:// angularjs 参考资料:http://www.lifelaf.

项目里的: build.gradle 依赖 的gradle 版本 在每个项目里 gradle/wrapper/properties/gradle-wrapper.properties 配置文件里 用户天朝的墙,到这个网站下载 http://services.gradle.org/distributions/ 对应的发行版本放到 C:\Users\Lucky.Sui\.gradle\wrapper\dists 目录下 https://blog.csdn.net/easion_zms/article

http://services.gradle.org/distributions/  首先下载 all 版本 ,解压 ,再d盘, 并保留zip 文件  ,新建环境变量 GRADLE_HOME   指向这个目录 修改 idea 下,gradle-wrapper.rpoperties    distributionUrl=file:///D:/gradle-5.0/gradle-5.0-rc-3-all.zip   变成本地文件 如果是升级 ,删除C:\Users\flin\.gradle  里面的

罪魁祸首就是手误 点了一下代码中方法的左侧打了个方法断点 Java Method Breakpoints 有时候debug启动很慢也有可能是这个原因,记录一下

No Spring WebApplicationInitializer types detected on classpath 下一句:Initializing Spring root WebApplicationContext 然后就没有然后了,感觉时间凝滞,因为tomcat再也不往下运行了,即使你等到天荒地老~ 原因:数据库原因 可能是集群原因 可能是字符串原因 可能是构造函数原因 可能是端口原因

https://www.jianshu.com/p/36c2d5682d87 1. PG介绍 继上次分享的<Ceph介绍及原理架构分享>,这次主要来分享Ceph中的PG各种状态详解,PG是最复杂和难于理解的概念之一,PG的复杂如下: 在架构层次上,PG位于RADOS层的中间. a. 往上负责接收和处理来自客户端的请求. b. 往下负责将这些数据请求翻译为能够被本地对象存储所能理解的事务. 是组成存储池的基本单位,存储池中的很多特性,都是直接依托于PG实现的. 面向容灾域的备份策略使得一般而言的

前言 问题的触发是在进行一个目录的查询的时候,osd就会挂掉,开始以为是osd操作超时了,后来发现每次访问这个对象都有问题 log [WRN] : slow request 60.793196 seconds old, received at osd_op(mds.0.188:728345234100006c6ddc.00000000 [o map-get-header 0-0,omap-get-vals 0~16,getxattr parent] snapc 0=[] ack+read+kno