@julyclyde #41 有启动脚本，我昨天也怀疑是不是在 shell 里手动启动的服务，但是和这个日期匹配不上。2w 1d 21h 28min 5.200 。这个日期要长于我们上次发版的日期。

@cyningxu 是的，非常感谢大家，我也喜欢这种氛围。

@hrapunzel #33 好的，我试一下，堆外内存默认 xmx 一样的 2g ，感觉 2g 应该够用了。我查了一下：如果 JVM 试图分配堆外内存（例如通过 ByteBuffer.allocateDirect()分配直接内存），但操作系统的内存资源已经耗尽，JVM 通常不会直接触发 SIGSEGV ，而是抛出 java.lang.OutOfMemoryError: Direct buffer memory 。JVM 本身一般不会直接因为堆外内存不足触发 SIGSEGV ，但如果程序使用了 JNI 、本地库或者使用了不安全的操作（例如 Unsafe 类），在处理内存时可能会导致 SIGSEGV

@ZZ74 #28 我们发送的是 JSON 的字符串，不是文件。您最后一句话是啥意思呢？是指可能是因为并发导致的吗

@hrapunzel 这个服务器 128g ，目前只用了十多 G

操作系统是 ubuntu ，检查 syslog 日志，发现一个信息，不知道是否有关联：
1 、程序最后一行 info 日志时间是，2024-10-09 08:52:57.251 ，无错误日志。
2 、检查 Syslog 日志，发现同一秒有下面的日志：
Oct 9 08:52:57 lenovo-07 systemd[1]: session-2106.scope: Deactivated successfully.
Oct 9 08:52:57 lenovo-07 systemd[1]: session-2106.scope: Consumed 2w 1d 21h 28min 5.200s CPU time.

@hideon 没有手动 dump ，因为当时 JVM 直接挂了。也没有自动生成 Dump 文件。您说的这个 ws 瞬间连接增大有一定道理，但是我们这个是内网使用，不会有很多人同时使用。以前有过 OOM ，是因为 ws 连接一直没释放，导致后端有引用在无法回收部分垃圾。但是目前已经加了五分钟自动断开重连 ws 的机制了。ws 推送的频次和数据量确实很高。毫秒级的。

@ZZ74 #20 查了一下，Undertow 使用 Java NIO （ non-blocking I/O ）来处理 WebSocket 和 HTTP 连接。NIO 会使用 ByteBuffer ，其中包括堆外内存（ Direct ByteBuffer ）。有可能和这个有关系么？

@ZZ74 #20 感谢大佬，AbstractFramedChannel.flushSenders()应该是 undertow 底层推送 ws 的时候调用的，系统中有 websocket 推送，数据量和频次很高，快的话几毫秒一次。但是据说出问题那会儿没有停留在有 ws 推送的页面。flushSenders 是给 web 客户端发送数据。

@willbetter 磁盘还有几个 T ，文件句柄看日志也正常范围

@D3EP 没有哦，我们程序有 websocket 推送，而且 web 框架是用的 undertow ，好像底层有 netty ，但是没有直接在业务代码里操作 netty

@ZZ74 #14 大佬能否帮忙分析一下呢？实在找不到问题了，这是几张完整的监控截图。大概八点四五十的时候用户开始使用的，之后没数据是因为 JVM 退出了。
https://imgse.com/i/pAJpwrD
https://imgse.com/i/pAJp0qe
https://imgse.com/i/pAJpdKO

这是 hs_err_pid1301132.log 文件
pan 点 baidu 点 com/s/1hZ5Fb8Nir458vSiS14XY-Q 提取码: cgpp

@ZZ74 我从监控平台看了下内存那些都很正常的呢？ https://imgse.com/i/pAGLDy9
https://imgse.com/i/pAGLBQJ 程序有大量的 IO 和 CPU 操作，用的 undertow 框架。

@serverKnignt #7 应该不是，查了系统日志没发现啥问题

@iyiluo 我的错误和这个很像，难道真的是 Netty 的问题？ https://github.com/netty/netty/issues/4206

@iyiluo 好的，感谢

@dx123 -Xmx2048m -Xms2048m -XX:+UseG1GC 没有做其他的优化

@jiom 没有优化过：
real-time non-blocking time (microseconds, -R) unlimited
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 513419
max locked memory (kbytes, -l) 16438992
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 513419
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

ripro