国产化软件性能优化技巧和x86环境下有共通之处，但国产CPU架构带来了新的调优点。很多承德系统刚迁到国产环境就被反馈变慢，其实不是硬件不行，而是JVM参数没按NUMA架构调、数据库统计信息没收集、慢查询没人管。从运行时、数据库、IO三个层面下手，大多数场景能追平原系统性能，甚至反超。

一、CPU与内存架构调优

NUMA节点绑定

国产多路服务器多为NUMA架构，内存访问跨节点会慢很多。Java应用要把JVM进程绑到对应的NUMA节点，避免线程在节点间漂移。承德运维团队常用numactl启动应用并查看节点间内存流量，一旦跨节点流量异常高，性能就会明显掉。

容器化部署时还要注意CPU绑核和内存限制，不要让容器在多个NUMA节点上随机调度，容器编排平台的亲和性策略要提前配置好。物理机部署则要把应用和它用到的本地磁盘、网卡都归到同一节点，远程访问外设也会拖累性能。

JVM参数对齐

堆大小、GC策略要按国产JDK版本重新测试，不要直接搬原x86环境的参数。G1还是ZGC、堆内存占物理内存比例，都要压测后定。容器化部署时注意不要把堆设得超过容器限额，否则一启动就被OOM Kill，排查半天找不到原因。

二、数据库性能治理

统计信息与索引

数据搬迁后第一要务是收集统计信息、重建索引，否则优化器选错执行计划。慢查询日志要定期扫，高频慢SQL单独改写，缺索引的建组合索引，不要一慢就加机器，多数情况是执行计划走错了。

连接池配置

国产数据库连接池大小不要照搬经验值，按CPU核数和事务平均耗时测算。连接过多会导致上下文切换飙升，过少则并发上不去。建议上线后观察一段时间的活跃连接数，再反向调整池大小，一次到位很难。

除了连接数，连接获取超时、空闲回收、PreparedStatement缓存等参数也要按国产数据库特性调。有些国产数据库默认缓存策略偏保守，调大后重复查询明显变快，这些细节压测时容易忽略，要专门盯一下。

三、IO与中间件优化

磁盘IO调度

国产服务器磁盘多为SSD，IO调度策略要调成noop或none，不要沿用机械盘的cfq。日志盘和数据盘建议物理分离，避免日志写满影响业务。很多系统白天卡、夜里正常，一查是备份任务和业务抢磁盘IO，把备份挪到低峰期就解决了。

缓存与静态资源

热点数据放本地缓存或国产缓存中间件，降低数据库重复查询。静态资源、报表文件走独立目录和优化策略。很多管理系统卡在报表导出上，分批异步导出比同步生成体验好得多，导出完成再通知用户下载。

四、建立性能基线

优化不是一次性动作。建议承德企业在切换后建立性能基线：关键接口响应时间、并发数、资源占用定期采集，出现劣化趋势提前告警。每季度做一次全链路压测，架构变更后回归一次。性能调优做到可监测、可对比，才不会上线即巅峰，过两个月没人管又慢慢慢回去。

监测工具也要用国产环境适配的版本。资源监控、链路追踪、日志采集这三类组件都要在目标架构上跑过，不要直接搬国外开源组件的默认配置。采集本身也会消耗资源，采样率要根据服务器余量调整，监控反而把系统拖慢是常见的反例。

国产化软件性能优化是个持续过程。按运行时、数据库、IO三层逐项排查，配合基线监测，承德企业完全可以让国产环境跑得不亚于原系统，打消业务部门对新环境的顾虑。

优化优先级建议从收益最大的项开始：先查慢SQL和缺索引，再调JVM和连接池，最后抠IO调度和缓存策略。顺序反了，花一周调内核参数，不如一条索引把慢查询从十秒降到十毫秒见效快。每次只改一类参数，改完压测对比，不要一次改一堆，出了问题说不清是哪项起作用。性能调优最忌讳凭感觉一把梭，把参数翻来覆去改，最后系统被改得面目全非，还不如最初的基线状态，每次改动都要可追溯、可回退，形成规范的调优记录和操作手册，团队换人也能接得上。