服务基本估算&性能监控告警

主要内容

服务资源基本估算

服务性能常用指标

打点组件介绍和使用

告警系统配置说明

服务资源基本估算

基本资源

4种基本资源：

• cpu：时间~程序耗时 * 服务负载
• 内存：在线运行空间~程序数据结构使用
• 磁盘：离线空间~文件存储
• 网络：外部资源~网络延迟和可达性

CPU

• 时间 ~ 程序耗时 * 服务负载
• 基本度量公式：1 CPU = 1 sec（秒）= 1000ms（毫秒）
• 假设服务A处理一次服务请求需要耗费稳定的50ms的CPU时间，则1个CPU在1sec秒时间内最多处理1000/50 = 20个请求。同理，假如当前服务的QPS为8，则该服务对1个CPU使用率为40%。
• 该计算不区分CPU密集型和IO密集型任务的区别，作为基本计算公式使用：
• • 单核CPU使用率 = (单次服务耗时ms * 服务负载QPS) / 1000ms
• • 多核CPU使用率 = (单次服务耗时ms * 服务负载QPS) / (1000ms * CPU逻辑核心数)
• cpu不够用了会怎样：
• • 一般服务模式都是基于队列，任务被迫排队等待处理，表现为延迟指数级增加；
• • cpu利用率合理区间应该稳定在50%，超过50%的服务延迟会有线性增长。
• cpu不够用了怎么办：
• • 降低单次服务耗时（优化算法）；
• • 获取更多的CPU资源（加docker实例、加机器、多线程并行化）；
• • 让等待IO的任务让出CPU时间片给其他任务（框架支持）。

内存

• 内存使用的场景：
• • 加载大型模型、词典等数据结构；
• • 处理服务请求时临时生成的局部数据结构；
• • 动态编程产生的方法和元数据结构。
    所有程序常驻内存和动态内存之和 < 物理内存
• k8s的docker实例内存是不能共享的，会影响单台物理机能够容纳的部署实例数上限，进而影响其他资源的利用率。
• 比如，intent内存16G + 1CPU，线上物理机内存为256G，32CPU。则1台物理机最多部署12~14个intent实例，CPU利用率不足50%。

磁盘

• 常用查看命令：df和du
• 务必在/data目录存储大文件和日志，/tmp目录不建议使用
• 冷数据（1~3个月不会使用）转储到hdfs，定时清理物理机器的数据目录

服务性能常用指标

• QPS = Requests / Sec = 请求数 / 秒；
• Latency服务延迟；
• 单次请求的接收和发送数据量。

Latency服务延迟

服务延迟是个分布，不是一个确定值。

• 服务延迟的平均值不具有参考性，一般分为50-per，75-per，90-per，95-per，99-per各个分位。
• 对外承诺延迟不高于100ms，隐含的意思是99-per不高于100ms，而不是平均值或者中位数。

单次请求的接受和发送数据量

• 数据服务，如hbase/redis等。需要通过单次请求的接受和发送数据量衡量数据分片和带宽使用。
• 如果我们的服务有数据密集型，如大量的embedding查询和rank打分服务传递上万个feature的情况，需要考虑服务带宽使用。
• 千兆网卡的理论读写上限是1000Mbit/s，即125MB/s。

打点组件的介绍和使用&告警系统配置说明