wordpress站点标题滁州市公共资源交易中心

wordpress站点标题,滁州市公共资源交易中心,镇江市精神文明建设网站,职业学院网站建设在高性能计算领域#xff0c;我们习惯于在代码、算法或基础设施中寻找瓶颈。但我遇到过的最棘手的问题却不在这些方面。那是Java虚拟机#xff08;JVM#xff09;的垃圾回收器与服务器磁盘之间一种无形的交互#xff0c;导致一个每秒处理数百万请求的服务出现了15秒以上的全…在高性能计算领域我们习惯于在代码、算法或基础设施中寻找瓶颈。但我遇到过的最棘手的问题却不在这些方面。那是Java虚拟机JVM的垃圾回收器与服务器磁盘之间一种无形的交互导致一个每秒处理数百万请求的服务出现了15秒以上的全局暂停STW。503 突增我当时正在处理一个大规模的Java服务该服务每秒要处理数百万用户请求。这个系统是为极高的吞吐量而设计的但我们却深受负载均衡器间歇性超时峰值的困扰这导致向用户返回了503响应。我们发现在负载情况下一部分Web服务器会停滞并停止接受新连接数秒导致请求堆积并失败。唯一的线索是这种行为与大量磁盘I/O的时段相关而这些磁盘I/O是同一主机上另一个基于磁盘的缓存系统产生的。确凿证据解读GC日志经过数周的调试我们终于在垃圾回收日志中找到了“确凿证据”。一次典型的新生代垃圾回收停顿时间应该在几十或几百毫秒。但我们看到的情况是这样的/* by yours.tools - online tools website : yours.tools/zh/json2cs.html */ [timestamp]: 184512.789: [GC [PSYoungGen: 1058042K-17224K(1069568K)] 3112024K-2018456K(3258112K), 15.3495220 secs] [Times: user0.25 sys0.05, real15.35 secs]乍一看这似乎是一个长得离谱的垃圾回收暂停。但“啊哈”的时刻出现在/* by yours.tools - online tools website : yours.tools/zh/json2cs.html */ [Times]部分user0.25 sys0.05总CPU时间0.30秒这是垃圾回收GC进程使用的实际CPU时间。垃圾回收算法本身快得令人难以置信且效率很高。real15.35 secs挂钟时间这是从暂停开始到暂停结束在现实世界中经过的总时间。这种差异十分明显JVM处于全局停顿状态超过15秒但实际占用CPU运行的时间仅为0.3秒。在其余约15秒内STW线程处于“脱离CPU”状态陷入了等待状态。年轻代GC是一种“Stop-the-World”事件。JVM实际上会暂停所有应用线程以安全地移动内存。我们发现这个GC操作的最后一步是将日志条目同步写入GC日志文件。那个简单的write()系统调用就是问题所在。由于磁盘受到其他缓存进程的激烈争用内核的I/O队列已饱和。GC线程的日志写入——一个看似无害的操作在该队列中陷入停滞等待物理磁盘。而且由于JVM处于STW暂停状态整个应用程序都被冻结等待那一行日志写入完成。修复方法很简单我们不再将GC日志写入那个竞争激烈的磁盘。解决方案这个基本问题即一个关键的、阻塞的线程在等待输入/输出。以下是解决这个问题的两种主要方法。1. 文件系统级修复我们的解决方案这是我们最初的解决方案。我们将GC日志路径从物理磁盘上的默认位置更改为内存支持的文件系统。方式我们将日志输出例如-Xloggc:/var/log/my-app/gc.log指向tmpfs中的一个路径例如-Xloggc:/dev/shm/my-app-gc.log。工作原理写入tmpfs并非真正的磁盘输入/输出操作。它们是内存到内存的复制几乎是瞬时完成的。write()调用会立即返回从而结束STW暂停。内存溢出怎么办这是一个合理的担忧。理论上将日志写入内存可能会耗尽所有可用内存并导致服务器崩溃。我们通过使用JVM的内置日志轮转标志来缓解此问题。通过设置-XX:UseGCLogFileRotation -XX:NumberOfGCLogFiles6 -XX:GCLogFileSize20M我们将垃圾回收日志的总内存使用量限制在可预测的120MB从而消除了进程失控的风险。缺点日志是临时的/dev/shm中的日志会在每次系统重启或容器重启时丢失。归档功能丢失这一变更意味着日志不再被我们的集中式持久化日志系统自动收集。如果仍需持久化则需要配置单独的日志传输代理如边车代理。2. JVM级修复现代方法多年来tmpfs这种权宜之计是 唯一 的解决方案。最近亚马逊 Corretto 团队开发并贡献了一项正式的 JVM 功能用于添加异步 GC 日志记录该功能已成为 OpenJDK 17 中的标准功能。方法将async修饰符用于您的-Xlog标志。-Xlog:async -XX:AsyncLogBufferSize100M其工作原理STW GC线程不再执行I/O操作。它会将日志消息写入一个小型的内存缓冲区并立即恢复应用线程。随后一个独立的低优先级后台线程负责将该缓冲区的内容刷新到磁盘。优点这是“官方”且期望的解决方案。无需操作系统级别的技巧。日志写入标准文件路径便于收集。缺点在极端突发场景下对于GC日志来说不太可能异步缓冲区可能会被填满这可能导致主线程停滞。在较旧的Java部署中不是一个选项为何这仍然重要在容器时代这个问题再次出现。现代的“最佳实践”是让应用程序直接将日志输出到stdout/stderr。但stdout并非一个神奇的虚无空间它是一个管道。必须有其他进程从该管道的另一端进行读取。这通常是容器运行时如containerd或日志代理如Fluentd、Vector或Logstash。如果该日志代理运行缓慢、配置错误或者它自身的网络或磁盘I/O出现阻塞其读取缓冲区就会被填满。这种背压会沿着管道向上传递导致应用程序下一次对stdout执行write()操作时会阻塞。如果JVM在STW暂停期间尝试将GC日志写入stdout而日志代理又不堪重负那么你将会再次陷入同样的停滞状态。核心要点real与usersys是你的信号当你在任何日志中看到较高的real时间但较低的usersys时间时这不是CPU问题。而是I/O问题磁盘、网络或操作系统调度程序问题CPU饥饿。关键路径上无输入/输出操作切勿在整个应用程序所依赖的线程上执行阻塞性输入/输出操作包括“简单的”日志记录。使用async日志记录对于现代JVM使用-XLog:async标志。这是将此I/O从关键路径移开的最简洁方法。要警惕stdout在容器化的世界中向stdout记录日志仍然是一个阻塞式I/O调用。要确保你的集群日志管道既稳健又非阻塞否则你可能会将日志记录延迟变成整个应用程序的停滞。原文链接https://dzone.com/articles/the-jvm-pause-that-wasnt-a-war-story