请求解析Kernel panic(obj_cgroup_uncharge)回溯及相关内存问题

系统信息 #

uname -a
Linux ubuntu-PC 5.19.0-46-generic #47~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Wed Jun 21 
15:35:31 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

崩溃转储信息 #

KERNEL: /usr/lib/debug/boot/vmlinux-5.19.0-46-generic
DUMPFILE: /var/crash/202307191343/dump.202307191343  [PARTIAL DUMP]
CPUS: 20
DATE: Wed Jul 19 13:42:41 EET 2023
UPTIME: 5 days, 21:13:29
LOAD AVERAGE: 1.14, 1.64, 1.66
TASKS: 1910
NODENAME: ubuntu-PC
RELEASE: 5.19.0-46-generic
VERSION: #47~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Wed Jun 21 15:35:31 UTC 2
MACHINE: x86_64  (3600 Mhz)
MEMORY: 31.3 GB
PANIC: ""
PID: 65
COMMAND: "ksoftirqd/8"
TASK: ffff98814133b380  [THREAD_INFO: ffff98814133b380]
CPU: 8
STATE: TASK_RUNNING (PANIC)

栈回溯信息 #

crash> bt
PID: 65       TASK: ffff98814133b380  CPU: 8    COMMAND: "ksoftirqd/8"
#0 [ffffa50ac038b9b0] machine_kexec at ffffffff81495c2b
#1 [ffffa50ac038ba10] __crash_kexec at ffffffff815bb822
#2 [ffffa50ac038bae0] crash_kexec at ffffffff815bd102
#3 [ffffa50ac038baf0] oops_end at ffffffff81446830
#4 [ffffa50ac038bb18] die_addr at ffffffff81446b41
#5 [ffffa50ac038bb48] exc_general_protection at ffffffff8232217a
#6 [ffffa50ac038bbf0] asm_exc_general_protection at ffffffff82400ab7
[exception RIP: refill_obj_stock+83]
RIP: ffffffff817d1b23  RSP: ffffa50ac038bca8  RFLAGS: 00010046
RAX: 0000000000000000  RBX: 00000000000000c8  RCX: 0000000000000000
RDX: 0000000000000000  RSI: 0000000000000000  RDI: 0000000000000000
RBP: ffffa50ac038bcd0   R8: 0000000000000000   R9: 0000000000000000
R10: 0000000000000000  R11: 0000000000000007  R12: ffff98889fa2dd40
R13: 0000000000000202  R14: ffff9881d422c380  R15: ffdf9881d422c380
ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
#7 [ffffa50ac038bcd8] obj_cgroup_uncharge at ffffffff817d5a13
#8 [ffffa50ac038bce8] memcg_slab_free_hook at ffffffff817a6c2c
#9 [ffffa50ac038bd48] kmem_cache_free at ffffffff817ae796
#10 [ffffa50ac038bd90] __d_free_external at ffffffff81812f50
#11 [ffffa50ac038bda8] rcu_do_batch at ffffffff8157c308
#12 [ffffa50ac038be20] rcu_core at ffffffff8157e4ca
#13 [ffffa50ac038be68] rcu_core_si at ffffffff8157e94e
#14 [ffffa50ac038be78] __softirqentry_text_start at ffffffff826000d5
#15 [ffffa50ac038bed8] run_ksoftirqd at ffffffff814d43a7
#16 [ffffa50ac038bee8] smpboot_thread_fn at ffffffff81502d60
#17 [ffffa50ac038bf10] kthread at ffffffff814fa08b
#18 [ffffa50ac038bf50] ret_from_fork at ffffffff814038cf

问题分析 #

1. 触发路径：panic起源于refill_obj_stock+83的通用保护错误，属于内存控制组（memcg）的slab内存回收流程。完整调用链为：rcu_do_batch（RCU批量回收）→ __d_free_external（释放dentry对象）→ kmem_cache_free（slab缓存释放）→ memcg_slab_free_hook（memcg钩子）→ obj_cgroup_uncharge（内存组对象减计）→ refill_obj_stock（填充对象库存）。
2. 异常根源：寄存器RAX/RDI/RDX等全为0，说明代码尝试访问空指针或无效内存区域。结合OOM killer终止Python进程的背景，推测是OOM触发后，内存回收过程中memcg的对象库存管理出现数据损坏或逻辑错误。
3. PostgreSQL关联问题：数据库出现的invalid page in block 4557 of relation异常，是内核panic导致的IO中断、内存数据损坏，或是OOM时进程强制终止引发的数据库文件一致性破坏。

排查建议 #

• 升级内核：Ubuntu 5.19.0-46属于旧版本，memcg模块在后续内核更新中有多个bug修复，建议升级至Ubuntu 22.04的最新稳定LTS内核（如5.15或6.2系列）。
• 检查memcg配置：确认是否存在自定义内存控制组规则，避免极端内存限制引发回收异常。
• 监控内存泄漏：在OOM发生前，监控系统内存、swap使用情况，排查Python等进程是否存在内存泄漏问题。
• 修复PostgreSQL：先备份数据库，使用pg_checksums检查数据完整性，通过pg_dump导出并重建数据库，修复损坏的文件。

内容的提问来源于stack exchange，提问作者polymetr