主要观点：ClickHouse Cloud 在 GCP 上出现神秘 CPU 峰值，经数月调试发现 Linux 内核内存管理中的深层问题，工程师 Sergei Trifonov 历经 eBPF 追踪、perf 分析等找到隐藏的活锁并修复，之后又出现新的内核 bug。
关键信息：

• 问题表现为随机 ClickHouse 实例 CPU 占满、无响应，监控系统检测到性能下降，重启 pod 是唯一解决办法，但不知原因和再次发作时间。
• 影响环境为 GCP，通过工具收集堆栈跟踪，发现活跃线程数异常高，许多线程等待进入临界区，栈跟踪指向意外位置。
• 调查中考虑过优化操作、mincore系统调用等，后来发现 ClickHouse 内部的查询分析器使用mincore系统调用导致内存分配慢，影响 GCP 实例性能。
• 使用bpftrace等工具测量mincore系统调用时长等，发现其不是主要因素；perf显示 CPU 消耗在内核函数shrink_lruvec，但之前的gdb栈跟踪有误。
• 经过多次尝试和分析，包括编译运行手册、使用多种诊断方法等，最终确定问题与内存管理和mmap_lock锁有关，通过实验和bpftrace脚本深入了解内核活动，发现不同环境下的差异和解决办法。
  重要细节：
• 介绍了 ClickHouse Cloud 的简单工具基于gdb收集堆栈跟踪，用于检测死锁等情况。
• 详细描述了mincore系统调用的相关情况，及其在 ClickHouse 中的作用和导致的问题。
• 展示了perf分析的结果，如各内核函数的 CPU 占用率等。
• 阐述了vmscan子系统在内存回收中的作用，以及页面在 LRU 列表中的管理方式。
• 介绍了通过bpftrace脚本收集内核活动相关事件和指标的过程及结果。
• 提到了 Multi-Gen LRU（MGLRU）在内存管理中的作用和启用方法，以及其对解决问题的帮助。