http://fxio.site/tags/db/Recent content in Db on FXIO 技术博客Hugo -- 0.157.0zh-cnFri, 12 Dec 2025 21:21:11 +0800http://fxio.site/posts/java/doris-zuul-oom/Fri, 12 Dec 2025 21:21:11 +0800http://fxio.site/posts/java/doris-zuul-oom/<h2 id="引言">引言</h2> <p>在开发者的潜意识里，<code>LIMIT</code> 关键字就是 SQL 查询的安全带。 我们通常认为，只要加了 <code>LIMIT</code>，无论表多大，数据库都只会吐出少量数据，内存就是安全的。</p> <p>然而，最近的一次线上 OOM（内存溢出）事故狠狠地打破了这个认知。 一个看似人畜无害的 <code>UNION ALL</code> + <code>LIMIT</code> 组合，竟然避开了doris 的优化器的下推机制，引发了生产环境的连锁崩溃。</p> <p>本文记录了这次在受限环境下，如何抽丝剥茧定位 Bug 的过程。</p> <h2 id="一高峰期的幽灵崩溃">一、高峰期的“幽灵”崩溃</h2> <p><strong>环境背景：</strong></p> <ul> <li><strong>部署方式</strong> Kubernetes</li> <li><strong>网关：</strong> Springboot + zuul</li> <li><strong>服务：</strong> Spring Boot + MyBatis</li> <li><strong>db：</strong> Apache Doris</li> <li><strong>报错服务：</strong> 网关</li> <li><strong>java版本：</strong> jdk8, g1</li> <li><strong>权限：</strong> 无root权限,只能查看基本日志</li> </ul> <p><strong>网关pod报错关键日志</strong></p> <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-java" data-lang="java"><span class="line"><span class="cl"><span class="n">netflix</span><span class="p">.</span><span class="na">zuul</span><span class="p">.</span><span class="na">exception</span><span class="p">.</span><span class="na">ZuulException</span><span class="p">:</span><span class="w"> </span><span class="n">Filter</span><span class="w"> </span><span class="n">threw</span><span class="w"> </span><span class="n">Exception</span><span class="w"> </span></span></span><span class="line"><span class="cl"><span class="n">postModifyResponseBodyFilter</span><span class="p">.</span><span class="na">run</span><span class="w"> </span></span></span><span class="line"><span class="cl"><span class="p">...</span><span class="w"> </span></span></span><span class="line"><span class="cl"><span class="n">Caused</span><span class="w"> </span><span class="n">by</span><span class="p">:</span><span class="w"> </span><span class="n">java</span><span class="p">.</span><span class="na">lang</span><span class="p">.</span><span class="na">OutOfMemoryError</span><span class="p">:</span><span class="w"> </span><span class="n">Java</span><span class="w"> </span><span class="n">heap</span><span class="w"> </span><span class="n">space</span><span class="w"> </span></span></span></code></pre></div><p>报错日志关键字: oom</p> <h2 id="二-真相误判gc-的烟雾弹">二、 真相误判：GC 的烟雾弹</h2> <p>面对 OOM，作为 Java 开发者的第一直觉往往是：“是不是流量太大，垃圾回收（GC）跟不上了？” 查看存活期间的 JVM 监控，发现 Old Gen（老年代）增长迅速。当时的判断是：CMS 回收器产生内存碎片，导致大对象分配失败。</p>