心流的博客

例子中，已使用内存为 16.4 GB，总内存为 188 GB，使用占比约为 8.7%。表示系统的CPU的核心数，每个核心后的数字就是核心的利用率。例子中，系统有64个核心，每个核心利用率都满了，表示当前CPU核心都被完全占用，没有任何空闲容量，这是计算的瓶颈。负载平均值，它是一个衡量系统忙碌程度的指标，表示在一段时间内，等待 CPU 处理的平均任务（进程）数量。最近在测试服务的性能，使用了htop指令，记录一下指令输出的内容要怎么去理解，下面给出一个htop输出的截图，总共分为8个模块，然后逐个进行解释。

今天在用celery做消息队列管理的时候出现了进程卡死的现象，具体表现为 celery 的 inference_task 函数接收到app 传来的请求，inference_task 在执行的时候直接卡在 model_pipeline 的地方不动了。另外，如果直接在 tasks.py 中加载模型，那么 app.py 引用 tasks.py 的时候也会导致重复加载，所以目前的办法就是 tasks.py 从其他脚本中导入加载好的模型，然后再延迟导入。

分享一个日志监控工具，openobserve（简称 o2），它是一个云原生可观察性平台，专为日志、指标、跟踪、分析 而构建，旨在以 PB 级规模运行。下面通过一个使用案例来分享o2的使用。首先是我们的服务产生日志，然后使用 filebeat 将日志解析并发送到 o2 平台，最后 o2 平台对日志进行可视化展示、分析等等。以上就是全部的内容了，介绍的比较简单，也是为了方便入门，后面更多的功能还需要进一步探索。默认只支持上传最近5小时的日志，超过5小时之前的不会传送。

今天使用了loguru来记录日志，感觉十分的方便，特此记录一下。

本文讲述了如何使用fastapi搭建一个属于自己的服务，整个服务使用fastapi框架搭建，celery管理任务队列，slowapi限制请求的频率，主要技术点就是这么几个，其实实践起来也是很简单的，那么我们就开始吧！该服务以高效、模块化和异步化的架构设计，满足了非实时语音转写的需求，并具有良好的可扩展性和稳定性。

Python作为一种广泛应用的编程语言，虽然因其GIL（全局解释器锁）限制，导致在多线程并发执行中存在一定局限性，但它依然提供了多种并发执行方式。通过合理地运用多线程、多进程、协程、以及子进程，开发者可以在不同场景下大幅提升程序性能。本篇文章将围绕Python的几种主要并发执行模式进行探讨，结合实际案例展示如何在不同任务场景中选择并实现这些技术。我们将重点介绍多线程适用于IO密集型任务的场景，多进程在CPU密集型任务中的优势，协程在高并发异步任务中的强大能力，以及子进程在独立进程间通信中的独特价值。

首次尝试多进程的时候没有共享模型，导致每增加一路的并发就要加载一次模型，这样显存很快就爆了，增加了共享模型之后，每增加一个进程加载一次模型，显存的使用大大降低，这样最终限制并发路数的瓶颈就是GPU的使用率。问题出在我的服务是跑在单个线程上的，虽然用了异步的处理方式，但由于python的GIL的限制，并不能做到真正的并行处理，导致并发路数提不上去。测试并发性能的时候显存、内存、带宽这些资源都没有达到瓶颈，但是并发的路数却提不上去。一般有两种方式，多线程和多进程，打破GIL的限制，这里我使用的是多进程的方式。

最近使用了flask和docker部署了一个深度学习的模型，做的是nlp的情感分析，经历了九九八十一难终于算是部署成功了，自己也总结了这次模型部署的流程，记录下来供自己和大家参考。以上就是全部的内容了，这是基于我自己做的项目部署来记录的，所以有一定的格式规范，比如需要准备app bin等文件。不知道是否写的足够清楚，如果有啥疑问欢迎留言，大家一起交流。