通常,我们在了解应用服务的性能时,都会去在所定义的垃圾收集日志文件中去分析GC活动轨迹,在gc.log文件中,我们经常会看到每个GC事件所打印的三种时间类型:
线上问题不同于开发期间的 bug,与运行时环境、压力、并发情况、具体的业务相关。对于线上的问题利用线上环境可用的工具,收集必要信息 对定位问题十分重要。
我在以前,分析过很多实际运行的故障,并把它做成了专辑,有十几篇文章,点击下面链接即可查看。
该接口的功能主要为查询HBase数据再返回给前端,初步怀疑为HBase集群问题,在查询HBase前后打印日志,发现接口超时的时候,查询耗时一直处于10s以上。但是该接口服务分布式部署了多台机器,其中只是某一台接口机超时,其实机器响应正常,且查看HBase集群负载和网络情况均无异常。于是怀疑为该接口服务发生了full gc。
每一种收集器的日志形式都是由它们自身的实现所决定的,换而言之,每个收集器的日志格式都可以不一样。但虚拟机设计者为了方便用户阅读,将各个收集器的日志都维持一定的共性,例如以下两段典型的GC日志:
lsof -i -P | grep LISTEN |grep java 查看应用端口
在高并发下,Java程序的GC问题属于很典型的一类问题,带来的影响往往会被进一步放大。不管是「GC频率过快」还是「GC耗时太长」,由于GC期间都存在Stop The World问题,因此很容易导致服务超时,引发性能问题。
阅读GC日志是处理Java虚拟机内存问题的基础技能,它只是一些人为确定的规则,没有太多技术含量。
看一段线上的gc日志,这是一段CMS完整步骤的日志,对于GC日志格式,不了解的可以再温习一下《GC及JVM参数》
常用的命令行工具主要有 jps、jstat、jinfo、jmap、jhat、jstack。
垃圾回收器的暂停问题一直是Java工程师关注的重点,特别是对实时响应要求较高的服务来说,CMS和G1等主流垃圾回收器的数十毫秒乃至上百毫秒的暂停时间相当致命。此外,调优门槛也相对较高,需要对垃圾回收器的内部机制有一定的了解,才能够进行有效的调优。
部署到生产环境的应用,无论是 C/S 结构,还是 B/S 结构的应用服务。肯定有基于 Shell 脚本编写的启动脚本。C/S 结构的应用服务的 Shell 脚本一般是公司内部开发人员编写的;以下一个 C/S 结构应用服务的简单启动脚本。
Linux 内核有个机制叫OOM killer(Out-Of-Memory killer),该机制会监控那些占用内存过大,尤其是瞬间很快消耗大量内存的进程,为了防止内存耗尽而内核会把该进程杀掉。
回望整个过年期间真的是躺的平平的,每天学习的时间和平时比起来差的不是一星半点。今天就复工了,也要收心了。我这个人有一个比较牛逼的能力就是状态调整特别快,只需要往工位上一坐下,我就能进入复工状态了。
Java 语言是当前互联网应用最为广泛的语言,作为一名 Java 程序猿,当业务相对比较稳定之后平常工作除了 coding 之外,大部分时间(70%~80%)是会用来排查突发或者周期性的线上问题。由于业务应用 bug(本身或引入第三方库)、内外部环境、底层硬件问题等原因,Java线上服务出现故障/问题几乎不可避免。例如,常见的现象包括部分请求超时、用户明显感受到系统发生卡顿等等。
随着系统自身数据量的增长,访问量增加,系统的响应通常会越来越慢,或者是新的功能在性能上无法满足修去,这个时候需要对系统进行性能调优。调优是一个复杂的过程,涉及的方面有:硬件,操作系统,运行环境软件和应用本身。
Arthas 是一款线上监控诊断产品,通过全局视角实时查看应用 load、内存、gc、线程的状态信息,并能在不修改应用代码的情况下,对业务问题进行诊断,包括查看方法调用的出入参、异常,监测方法执行耗时,类加载信息等,大大提升线上问题排查效率。
“ 给一个系统定位问题的时候,知识、经验是关键基础,数据是依据,工具是运用知识处理数据的手段。这里的数据包括:运行日志、异常堆栈、GC日志、线程快照(threaddump/javacore文件)、堆转储快照(heapdump/hprof文件)等。经常使用适当的虚拟机监控和分析的工具可以加快我们分析数据和定位解决问题的速度,但我们在学习工具前,也应当意识到工具永远都是知识技能的一层包装,没有什么工具是“秘密武器”,学会了就能包医百病”
每一种收集器的日志形式都是由他们自身的实现决定的,也就是说每个收集器的日志格式都可能不一样。
值此七夕佳节,烟哥放弃了无数妹纸的邀约,坐在电脑面前码字,就是为了给读者带来新的知识,这是一件伟大的事业! 好吧,实际情况是没人约。为了化解尴尬,我决定卖力写文章,嗯,一定是我过于屌丝! 好了,开始说重点。今天讲的这个问题
最近在做 Java8 到 Java17 的迁移工作,前期做了一些准备,但是在升级过程还是有些问题,太emo了,一些信息记录如下,分为几个部分:
尽管性能成本极低,但垃圾回收日志提供了宝贵的见解,说明 JVM 如何在运行时动态管理内存。
目前采用微服务架构已经逐渐成为企业架构的标准范式,而大多微服务是基于Spring Cloud框架来进行应用的构建的,所以在开发实践中,甚至生产环境中,会遇到java相关问题,例如系统运行变慢、内存OOM,堆栈异常等问题,这里结合我之前的一些实践提供一些相关工具,和大家一起分享我们的诊断思路和解决技巧。
whereis搜索redis服务执行文件:whereis redis-server
来源:juejin.cn/post/7117531586232320031 最近在做 Java8 到 Java17 的迁移工作,前期做了一些准备,但是在升级过程还是有些问题,太emo了,一些信息记录如下,分为几个部分: 编译相关 参数迁移相关 运行相关 前人栽树后人乘凉,有需要升级的可以参考一下,避免踩坑。。。 *编译相关* JEP 320 在 Java11 中引入了一个提案 JEP 320: Remove the Java EE and CORBA Modules (openjdk.org/jeps/32
因为有太多人公众号偷转我的掘金文章,我还是发到公众号这里吧。 Java 8 是旧时代的 Java 6,还不快升级,😄。最近在做 Java8 到 Java17 的迁移工作,前期做了一些准备,过程中的一些信息记录如下(持续更新。。。https://juejin.cn/post/7117531586232320031 ) 分为几个部分: 编译相关 参数迁移相关 运行相关 编译相关 JEP 320 在 Java11 中引入了一个提案 JEP 320: Remove the Java EE and CORBA Mod
Java 8 是旧时代的 Java 6,还不快升级 。最近在做 Java8 到 Java17 的迁移工作,前期做了一些准备,过程中的一些信息记录如下(持续更新。。。)
//输出大对象到文件 jmap -histo:live pid > ./java.log //查询前20占用内存大对象 jmap -histo:live 2837 | head -n 20 //查看Full GC情况 jstat -gcutil 2501 //查看线程 top -H -p 2501 //查看启动参数 jinfo -flags //查看linux内核日志 dmesg | grep java //查看系统日志 vim /var/log/messages 查看系统日志 //jvm使用
CMS(标记-清除)——》G1(标记整理)——》ZGC(染色指针,多重映射等技术)
ZGC 启用Large Pages 是一种对应用高性能的折中(吞吐量、低延迟及启动时间),但是却不会带来明显的弊端。除了在应用启动上需要稍微复杂的配置,所需要的系统相关root权限需要手动进行配置。
通常情况下,在部署了 K8S 服务之后,为了更好地监控服务的运行情况,都会接入对应的日志系统来进行检测和分析,比如常见的 Filebeat + ElasticSearch + Kibana 这一套组合来完成。 虽然该组合可以满足我们对于服务监控的要求,但是如果只是部署一个内部单服务用的话,未免显得大材小用,而且部署服务还会带来大量的资源消耗。那么有没有简单查看 K8S 中多个 Pod 中的日志工具呢?咳咳咳,那么今天就介绍两款超好用的多容器实时日志查看工具 Kubetail 和 Stern。
连起来看 运行时间: [GC类型 (原因)] [收集器类型: GC前该内存区域已经使用容量->GC后该内存区域已使用容量(该内存区域总容量)] GC前Java堆已使用容量->GC后Java堆已使用容量(Java堆总容量), 执行时间 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
最后一个脚本是执行另一个脚本:kafka-run-class.sh,这个脚本的内容比较复杂了。
今天要探讨的是最近不知道为什么突然间火起来的面试题:当JAVA程序出现OOM之后,程序还能正常被访问吗?答案是可以的,很多时候他并不会直接导致程序崩溃,而是JVM会抛出一个error,告知你程序内存溢出了。当然也要分操作系统。
垃圾回收日志(GC 日志)是 JVM 在进行垃圾回收时产生的日志记录。它包含了垃圾回收器的各种信息,如垃圾回收的类型、垃圾回收的时间、垃圾回收的阶段、回收的内存占比等。通过分析 GC 日志,我们可以了解垃圾回收器的行为和性能,并根据日志数据进行调优。
Elasticsearch是一个基于Lucene的搜索和分析引擎,能够处理大规模的数据并提供实时的搜索和分析功能。为了充分发挥Elasticsearch的性能,集群搭建时的Linux系统设置优化至关重要。本文将分模块详细介绍如何优化Linux设置,以确保Elasticsearch集群的高效运行。
之前线上有过一两次OOM的问题,但是每次定位问题都有点手足无措的感觉,刚好利用星期天,以测试环境为模版来学习一下Linux常用的几个排查问题的命令。 也可以帮助自己在以后的工作中快速的排查线上问题。
这一系列文章是学习K8S过程的笔记,使用的是kubeadm来部署。 参考https://kubernetes.io/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/。
前面介绍了虚拟机的内存分配和回收,大致有了一些理论基础,接下来我们从实践的角度去了解虚拟机内存管理。定位问题的时候,知识、经验是关键基础,数据是依据,工具是运用知识处理数据的手段。
本文作者:yifhao,腾讯PCG NOW直播 后台工程师 介绍 本文基于 2019.02 发布的 go 1.12 linux amd64 版本, 主要介绍了 Runtime 实现的一点原理和细节, 对大家容易错或者网络上很多错误的地方做一些梳理: Golang Runtime 是个什么 Golang Runtime 的发展历程, 每个版本的改进 Go 调度: 协程结构体, 上下文切换, 调度队列, 大致调度流程, 同步执行流又不阻塞线程的网络实现等 Go 内存: 内存结构, mspan 结构, 全
最开始的mqnamesrv.sh脚本获取环境变量的部分看不懂其实没啥影响,大略有个印象即可,当然可以截取部分的命令到Linux运行测试一下就明白了,比如准备环境变量等等,最后一句话比较关键。
-XX:+UseG1GC -XX:MaxGCPauseMillis=100 -Xms524m -Xmx524m -XX:+PrintCommandLineFlags -Xlog:gc=debug,gc+metaspace:gc.log
Elasticsearch是当前主流的分布式大数据存储和搜索引擎,可以为用户提供强大的全文本检索能力,广泛应用于日志检索,全站搜索等领域。Logstash作为Elasicsearch常用的实时数据采集引擎,可以采集来自不同数据源的数据,并对数据进行处理后输出到多种输出源,是Elastic Stack 的重要组成部分。本文从Logstash的工作原理,使用示例,部署方式及性能调优等方面入手,为大家提供一个快速入门Logstash的方式。文章最后也给出了一些深入了解Logstash的的链接,以方便大家根据需要详细了解。
若要安装最新版 dotnet-gcdump NuGet 包,请使用 dotnet tool install 命令:
虽然天猫,蚂蚁金,菜鸟都归属阿里旗下,但每个面试官问的问题都不一样,相同点主要在流程方面。面试开始会让自我介绍,主要业务架构和技术架构两部分。业务架构一般不会深究,但要面试官听明白,并且一般面试官会顺着问是如何根据这些业务去设计技术架构的。 面试试题 其他 什么是幂等?什么情况下需要考虑幂等?你怎么解决幂等的问题? Java 多个线程同时读写,读线程的数量远远大于写线程,你认为应该如何解决并发的问题?你会选择加什么样的锁? JAVA的AQS是否了了解,它是干嘛的? 除了synchronized关键字之外
年更贴,因为两年里遇到的事情,一些想法变了。也补充了不少VJTools的内容,比如为伸手党们准备的jvm-options.sh。
异常现象:2019-1-21~2019-1-22测试环境的apollo频繁宕机,大概有4~5次。
生产环境上,或者其他要测试 GC 问题的环境上,一定会配置上打印GC日志的参数,便于分析 GC 相关的问题。
领取专属 10元无门槛券
手把手带您无忧上云