Linux内核OOM保护机制(查看系统日志)

Linux OOM Killer 深度解析:3种 overcommit_memory 策略与进程保护实战 本文深入解析Linux OOM Killer机制,详细讲解overcommit_memory的三种策略模式(启发式、无条件允许、严格限制),并提供关键进程保护实战技巧。通过调整进程OOM优先级、Cgroup级别内存保护及数据库服务专用配置,有效防止Out of memory导致的进程自动退出问题,提升系统稳定性。 阅读详情

kill:

参考文献:

转载:https://www.cnblogs.com/felixzh/p/9238274.html
转载 : https://blog.youkuaiyun.com/zgrjkflmkyc/article/details/77645570

人工维护或进程在Linux中使用内存最大 时,保护机制自动kill
我们应该估算系统内存,合理分配
解决方法:赶快升级,把不重要的服务停了,把内存加大一点。

看系统日志

[root@hadoop001 ~]# cd /var/log
[root@hadoop001 log]# ll
total 708952
-rw-------. 1 root  root          0 Jul  6  2018 anaconda.ifcfg.log
-rw-------. 1 root  root          0 Jul  6  2018 anaconda.log
-rw-------. 1 root  root          0 Jul  6  2018 anaconda.program.log
-rw-------. 1 root  root          0 Jul  6  2018 anaconda.storage.log
-rw-------. 1 root  root          0 Jul  6  2018 anaconda.syslog
-rw-------. 1 root  root          0 Jul  6  2018 anaconda.xlog
-rw-------. 1 root  root          0 Jul  6  2018 anaconda.yum.log
drwxr-x---. 2 root  root       4096 Jul 11 07:32 audit
-rw-r--r--  1 root  root       1118 Jul  9 03:06 boot.log
-rw-------  1 root  utmp   44162304 Jul 12 02:26 btmp
-rw-------. 1 root  utmp   61329792 Apr  1 03:29 btmp-20190401
-rw-------  1 root  utmp  170359680 May  1 03:50 btmp-20190501
-rw-------  1 root  utmp  184469760 Jun  1 03:42 btmp-20190601
-rw-------  1 root  utmp  141014016 Jul  1 03:07 btmp-20190701
drwxr-xr-x  2 root  root       4096 Jul  1 03:08 ConsoleKit
-rw-------  1 root  root     197953 Jul 12 02:30 cron
-rw-------  1 root  root     129550 Jun 16 03:35 cron-20190616
-rw-------  1 root  root     121631 Jun 23 03:32 cron-20190623
-rw-------  1 root  root     199284 Jun 30 03:19 cron-20190630
-rw-------  1 root  root     286157 Jul  7 03:50 cron-20190707
-rw-r--r--  1 root  root      21999 Jul  9 03:06 dmesg
-rw-r--r--  1 root  root      21999 Jun 30 01:22 dmesg.old
-rw-r--r--. 1 root  root          0 Jul  6  2018 dracut.log
drwx------  2 root  root       4096 Jul 10 03:50 httpd
-rw-r--r--. 1 root  root     152716 Jul 12 02:29 lastlog
-rw-------  1 root  root          0 Jul  7 03:50 maillog
-rw-------  1 root  root          0 Jun  9 04:22 maillog-20190616
-rw-------  1 root  root          0 Jun 16 03:35 maillog-20190623
-rw-------  1 root  root        117 Jun 23 14:42 maillog-20190630
-rw-------  1 root  root          0 Jun 30 03:19 maillog-20190707
-rw-------  1 root  root      32791 Jul 11 23:26 messages
-rw-------  1 root  root      34005 Jun 16 03:35 messages-20190616
-rw-------  1 root  root      71874 Jun 23 03:32 messages-20190623
-rw-------  1 root  root      38307 Jun 30 03:19 messages-20190630
-rw-------  1 root  root       2887 Jul  7 03:50 messages-20190707
-rw-r-----  1 mysql mysql         0 Jun 30 03:11 mysqld.log
-rw-r-----  1 mysql mysql       865 Jun 30 01:02 mysqld.log.rpmsave
drwxr-xr-x. 2 ntp   ntp        4096 Jan 26  2018 ntpstats
drwx------  2 root  root       4096 Mar 16  2015 ppp
drwxr-xr-x. 2 root  root       4096 Jul 12 00:00 sa
-rw-------  1 root  root    8397041 Jul 12 02:29 secure
-rw-------  1 root  root   39115735 Jun 16 03:35 secure-20190616
-rw-------  1 root  root   18686664 Jun 23 03:31 secure-20190623
-rw-------  1 root  root   25685678 Jun 30 03:17 secure-20190630
-rw-------  1 root  root   30867737 Jul  7 03:49 secure-20190707
-rw-------  1 root  root          0 Jul  7 03:50 spooler
-rw-------  1 root  root          0 Jun  9 04:22 spooler-20190616
-rw-------  1 root  root          0 Jun 16 03:35 spooler-20190623
-rw-------  1 root  root          0 Jun 23 03:32 spooler-20190630
-rw-------  1 root  root          0 Jun 30 03:19 spooler-20190707
-rw-------. 1 root  root          0 Jul  6  2018 tallylog
-rw-r--r--  1 root  root          0 Jul  6  2018 wpa_supplicant.log
-rw-rw-r--. 1 root  utmp     221184 Jul 12 02:29 wtmp
-rw-------. 1 root  root       1915 Jun 30 03:11 yum.log

[root@hadoop001 log]# tail -f messages   在这里看系统日志,会记录
Jul  9 03:06:55 hadoop001 ntpd[1147]: Listen normally on 3 eth0 10.9.6.136 UDP 123
Jul  9 03:06:55 hadoop001 ntpd[1147]: Listening on routing socket on fd #20 for interface updates
Jul  9 03:06:55 hadoop001 ntpd[1147]: 0.0.0.0 c016 06 restart
Jul  9 03:06:55 hadoop001 ntpd[1147]: 0.0.0.0 c012 02 freq_set ntpd 15.848 PPM
Jul  9 03:07:02 hadoop001 ntpd[1147]: 0.0.0.0 c615 05 clock_sync
Jul  9 21:31:06 hadoop001 auditd[963]: Audit daemon rotating log files
Jul 10 10:15:16 hadoop001 auditd[963]: Audit daemon rotating log files
Jul 11 02:41:36 hadoop001 auditd[963]: Audit daemon rotating log files
Jul 11 07:32:33 hadoop001 auditd[963]: Audit daemon rotating log files
Jul 11 23:26:55 hadoop001 kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
^C
[root@hadoop001 log]# 
从宕机到洞察:掌握Linux内核调试与Crash工具实战分析 在Linux系统运维与开发中,系统稳定性是核心诉求。当发生内核崩溃(Kernel Crash)时,常规的日志和用户态coredump往往失效,导致根因定位困难。其原理在于内核崩溃意味着系统控制权丢失,无法记录现场。为此,Linux提供了内核崩溃转储机制,通过Kdump在系统崩溃瞬间捕获完整物理内存的快照(vmcore),再使用专门的Crash工具进行离线分析,这构成了事后调试(Post-mortem Analysis)的技术基础。这项技术的核心价值在于能将黑盒般的系统宕机转化为可追溯、可分析的现场,实现从故 阅读详情

相关推荐

ESP32S3开发板玩转多语言AI对话:小智语音机器人粤语/日语/韩语实测

本文基于正点原子ESP32S3开发板,实测了“小智AI”语音机器人的多语言对话能力。项目巧妙整合云端AI与嵌入式硬件,实现了对粤语、日语、韩语等语言的实时识别与合成,为开发者和爱好者提供了一个低成本、可玩性高的跨语言人机交互开发平台。

h9j8k7l6m5n的博客 537

linux 突然变得很慢

这两天服务器出现了一个很神奇的问题,那就是周期性的变得

借人之智,完善自己 1万+

webpack性能优化-optimization.splitChunks.chunks中的“all“、“async“和“initial“

最初,chunks(以及内部导入的模块)是通过内部 webpack 图谱中的父子关系关联的。CommonsChunkPlugin 曾被用来避免他们之间的重复依赖,但是不可能再做进一步的优化。 ——摘自 webpack 从 webpack v4 开始,移除了 CommonsChunkPlugin,取而代之的是 optimization.splitChunks。 而关于 optimization.splitChunks 中的chunks,webpack 官方文档却没有很好的进行举例解释,只说明了 async.

程序员秋风的博客 3135

【Linux】Daemon

1

Lindsey's Blog 1730

jetson agx orin开箱及接口介绍

jetson agx orin开箱及接口介绍

qq_58728069的博客 1万+

携程酒店数据爬取进阶:动态接口破解与反反爬策略实战

本文详细解析了携程酒店数据爬取的进阶技巧,包括动态接口参数破解、反爬虫策略对抗及企业级采集方案实现。重点介绍了eleven参数的生成逻辑、动态Cookie维护方法,以及如何应对携程的请求指纹检测和行为模式识别。通过实战案例,帮助开发者高效获取酒店价格数据,同时遵守行业规范。

eee77的博客 1078

linux服务器宕机原因排查,服务器宕机原因探讨 - 系统管理 - LinuxTone | 运维专家网论坛 - 最棒的Linux运维与开源架构技术交流社区! - Powered by Discuz...

以下日志反馈为Hardware Error后宕机,当时机房空调存在故障,是否可定性为温度过高导致该服务器CPU异常宕机。Sep 27 03:37:01 server5 rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="2617" x-info="http://www.rsyslog.com"] rsyslogd was ...

weixin_39933895的博客 2372

通义千问语言模型Qwen2.5架构详解

此外,将基于API的模型 Qwen-Plus 与领先的专有和开源模型进行了对比,包括 GPT4-o、Claude-3.5-Sonnet、Llama-3.1-405B和DeepSeek-V2.5。Qwen2.5-Math-72B-Instruct的整体性能超越了Qwen2-Math-72B-Instruct和GPT4-o,甚至是非常小的专业模型如 Qwen2.5-Math-1.5B-Instruct也能在与大型语言模型的竞争中取得高度竞争力的表现。近来也出现了明显的转向小型语言模型(SLMs)的趋势。

搏博的专栏 1万+

linux rac节点主机不定时重启,oracle 10 rac 节占不定时自动重启

操作系统日志:[root@rac2 ~]# vi /var/log/messagesJan 13 04:02:06 rac2 syslogd 1.4.1: restart.Jan 13 05:52:03 rac2 kernel: racgmain[8032]: segfault at 00000000000000e1 rip 00000036b7408293 rsp 0000000042f3007...

weixin_39728572的博客 246

Python爬取天天基金网历史数据

前言 最近开始学习基金????,感觉需要收集一些数据统计分析才靠谱????毕竟给A股交学费的感觉可不好受???? 网上有很多公开的数据,我这里选择的是天天基金网进行爬取 页面分析 接口我分析过了,有些验证不太好获取数据,所以直接从html提取 在天天基金网中随便选择一款基金,然后点击进入历史数据页面 容易定位出日增长率的css选择器 还有翻页按钮 程序编写 使用selenium打开chrome浏览器进行爬取,全代码如下 from selenium import webdriver from sel

JiajunBernoulli的博客 2949

Linux系统故障排查思路实践教程(上)

本文主要介绍了Linux系统日志分析与常见故障排查的实用方法。首先从系统日志的分类及其涉及的日志文件进行说明;其次详细讲解了忘记用户密码的解决方案;接着对系统无法启动问题,提供了异常断电后修复文件系统、/etc/fstab文件丢失恢复等常见故障的处理方案。最后介绍了文件系统只读错误的排查思路和修复方法,包括磁盘空间检查、文件系统修复等实用技巧。全文提供了大量具体命令和操作流程,为Linux系统维护人员提供了实用的故障处理指南。

提供C#相关开发 、云计算、运维测试、网络安全相关技术分享与服务,有意向可联系。 328

Linux内存占满导致进程被终止

Linux内存占满导致进程被终止

m0_55901066的博客 3333

电商数据采集实战——多平台价格监控、比价分析与智能告警系统

在电商竞争日益激烈的今天,价格监控与比价分析已成为品牌商、渠道商和消费者的核心需求。对于品牌商而言,需要监控各渠道售价是否低于指导价(破价监控);对于消费者而言,希望在最佳时机以最低价购入心仪商品;对于数据分析师而言,价格波动数据是洞察市场趋势的金矿。然而,电商数据采集面临三大核心挑战:本文将基于 Python + Scrapy + Playwright + Redis + ClickHouse 技术栈,构建一套完整的电商价格监控与比价系统。架构分层说明:电商平台的反爬手段层出不穷,采集系统必须具备多层次的

从事移动开发八年,csdn博客专家,阿里云特邀专家,华为云云享专家,高级网络信息安全工程师,大数据工程师(高级),python技术开发(高级),HarmonyOS 应用开发者高级认证,现在某学校任教。 136

Linux OOM Killer详解

在Linux操作系统中,内存管理至关重要。当系统内存耗尽时,如果不采取措施,会导致系统崩溃。为了解决这个问题,Linux内核引入了一种保护机制——OOM Killer(Out-Of-Memory Killer)。当系统内存耗尽时,OOM Killer会选择并终止一些进程,以释放内存,确保系统继续运行。本博客将详细介绍OOM Killer的技术原理、工作机制,并通过实际场景举例说明其应用。Linux OOM Killer是一种重要的内存保护机制,在系统内存耗尽时通过终止进程来释放内存,确保系统继续运行。

抛物线的博客 2403

老版QQ原生表情gif动态

这是老版的QQ表情,不过全是动态的的,Windows照片查看器是不会动的,可以右击用浏览器打开查看,再说一遍是老版的,只是分享给宁愿用老版也要动态的人。

TMS_WebGMaps_1.9.8.0_Full_Source

TMS_WebGMaps_1.9.8.0_Full_Source 全源码 delphi cbuilder

Linux内存管理——OOM Killer

OOMKiller是Linux内核的内存保护机制,当系统内存耗尽时,它会终止高内存消耗进程以释放内存。其选择策略基于进程的OOM得分,通过调整可控制进程被杀优先级。理解OOMKiller有助于优化内存管理,保护关键进程,提高系统稳定性。

m0_72426445的博客 1451

LinePhone3.2.7(android端最新版本) sip客户端

SIP客户端For android:LinePhone3.2.7(最新版本),官网地址:http://www.linphone.org/

当你的云实例频繁重启:排查系统日志、内核崩溃与云厂商监控工具的使用方法

当操作系统核心组件遇到无法恢复的错误时,会触发内核崩溃(Kernel Panic),此时系统可能会自动重启。驱动冲突;内存访问越界;文件系统损坏;内核模块加载失败。系统日志是排查问题的第一步,定期检查有助于提前发现问题。内核崩溃日志提供了深入分析系统崩溃原因的机会。云厂商提供的监控工具可以帮助实时监测系统健康状况,并及时发出警告。多种因素可能导致实例重启,需结合日志、监控、环境综合判断。

moppol的博客 1154

SIMATIC S7-1200, S7-1500 PID 控制[手册]

SIMATIC S7-1200, S7-1500 PID 控制[手册]

排查java进程被linux杀掉

通俗的话来说,其实因为java进程占用内存太高,被linux进程评为最高分,linux内核为了自保,而把评分高的进程给杀死,如果这个java进程设置不可杀死,可能会造成linux死机,而实际查到linux上当时还有其余的一些服务在运行,其余的服务在申请内存的时候,发现内存不够,但是linux为自保就把评分高的进程给杀掉了。原因:当时还有一个docker启动的一些服务,停掉后会自动拉起,而造成原因是这些服务申请内存的时候造成了linux杀掉了评分高的服务。

刘超军的博客 2914

Docker OOM Killer详解:从原理到实践,彻底掌控容器内存行为

掌握Docker容器内存管理难题,深入解析Docker容器内存限制与OOM处理机制。涵盖资源配额设置、OOM Killer触发条件及避坑策略,适用于高并发与微服务场景。有效预防容器被强制终止,提升系统稳定性,值得收藏。

simcode的专栏 895

Linux系统OOM killer机制详解

介绍: Linux下面有个特性叫OOM killer(Out Of Memory killer),会在系统内存耗尽的情况下出现,选择性的干掉一些进程以求释放一些内存。广大从事Linux方面的IT农民工兄弟或多或少都有遇到过吧。 现象: 主机SSH突然无法连接,主机重启要过很久,重启后主机正常,登录查看日志信息,会有大量的 " Out of Memory: Killed proce

渡江客涂鸦板 4525

ANIMATEDIFF PRO环境配置:解决Linux内核OOM Killer误杀渲染进程问题

本文介绍了如何在星图GPU平台上自动化部署ANIMATEDIFF PRO电影级渲染工作站镜像,解决Linux OOM Killer误杀渲染进程的问题。通过平台提供的自动化部署能力,用户可快速搭建稳定的AI视频生成环境,高效产出电影级视觉内容,避免渲染中断,提升创作效率。

weixin_30789053的博客 341

与Linux OOM-killer的第一次亲密接触

受害人口述悲惨的遭遇——1、最近一段时间(更换了预发机器后)我负责的一个应用的预发环境(线上稳定得像个婴儿~)特别不稳定,最先是应用频频的过几天就发现提供的接口不工作了,但容器Jetty还在跑得欢,于是jstack/jmap看,发现没有一个线程在跑我的war包中的程序,但是容器里个中间件的sar还跑得很欢(-_-|||),dump出来的对象也没有一点蛛丝马迹,所有日志到04:...

weixin_33881753的博客 163

4.Linux性能诊断 --- Linux工作流程&内存管理

Linux工作流程 : 1.POST加电自检 2.加载BIOS, BIOS 加载 CMOS , 取得硬件信息和自我检测,取得第一个可启动设备 3.读取第一个启动设备内 MBR(MasterBoot Record,主引导分区) 的 Boot Loader 4.Boot Loader(主引导程序,识别操作系统的文件格式,决定装载哪个内核) 5.加载内核,内核检测硬件和加载驱动程序 6....

enlyhua的专栏 282

【WSL内存优化实战】从OOM到稳定运行:深度解析WSL2内存管理与性能调优

本文深度解析WSL2内存管理与性能调优,针对运行AI训练或大数据处理时常见的“Killed”问题提供实战解决方案。通过理解WSL2内存动态管理机制,指导用户利用.wslconfig配置文件精准调整内存上限、交换分区等核心参数,并结合系统监控与代码级优化技巧,从根本上解决内存溢出(OOM)问题,实现从频繁崩溃到稳定运行的转变。

js777的博客 356

如何抓获JVM crash的幕后黑手?(三)

通过前两篇如何抓获JVM crash的幕后黑手?(一) 如何抓获JVM crash的幕后黑手?(二)的分析,如果还不能查到原因,那很有可能不是应用自身的问题,而是系统将应用强行kill了,如何判断是系统强行kill的呢?       我们需要先了解下linux的一个oom-killer机制。linux oom-killer是一种自我保护机制,当系统分配不出内存时会触发这个机制,由操作系统在己

海阔天空 1719

Linux java进程无故被kill

Linux java进程无故被kill 这两天,演示环境的java应用无端端就被停止了。在这里记录一下原因和排查过程: 发现应用挂掉以后,第一时间登陆centos,发现进程没有了。于是重新启动应用。 但是启动不起来,去看业务日志,没有找到任何堆栈信息。 后来,在同事的指导下,找到了jdk的错误日志(如果没有指定,通常生产在应用的bin目录...

weixin_30666753的博客 2913
上一篇: -sql语法-2-拉垮MySQL服务怎么解决
下一篇: -大数据入门-2-Hadoop-部署yarn,跑案例
吾..二..二
博客等级 码龄8年 4粉丝 36原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值