本文旨在介绍下几种常见的调试方法gdb、crash、kgdb and kdb 以及dynamic debug. 关于在 Linux 内核上使用debuggers，Linus Torvalds 长期以来对它们不太喜欢。简短地解释这种态度是，依赖调试器可能鼓励用权宜之计而非深思熟虑来解决问题，这会导致代码质量恶化。详细解释可以参考https://lwn.net/2000/0914/a/lt-debugger.php3
Linux 内核有个机制叫OOM killer（Out-Of-Memory killer），该机制会监控那些占用内存过大，尤其是瞬间很快消耗大量内存的进程，为了防止内存耗尽而内核会把该进程杀掉。
值此七夕佳节，烟哥放弃了无数妹纸的邀约，坐在电脑面前码字，就是为了给读者带来新的知识，这是一件伟大的事业！ 好吧，实际情况是没人约。为了化解尴尬，我决定卖力写文章，嗯，一定是我过于屌丝！ 好了，开始说重点。今天讲的这个问题
这段代码非常简单，就是先用mmap的方式，为该进程分配10GiB的虚拟内存，然后再用page写的方式，让操作系统为这10GiB虚拟内存，分配对应的物理内存，最后sleep，等待我们测试。
centos7 3.10.0-1160.62.1.el7.x86_64内核版本已修复该问题，CentOS7受影响内核版本 3.10.0-862.el7 - 3.10.0-1160.59.1.el7
背景描述 某项目结构图如下(前端交互式体验及对象存储为主，Redis 及 rds 负载较小没有画出)： web1 和 web2 是两个 Apache，publisher1 和 publisher2 是
| 导语 企鹅FM近几个版本的外网Crash出现很多OutOfMemory（以下简称OOM）问题，Crash的堆栈都在Thread::start方法上。该文详细分析了发生原因。 ---- 有两种栈： 出现次数最多的一种，称之为 堆栈A。 java.lang.OutOfMemoryError: pthread_create (1040KB stack) failed: Out of memory java.lang.Thread.nativeCreate(Native Method)
客户上云过程中将原有在数据中心自建kubernetes集群迁移至腾讯云TKE集群，迁移过程中发现其中有一个容器沙箱环境频繁出现node节点夯死现象，目前已经出现5-6次，亟需定位原因。出现异常时节点无法登陆且需要手动重启才能恢复，"罪犯"逃离，异常后节点状态置为NotReady，无状态化pods会自动驱逐至其他节点，有状态化StatefullSets部署的pods无法驱逐成功。
注：本问题影响 3.10.0-862.el7.centos 及之后的 CentOS 7 版本内核，目前问题还未被修复。
由于早期的云服务器，大量存量3.10内核作为cvm的操作系统内核。3.10内核存在着很多已知问题，其中的常客之一便是内存不足场景下，内存回收引发的问题。 内存回收和OOM一直是Linux中一个饱受诟病的问题，其路径内核一直在优化，所以从理论上新版本内核一定是优于老版本。 本文通过构造用例测试，来针对3.10和5.4内核在内存不足场景下的表现进行分析对比，以说明5.4会在内存不足的场景下有更好的表现。
在启动一个Springboot工程时，抛出一项“Cannot allocate memory”异常，很明显，是因为内存分配原因导致的OOM异常导致JVM宕掉。跟随log，查看JVM hs_err_pid24442.log文件。
配送骑手端App是骑手用于完成配送履约的应用，帮助骑手完成接单、到店、取货及送达，提供各种不同的运力服务，也是整个外卖闭环中的重要节点。由于配送业务的特性，骑手App对于应用稳定性的要求非常高，体现App稳定性的一个重要数据就是Crash率，而在众多Crash中最棘手最难定位的就是OOM问题。对于骑手端App而言，每天骑手都会长时间的使用App进行配送，而在长时间的使用过程中，App中所有的内存泄漏都会慢慢累积在内存中，最后就容易导致OOM，从而影响骑手的配送效率，进而影响整个外卖业务。
最近一朋友提了几个Android问题让我帮忙写个小分享，我觉得对新人还是挺有帮助的，所以有了这个小分享。 1.目前， Android APP开发完成后，通常需要在哪些机型上进行测试？ 2.目前， 开发Android APP时，需要考虑的分辨率有哪些？ 这两个问题可以合起来回答的。 http://developer.android.com/about/dashboards/index.html 源自Google Play的数据，每月都会进行update，可以及时了解Android版本比例趋势。 屏幕密度数
CentOS 7默认安装MySQL5.7.23，服务管理发生了变化，从sysvinit（service mysql start）变化为systemd（systemctl start mysqld.service）
相信大多数动脑同学对文章中提到的ActivityManagerService（以后简称AMS）都有所耳闻。
这个标题很吸引眼球实际上内容也应该很好玩. 问题的产生是最近我们在各个数据库进行数据库安装规范的事情,而在规范后,安装的第一台机器,进行压测就惨遭崩溃.
对crash的数据库进行故障分析并不是一件快乐的事情，尤其是 MySQL 的日志中没有提供 crash 原因的情形。比如当 MySQL 内存耗尽。在 2012年 Peter Zaitsev 写了一篇文章 分析MySQL如何使用内存
目录介绍 01.该库具有的功能 02.该库优势分析 03.该库如何使用 04.降低非必要crash 05.异常恢复原理 06.后续的需求说明 07.异常栈轨迹原理 08.部分问题反馈 09.其他内容说明 01.该库具有的功能 1.1 功能说明 异常崩溃后思考的一些问题 1.是否需要恢复activity栈，以及所在崩溃页面数据 2.crash信息保存和异常捕获，是否和百度bug崩溃统计sdk等兼容。是否方便接入 3.是否要回到栈顶部的那个activity(保存栈信息) 4.崩溃后需要收集哪些信息。手机信息，a
Crash率是衡量一个App好坏的重要指标之一，如果你忽略了它的存在，它就会愈演愈烈，最后造成大量用户的流失，进而给公司带来无法估量的损失。本文讲述美团外卖Android客户端团队在将App的Crash率从千分之三做到万分之二过程中所做的大量实践工作，抛砖引玉，希望能够为其他团队提供一些经验和启发。
内存太高导致free内存低于水位时，会导致网络收包时因free 内存低于水位线频繁触发分配内存失败导致无法ssh登陆机器。 这时候如果发生了重启，或者是sysrq自己触发重启并生成了coredump，可以用来定位问题的原因。
前言： 进程crash一般比较讨厌，尤其是segmentation fault，所谓的“踩内存”，是最讨厌的。 分析： 1，status 进程的状态，一般使用ps aux命令查看： 其中STAT列
PAG 4.1 版本新增支持微信小程序，新增支持多个常用 AE 特性，如图层样式-渐变叠加、蒙版-羽化和不透明度、 亮度轨道遮罩/亮度轨道反转遮罩等。经过 2 个多月 6 个版本的迭代，PAG 4.1 版本已经趋于稳定，目前广泛应用于 QQ、小红书等头部 APP，现正式发布，欢迎大家接入使用。 4.1 版本主要修改内容 平台支持 新增支持微信小程序，目前 PAG SDK 已完成覆盖 iOS、Android、macOS、Windows、Linux、Web 和微信小程序等常用平台。 AE 特性新增支持
本文是我订阅“腾讯大讲堂”公众帐号时，他们推送的一篇文章，但在腾讯大讲堂官网上我并没有找到这篇文章，不过其它专门“爬”公众号文章的网站倒是有。我觉得写的很不错。就转载出来，如有版权问题请email告知。
Crash率是衡量一个App好坏的重要指标之一。如果你忽略了它的存在，它就会得寸进尺，愈演愈烈，最后造成大量用户的流失，进而给公司带来无法估量的损失。本文讲述美团外卖Android客户端团队在将App的Crash率从千分之三做到万分之二过程中所做的大量实践工作，抛砖引玉，希望能够为其他团队提供一些经验和启发。
问题 最近总有开发小伙伴来找我，为什么我的容器总退出呢，在哪能看到原因。故写篇文章整理下docker退出的状态码。
最近总有开发小伙伴来找我，为什么我的容器总退出呢，在哪能看到原因。故写篇文章整理下docker退出的状态码。
前言 对于大多数大三学生来说，这个暑假是人生最后一个暑假。对于IT专业的学生来说，开学后就要面对各大IT企业的秋招，很多人会成为从0开始的Android实习生。在Android初学之路上，每个Android实习生都会遇到各式各样的瓶颈。 克服瓶颈要从克服自己对一切瓶颈的偏见做起，把逃避瓶颈的行为变成享受瓶颈带来的乐趣的过程。要知道喜力比国产啤酒贵好多的一条重要原因就在于喜力的瓶颈：你现在去买一瓶玻璃瓶装喜力，用手握住瓶颈，大拇指按住那颗星，然后用你最熟悉的动作撸瓶颈，你会喜
前言 内存问题是软件领域的经典问题，平时藏得很深，在出现问题之前没太多征兆。而一旦爆发问题，问题来源的多样、不易重现、现场信息少、难以定位等困难，就会让人头疼不已。 微信在过去 N 多的版本迭代中，经历了各式各样的内存问题，这些问题包括但不限于 Activity 的泄漏、Cursor 未关闭、线程的过度使用、无节制的创建缓存、以及某个 so 库悄无声息一点点的泄漏内存，等等。有些问题甚至曾倒逼着我们改变了微信的架构（2.x 时代 webview 内核泄露催生了微信多进程架构的改变）。时至今日微信依然偶尔
本文聚焦的问题 1、Bitmap的像素数据是存在哪里的？ 2、Bitmap内存如何释放？需要调用recycle吗？
在一个迭代开发完毕之后，ci构建好测试包，交给测试人员进行测试，随后在测试的过程中，出现了一些问题，有些很容易追踪，比如一些逻辑bug，需求没有实现，但还是有一些需要花费一些经历去排查，比如：
我们知道Java崩溃是在Java代码中出现了未捕获异常，导致程序异常退出，常见的异常有：NPE、OOM、ArrayIndexOutOfBoundsException、IllegalStateException、ConcurrentModificationException等等。 还有一类崩溃，也是我们不得不关注，那就是Native层崩溃，这类崩溃不像Java层崩溃那样比较清晰的看出堆栈信息以及具体的崩溃。每当遇到是都要查找分析，写这篇的目的是帮助自己做下记录，也希望能帮到有类似困扰的你，下面我们开始一起学习实践吧。 本文学习实践的demo以张绍文《Android开发高手课》中的例子进行。
前言 在 Android开发中，性能优化策略十分重要 因为其决定了应用程序的开发质量：可用性、流畅性、稳定性等，是提高用户留存率的关键 本文全面讲解性能优化中的所有知识，献上一份 Android性能优化的详细攻略， 含：优化方向、原因 & 具体优化方案，希望你们会喜欢 目录 1. 性能优化的目的 性能优化的目的是为了让应用程序App 更快、更稳定 & 更省。具体介绍如下： 更快：应用程序 运行得更加流畅、不卡顿，能快速响应用户操作 更稳定：应用程序 能 稳定运行 & 解决用户需求，在用户使用过程中不
本文介绍Java诸多优化实例：第一，排查堆上、堆外内存泄露；第二，使用arthas、jaeger、tcpdump、jstack做性能优化；第三，排查进程异常退出的原因，如被杀、System.exit、Java调用的C++发生Crash、Java内Crash；第四，排查死锁的原因，如log4j死锁、封装不严谨导致的死锁
作者：杨超，腾讯移动客户端开发 工程师 商业转载请联系腾讯WeTest获得授权，非商业转载请注明出处。 原文链接：http://wetest.qq.com/lab/view/362.html We
在 我这样减少了26.5M Java内存！中内存优化一期已经告一段落，主要做的事情是，造了几个分析内存问题的轮子，定位进程各种类型内存占用情况，分析了线程创建OOM的原因。当然最重要的是，优化了一波进程静息态的内存占用（减少26M+）。而二期则是在一期的基础之上，推进已发现问题的SDK解决问题，最终要的是要优化进程的动态Java内存占用！
在 我这样减少了26.5M Java内存！中内存优化一期已经告一段落，主要做的事情是，造了几个分析内存问题的轮子，定位进程各种类型内存占用情况，分析了线程创建OOM的原因。当然最重要的是，优化了一波进程静息态的内存占用（减少26M+）。而二期则是在一期的基础之上，推进已发现问题的SDK解决问题，最终要的是要优化进程的动态Java内存占用！ 通常来说不管是做什么性能优化，逃不出性能优化3步曲： 1. 找到性能瓶颈 2. 分析优化方案 3. 执行优化 上述三步看似第三步最能决定优化结果，而事实上，从笔者的几次
导读 本文介绍Java诸多优化实例：第一，排查堆上、堆外内存泄露；第二，使用arthas、jaeger、tcpdump、jstack做性能优化；第三，排查进程异常退出的原因，如被杀、System.exit、Java调用的C++发生Crash、Java内Crash；第四，排查死锁的原因，如log4j死锁、封装不严谨导致的死锁 内存泄漏 内存泄露在C++里排查很简单，用钩子函数勾住内存分配和释放函数malloc和free，统计哪些malloc的内存没有free，就可以找出内存泄露的源头。但在Java
该系统属于长连接消息推送业务，某节假日推送消息的流量突增几倍，顺时出现比平日多出几倍的消息量等待下推。事后，发现生产消息的业务服务端因为某 bug ，把大量消息堆积在内存里，在一段时间后，突发性的发送大量消息到推送系统。但由于流量保护器的上限较高，当前未触发熔断和限流，所以消息依然进行流转。消息系统不能简单的进行削峰填谷式的排队处理，因为很容易造成消息的耗时长尾，所以在不触发流量保护器的前提下，需要进行的并发并行的去流转消息。
The OOM Killer 是内核中的一个进程，当系统出现严重内存不足时，它就会启用自己的算法去选择某一个进程并杀掉. 之所以会发生这种情况，是因为Linux内核在给某个进程分配内存时，会比进程申请的内存多分配一些. 这是为了保证进程在真正使用的时候有足够的内存，因为进程在申请内存后并不一定立即使用，当真正使用的时候，可能部分内存已经被回收了。
看了 《Android 的离奇陷阱 — 设置线程优先级导致的微信卡顿惨案》这篇文章，有没有觉得原来大家再熟悉不过的线程，也还有鲜为人知的坑？除此之外，微信与线程之间还有很多不得不说的故事，下面跟大家分享一下线程还会导致什么样的内存问题。 [anon:thread stack guard page] 在分析虚拟内存空间耗尽导致的 crash 问题时，我们在 /proc/[pid]/maps 中发现了新增了不少跟以往不一样 case，内存中充满了大量这样的块： 从 map entry 的名字与内存大小和权
最近加群的人太多了，可能是因为这篇 Peace and love，从今天开始我们群正式加入 ORACLE ，因为群里的ORACLE 大佬也很多，所以基本上市面上能见到的常见的数据库产品，群里都有大佬和各种厂商，和工作者，我们准备把 Peace and love 发扬光大，都是数据库，大家一起学。
App开发不可避免的要和图片打交道，由于其占用内存非常大，管理不当很容易导致内存不足，最后OOM，图片的背后其实是Bitmap，它是Android中最能吃内存的对象之一，也是很多OOM的元凶，不过，在不同的Android版本中，Bitmap或多或少都存在差异，尤其是在其内存分配上，了解其中的不用跟原理能更好的指导图片管理。先看Google官方文档的说明：
之前做热修复的时候研究过 Application 的启动原理。项目中也做过一些启动优化。
本文主要介绍kdump服务和crash的使用，并结合一个简单的实例演示如何分析内核奔溃的原因。本文基于linux kernel 4.19, 体系结构为aarch64。 kdump概述 kdump kdump 是一种先进的基于 kexec 的内核崩溃转储机制，用来捕获kernel crash（内核崩溃）的时候产生的crash dump。当内核产生错误时，kdump会将内存导出为vmcore保存到磁盘。 kdump流程 当系统崩溃时，kdump 使用 kexec 启动到第二个内核。第二个内核通常叫做捕获内核，以
分为：较轻的影响是UI的卡顿掉帧； 比较大的影响是ANR（Application Not Responding）：能恢复的ANR；不能恢复的ANR-永久性卡死问题。
前言： qemu发生了crash。这种类型的问题比较少见，这里说一下这个问题的分析过程。 分析： 1，coredump 生成的coredump，一种是配置了/proc/sys/kernel/cor
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
腾讯会议
