lowmemorykiller 的日志查询

最新推荐文章于 2025-06-09 22:24:23 发布
原创 最新推荐文章于 2025-06-09 22:24:23 发布 · 3.1k 阅读 · 5 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#lowmemorykiller #日志关键字查询

本文介绍如何通过查询lowmemorykiller日志来诊断系统卡顿问题。以com.su.download为例，展示了不同日志文件中关于该应用被系统内存管理器终止的相关记录，包括kernel_log、main_log、events_log及sys_log。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

1 lowmemorykiller 的日志查询

系统卡顿优化往往会触发lowmemorykiller，查看应用是否被lowmemorykiller的日志，一般需要查询对应包名对应的pid

例如 com.su.download pid 是16826，目前pid一般可以在event日志查看到

1.1 kernel_log_6__2018_0614_191444
13,845: <7>[  404.507273] -(6)[97:kswapd0][signal][97:kswapd0]send death sig 9 to[16826:redstone.ota.ui:R] 
13,846: <6>[  404.507319]  (6)[97:kswapd0]lowmemorykiller: Killing 'redstone.ota.ui' (16826), adj 904, state(0)
1.2 main_log_1__2018_0614_191444

76,496: 06-14 18:56:32.305074 1005 1023 I zygote64: Successfully killed process cgroup uid 1000 pid 16826 in 0ms

1.3 events_log_3__2018_0614_191444

4,202: 06-14 18:56:32.303401 1005 1404 I am_proc_died: [0,16826,com.su.download,904,11]

1.4 sys_log_4__2018_0614_191444
06-14 18:56:32.293532  1005  6176 I WindowManager: WIN DEATH: Window{e5030bc u0 com.su.download/com.su.download.activity.RsMainActivity}
06-14 18:56:32.303128  1005  1404 I ActivityManager: Process com.su.download (pid 16826) has died: cch+4SVC 
06-14 18:56:32.303719  1005  1404 W ActivityManager: Scheduling restart of crashed service com.su.download/com.globe.android.stats.agent.AgentService in 16262ms
06-14 18:56:32.303882  1005  1404 W ActivityManager: Scheduling restart of crashed service com.su.download/com.android.meteor.agent.library.AgentService in 26262ms
Android 12.0 lowmemorykiller低内存时，禁止某个app被kill掉功能实现
安卓兼职framework和app工程师的博客
07-20 946
在12.0的系统ROM定制化开发中，在对于系统lowmemorykiller低内存的时候，应用保活功能是非常重要的，就是在低内存的情况下 禁止某个app被杀掉，所以就需要从lowmemorykiller机制入手，在杀进程的相关流程中进行分析来实现进程避免被杀掉，接下来 就来实现这个功能
lowmemorykiller 问题排查
u013168615的专栏
02-02 2370
lowmemorykiller 问题排查
lowmemorykiller分析1
qq_42894864的博客
06-05 458
Android在内存管理上于Linux有些小的区别，其中一个就是引入了lowmemorykiller。从lowmemorykiller.c位于drivers/staging/android也可知道，属于Android专有，没有进入Linux kernel的mainline。lmkd，即Low Memory Killer Daemon，基于memory子系统和Kernel lowmemorykiller功能参数，选择一个合适的进程，然后kill进程，以达到释放内存的目的。所以也绕不开Kernel模块lowme
LMKD（Low Memory Killer Daemon）原理初识
最新发布
苏法迪的专栏
06-09 1107
非常明确的一点是min_score是有最小值的，最小值是0，也就是所有分数为负值的进程肯定是不会被lmkd杀掉的，在系统资源极度极度紧张的情况下，分数大于等于0的进程都会被杀掉（前台进程、后台无焦点进程、后台进程）以上就是该杀谁的内容，其实杀的进程都是app进程，后台app进程是先被杀掉的，像system_server进程、系统persistent进程它们都是负值是不会被杀掉的，甚至系统native进程它们的分数基本都是-1000，因此也是不会被杀掉的。频繁的进行进程维度的内存回收，会有性能衰退的风险。
low memory killer
05-07 2381
Low Memory Killer(低内存管理) 　　对于PC来说，内存是至关重要。如果某个程序发生了内存泄漏，那么一般情况下系统就会将其进程Kill掉。Linux中使用一种名称为OOM(Out Of Memory，内存不足)的机制来完成这个任务，该机制会在系统内存不足的情况下，选择一个进程并将其Kill掉。Android则使用了一个新的机制——Low Memory Killer来完成同样的
Lowmemkill问题分析
IT先森
07-09 3202
Lowmemkill问题分析 前言 由于我们POS采用的是1+8的硬件设计结构，所以经常会出现由于内存占用过高而导致一些应用被杀死，由于这些机器在商户手里，且杀死的应用虽然对于android来说认为并不重要，但是对应用调用的关系非常重要。这篇文章就是在这个前提的基础上开展的，主要通过工具和查看日志的方...
android LMK 工作机制
anjen的专栏
09-28 4466
Android分析之LowMemoryKiller Android Kernel 会定时执行一次检查，杀死一些进程，释放掉内存。     那么，如何来判断，那些进程是需要杀死的呢？答案就是我们的标题：Low memory killer机制。
Android13 针对low memory killer内存调优
superjaingchao的专栏
02-20 3792
在旧版本的安卓系统中，当触发lmk（low memory killer）的时候一般认为就是内存不足导致，但是随着安卓版本的增加lmk的判断标准已经不仅仅是内存剩余大小，io，cpu同样会做评判，从而保证设备性能。这里控制是通过监听kernel里的epoll事件，然后做相关判断进行进程的kill，这里代表了内存失速，由于我们3g内存其实也并不是很宽裕，通过killinfo我们可以看到psi最后一项达到了23.650000证明cpu压力很大，证明系统回收内存压力较大，我们通过修改。内存压力检测的默认机制。
lowmemorykiller 杀死进程
拒绝背八股文
10-11 1012
lowmemorykiller: /sys/module/lowmemorykiller/parameters/minfree: 里面是以”,”分割的一组数，每个数字代表一个内存级别 1950,2250,3000,3500,5000,7500 /sys/module/lowmemorykiller/parameters/adj: 对应上面的一组数，每个数组代表一个进程优先级级别 ...
Android low memory killer 机制
tq08g2z的专栏
02-04 2997
Android中，进程的生命周期都是由系统控制的。即使用户在界面上关掉一个应用，切换到了别的应用，那个应用的进程依然是存在于内存之中的。这样设计的目的是为了下次启动应用能更加快速。当然，随着系统运行时间的增长，内存中的进程可能会越来越多，而可用的内存则将会越来越少。Android Kernel会定时执行一次检查，杀死一些进程，释放掉内存。 那么，如何来判断，哪些进程是需要杀死的呢？答案就是：lo
LowMemoryKiller 的使用(安卓lowmemorykiller)
weixin_72426331的博客
10-13 360
oom_score_adj 的方式,获取所有四位id 的oom_score_adj 路径遍历以上路径，输出oom_score_adj 值和路径，每行格式如：-800/proc/1947/oom_score_adj，从整个文件获取列表，每行第一位是oom_score_adj 值，第三位是pid值。sh文件如何执行呢？我们把sh文件命名为adj.sh. 可以简单的通过adb命令来执行，adb shell adj.sh，作为代码实现执行，可以通过创建rc文件，在rc文件中定义，写系统属性的时候，执行sh。
Android-System.exit()和Process.killProcess()
火星男孩的分享空间
07-03 4338
Android上杀掉进程的方式有两种，分别是System.exit(0)和Process.killProcess(Process.myPid())，那么这两种方式有何区别呢？相同点1、APP进程都会被直接杀掉我们通过adb shell ps可以查看当前手机所有运行的进程状态， 在执行完这两种方式之后，APP进程都会消失。2、生命周期都不会被调用onPause()、onStop()和onDesto
Android adj调整时的各类进程状态
yun_hen的博客
02-11 5286
Android adj调整时的各类进程状态1. dump一下进程的信息2. ProcState的枚举值和打印字串的对应关系3. ProcState的各类状态都是在什么时候设置，都代表什么意思 1. dump一下进程的信息 使用adb shell dumpsys activity p可以将Android的各类进程状态信息打印出来，这通常对于分析进程的运行状态和adj有很大帮助 Process LRU list (sorted by oom_adj, 46 total, non-act at 6, non-s
Android 进阶——性能优化之一次偶现的原生Settings 内存泄漏导致的系统重启的定位和解决
最美不过，心中有梦，身旁有你！
12-24 2471
一次偶现的原生Settings 内存泄漏导致的系统重启的定位和解决
Caused by: java.lang.SecurityException: Caller no longer running, last stopped +1m20s809ms because:
lei7143的专栏
04-11 3562
$** *** *** *** *** *** *** *** Fatal *** *** *** *** *** *** *** **$Exception Log Time:[Sat Apr  7 09:22:32 EDT 2018] [212319.658769]Exception Class: Java (JE)Exception Type: system_server_crashCurre...
Android 开机Process xxx (pid xxxx) has died问题分析
2401_84121980的博客
04-08 828
今天关于面试的分享就到这里，还是那句话，有些东西你不仅要懂，而且要能够很好地表达出来，能够让面试官认可你的理解，例如Handler机制，这个是面试必问之题。有些晦涩的点，或许它只活在面试当中，实际工作当中你压根不会用到它，但是你要知道它是什么东西。最后在这里小编分享一份自己收录整理上述技术体系图相关的几十套腾讯、头条、阿里、美团等公司20年的面试题，把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节，由于篇幅有限，这里以图片的形式给大家展示一部分。还有。
Low Memory Killer分析
vichie2008的专栏
10-14 536
Chipset: MSM8X25Q Codebase: Android4.1 Kernel: 3.4.0   概念：          Lowmemory killer是android基于oom killer做了改进。两者区别： Oom killer: 当系统内存不足时，会根据当前进程的内存使用状况以及oom score来Kill掉某个进程。 Low memorykiller: 会周
android如何分析进程被杀问题
热门推荐
xiaoyantan的博客
07-05 3万+
查看进程被杀的3个步骤 确定被杀进程的包名 有人给出直接用 百度搜索app对应的包名 确定进程被杀的精确时间点 有进程被杀时间点及原因包名，则直接用 log中搜索正则表达式（gedit支持正则）am_proc_died: [0,[0-9]*,xxxx,，xxxx代表包名 ，拿到这行log的时间点以及进程pid eg: 08-19 10:06:55.302 1000 1699 12137 I am_proc_died: [0,9307,com.quark.browser,905,11] 如上栗子：
你真的会解决android ANR 问题吗？
android 系统定制开发那些事
11-15 8265
ANR 详解思路，案例。
看到lowmemorykiller后面接着NativeWatchCall
03-19
<think>好的，我现在需要回答用户关于“lowmemorykiller后面接着NativeWatchCall”的问题。首先，我得确认用户提到的这两个术语分别是什么，以及它们之间的关联。 首先，lowmemorykiller。我记得在Android系统中，内存管理是一个重要的部分，特别是当系统内存不足时，需要一种机制来终止不必要的进程以释放内存。LowMemoryKiller（LMK）应该就是负责这个任务的模块。它通过监控系统的内存使用情况，根据进程的优先级（oom_adj值）来决定哪些进程应该被终止。比如，前台应用的优先级高，不会被轻易杀掉，而后台进程可能更容易被终止。 接下来是NativeWatchCall。这个术语我不太熟悉，可能需要进一步确认。可能是指Android系统中的某个本地（Native）层的监控或回调机制。可能和Watchdog（看门狗）相关，用来监控系统服务是否响应，防止系统死锁或服务无响应的情况。当某个服务长时间没有响应时，Watchdog会触发相应的处理机制，比如杀死相关进程或重启系统。 现在，用户提到的是lowmemorykiller后面接着NativeWatchCall，可能是在日志或调试信息中看到的这两个事件接连发生的情况。我需要分析这种情况的可能原因和含义。 可能的情况是，当系统内存不足时，LowMemoryKiller被触发，杀死了某个进程以释放内存。而随后，NativeWatchCall可能检测到某个系统服务因为进程被终止而无法响应，从而触发相关处理。例如，某个关键服务进程被LMK杀死，导致系统服务无法正常工作，NativeWatchCall检测到超时，记录日志或采取恢复措施。 接下来，我需要验证这个思路是否正确。查阅相关资料，LowMemoryKiller确实是Android内存管理的一部分，负责在内存不足时终止进程。而Watchdog在Android系统中确实存在，用于监控系统服务的健康状态。当服务长时间没有响应时，Watchdog会记录错误或重启系统。 那么，当LMK杀死了一个重要的系统服务进程，可能导致该服务无法响应Watchdog的检查，从而触发NativeWatchCall的相关日志或处理。这种情况下，用户可能在日志中看到这两个事件连续出现，表明系统在内存压力下杀死了进程，进而导致服务异常。 不过，也有可能NativeWatchCall是另一个机制，比如与应用层面的监控相关，比如某个Native层的监控调用，用于追踪资源使用情况或其他性能指标。需要进一步确认NativeWatchCall的具体定义和上下文。 如果用户是在分析系统日志时遇到这两个条目，可能需要检查具体的日志内容、时间戳以及相关进程的信息，以确定它们之间的因果关系。例如，LMK杀死进程后，NativeWatchCall可能是在报告该进程终止后的资源释放情况，或者是在尝试恢复服务时触发的操作。 此外，还需要考虑系统版本和定制ROM的影响，不同厂商可能对Android系统进行定制，添加特定的监控或日志机制，导致NativeWatchCall的具体行为有所不同。 总结来说，可能的解释是：当系统内存不足触发LowMemoryKiller终止进程后，Native层的监控机制（如Watchdog）检测到相关服务异常，从而记录NativeWatchCall事件。这反映了系统在内存压力下的自我修复或错误处理机制。用户需要进一步检查日志的上下文和具体进程信息，以确定具体原因和影响。</think>在Android系统中，`lowmemorykiller`和`NativeWatchCall`的关联通常与内存管理及系统监控机制相关。以下是逐步分析： --- ### **1. LowMemoryKiller 的作用** - **功能**：Android系统的`lowmemorykiller`（LMK）负责在内存不足时终止低优先级的进程以释放内存。 - **优先级规则**： - 进程按`oom_adj`值划分优先级（值越高越容易被终止）。 - 前台应用（如用户正在操作的APP）优先级最低（`oom_adj`值小），后台进程优先级高（`oom_adj`值大）。 - **触发条件**：当系统可用内存低于特定阈值时，LMK会按优先级从高到低终止进程。 --- ### **2. NativeWatchCall 的潜在含义** - **可能场景**： 1. **Watchdog 机制**：Android的`Watchdog`（看门狗）监控系统服务的响应情况。若某个服务长时间未响应，会触发重启或记录错误。 2. **Native 层监控**：`NativeWatchCall`可能是厂商定制的本地层监控工具，用于追踪资源使用（如内存、CPU）或服务健康状态。 - **关联现象**：若LMK终止了关键服务进程，可能导致依赖该服务的组件无响应，进而触发`NativeWatchCall`记录异常。 --- ### **3. 两者连续出现的典型原因** 1. **内存压力引发连锁反应**： - **步骤1**：系统内存不足 → LMK杀死某进程释放内存。 - **步骤2**：被终止的进程可能是某系统服务（如`SurfaceFlinger`、`MediaServer`），其异常终止导致依赖它的组件无法工作。 - **步骤3**：`NativeWatchCall`检测到服务无响应，记录日志或尝试恢复。 2. **日志中的表现**： ```log lowmemorykiller: Kill 'com.example.app' (adj 900) NativeWatchCall: Service X timeout, restarting... ``` --- ### **4. 排查与解决方法** - **检查日志上下文**： - 确认被LMK终止的进程名称及其重要性。 - 查看`NativeWatchCall`的具体错误描述（如服务名称、超时时间）。 - **优化内存使用**： - 减少后台进程数量。 - 检查内存泄漏（如通过`Android Profiler`）。 - **调整LMK阈值**（需Root权限）： ```shell # 修改/sys/module/lowmemorykiller/parameters/minfree中的阈值 echo "1536,2048,4096,5120,5632,6144" > /sys/module/lowmemorykiller/parameters/minfree ``` --- ### **5. 厂商定制的可能性** 部分设备厂商会增强监控机制，例如： - 添加更细粒度的内存事件追踪。 - 自定义Watchdog策略（如延长超时时间或增加恢复逻辑）。 若问题频繁出现，建议联系设备厂商或查看官方文档以获取针对性解决方案。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

法迪

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值