kkFileView 上 ARM飞腾 / 鲲鹏 4 个坑、4 步修好附实测前后对比【免费下载链接】kkFileViewUniversal File Online Preview Project based on Spring-Boot项目地址: https://gitcode.com/GitHub_Trending/kk/kkFileView飞腾机器上 soffice.bin 又崩了一周第 3 次Word 预览直接 500。把 kkFileView 的 ARM 文件预览服务在国产芯片上调稳坑就这几类你照着修就行。踩过的坑飞腾 / 鲲鹏上 kkFileView 文件预览为什么翻车先说结论不是某个文件抽风是四个固定场景。soffice.bin 随机消失Word 转换报 500→ ARM64 的线程调度和内存行为跟 x86 不一样默认单进程任务上限压太满 → 大约每三个文档挂一个。中文全变方块英文正常→ 基础镜像里中文字体缺失或者 fc-cache 没重建 → 中文 PDF 预览一眼就是豆腐块。同一份 200 页 PDF飞腾 40 秒x86 15 秒→ CPU 单核偏弱PDF 转图是纯 CPU 活 → 用户以为预览服务卡死了。跑一周内存一路涨最后 OOM→ 残留 soffice 进程没被回收JVM 堆还给默认值 → 每隔几天就得重启一次。各芯片上翻车的位置不太一样平台架构最先翻车的点付出的代价飞腾 FT-2000/4ARM64高并发转文档崩 soffice.bin转换超时页面 500鲲鹏 920ARM64中文字体渲染中文文档预览不可用海光 7000 系列x86_64不崩就是首次转换慢只能当基线对照机字体修好之后中文 PDF 的 kkFileView 文件预览效果长这样怎么修application.properties 该改哪几行ARM 镜像怎么构建按顺序做镜像跑起来是前提。四步构建镜像 → 改配置 → 查字体 → 调 JVM。第 1–2 步构建 arm64 基础镜像改 6 行配置第 1 步做什么在飞腾 / 鲲鹏机器上克隆代码原地构建 arm64 基础镜像。为什么docker/kkfileview-base/ 下的 Dockerfile 是跨平台兼容的libreoffice-nogui 和 JRE 这些依赖在构建时按本机架构从 apt 拉只有 arm64 机器上构建才拿得到 arm64 镜像。git clone https://gitcode.com/GitHub_Trending/kk/kkFileView cd kkFileView/docker/kkfileview-base docker build --tag keking/kkfileview-base:arm64 .⚠️ 别踩这个坑别在 x86 上用 buildx 编完再推给飞腾跑。镜像里的包在构建时就定死了架构编出来的是 amd64上飞腾直接起不来。跨平台构建留给 CI 出包部署这件事就在目标机上做。第 2 步做什么打开 application.properties只改这几行别的都别动office.home /opt/libreoffice office.plugin.server.ports 2001 office.plugin.task.maxtasksperprocess 100 office.plugin.task.timeout 10m pdf.max.threads 5 media.convert.disable true为什么office.home 指向 ARM64 版 LibreOffice 目录default 在飞腾上会找不到端口减一个、单进程任务封顶 100是治 soffice.bin 崩的主药超时放宽到 10mARM 上首次转换就是慢关掉视频转换省 CPU预览够用。⚠️ 别踩这个坑maxtasksperprocess 别直接怼默认值 200ARM 上 soffice.bin 会崩得比 x86 更勤。100 是试了几轮才稳的数再往下调响应就慢了。第 3–4 步查字体调 JVM第 3 步做什么一行命令查中文字体fc-list :langzh | wc -l为什么结果大于 0 才算过。基础镜像已内置文泉驿微米黑 / 正黑老基础镜像要手动把字体丢进 /usr/share/fonts/chinese 再跑 fc-cache -fv——索引不建字体文件躺在哪儿预览照样是方块。第 4 步做什么JVM 启动参数换成 G1JAVA_OPTS-Xms1g -Xmx2g -XX:UseG1GC -XX:MaxGCPauseMillis150为什么G1 适合大量短平快转换这种负载。堆别给超 2g——LibreOffice 的内存长在 native 区JVM 管不着给多了只会推迟 OOM 到来的时间。跑通了没验证 checklist 和前后对比数据按顺序过一遍全部通过才算跑通确认 docker inspect 里镜像架构是 arm64是 amd64 的话后面全白搭。检查 fc-list :langzh 输出大于 0。确认 /actuator/health 返回 UPoffice 插件端口在监听。预览同一组中文 Word、PDF、xlsx飞腾和 x86 渲染逐页比对。跑 20 个连续转换观察 soffice.bin 进程数与内存增长曲线。观察日志 24 小时确认无转换超时、无进程残留。前后对比飞腾 FT-2000/450 份样例文件指标修复前修复后Word 预览成功率约三分之二基本全过200 页 PDF 首次转换40 秒以上20 秒左右20 并发下内存峰值超 2G2G 以内连跑 3 天 soffice 残留进程几十个0文档和表格预览的实际效果后续怎么管监控、巡检、告警别另搞一套挂在现成的上Prometheus 指向 /actuator/metrics盯 soffice 进程数、JVM 堆、转换超时率三条曲线巡检每周跑一遍上面那份 checklist重点是字体和进程残留告警只留两条——转换失败率超 5%、堆使用率超 80% 拉人。基础镜像升级时先在目标机构建并跑完 checklist再换生产。别急着上生产。先拿一份真实业务文件在目标机上把 checklist 跑一遍渲染结果跟 x86 环境并排比一比。字体和并发转换这两关稳了剩下的性能差用资源换就行。【免费下载链接】kkFileViewUniversal File Online Preview Project based on Spring-Boot项目地址: https://gitcode.com/GitHub_Trending/kk/kkFileView创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
