宕机日志

2025.2.6 
年后第一周, 客户现场出现了宕机的问题.
当时反馈了下hs_err的异常日志文件: 
Problematic frame:
C  [libfreetype.so.6+0x20070]  TT_Load_Glyph_Header+0x20
Current thread
JavaThread "http-nio-5200-exec-183" daemon [_thread_in_native
siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR)
sun.font.FreetypeFontScaler.getGlyphMetricsNative
com.stimulsoft.report.export.tools.pdf.PdfFonts.getFontMetrics
com.stimulsoft.report.export.tools.pdf.PdfFonts.initFontsData

当天同事就基于异常Bug发现了一个链接: 
https://backend-with-java.hashnode.dev/a-jvm-crash-analysis

上面的异常bug日志与我们的是很接近的. 

宕机可能的原因

CentOS系列的 tmp dev等路径是tempfs 内存文件系统
/tmp 目录作为临时文件存储
默认文件不发生变化的话 十天就会被清理. 
/var/tmp 下的文件是默认30天进行清理.

因为Springboot在默认启动时,如果不设置 临时文件存放路径.
默认选择的是系统环境变量里面的 临时空间,
也就是会选择到 tmp 路径下面

因为打印文件生成后一般只读不写, 所以这个文件一般会在十天左右被清理. 

根据第一部分里面的文章, 会议是这一块的fonts 文件缺失之后,
再进行渲染的时候就会导致宕机了.  

解决思路

1. 修改临时文件的目录: 
export JAVA_OPTS="-Djava.io.tmpdir=/custom/tmp"

这里有一个风险: 
临时目录还是要择机进行清理的
不然里面的文件会越来越多的. 
第二个风险: 
磁盘文件的性能不如内存临时文件
如果这里面需要大量的读取操作性能会衰退.

2. 安装字体文件到系统目录
之前跟同事聊过
打印控件优先去找/usr/share/fonts 目录下面的字体文件
找不到在应用特定目录下面去找, 然后为了提高性能
会将字体文件缓存到 tmp 目录下面去
所以如果使用系统目录, 理论上也可以避免使用/tmp
并且效果可能更好. 

自定义temp存在的问题

自己有一个环境 经常重启, 然后发现里面的文件就很多了:

[root@auto81 temp]# ll -ltrh |head -n 10
总用量 470M
drwxr-xr-x    3 root root   20 11月 30 2023 hip
-rw-r--r--    1 root root    0 11月 30 2023 sqlite-3.41.2.2-073e119f-06fc-4f54-abb0-a0c80dd94491-libsqlitejdbc.so.lck
-rwxr--r--    1 root root 974K 11月 30 2023 sqlite-3.41.2.2-073e119f-06fc-4f54-abb0-a0c80dd94491-libsqlitejdbc.so
drwxr-xr-x    4 root root   37 11月 30 2023 e9442fe3-19bb-4764-9b65-71812a710c67
drwxr-xr-x    4 root root   34 11月 30 2023 docconverter
-rwxrwxrwx    1 root root    0 11月 30 2023 serverlist.lock
-rw-r--r--    1 root root 5.9K 11月 30 2023 da23052d-fdf8-4c05-9329-bcb9fecd9f1f投资组织20231130.xlsx
drwx------    2 root root    6 11月 30 2023 cxf-tmp-1201195666473717660
drwxr-xr-x    4 root root   37 12月  1 2023 2620a676-d037-48eb-b654-01e3e44cab33
[root@auto81 temp]# ll -ltrh |tail -n 10
-rwxr--r--    1 root root 1.1M 3月  17 00:12 sqlite-3.47.0.0-3fa9738d-14aa-46b9-8e6f-1fcd06613592-libsqlitejdbc.so
-rw-r--r--    1 root root 3.9K 3月  17 00:44 d29afbbe-9471-4cbf-85e6-4a3f450d943dIPO企业指标.xlsx
drwxr-xr-x 1044 root root  52K 3月  17 04:16 basaoutput
drwx------    2 root root    6 3月  17 13:56 cxf-tmp-3436231278669006615
drwxr-xr-x    4 root root   37 3月  17 15:06 bcb70aab-fb56-4b5f-a318-00b07de5662c
drwx------    2 root root    6 3月  17 17:32 cxf-tmp-4062533689848447530
drwxr-xr-x    2 root root 4.0K 3月  17 19:22 poifiles
drwx------    2 root root    6 3月  17 19:33 cxf-tmp-290910658745261467
-rw-r--r--    1 root root    0 3月  17 19:35 sqlite-3.47.0.0-c1188630-9a23-46e8-8442-1c4717f711a5-libsqlitejdbc.so.lck
-rwxr--r--    1 root root 1.1M 3月  17 19:35 sqlite-3.47.0.0-c1188630-9a23-46e8-8442-1c4717f711a5-libsqlitejdbc.so
[root@auto81 temp]# du -ahd 1 |tail -n 
1.3G    .

并且文件数也很多.
[root@auto81 temp]# find . |wc -l
22274

这么多文件如果再往里面写入后者是查询 性能其实是有比较大的负面影响的. 

清理应该有一个基准, 应该是在启动成功后清理前两次启动成功之前的文件.