首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
您找到你想要的搜索结果了吗?
是的
没有找到

一次ES故障排查过程

思路:现象是阻塞,通常是 CPU 彪高,导致业务线程分配不到 CPU 时间片,或者内存吃紧,频繁 GC 导致的 STW。登录到目标服务器,由于 ES 的用户不是 LZ,因此找运维要了 root 权限,登录到服务器。sudo -i 切到 root,使用 ps -ef | grep Elasticsearch 找到该用户,然后 su - es 切到 es 用户(不切是无法处理 es 用户的 Java 进程的,例如打印 jstack 日志)。 top 查看服务器状态,发现 pid 4335 进程的 CPU 占用达到 180%,查看 CPU 核数:cat /proc/cpuinfo| grep “processor”| wc -l, 核数为 4,根据经验,通常是 C2 编译器,或者 GC 线程,最后是业务代码导致。因此需要定位该线程。使用 top -Hp 4335,得到线程号 30785,使用 printf "%x" 得到 16 进制数字 7841,方便在 jstack 日志查找线程。使用 jstack -l 4335 > jstacklog.txt 打印日志,然后找线程,vim jstacklog.txt, 开始查找,gg,/7841,enter,n, 找到 "Concurrent Mark-Sweep GC Thread" os_prio=0 tid=0x00007fd380063800 nid=0x7841 runnable 这个 CMS GC 线程,看来是内存不够了。 使用 jps -l 找到 es 启动类名称,然后使用 ps aux | grep Elasticsearch 找到启动详细信息,发现启动配置为 -Xmx2g -Xms2g, -XX:CMSInitiatingOccupancyFraction=50 ,这里为了防止串行 FGC,让 CMS 在 old 区达到 50% 时就开始 GC,所以 CMS 非常繁忙。为了验证此问题,使用 jstat -gcutil 4335 1000 查看 gc 状态,发现 fgc 频繁(5 秒一次),ygc 正常(3 秒一次) ,这里说一下,CMS 的 fgc 此时和我们想象的不一样,CMS GC 只工作在老年代,每次 GC 会对 FGC 次数加 2,一次是 init mark,一次是 remark,这两个阶段会影响暂停应用,其他的清理阶段是并行清理的,对业务线程无影响,所以,当使用 CMS GC ,如果 jstat 看到 FGC 次数很多,不用在意。但当 CMS 出现 concurrent mode failure(CMS GC 的速度赶不上对象晋升到 old 区的速度),则会使用备用收集器 Serial,开始串行 GC,此时将会彻底 STW。 因此,这个 ES 将 CMS 的阈值调的很低,就是为了防止出现 concurrent mode failure。

01

日常随笔--Spring Cloud、Shell脚本、JDK版本新特征

– 针对微服务架构,spring cloud提供了一套解决方案 – 服务注册与发现 – 服务网关 – 服务通信 – 服务治理 – 配置管理 spring cloud netflix快速实现分布式系统的常见架构模式 – 服务发现Eureka – 只能路由Zuul – 客户端负载均衡Ribbon – 断路器Hystrix – Eureka提供在分布式环境下的服务发现和服务注册 高可用 自我保护模式 基于HTTP – Eureka server 服务注册中心,存储所有的注册服务信息,根据客户端上报的心跳检查,定期清理无效服务 – Eureka client Java客户端,嵌入业务服务模块,用来简化与服务器交互,启动的时候,会初始化多个定时任务 – 定时的把本地的服务配置信息,即需要注册到远端的服务信息自动刷新到注册服务器上 – 定时的获取远端的注册信息 – 定时上报本地服务器状况(心跳检查) – 作为轮询负载均衡器,并提哦国内服务的故障切换支持 Zuul 提供在分布式环境下智能路由、反向代理等网关功能 – 智能路由 以动态方式根据需要将请求路由至不同后端集群处理 – 安全与验证 识别面向不同资源的验证要求并拒绝那些与要求不符的请求 – 静态响应处理 在请求入口位置直接建立部分响应,从而避免景钛资源访问流入内部动态服务集群 – 流量整形 为不同负载类型分配对应容量,并弃用超出限定值的请求 – 多区域弹性 跨越AWS区域进行请求路由,旨在实现ELB使用多样化并保证网关位置与使用者尽可能接近

02
领券