linux-oom-analyzer

Name: linux-oom-analyzer
Availability: InStock
Author: openEuler

Correlate kernel logs, process memory snapshots, and cgroup metrics to diagnose Linux OOM events.

3|2|Updated Apr 24, 2026

Search Tags:#debugging #memory #diagnosis #linux #kernel #oom

Ready to run

npx skills add https://github.com/openeuler-mirror/witty-diagnosis-agent --skill linux-oom-analyzer-openeuler-mirror

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: linux-oom-analyzer
Source: https://github.com/openeuler-mirror/witty-diagnosis-agent/tree/main/skills/linux-oom-analyzer
Command: npx skills add https://github.com/openeuler-mirror/witty-diagnosis-agent --skill linux-oom-analyzer-openeuler-mirror

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires ansible, and includes scripts (resource) and references (resource) components.

What problem does it solve?

This Skill resolves complex Linux memory exhaustion issues by providing a structured, automated diagnostic path for system-level, process-level, cgroup, and kernel-space OOM events.

Core Features & Use Cases

Automated Scenario Routing: Instantly identifies whether an OOM event is caused by system-wide pressure, specific process leaks, container limits, or kernel-space slab/shmem anomalies.
Evidence-Based Reporting: Generates standardized diagnostic reports that link memory growth trends, OOM killer events, and kernel-level metrics to a definitive root cause.
Use Case: When a production server experiences a sudden service crash with exit code 137, use this Skill to automatically collect memory snapshots, analyze the OOM killer logs, and determine if the cause is a memory leak in the application or a misconfigured cgroup limit.

Quick Start

Use the linux-oom-analyzer skill to diagnose the memory crash that occurred on the production server at 14:30 today.

Frequently Asked Questions about linux-oom-analyzer

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I diagnose a Linux OOM killer event and find the root cause of memory exhaustion?▼

To diagnose a Linux OOM killer event, analyze kernel logs, process memory snapshots, and cgroup metrics to identify memory pressure indicators. This automated diagnostic path correlates exit code 137 crashes with system-wide pressure, process leaks, or container limits to determine a definitive root cause.

Why does my Linux container crash with exit code 137 and how can I analyze cgroup memory limits?▼

A container crash with exit code 137 indicates the OOM killer triggered due to memory exhaustion. Analyze cgroup metrics and memory snapshots to determine if the cause is a misconfigured cgroup limit or an application memory leak that breached container boundaries.

Can I use Ansible to automate system diagnostic scripts for kernel-space slab or shmem anomalies?▼

Yes, you can use Ansible to automate the execution of system diagnostic scripts required to extract and interpret memory pressure indicators. This setup analyzes kernel-space slab or shmem anomalies and routes them to the correct diagnostic workflow.

What is the best way to troubleshoot a process-specific memory leak causing system-wide OOM pressure?▼

The best way to troubleshoot a process-specific memory leak is to correlate OOM killer logs with process memory growth trends. Automated scenario routing isolates whether system-wide pressure originates from specific process leaks, container limits, or kernel-space anomalies.

Does this OOM diagnosis approach require access to specific system diagnostic scripts?▼

Yes, OOM diagnosis requires access to system diagnostic scripts to extract and interpret memory pressure indicators and OOM killer event data. These scripts gather the kernel logs and cgroup metrics needed to generate standardized, evidence-based diagnostic reports.

When should I not use automated memory exhaustion diagnosis for kernel-space anomalies?▼

You should not use automated memory exhaustion diagnosis if you cannot provide the required system diagnostic scripts or Ansible access. Without these dependencies, the tool cannot extract the kernel logs, cgroup metrics, or memory snapshots needed to interpret OOM killer events.