Page 493 - 《软件学报》2024年第4期

吴圣垚 等: HiLog: OpenHarmony 的高性能日志系统 2071

为了横向比较 HiLog 日志系统和 Log 日志系统的持久化丢包率, 在相同平台 RPI3B 平台上分别安装 Android
5.1.1 操作系统和 OpenHarmony3.0 操作系统, 分别测试 Log 和 HiLog 的持久化丢包率, 测试结果如图 13(b)
所示. 可以看到 Log 日志系统在持久化 25 000 条日志时已有 13.4‰的丢包率, 且这一数值随日志数量的增加有明
显的增长. 而 HiLog 日志系统在持久化相同日志数量时丢包率仅有 1.8‰, 仅为前者的 13%, 且随日志数量的增加
没有明显的变化.
为了量化 Log 和 HiLog 的持久化稳定性差距, 通过最小二乘法分别对 Log 和 HiLog 进行了 L p -N inpu 线性拟
t
合, 发现丢包率随日志条数的变化具备线性特征, 曲线表达式为:
Log Log Log
R (n) = k ×n+b (5)
l
R HiLog (n) = k HiLog ×n+b HiLog (6)
l
n 代表日志系统内存 Buffer 中的日志数量. 拟合结果显示, Android 的 Log 日志系统 k Log 1.54×10 −3 , 而
其中, 值为
OpenHarmony 的 HiLog 日志系统 k HiLog 值为 2.34×10 −6 , 仅为前者的 1.52×10 −3 倍, 说明 HiLog 的落盘丢包率随日
志数量的增长是极为缓慢的, 可以适应大量日志持久化的场景需求.
接下来在不同的硬件平台上测试了 HiLog/Log 的持久化存储占用情况. 由于 Android 的 Log 日志系统不存在
压缩持久化功能, 理论上其持久化日志文件大小应等于缓冲区中的日志大小. 然而从图 14(a) 可以看出, Log 的日
志文件总是小于缓冲区中的日志大小, 且随着日志大小的增加偏差在增大, 基于上述丢包率分析, 可以将这种现象
归因为丢包. 图 14(b) 表明 HiLog 的持久化压缩率约为 3.5%, 这一结果在不同的设备上是较为稳定的.

30 100
HiLog (Hi3516DV300) HiLog (Hi3516DV300)
99
HiLog (RPI3B) HiLog (RPI3B)
25 98
HiLog (DAYU200) HiLog (DAYU200)
Log (RPI3B) 97 Log (RPI3B)
20
96
S file (MB) 15 C p (%) 95
10 4
3
2
5
1
0 0
0 5 10 15 20 25 30 0 5 10 15 20 25 30
S input (MB) S input (MB)
(a) S file 随 S input 的变化 (b) C p 随 S input 的变化
图 14 HiLog 和 Log 的持久化性能对比

上述分析表明, OpenHarmony 的 HiLog 日志系统相比 Android 的 Log 日志系统, 在保持低持久化丢包率的基
础上, 还能够对日志进行压缩以节省大量的存储空间 (约 96.5%).
4.4 HiLog 设备兼容性分析
后文表 5 列出了 1 种 L2 硬件平台和 3 种 L1 硬件平台的硬件参数, 可以看到 L1 平台的 CPU 主频、内存空
间、存储空间均远小于 L2 平台. 轻量 HiLog 通过编译时参数控制, 不编译 hilogd 模块达到减少缓冲区维护所需
的计算量和内存空间, 同时 LiteOS 内核的日志缓冲区将会替代 hilog_buffer 作为日志暂存的缓冲区, hilogtool 将
保留持久化压缩的能力, 节约 L1 硬件平台本不富裕的存储空间.
兼容性实验测试了 HiLog 和 Log 在 4 种设备上的运行情况, 相应结果如表 5 所示. 测试结果表明, HiLog 在内
存最小为 96 KB 的设备上依然可以完成日志的写入、打印、持久化功能. 由于 Log 无法脱离 logd 运行, 因此在
L1 设备上是无法安装和运行的. 综上所述, HiLog 具备更强的设备兼容能力, 对于计算资源丰富的硬件可以提供
标准 HiLog 作为高性能的日志系统, 对于计算资源受限的硬件可以提供轻量 HiLog 实现基本的日志功能.
4.5 HiLog 数据安全能力分析
作为对轻量化日志数据安全能力的初步探索, 在设计 HiLog 的数据安全能力时重点考虑了变量的安全问题.