--- title: 鲲鹏博客 - 鲲鹏计算技术深度解析与交流分享 | 鲲鹏社区 description: 鲲鹏博客是鲲鹏开发者社区的技术分享平台，提供关于鲲鹏处理器、操作系统适配、应用迁移、性能优化等领域的深度技术文章、实践案例与行业洞察。加入我们，获取最新的鲲鹏计算技术动态，学习开发者实践经验，探索计算产业的创新与发展。 keywords: 鲲鹏博客，鲲鹏计算技术文章，鲲鹏处理器解析，操作系统适配指南，应用迁移实践分享，性能优化案例，鲲鹏计算生态，开发者技术实践，高性能计算技术分享 url: https://www.hikunpeng.com/developer/blog section: (其他) --- # 鲲鹏博客 - 鲲鹏计算技术深度解析与交流分享 | 鲲鹏社区 URL: https://www.hikunpeng.com/developer/blog 描述: 鲲鹏博客是鲲鹏开发者社区的技术分享平台，提供关于鲲鹏处理器、操作系统适配、应用迁移、性能优化等领域的深度技术文章、实践案例与行业洞察。加入我们，获取最新的鲲鹏计算技术动态，学习开发者实践经验，探索计算产业的创新与发展。 关键词: 鲲鹏博客，鲲鹏计算技术文章，鲲鹏处理器解析，操作系统适配指南，应用迁移实践分享，性能优化案例，鲲鹏计算生态，开发者技术实践，高性能计算技术分享 我的关注全部鲲鹏通用鲲鹏DevKit鲲鹏BoostKit鲲鹏HPCopenEuleropenGauss鲲鹏硬件鲲鹏同辕开发鲲鹏DA Kit ... 全部类型 精华 热门 推荐 最新发布 最新回复 最多回复 精 荐 顶 鲲鹏7月精选博文 openGaussDevKitopenEuler鲲鹏BoostKit虚拟化使能套件 版块 作者 帖子名称及链接 （点击名称查看帖子详情） openEuler 崇理 【openEuler 实战】实验室摸了三个月鲲鹏服务器，聊聊我踩过的系统调优那些坑 hw_0086_hrf 鲲鹏平台K3s轻量Kubernetes部署与容器应用实战 hw78905213 openEuler 虚拟化平台：IOMMU部署 openEuler 虚拟化 SMMU 技术原理与实操 hw77849011 毕昇 JDK AppCDS 落地实践：性能优化 openGauss Yeats_Liao openGauss 大表查询从全分区扫描到精准锁定：分区裁剪失效排查纪实 openGauss 慢 SQL 排查实战：从接口告警到全表扫描根因 openGauss 迁移鲲鹏实战：从 PostgreSQL WAL 机制到 ARM64 原子操作优化 hhh91100 从 Append Update 到 In-place Update 的演进之路 鲲鹏通用 Yeats_Liao Node.js 服务迁移鲲鹏实战：事件循环延迟排查与 ICU 库适配 鲲鹏 920 上 Elasticsearch 堆外内存优化：ARM64 页表开销与索引缓冲区调优 鲲鹏 920 网卡软中断不均衡排查：从 RSS 队列配置到 smp_affinity 手动调优 hw_0086_hrf 鲲鹏平台Kafka消息队列部署与JVM aarch64调优实战 鲲鹏平台PostgreSQL编译安装与ARM性能调优实战 鲲鹏DevKit ajjjxl 鲲鹏 DevKit 系统调优：Java 应用性能瓶颈定位与优化 鲲鹏 DevKit 系统调优：热点函数识别与全栈落地 acmilanpuli 鲲鹏 DevKit 代码迁移工具：软件迁移评估 鲲鹏 DevKit 代码迁移工具：源码迁移实战 taohuazhuozhuo 鲲鹏 Devkit 应用开发工具：处理器互联开发实践 Faiz 华为云 ECS 鲲鹏服务器 DevKit 热点分析 PMU 事件采集异常修复 鲲鹏锁性能调优实验 hid_s-sq_odhyqmvv7o 鲲鹏软件性能调优：控制流优化原理 wangyuyanhw 鲲鹏 DevKit 系统迁移：待改造 SQL 一键识别提取 鲲鹏 DevKit 系统迁移：中间件自动替换原理、架构 zhaoxintong 鲲鹏 DevKit 性能调优：函 社区博客小助手 4天前 93 0 荐 顶 鲲鹏 DevKit 代码迁移工具：软件迁移评估 DevKit 鲲鹏 DevKit 提供的软件迁移评估是 x86 软件向鲲鹏 ARM64 平台迁移的前置核心环节。区别于后期源码修复，迁移评估阶段通过 porting-advisor 工具自动扫描源码、二进制包、编译脚本，识别架构兼容性风险，输出风险等级、问题位置、修复建议。评估可以提前甄别：x86 汇编指令、SSE/AVX SIMD 内建函数、平台宏、硬编码编译参数、缺少 ARM 依赖库等问题。评估结果作为迁移可行性依据，避免投入大量开发资源后才发现软件无法移植。 软件迁移评估支持命令行批量扫描，可集成 CI 流水线，实现代码提交自动评估。 一、迁移评估核心流程 准备源码 / 二进制软件包； 使用 porting-advisor 执行评估扫描； 导出结构化报告（HTML+JSON）； 通过代码解析报告，统计高、中、低风险项； 根据风险清单判定软件迁移可行性，输出评估结论。 二、基础 Shell 脚本：启动软件迁移评估扫描 bash #!/bin/bash # devkit_migration_assess.sh # 鲲鹏DevKit 软件迁移评估自动化脚本 # DevKit默认安装路径 PORTING_TOOL="/opt/huawei/devkit/porting-advisor/bin/porting-advisor" # 待评估源码目录 SOURCE_PATH="./software_source" # 评估报告输出目录 REPORT_OUTPUT="./assess_report" # 评估语言：C/C++ LANG="c,cpp" if [ ! -d "SOURCEPATH"];thenecho"[ERROR]源码目录不存在{SOURCE_PATH}" ];then echo "[ERROR] 源码目录不存在SOURCEPATH"];thenecho"[ERROR]源码目录不存在{SOURCE_PATH}" exit 1 fi mkdir -p{REPORT_OUTPUT} # 执行迁移评估，开启二进制+源码联合扫描{PORTING_TOOL} \ --sourceSOURCEPATH−−output{SOURCE_PATH} \ --outputSOURCEPATH−−output{REPORT_OUTPUT} \ --languageLANG−−report−formathtml,json−−binary−scanyesecho"=====软件迁移评估扫描完成====="echo"可视化报告：{LANG} \ --report-format html,json \ --binary-scan yes echo "=====软件迁移评估扫描完成=====" echo "可视化报告：LANG−−report−formathtml,json−−binary−scanyesecho"=====软件迁移评估扫描完成====="echo"可视化报告：{REPORT_OUTPUT} hwzgxjiayou 07/31 185 0 荐 热 顶 openGauss 大表查询从全分区扫描到精准锁定：分区裁剪失效排查纪实 openGauss 一、现象与告警 一张按月的订单明细表 orders 已经做了范围分区，共 120 个分区，单表数据量约 2.1 亿行。BI 报表每天上午跑一批"上季度订单汇总"的查询，平时 3 秒内能出结果，这周突然告警：单条查询 P99 从 3.1s 涨到 23.6s，数据库节点 CPU 在报表时段被打满，连带拖慢了同实例下的交易类查询。 监控曲线很典型——报表查询的 EXPLAIN ANALYZE 执行时间绝大部分花在 Seq Scan 上，而且 scans 行数接近全表 2.1 亿，而不是预期的一个季度（3 个分区）的量级。第一反应是统计信息过期，但 ANALYZE 之后毫无改善，说明根因不在优化器估算，而在查询本身没触发分区裁剪。 二、环境信息 项目 配置详情 服务器 鲲鹏 920 双路 64 核，256GB DDR4 操作系统 openEuler 22.03 LTS 数据库 openGauss 5.0.0 表结构 orders，PARTITION BY RANGE (order_time)，120 个按月分区 监控工具 dbeperf.statementhistory + EXPLAIN ANALYZE 业务特征 BI 报表批量聚合，按自然月/季度出汇总，并发不高但单条重 三、定位与排查 阶段一：看执行计划是否真的剪枝了 分区裁剪在 openGauss 里是透明发生的，判断它有没有生效，唯一可靠的办法是看 EXPLAIN 计划里的 Partition Iterator 节点。Iterations 表示实际要迭代的分区数，Selected Partitions 表示最终被选中扫描的分区下标范围。-- 报表原始 SQL 的执行计划（节选） EXPLAIN SELECT SUM(amount), COUNT(*) FROM orders WHERE to_char(order_time, 'YYYY-MM') = '2026-07'; Partition Iterator (cost=0.00..31286.40 rows=716) Iterations: 120 -> Partitioned Seq Scan on orders Filter: (to_char(order_time, 'YYYY-MM'::text) = '2026-07'::text) Selected Yeats_Liao 07/31 37 1 荐 顶 鲲鹏 BoostKit 大数据使能套件 Velox 开发实战 鲲鹏 一、技术概述 BoostKit Velox 是鲲鹏大数据加速套件核心组件，面向 openEuler ARM 架构深度优化的向量化查询引擎，替代传统 Spark、Hive 原生执行器，底层基于鲲鹏 ARM NEON SIMD、NUMA 亲和调度、内存池优化，解决大数据场景过滤、聚合、Join、排序算子 CPU 利用率低、内存抖动、小查询延迟高等痛点。 Velox 作为 BoostKit 一体化组件，提供 C++ 底层算子库、Spark 适配插件、原生 SQL 执行接口，完整适配鲲鹏 920/930 服务器，支持向量化批量数据处理、数据预分片、内存绑定 NUMA 节点、向量化字符串函数加速。本文以可运行 C++ 底层算子、Spark 集成代码、性能调优脚本为核心，完整演示 Velox 编译、自定义向量化算子、Spark SQL 集成、NUMA 内存优化全流程。 二、鲲鹏 openEuler 环境编译部署脚本 1. 一键环境依赖安装脚本（ARM64） bash 运行 #!/bin/bash # boostkit_velox_env.sh 鲲鹏Velox依赖部署 yum update -y # BoostKit大数据全套依赖 yum install boostkit-velox boostkit-blas boostkit-simd libarrow-devel gcc-c++ cmake3 numactl-devel -y # 开启ARM NEON向量化编译开关 echo "export CFLAGS='-march=armv8.2-a -mfp16 -fsimd'" >> /etc/profile echo "export CXXFLAGS='-march=armv8.2-a -mfp16 -fsimd'" >> /etc/profile # NUMA内存绑定优化（鲲鹏HPC/大数据标配） echo 1 > /proc/sys/vm/numa_balancing # 透明大页，消除内存分配抖动 echo never > /sys/kernel/mm/transparent_hugepage/enabled echo never > /sys/kernel/mm/transparent_hugepage/defrag source /etc/profile # 验证V ddjdzxgzx 07/18 159 0 荐 顶 鲲鹏 Devkit 应用开发工具：处理器互联开发实践 DevKit 一、概述 鲲鹏 Devkit 是面向鲲鹏 ARM 架构处理器的一站式开发套件，内置 BoostKit 加速库、多核亲和调度、NUMA 节点互联、跨 CPU 通信组件，针对多鲲鹏处理器服务器（Kunpeng 920/930）提供完整的处理器互联开发能力。 多鲲鹏 CPU 硬件通过板载 PCIe、NUMA 互联总线实现多处理器数据互通，开发难点集中在跨核 / 跨 CPU 数据拷贝、NUMA 节点内存访问失衡、多处理器通信延迟高。鲲鹏 Devkit 提供配套 API、编译工具、性能调优接口，可通过代码绑定处理器节点、控制跨 CPU 数据传输、优化多处理器协同计算。 本文以代码为核心，基于鲲鹏 Devkit 标准开发环境，覆盖 NUMA 节点查询、处理器亲和绑定、跨处理器内存交换、BoostKit 多核通信接口完整实现，适配多 CPU 并行计算场景。 二、鲲鹏 Devkit 环境基础配置 开发环境依赖鲲鹏配套编译器毕昇 JDK / 毕昇 GCC、libnuma、BoostKit 通信库，编译脚本 build.sh： bash 运行 #!/bin/bash # 加载鲲鹏Devkit环境变量 source /opt/kunpengdevkit/set_env.sh # 毕昇GCC编译，链接numa与BoostKit多核库 bisheng-gcc multi_cpu_link.c -o cpu_link_demo -lnuma -lboostkit_comm -O3 -march=armv8.2-a # 执行需root，允许修改CPU亲和、NUMA内存策略 sudo ./cpu_link_demo 三、核心 C 代码：多鲲鹏处理器互联开发 3.1 功能总览 使用 Devkit 封装接口查询本机 CPU 数量、NUMA 节点、处理器互联拓扑； 设置线程 CPU 亲和，绑定线程至指定处理器，避免跨 CPU 频繁迁移； NUMA 内存分配，本地节点优先分配，减少跨处理器内存访问延迟； BoostKit 通信接口实现两个鲲鹏处理器之间数据高速互传； c 运行 #include #include #include #include #include #include #define DATA_LEN 1024 * 1024 // 双处理器编号，多CPU服务器0号、1号鲲鹏处理器 #defi taohuazhuozhuo 07/16 163 0 荐 顶 从 Append Update 到 In-place Update 的演进之路 openGauss 在数据库运维中，DBA 们经常会遇到一个令人头疼的问题：一个频繁更新的业务表，数据量明明只有几百万行，表文件却膨胀到了几十个 GB，VACUUM 怎么也回收不了空间。这种“表膨胀”现象在基于追加更新（Append Update）模式的数据库中尤为常见。 openGauss 早期版本同样采用这种模式——即 Astore（Append-Only Storage）。Astore 在 INSERT、DELETE 以及 HOT UPDATE（同一页面内更新）场景下表现良好。然而，一旦业务出现大量跨数据页面的非 HOT UPDATE，垃圾回收效率便急剧下降，表膨胀问题随之而来。 为了解决这一痛点，openGauss 从 2.1.0 版本开始引入了 Ustore（In-place Update 存储引擎）。本文将深入剖析 Ustore 的设计原理与核心实现，揭示它如何从根本上解决表膨胀问题。 一、Astore 的困境：为什么表会膨胀？ 要理解 Ustore 的价值，首先需要搞清楚 Astore 的问题出在哪里。 1.1 Append Update 的工作方式 Astore 采用追加更新模式：每次 UPDATE 操作并不直接修改原有数据行，而是在数据页尾部追加写入一个新版本的数据行，然后将旧版本标记为“垃圾”（dead tuple）。这种方式在 INSERT 密集型和 HOT UPDATE 场景下表现优异——因为新版本和旧版本在同一个数据页内，索引不需要更新，垃圾回收也相对高效。 1.2 非 HOT UPDATE 的代价 问题出现在非 HOT UPDATE 场景——当更新涉及索引列，或者数据页空间不足无法容纳新版本时，新版本必须写入其他数据页。此时： 1.所有索引都必须新增一条指向新版本的索引项 2.旧版本所在的数据页产生“垃圾”空间 3.垃圾回收（VACUUM）需要扫描全表来清理 随着更新频率增加，数据文件中“垃圾”版本越积越多，而 VACUUM 又难以高效回收，表文件持续膨胀。更严重的是，索引也在同步膨胀——每个更新版本都对应一条索引项，索引扫描效率持续下降。 二、Ustore 的设计哲学：有效数据与垃圾数据分离 Ustore 的核心设计思想可以概括为一句话：将最新版本的“有效数据”和历史版本的“垃圾数据”分离存储。 2.1 数据页面只存“活数据” 在 Ustore 中，数据页 hhh91100 07/16 16 0 荐 热 顶 鲲鹏 920 上 Elasticsearch 堆外内存优化：ARM64 页表开销与索引缓冲区调优 鲲鹏 一、问题核心定位：堆外内存泄漏与页表膨胀 （一）ARM64 页表结构导致堆外内存膨胀 Elasticsearch 迁移至鲲鹏 920 后，运行 72 小时后节点频繁触发 OOM Killer。jstat -gc 显示 JVM 堆使用正常（4GB/8GB），但 pmap -x 显示进程 RSS 达 28GB，远超堆上限。ARM64 架构使用 4 级页表（x86 为 4 级或 5 级），默认页大小 64KB（鲲鹏内核配置），页表项数量比 x86 多 16 倍。Elasticsearch 的 mmap 文件缓存（Lucene 段文件）每个映射消耗独立页表项，导致页表内存（pagetable）膨胀。 （二）索引缓冲区与段合并策略不匹配 GET /_nodes/stats 显示 indexing_pressure.memory.limit 已耗尽，refresh 操作频繁触发段合并。鲲鹏 920 的高内存带宽使索引写入速度提升，但默认 indices.memory.index_buffer_size（10% 堆）在 ARM64 页表开销下显得不足，堆外内存增长速率超过段合并回收速率。 二、调优前置准备：环境搭建与依赖配置 配置项 具体选型 选型原因 操作系统 openEuler 22.03 LTS (ARM64) 支持 64KB 大页配置，页表开销低于 4KB 页 编译器 GCC 12.1.0 支持 ARM64 大页优化，适配鲲鹏内存子系统 内核版本 Linux 5.10+ 支持 hugetlbfs 与 THP 精细控制 Elasticsearch 8.11.0 最新稳定版，支持 ARM64 原生二进制 JVM OpenJDK 21（毕昇 JDK） 支持 ZGC，降低堆外内存碎片 集群规模 3 节点，每节点 64GB 内存 标准生产配置，数据节点角色 监控工具 Elasticsearch API、node-exporter、smem 精确统计堆外内存与页表占用 三、核心调优步骤：从页表优化到索引策略调整 （一）配置透明大页（THP）用于匿名映射 Elasticsearch 的 mmap 映射的 Lucene 段文件本身已在磁盘上，无法使用 THP。但 JVM 的堆外内存分配（Unsafe.allocateMemory）使用匿名映射，启用 THP 可减少页表项数量。# 仅对匿名 Yeats_Liao 07/13 21 1 荐 顶 鲲鹏DevKit Java性能分析与调优实践 DevKit 鲲鹏DevKit是面向鲲鹏ARM架构的一站式开发套件，内置性能分析、代码迁移、架构适配、性能调优工具。传统Java程序多基于x86架构开发，移植至鲲鹏ARM服务器后，常出现循环遍历低效、集合操作冗余、内存泄漏、线程调度不合理等性能问题。本文基于鲲鹏DevKit性能分析工具，结合缺陷代码、优化代码、压测代码、调优对比全流程实操，聚焦Java业务代码性能瓶颈定位与架构级调优，所有代码均可直接在鲲鹏服务器运行，贴合企业生产调优场景。 一、调优前置环境准备 本次调优环境为鲲鹏920处理器、CentOS ARM64系统、JDK1.8、鲲鹏DevKit 24.03版本。首先安装性能分析插件，开启Java性能采集功能，适配ARM架构性能采样机制。 鲲鹏DevKit性能工具初始化（ARM专属） cd /usr/local/kunpeng-devkit/performance sh perf_install.sh 开启Java栈采样、内存监控、线程分析 export PERFJAVAAGENT=true export ARMPERFSAMPLE_RATE=99 查看工具识别CPU架构（确认鲲鹏ARM适配成功） perf list | grep arm64 鲲鹏架构特性：ARM处理器对循环迭代、对象创建、锁竞争的敏感度远高于x86架构，大量常规x86写法会在鲲鹏平台产生性能衰减，是本次调优核心切入点。 二、典型性能缺陷代码 以下为业务中高频出现的鲲鹏低效Java代码，存在频繁对象创建、循环冗余、集合遍历低效问题，在ARM架构下CPU占用高、吞吐量低。 import java.util.ArrayList; import java.util.List; /** ●鲲鹏平台性能缺陷代码 ●问题：循环内创建对象、普通for遍历、频繁字符串拼接 */ public class BadPerformanceDemo { // 模拟业务数据处理 public static List handleData(int count) { List dataList = new ArrayList<>(); for (int i = 0; i < count; i++) { // 缺陷1：循环内频繁创建String对象，ARM内存分配开销大 String info = "data_" + i; // 缺陷2 zhaoxintong 07/12 27 0 登录后可发布博客 登录 官方技术文章查看更多 openGauss 主备同步机制概述 用 openGauss 存储过程构建规则引擎：让大模型在 DABStep 基准上稳定算对 openGauss 自动化测试失败用例 AI 辅助分析实践 Trae IDE + WSL2 openEuler 构建 openGauss 完整指南 明星创作榜查看更多 hw_wihudnz. 关注 向 向远生 关注 崇理 关注 H hw_008618366185126_01 关注 H hw_0086_hrf 关注 Yeats_Liao 关注 S sinanlei 关注 hhh91100 关注 优秀博文推荐换一换 1 代码高手留步！鲲鹏社区任务上新！一边写代码一边把奖品拿了！ 2 计算产品线AI创新应用开源实习生招募：5大领域，7+重点方向，欢迎投递，共筑繁荣软件生态 3 【精选问答系列】第七期：高性能计算常见问题 4 【精华文章系列】第七期：高性能计算：从入门到"放弃" 5 鲲鹏7月精选博文 热门标签推荐查看更多 鲲鹏openGaussopenEulerDevKitLinux数据库迁移开源Java调优