
  <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
      <title>Chaos and Order</title>
      <link>https://www.youngju.dev/blog</link>
      <description>천천히 올바르게. AI Researcher &amp; DevOps Engineer Youngju&#39;s blog. GPU/CUDA, LLM, MLOps, Kubernetes AI workloads, and data engineering — plus mindset essays on confidence, routines, health, and sport psychology.</description>
      <language>ko</language>
      <managingEditor>fjvbn2003@gmail.com (Youngju Kim)</managingEditor>
      <webMaster>fjvbn2003@gmail.com (Youngju Kim)</webMaster>
      <lastBuildDate>Sun, 26 Jul 2026 00:00:00 GMT</lastBuildDate>
      <atom:link href="https://www.youngju.dev/tags/oom/feed.xml" rel="self" type="application/rss+xml"/>
      
  <item>
    <guid>https://www.youngju.dev/blog/linux/2026-07-26-linux-oom-killer-debugging</guid>
    <title>OOM Killer가 프로세스를 죽였을 때 — dmesg 로그 해독부터 cgroup OOM 구분까지</title>
    <link>https://www.youngju.dev/blog/linux/2026-07-26-linux-oom-killer-debugging</link>
    <description>프로세스가 아무 로그도 남기지 않고 사라졌고 종료 코드는 137입니다. 커널 OOM Killer가 남긴 dmesg 리포트를 한 줄씩 읽는 법, badness 점수가 계산되는 방식과 가장 큰 프로세스가 아닌 다른 프로세스가 죽는 이유, 시스템 전역 OOM과 cgroup v2 memory.max에 의한 컨테이너 OOM을 로그만 보고 구분하는 법을 정리합니다. overcommit_memory 0/1/2가 실제로 무엇을 바꾸는지, 스왑이 있으면 OOM이 나지 않는다는 오해가 왜 틀렸는지, earlyoom과 systemd-oomd로 커널보다 먼저 개입하는 방법까지 다룹니다.</description>
    <pubDate>Sun, 26 Jul 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>linux</category><category>memory</category><category>oom</category><category>cgroups</category><category>kubernetes</category>
  </item>

    </channel>
  </rss>
