原来以为内存溢出这种事情只会发生在书本上，没想到在我们生产环境发生了，而且是618，P0事故安排上了。先回顾一下内存溢出排查的基本思路，然后再来复盘一下内存溢出发生的原因
有些网站web服务的架构是Apache配合websphere application server搭建起来的。如果不注意websphere applicationserver的配置，随着网站访问量的上升，可能出现内存占用不断上涨，网站速度变慢，最后内存耗尽的后果。
作者简介 刘韬，云和恩墨中间件服务交付团队专家 Java开发出身，10年WebLogic相关开发、运维工作经验，熟悉SOA、现代业务系统架构中各层组件，尤其擅长故障处理、性能优化等工作。 故障案例一 系统环境： RHEL 6.8 64-bit（glibc 2.12）、Sun JDK 6u45 64-bit、WLS 10.3.6 故障现象： 这里引用一下客户当时发邮件时提出的问题描述吧。 下面pid 6287 weblogic进程占用7.6G的物理内存，之前只占用5G内存。我发现只有系统有空余的内存，就会被j
前段时间做一个需求，需要用到一个本地词典文件。该词典原始文件超过2G，在服务启动的时候加载到内存中，并且保持词典数据的热加载，也就是不停服更新词典数据到服务进程的内存中。
内存问题往往是线上环境最容易导致的问题，因为其实对于程序来说，内存总是不够用的。而大多数我们在线上遇到的问题总是一个叫 OOM 的，导致这个问题的原因也有很多，今天我们就来看看，如何在线上定位或者排查这样的问题。
通过上一篇文章 《自研的内存分析利器开源了！Android Bitmap Monitor 助你定位不合理的图片使用》 我们知道了好用的图片内存分析工具 AndroidBitmapMonitor，现在我们来了解下它的原理。
当应用实现了新功能后，准备发布版本前，必须进行性能测试以确定没有性能问题，内存使用情况便是其中必须要测试的性能之一。由于内存组成的复杂性，并没有简单通用的方法能够发现所有的内存问题。有时候因为问题比较明显，就真的发现了问题，但是对于较为成熟的软件，并不是那么容易发现内存问题。现在从内存测试流程、内存测试方法、内存占用的评判建议三个方面总结如下，希望能提升内存测试的有效性。
记录一次线上JVM堆外内存泄漏问题的排查过程与思路，其中夹带一些「JVM内存分配的原理分析」以及「常用的JVM问题排查手段和工具分享」，希望对大家有所帮助。
记录一次线上JVM堆外内存泄漏问题的排查过程与思路，其中夹带一些JVM内存分配机制以及常用的JVM问题排查指令和工具分享，希望对大家有所帮助。
你可能用过ps命令，打印所有正在运行的进程的相关信息。JDK 中的jps命令。沿用了同样的概念：它将打印所有正在运行的 Java 进程的相关信息。
近期，腾讯云 Serverless 云函数发布了并发管理能力升级版，提供了 3 个维度的并发额度管理的功能。该功能究竟提供了哪些能力，有哪些使用场景？本文将为您全方位解读并发管理功能，并对多种使用场景提供配置建议。 背景介绍 原先，创建一个函数，默认具有300的并发数量上限。针对小的低频业务，300 的并发值足够使用。但是遇到业务量上涨、支撑大型运营活动等大并发的情况，开发者就需要通过提工单联系平台方，申请提升函数并发额度。这样可能导致： 每遇到一次大并发，就需要联系一次平台方来提升配额，时效性弱。 申请
在今年的敏捷团队建设中，我通过Suite执行器实现了一键自动化单元测试。Juint除了Suite执行器还有哪些执行器呢？由此我的Runner探索之旅开始了！
一、背景 2020年K歌安卓的白屏反馈和top crash在逐渐恶化，深入分析后，这两个问题的原因都指向了内存不足，我们通过脚本压测直播、歌房等核心场景复现了问题，也实锤了我们的猜想，确定是内存、线程、fd等资源耗尽，app开始出现各种异常。当前需求的性能测试主要依赖我们测试同学的人工覆盖，在K歌需求飞速迭代的情况下，人工性能测试的发现问题能力出现了瓶颈： 测试人力有限，只能覆盖小部分的需求，大量的需求未经过严格的性能测试，可能会带着内存问题发布到外网； 测试场景不足，无法反映外网海量用户的复杂情况，很难
Shell脚本实现监控swap空间使用情况和查看占用swap的进程,曾经有一段时间机器的swap不停上涨,监控后发现是一些java进程占用swap空间后,完全不释放,杀死这些java进程后,释放swap。
活动介绍 TMQ第四十一期在线沙龙分享活动圆满结束啦！ 本次分享的主题：性能测试 共有326位测试小伙伴报名参加活动。 想知道活动分享了啥吗？ 请往下看吧！ 嘉宾 樊春霖：腾讯测试工程师，目前主要负责
最近我们有个服务的时延(Latency)略微上涨，gc时间上涨了一倍，dump出java堆(Heap)之后用Mat分析发现，有份cache数据占据了20%+的堆内存，拥有上千万个小对象。然而这部分数据只是部分逻辑会用到，所以它占据这么大的堆内空间显得有些不值，并且会影响到gc进而影响到服务的时延。 当然也有一些其他数据也占用比较多的堆内空间，但做优化总是先拿大头开刀。 当然把这份数据去掉是不可能了，因为上面还承载着几个比较重要的业务逻辑。既然数据放到java 堆内影响gc，是否可以放到堆外？答案是肯定的，这也是我写这篇博客的目的。就是用Ehcahe把数据移动到堆外，ehcahe甚至可以把数据放到磁盘、放到远端服务器。
这几天，一直在为Java的“内存泄露”问题纠结。Java应用程序占用的内存在不断的、有规律的上涨，最终超过了监控阈值。福尔摩 斯不得不出手了！
为了判断 Java 中是否有内存泄漏，我们首先必须了解 Java 是如何管理内存的。下面我们先给出一个简单的内存泄漏的例子，在这个例子中我们循环申请 Object 对象，并将所申请的对象放入一个 HashMap 中，如果我们仅仅释放引用本身，那么 HashMap 仍然引用该对象，所以这个对象对 GC 来说是不可回收的。
线上某个kafka集群由于种种原因，从 24 * 机型 A 置换迁移为 12 * 机型 B。从集群总资源维度看，排除其他客观因素，置换后，CPU总核数少了一半，使用率上升其实也是预期之内的。事实上置换后，集群CPU使用率确实也由原有的 20%提升至 40%，上升了约 1 倍多。但置换后，cpu sys使用率均值约达到了 12%，较为抢眼，系统相关服务却并无异常，令人有些困惑。
随着云计算的广泛普及和云原生实践，越来越多的公司开始将目光投向云上的稳定性治理。混沌工程的概念最早来自Netflix，并且在NF取得成功，证明了混沌工程在云计算中扮演关键角色，通过有计划地引入故障和不稳定性，确保系统的健壮性和可靠性，使组织能够充分利用云计算的优势，并实现高质量的应用交付。
在 Erda 的技术架构中，我们使用了 kong 作为 API 网关的技术选型。因其具备高并发低延时的特性，同时结合了 Kubernetes Ingress Controller，基于云原生的声明式配置方式，能够实现丰富的 API 策略。
OOM(Out Of Memory)是Android应用开发中相信每个人都遇到过的问题，而OOM在crash log中的stack trace一般没有实际意义，因为是在分配内存的时候才会抛出OOM异常，而这个时候的stack trace和OOM的原因没有任何关系。所以OOM问题的定位和分析就需要多花费一些功夫。
JIT 即时编译可能会遇到编译后的代码缓存占满，或者因为空间有限或者代码设计问题，导致某些关键方法需要重编译导致性能问题，以及因为代码块过大导致编译失败从而性能有问题，这些问题我们可以通过 JFR 中相关的 Event 进行查询。 JFR 对于 Java 开发可以完全替换 JVM 编译日志。
分布式系统对于用户而言，他们面对的就是一个服务器，提供用户需要的服务而已，而实际上这些服务是通过背后的众多服务器组成的一个分布式系统，因此分布式系统看起来像是一个超级计算机一样。
然后执行 jmap -histo:live 7320 （注：如果输出内容太多，只想看排名前10的，可以加 | head -10）
不知道大家有没有注意到，在22.10.31 21点之后，凯哥的个人博客站点(凯哥Java:www.kaigejava.com)访问速度提升了不少。那是因为凯哥对站点做了优化。本文就记录优化方面：
本文描述问题及解决方法同样适用于 腾讯云 Elasticsearch Service（ES）。
通过jstat -gcutil pid 5000 ,发现fgc次数很多而且频繁，此时老年代占比已经大约70%左右，且已经回收不了内存，我们这边设置的fgc阈值是老年代的70%。此时因为还有30%的老年空间，所以整体内存相对还算稳定，CPU也比较稳定，但是有很大的潜在的风险，就是内存一直上涨，不释放。
服务在线上环境频繁的Full GC。把相关运行时数据区的监控打开，发现堆外内存一直在上升。
在最近的一次百万长连接压测中，32C 128G 的四台 Nginx 频繁出现 OOM，出现问题时的内存监控如下所示。
Django 作为 Python著名的Web框架，相信很多人都在用，自己工作中也有项目项目在用，而在最近几天的使用中发现，部署Django程序的服务器出现了内存问题，现象就是运行一段时间之后，内存占用非常高，最终会把服务器的内存耗尽，对于Python项目出现内存问题，自己之前处理过一次，所以并没有第一次解决时的慌张，自己之前把解决方法也整理了博客：https://www.cnblogs.com/zhaof/p/10031945.html
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
JVM相关的异常，一直是一线研发比较头疼的问题。因为对于业务代码，JVM的运行基本算是黑盒，当异常发生时，较难直观的看到和找到问题所在，这也是我们一直要研究其内部逻辑的原因。
《全民K歌内存篇1——线上监控与综合治理》 《全民K歌内存篇2——虚拟内存浅析》 《全民K歌内存篇3——native内存分析与监控》 一、背景 在2020年的上半年，我们在用户反馈后台发现闪退、白屏问题不断增多，这些问题严重影响用户体验。观察Crash监控平台发现Crash率也在逐步升高,其中Native层的Top1的crash堆栈信息如下： 这个Crash在整体的crash中占比很大，通过这个堆栈信息，发现并没有明显的指向哪个业务代码。此时，把发生Crash时的内存信息上报到后台，分析发现：Cra
本文以我司生产环境Java应用内存泄露为案例进行分析，讲解如何使用Eclipse的MAT分析定位问题
虽然java有自动化的GC，但是还会有内存泄露的情况。当然java中的内存泄露跟C++中的泄露不同。
top，观察内存占用率（这里图是重启之后一段时间的）但是cpu占用率比较高，很快就降下去了，这里耽误了一下时间，top -Hp pid,确认那个线程占用率高，jstack看了下对应的线程在作甚
希望这期不要掉粉，因为在说SQL SERVER 但实际上这期如果你放到所有的数据库上去看，也是有营养的，虽然放到了一般不会发文的周六，也没想有多少观众，就当自己对某些东西的回顾和反思。
随着业务的日渐复杂，性能优化俨然成为了每一位技术人的必修课。性能优化从何着手？如何从问题表象定位到性能瓶颈？如何验证优化措施是否有效？本文将介绍分享 vivo push 推荐项目中的性能调优实践，希望给大家提供一些借鉴和参考。
最近新版本发布后，在运行一段时间后程序突然无响应了，观察监控，发现JVM堆内存占用在某个时间点突然飙升，最终导致应用无响应：
介绍完 深入学习Android：虚拟机&运行时 之后，很多小伙伴问我，你描述的这些知识结构看起来艰深晦涩高大上，实际工作中能有多大用途呢？今天我就简单举个例子。
俗话说，工欲善其事，必先利其器，一名好的开发者，必然要有一套好的开发工具，这样才能打造出最好的产品给用户。世界上的IDE种类繁多，要论那个IDE好用，可能有人会选择老牌的Visual Studio 或是Eclipse；也有人会选择使用者人数一路飙升的Intellij；也有人更偏爱Google发布的Android Studio。
OOM是实例使用内存超过实例规格内存上限导致进程被kill，实例存在秒级的不可用。MySQL的内存管理比较复杂，内存监控需要开启performance schema查询(默认关闭)，会带来额外的内存消耗和性能损失，在不开启performance schema情况下排查内存使用情况又比较困难。本文将基于TDSQL-C（基于MySQL5.7）总结一下在线上经常出现的一些OOM的场景、排查手段及相应的优化方案。 ---- 一、MySQL线上常见OOM问题 1.1 表数量较多导致innodb数据字典内存占用多 查
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
云直播
