index_new5.html
../../../zaker_core/zaker_tpl_static/wap/tpl_guoji1.html
![]()
本文分享了算法SRE在性能优化中的经验,重点关注浮点转换、GC问题和RT时间优化。通过Ryu和Fast_Float算法优化浮点转换,规避了JDK原生API的性能瓶颈,提升了CPU利用率。针对GC问题,通过调整JVM参数,避免了小堆场景下的GC抖动。同时,通过Wall火焰图和Trace工具,定位并解决了特征读取阶段的IO等待问题,最终提升了系统的整体性能,实现了业务价值的最大化。
💡 浮点转换优化:通过Ryu算法和Fast_Float算法替代JDK原生浮点转换,显著降低了CPU算力消耗,性能提升高达98%,CPU实际获得50%收益,RT实际获得25%左右性能收益。
🗑️ GC问题规避:针对小堆场景下的GC抖动问题,通过调整JVM参数(如-XX:GPGCTimeStampPromotionThresholdMS 和 -XX:GPGCOldGCIntervalSecs),规避了老年代GC,解决了RT99抖动和错误率问题。
🔥 RT时间优化:通过Wall火焰图分析,发现特征读取阶段的IO等待是RT瓶颈。结合Trace工具,定位到Proxy层是瓶颈,并提出了通过垂直多副本部署模式解决问题的方案。
🔍 性能分析方法:文章强调了性能分析的重要性,推荐使用CPU火焰图、内存分配火焰图和Wall火焰图,以及Trace工具,来定位和解决性能问题。
原创 月醴 2025-06-04 18:30 上海
在算法工程中,性能尤为关键——它既能提升系统稳定性,又能降低成本、优化效果,因此工程团队将微秒级的性能优化作为核心攻坚方向。本文将结合具体案例,分享算法SRE在日常性能优化中的宝贵经验,助力更多同学在实践中提升系统性能、实现业务价值最大化。


目录
一、引言二、给浮点转换降温 1. 浮点转字符串:Ryu算法 2. 字符串转浮点:Fast_Float算法 3. 代码优化样例 4. 性能实测效果 5. 小结三、拔掉诡异的GC毛刺 1. 小堆GC问题 2. GC问题分析 3. 解决方案 4. 小结四、是谁偷走了RT时间 1. 业务瓶颈的卡点 2. 活用三昧真火 3. 逐帧跟踪确认 4. 小结五、结语:性能优化无止尽
引言在算法工程中,大家一般关注四大核心维度:稳定、成本、效果、性能。其中,性能尤为关键——它既能提升系统稳定性,又能降低成本、优化效果。因此,工程团队将微秒级的性能优化作为核心攻坚方向。本文将结合具体案例,分享算法SRE在日常性能优化中的宝贵经验,助力更多同学在实践中优化系统性能、实现业务价值最大化。 给浮点转换降温算法工程的核心是排序,而排序离不开特征。特征大多是浮点数,必然伴随频繁的数值转换。零星转换对CPU无足轻重,可一旦规模如洪水倾泻,便会出现CPU瞬间飙红、性能断崖式下跌的情况,导致被迫堆硬件,白白抬高成本开销。例如:《交易商详页相关推荐 - neuron-csprd-r-tr-rel-cvr-v20-s6》 特征处理占用CPU算力时间的61%。其中大量工作都在做Double浮点转换,如图所示:优化前CPU时间占比 18%Double.parseDouble、Double.toString是JDK原生原子API了,还能优化?直接给答案:能!https://github.com/ulfjack/ryuRyu算法,用“查表+定长整数运算”彻底摒弃“动态多精度运算+内存管理”的重开销,既正确又高效。算法的完整正确性证明:https://dl.acm.org/citation.cfm? doid=3296979.3192369 伪代码说明
void convertStandard(double d, char *out) {
bool sign = (d < 0);
int exp = extractExponent(d);
uint64_t mant = extractMantissa(d);
BigInt num = BigInt_from_uint64(mant);
num = BigInt_mul_pow2(num, exp);
char buf[32];
int len = 0;
while (!BigInt_is_zero(num)) {
BigInt digit, rem;
BigInt_divmod(num, 10, &digit, &rem);
buf[len++] = '0' + BigInt_to_uint32(digit);
BigInt_free(num);
num = rem;
}
formatOutput(sign, buf, len, out);
}
void convertRyu(double d, char *out) {
bool sign = (d < 0);
int e2 = extractBiasedExponent(d) - BIAS;
uint64_t m2 = extractMantissa(d) | IMPLIED_ONE;
int k = computeDecimalExponent(e2);
uint64_t pow5 = POW5_TABLE[k];
int shift = SHIFT_TABLE[k];
__uint128_t prod = ( __uint128_t )m2 * pow5;
uint64_t v = (uint64_t)(prod >> shift);
char buf[24];
int len = 0;
do {
buf[len++] = '0' + (v % 10);
v /= 10;
} while (v);
formatShort(sign, buf, len, k, out);
}
传统方法 vs. Ryu算法对比:
算法比较 | “普通”算法 | Ryu算法 |
内存分配 | BigInt动态扩容 + 释放 →heap分配/回收成本高 | 全/静态表 + 栈数组,无malloc→ 零动态分配 |
算术成本 | 频繁多精度除法(数百纳秒) | 单次64位乘法+位移(约30-40纳秒) |
循环次数 | 取决于浮点数数值难以预测 | 固定次数易于优化和预测 |
缓存友好 | 内存分散不利CPU缓存 | 栈上集中CPU缓存友好 |
https://github.com/wrandelshofer/FastDoubleParser相比Java自带的Double.parseDouble使用复杂状态机(如BigDecimal或 BigInteger)来处理各种情况,FastDoubleParser使用以下优化策略。FastDoubleParser 优化策略※ 分离阶段将输入拆分为三个部分:significand、exponent、special cases(如 NaN, Infinity)。解析时直接处理整数位和小数位的组合。※ 整型加速 + 倍数转换在范围允许的情况下使用“64位整数直接表示”有效位。再通过预计算的“幂次表(10ⁿ 或 2ⁿ)”进行快速缩放,避免慢速浮点乘法。※ 避免慢路径避免使用BigDecimal或字符串转高精度,再转回double的慢路径。对于大多数输入,整个解析过程不涉及任何内存分配。※ SIMD加速(原版 C++)在C++中使用SIMD指令批量处理字符,Java版受限于JVM,但仍通过循环展开等技术尽量进行优化。 转换思路 Input: "123.45e2"
1. 拆分成:
significand = 12345 (去掉小数点)
exponent = 2 - 2 = 0 // 小数点后两位,但有 e2
2. 快速转换:
result = 12345 * 10^0 = 12345.0
3. 最终使用 Double.longBitsToDouble 构造结果
压测报告Double 字符解析相对JDK原生API 4.43倍 加速通过多层判断,尽可能不让Object o做toString()操作。减少toString触发的可能工具类 替换浮点转换算法工具类 替换浮点转换算法启用Ryu、Fast_Float算法替换JDK原生浮点转换,效果如下:优化后CPU时间占比 0.19%【性能提升(18-0.19)/18=98%】CPU实际获得50%收益RT实际获得25%左右性能收益告别原生JDK浮点转换的高昂代价,拥抱Ryu与FastDoubleParser,让CPU从繁忙到清闲,性能“回血”,节约的成本大家可以吃火锅。 拔掉诡异的GC毛刺特征维度多时内存压力大,GC问题可以预期。但很多同学可能没有见过,小堆场景,GC也可能频繁触发,甚至引发异常。如图所示:18GB堆 扩容 -> 30GB堆,均出现RT99周期脉冲,致使5~6%的失败率。社区瀑布流广告投放-Neuron精排 因GC导致错误首先这是GC问题,其次增加了近1倍的内存,没有丝毫缓解,判断这应该是个伪GC问题。Neuron主要功能就是拿着特征转向量做排序。一般特征量都是亿起步,多的达十亿,因此特征缓存必不可少。但是这个场景,仅仅是将1700个左右的广告特征信息进行了缓存,为什么对象内存会出现周期性的脉冲?年轻代+老年代 周期共振脉冲如图所示,关键的问题在于“共振”。因此要用放大镜看问题,再如图所示:共振点 放大共振点CPU峰值水位:28%GC 暂停时间
线索 | 矛盾点 | 疑惑点 |
老年代回收 3GB | 老年代3GB回收,对于C4垃圾回收器,应该毫无压力 |
|
年轻代徒增 9GB |
| 老年代GC,为什么年轻代会同步往上飚? |
年轻代瞬间回收 9GB |
| 年轻代内存飚升后,为什么瞬间又把内存释放? |
共振点CPU无压力 | 两代整体回收12GB,对于C4垃圾回收器,应该毫无压力
| GC窗口期间,CPU算力充足,为什么会导致 RT99 成倍往上飚? |
到这里,其实问题已经很明显了:C4作为世界顶级垃圾回收器,GC的能力不用怀疑,STW(Stop-The-World)的时间理论是亚毫秒级。如果GC能力没问题,算力又充足,那么造成RT99翻倍的原因:要么是线程在等数据,要么是线程忙不过来。Neuron堆内存大头是缓存,那么老年代回收的数据一定是缓存数据,年轻代一定是在回补缓存缺口。为什么会有这个逻辑?因为缓存命中率一直是 99.9%【1700个广告条目】,如图所示:在极高缓存命中率的场景下,仅清理少量缓存条目,也可能造成“缓存缺口”。缓存缺口本质上也是一次“中断”,线程被迫等待或执行数据回补,导致性能抖动。为方便理解,类比“缺页中断”(Page Fault):当程序访问未加载的内存页时,操作系统必须中断执行、加载数据,再继续运行。首先是缓存命中率一定是越高越好,99.9%的命中率没毛病。问题出在1700条广告缓存条目,究竟为何必须如此频繁地设置过期?【TTL: 60~90s】原因是:业务期望广告特征,能够尽可能实时更新。缓存失效策略失效时间 60~90s关键在于,缓存条目必须及时失效,却又不能因GC过度而引发性能问题。从观察结果来看,年轻代的GC没有对RT99的性能产生明显影响,这说明年轻代GC的力度恰到好处,不会造成频繁的“缓存缺口”。既然如此,我们考虑:如果能彻底规避老年代GC,性能瓶颈的问题是否就能迎刃而解?因此,我们尝试大幅提高对象晋升到老年代的门槛,直接提升了几个数量级。增加JVM参数:
-XX:GPGCTimeStampPromotionThresholdMS
默认值:2000 调整为:6000000 (1.6小时)
-XX:GPGCOldGCIntervalSecs
默认值:600 调整为:600000
在这个场景中,实际有效的对象并不多,最多不过5GB。 其余大部分都是生命周期不超过2分钟的短期广告特征条目(约1700条)。这种短生命周期、低占用的场景完全靠年轻代GC就能轻松支撑,根本不需要启用分代GC。实际测试一天后,完全印证了这一判断:GC抖动、RT99抖动以及错误率抖动全都彻底消失,同时内存也没有出现任何泄漏。GC 毛刺消失RT99失败率 毛刺峰值降至 1/10 +C4的分代GC对大堆确实有奇效,但放在小堆场景里,非要套个复杂架构,就成了典型的“形式主义”大堆适用,小堆不行。 是谁偷走了RT时间最近算法特征多了,推理成本就高了;RT一长,用户体验就垮了;产品一急,秒开优化就立项了。全业务链路都已锁定 RT 优化目标,社区个性化精排也在其中,可这一链路优化阻力最大——RT99长期卡在120ms 以上,始终难以突破。性能分析必看CPU火焰图。一看图就是GC问题。
GC日志分析,年轻代+老年代,堆积起来约150GB,而堆内存才给108GB,怎么做到的?->>> 频繁GC!GC算力消耗占比 超50%至少要 150GB 勉强够用高频GC看看哪里分配内存比较疯狂,如图内存分配火焰图所示:内存分配压力指向两大热点※ Dump业务刚需,大量序列化点对象带来的瞬时垃圾情有可原。※ 特征真正的“吞金兽”——独占超过50%的堆。业务方解释:当前500万特征才勉强把命中率抬到80%,想继续往上,只能指数级内存扩容,总特征数10亿+。堆已拉到128GB,找不到更大规格的机器。也就是说内存主要被特征吞掉了,优化空间基本没有。如果优化止步于此,显然无法满足业务方的期望,于是我们进一步深入到Wall火焰图进行更精细的分析。Wall火焰图同时捕获了CPU执行与IO等待,因此不能简单地以栈顶宽度判断性能瓶颈。否则只会发现线程池空闲的等待任务,看似正常,但真正的性能瓶颈却隐藏在细节中。因此,我们需要放大视角,聚焦到具体的业务逻辑堆栈位置。在这个案例中,一旦放大便能发现显著问题:特征读取阶段的IO等待时间,竟然超过了远程DML推理与Kafka Dump的总耗时。这直接说明,所谓的80%特征缓存命中率存在明显的缓存击穿现象,大量请求可能被迫穿透至远端Redis或C引擎进行加载,其耗时成本远高于本地缓存命中的场景。通过进一步的Trace跟踪分析,我们的猜测得到了验证。通过和C引擎团队联合排查发现,现有架构采用了早期的部署模式,其中为索引分片路由而设立的中间Proxy层成为性能瓶颈,其RT999甚至超过100ms。这种架构带来的问题在于,上游业务对特征数量需求极大,即使缓存已扩大到500万条目,也仅能达到80%的命中率。算法工程团队通过对特征请求进行多层拆分及异步并发查询优化,但仍有少量长尾特征无法命中缓存,只能依靠C引擎响应。一旦任何一批次特征查询触发了C引擎的慢查询,这一请求的整体RT势必大幅提升,甚至可能超时。好在C引擎同时提供了一种更先进的垂直多副本部署模式,能够去除Proxy这一中心化的瓶颈组件。未来的新架构仍会保留索引分片设计,但会利用旁路方式实现完全的去中心化。通过Wall火焰图深入分析RT性能瓶颈,并结合Trace工具验证猜想,是优化系统性能不可或缺的关键步骤。 结语:性能优化无止尽性能优化没有终点,只有下一个起点。每次性能的提升,不仅是对技术边界的突破,更是为业务创造了更多可能性。本文分享的场景和实操经验,旨在抛砖引玉,帮助各位同学掌握深度性能分析的方法论,避免走弯路,更高效地解决工程难题。希望每位研发和SRE同学,都能从微妙的细节中捕捉优化机会,让应用在极致性能的路上稳步前进。往期回顾
1.得物自研DScript2.0脚本能力从0到1演进2.社区造数服务接入MCP|得物技术3.CSS闯关指南:从手写地狱到“类”积木之旅|得物技术4.从零实现模块级代码影响面分析方案|得物技术5.以细节诠释专业,用成长定义价值——对话@孟同学 |得物技术
文 / 月醴
关注得物技术,每周一、三更新技术干货要是觉得文章对你有帮助的话,欢迎评论转发点赞~未经得物技术许可严禁转载,否则依法追究法律责任。“
扫码添加小助手微信
如有任何疑问,或想要了解更多技术资讯,请添加小助手微信:




























阅读原文
跳转微信打开