1.在 Nvidia Docker 容器编译构建显存优化加速组件 xFormers
2.JobScheduler的使用和原理
3.SpringBoot定时任务 - 集成quartz实现定时任务（单实例和分布式两种方式)
4.分布式任务调度平台xxl-job
5.技术人生阅读源码——Quartz源码分析之任务的源码调度和执行

在 Nvidia Docker 容器编译构建显存优化加速组件 xFormers

       本篇文章，聊聊如何在新版本 PyTorch 和 CUDA 容器环境中完成 xFormers 的源码编译构建。

       让你的源码模型应用能够跑的更快。

       写在前面

       xFormers[1] 是源码 FaceBook Research （Meta）开源的使用率非常高的 Transformers 加速选型，当我们使用大模型的源码时候，如果启用 xFormers 组件，源码wordpress社区源码能够获得非常明显的源码性能提升。

       因为 xFormers 对于 Pytorch 和 CUDA 新版本支持一般会晚很久。源码所以，源码时不时的源码我们能够看到社区提出不能在新版本 CUDA 中构建的问题（ #[2]或 #[3]），以及各种各样的源码编译失败的问题。

       另外，源码xFormers 的源码安装还有一个问题，会在安装的源码时候调整当前环境已经安装好的 PyTorch 和 Numpy 版本，比如我们使用的源码是已经被验证过的环境，比如 Nvidia 的29的源码月度发布的容器环境，这显然是我们不乐见的事情。

       下面，我们就来解决这两个问题，让 xFormers 能够在新的 CUDA 环境中完成编译，以及让 xFormers 的安装不需要变动我们已经安装好的 Pytorch 或者 Numpy。

       环境准备

       环境的准备一共有两步，下载容器和 xFormers 源代码。

       Nvidia 容器环境

       在之前的 许多文章[4]中，我提过很多次为了高效运行模型，我推荐使用 Nvidia 官方的容器镜像（ nvcr.io/nvidia/pytorch:.-py3[5]）。

       下载镜像很简单，一条命令就行：

       完成镜像下载后，准备工作就完成了一半。

       准备好镜像后，我们可以检查下镜像中的新卡源码具体组件环境，使用docker run 启动镜像：

       然后，使用python -m torch.utils.collect_env 来获取当前环境的信息，方便后续完成安装后确认原始环境稳定：

       获取 xFormers

       下载 xFormers 的源代码，并且记得使用--recursive 确保所有依赖都下载完毕：

       xFormers 的源码包含三个核心组件cutlass、flash-attention、sputnik，除去最后一个开源软件在 xFormers 项目 sputnik 因为 Google 不再更新，被固定了代码版本，其他两个组件的版本分别为：cutlass@3.2 和 flash-attention@2.3.6。

       Dao-AILab/flash-attention[6]目前最新的版本是 v2.4.2，不过更新的主干版本包含了更多错误的修复，推荐直接升级到最新版本。在 v2.4.2 版本中，它依赖的 cutlass 版本为 3.3.0，所以我们需要升级 cutlass 到合适的opencascade源码下载版本。

       Nvidia/cutlass[7] 在 3.1+ 的版本对性能提升明显。

       不过如果直接更新 3.2 到目前最新的 3.4flash-attention 找不到合适的版本，会发生编译不通过的问题，所以我们将版本切换到 v3.3.0 即可。

       另外，在前文中提到了在安装 xFormers 的时候，会连带更新本地已经安装好的依赖。想要保护本地已经安装好的环境不被覆盖，尤其是 Nvidia 容器中的依赖不被影响，我们需要将xformers/requirements.txt 内容清空。

       好了，到这里准备工作就结束了。

       完成容器中的 xFormers 的安装

       想要顺利完成 xFormers 的构建，还有一些小细节需要注意。为了让我们能够从源码进行构建，满屏樱花源码我们需要关闭我们下载 xFormers 路径的 Git 安全路径检查：

       为了让构建速度有所提升，我们需要安装一个能够让我们加速完成构建的工具ninja：

       当上面的工具都完成后，我们就可以执行命令，开始构建安装了：

       需要注意的是，默认情况下安装程序会根据你的 CPU 核心数来设置构建进程数，不过过高的工作进程，会消耗非常多的内存。如果你的 CPU 核心数非常多，那么默认情况下直接执行上面的命令，会得到非常多的Killed 的编译错误。

       想要解决这个问题，我们需要设置合理的MAX_JOBS 参数。如果你的硬件资源有限，可以设置 MAX_JOBS=1，如果你资源较多，可以适当增加数值。我的构建设备有 G 内存，我一般会选择设置 MAX_JOBS=3 来使用大概最多 GB 的内存，来完成构建过程，MAX_JOBS 的构建内存消耗并不是完全严格按照线性增加的，当我们设置为 1 的时候，GB 的设备就能够完成构建、当我们设置为 2 的时候，使用 GB 的设备构建会比较稳妥，当设置到 4 的时候，构建需要的内存就需要 GB 以上了。

       构建的过程非常漫长，过程中我们可以去干点别的事情。

       当然，为了我们后续使用镜像方便，最好的方案是编写一个 Dockerfile，然后将构建的产物保存在镜像中，以方便后续各种场景使用：

       在构建的时候，我们可以使用类似下面的命令，来搞定既使用了最新的 Nvidia 镜像，包含最新的 Pytorch 和 CUDA 版本，又包含 xFormers 加速组件的容器环境。

       如果你是在本机上进行构建，没有使用 Docker，那么构建成功，你将看到类似下面的日志：

       等待漫长的构建结束，我们可以使用下面的命令，来启动一个包含构建产物的容器，来测试下构建是否成功：

       当我们进入容器的交互式命令行之后，我们可以执行python -m xformers.info，来验证 xFromers 是否构建正常：

       以及，使用python -m torch.utils.collect_env 再次确认下环境是否一致：

       最后

       好了，这篇文章就先写到这里啦。

JobScheduler的使用和原理

        JobScheduler主要用于在未来某个时间下满足一定条件时触发执行某项任务的情况，涉及的条件可以是网络、电量、时间等，例如执行特定的网络、是否只在充电时执行任务等。

        JobScheduler类负责将应用需要执行的任务发送给框架，以备对该应用Job的调度，是一个系统服务，可以通过如下方式获取：

        JobInfo是传递给JobScheduler类的数据容器，它封装了针对调用应用程序调度任务所需的各种约束，也可以认为一个JobInfo对象对应一个任务，JobInfo对象通过JobInfo.Builder创建。它将作为参数传递给JobScheduler：

        JobInfo.Builder是JobInfo的一个内部类，用来创建JobInfo的Builder类。

        JobService是JobScheduler最终回调的端点，JobScheduler将会回调该类中的onStartJob()开始执行异步任务。它是一个继承于JobService的抽象类，做为系统回调执行任务内容的终端，JobScheduler框架将通过bindService()方式来启动该服务。因此，用户必须在应用程序中创建一个JobService的子类，并实现其onStartJob()等回调方法，以及在AndroidManifest.xml中对它授予如下权限：

        注意在AndroidManifest.xml中添加权限

        当任务开始时会执行onStartJob(JobParameters params)方法，如果返回值是false，则系统认为这个方法返回时，任务已经执行完毕。如果返回值是true，那么系统认为这个任务正要被执行，执行任务的重担就落在了你的肩上。当任务执行完毕时你需要调用jobFinished(JobParameters params, boolean needsRescheduled)来通知系统。

        当系统接收到一个取消请求时，系统会调用onStopJob(JobParameters params)方法取消正在等待执行的任务。很重要的一点是如果onStartJob(JobParameters params)返回false，那么系统假定在接收到一个取消请求时已经没有正在运行的任务。换句话说，onStopJob(JobParameters params)在这种情况下不会被调用。

        需要注意的是这个Job Service运行在主线程，这意味着你需要使用子线程，handler，或者一个异步任务来运行耗时的操作以防止阻塞主线程。

        Google官方的Sample： /post/

技术人生阅读源码——Quartz源码分析之任务的调度和执行

       Quartz源码分析：任务调度与执行剖析

       Quartz的调度器实例化时启动了调度线程QuartzSchedulerThread，它负责触发到达指定时间的任务。该线程通过`run`方法实现调度流程，包含三个主要阶段：获取到达触发时间的triggers、触发triggers、执行triggers对应的jobs。

       获取到达触发时间的triggers阶段，通过`JobStore`接口的`acquireNextTriggers`方法获取，由`RAMJobStore`实现具体逻辑。触发triggers阶段，调用`triggersFired`方法通知`JobStore`触发triggers，处理包括更新trigger状态与保存触发过程相关数据等操作。执行triggers对应jobs阶段，真正执行job任务，先构造job执行环境，然后在子线程中执行job。

       job执行环境通过`JobRunShell`提供，确保安全执行job，捕获异常，并在任务完成后根据`completion code`更新trigger。job执行环境包含job对象、trigger对象、触发时间、上一次触发时间与下一次触发时间等数据。Quartz通过线程池提供多线程服务，使用`SimpleThreadPool`实例化`WorkerThread`来执行job任务，最终调用`Job`的`execute`方法实现业务逻辑。

       综上所述，Quartz通过精心设计的线程调度与执行流程，确保了任务的高效与稳定执行，展示了其强大的任务管理能力。