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

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

DAYU200 开发板在面对相同的日志写入速率时, 丢包率有了明显的下降; 在面对 1 730 KB/s 的写入速率时, 仅分
别有 4.6% 和 0.1% 的数据丢包. 这一定程度上印证了丢包是由于覆盖写操作造成的 CPU 瓶颈导致的.
最后, 在 RPI3B 开发板上比较了 Android 的日志系统 Log 和 OpenHarmony 的日志系统 HiLog 的丢包率随写
日志速率的变化. 在选择参数 S s_buffer 、S h_buffe 时, 参考使用 Android 日志系统 Log 的默认 socket_buffer 空间大小
r
(64 KB) 和 list_buffer 空间大小 (256 KB). 结果如图 11 所示, 可以看出 Log 在写入速率达到 700 KB/s 时开始出现
丢包情况, 而 HiLog 直到 1 500 KB/s 时才出现丢包; 当日志写入速率达到 1 730 KB/s 时, Log 的丢包率达到 19%,
而 HiLog 的丢包率仅为 8%. 上述结果表明, HiLog 相比 Log 具有更高的日志吞吐量, 且在写日志速率超过吞吐量
的情况下具备更低的丢包率, 可以有效地保留更完备的操作系统事件信息提供给系统开发者或运维人员使用.

20

15 Log (Android)
HiLog (OpenHarmony)
L (%) 10

5

0
400 600 800 1 000 1 200 1 400 1 600 1 800
V input (KB/s)
图 11 Log 和 HiLog 的丢包率 L 随 V inpu 增长的变化趋势 (硬件平台: RPI3B)
t

上述实验首先分析了 HiLog 日志系统在 500 KB/s–1 730 KB/s 写入速率范围的丢包情况和原因, 发现在高日
志写入速率下的丢包是由于 hilog_buffer 覆盖写操作造成的 CPU 瓶颈导致的, 可以通过增大 S h_buffe 降低丢包率.
r
接下来对比了 HiLog 和 Log 在 500 KB/s–1 730 KB/s 写入速率范围内的丢包率情况, 结果表明在相同的硬件条件
下, HiLog 相比 Log 具有更低的丢包率, 这说明 HiLog 日志系统可以更好地保留操作系统中的事件信息, 为使用者
提供更详尽的日志数据用于开展工作. 在如今这种由于丰富的软件带来日志数量持续膨胀而硬件摩尔定律失效的
状态下, HiLog 的性能优势是十分有意义的.
4.2 HiLog 流控性能分析
流量控制机制是 HiLog 实现系统资源合理分配的重要手段. 对于日志系统的基本性能分析表明, 当日志写入
速率过快时, 会导致丢包的情况, 同时也会大量占用 CPU 等系统资源. 为了避免这一问题, HiLog 设计了日志的流
量控制功能, 它可以对每进程的日志流量进行限制, 避免由于部分程序写日志速率过快占用 HiLog 的处理资源.
为了测试流量控制功能的效果, 实验基于 HiKey960 开发板搭建了测试环境, 构建了 2 个写日志进程, 其中进
程 A 是正常写日志进程, 其写日志速率 V input_ 在正常速率范围内写日志 (1–20 KB/s); 进程 B 是违规写日志进程,
A
持续以极高速度写日志 (4 096 KB/s). 实验目的是分析在开启 (每进程写日志流量上限为 13 KB/s)/关闭流量控制的
情况下, 进程 A 的日志丢包率 L A 和 hilogd 进程的 CPU 占用率.
实验结果如图 12 所示, 其中, 黑色虚线代表单进程写日志流量上限, 可以看到当系统中存在一个高速写日志
进程时, 如果关闭流量控制, HiLog 几乎无法收集到其余进程的日志信息, 且 hilogd 进程的 CPU 占用率达到了
44%, 严重侵占了系统的资源. 流量控制功能开启时, 情况发生了变化, 当进程 A 写日志速率低于设定的流量上限
(13 KB/s) 时, 几乎不会出现丢包情况, 且 hilogd 的 CPU 占用率也下降到 3% 左右. 说明流量控制功能抛弃了进程
B 的绝大多数日志, 使它们不会进入 IPC 和缓冲区处理环节, HiLog 能够有效处理进程 A 的日志信息. 流量控制功
能同时降低了 hilog_buffer 达到容量上限进行的覆盖写操作频率, 降低丢包率和 CPU 资源的损耗.
上述实验说明了 HiLog 流量控制功能的有效性, 可以有效降低违规高速写日志进程对其他进程日志资源的侵