torchx.schedulers

TorchX Schedulers定义插件以与现有调度器兼容。使用 runner，它们将组件作为任务提交到 相应的调度器后端。TorchX支持一些内置的< a data-trkey="2">schedulers。您可以通过实现.. py:class::torchx.schedulers和 registering它在入口点来添加自己的。

Scheduler 函数

torchx.schedulers.get_schedulers(session_name: str, **scheduler_params: object) → Dict[str, torchx.schedulers.api.Scheduler]

get_schedulers 返回所有可用的调度器。

torchx.schedulers.get_scheduler_factories() → Dict[str, torchx.schedulers.SchedulerFactory]

get_scheduler_factories 返回所有可用的调度器名称和实例化它们的方法。

字典中的第一个调度器作为默认调度器使用。

torchx.schedulers.get_default_scheduler_name() → str

默认的 scheduler_name 返回在 get_scheduler_factories 中定义的第一个调度器。

Scheduler 类

class torchx.schedulers.Scheduler(backend: str, session_name: str)

一个抽象调度器功能的接口。 实现者只需要实现那些带有 @abc.abstractmethod注释的方法。

cancel(app_id: str) → None

取消/杀死应用程序。此方法在同一个线程内是幂等的，并且可以在同一应用程序上多次安全调用。然而，当从同一应用程序上的多个线程/进程中调用时，此方法的确切语义取决于底层调度器API的幂等性保证。

注意

这个方法不会阻塞应用程序到达取消状态。为了确保应用程序达到终端状态，请使用wait API。

close() → None

仅适用于具有本地状态的调度器！关闭调度器，释放任何分配的资源。一旦关闭，调度器对象被认为不再有效，对该对象调用的任何方法都会导致未定义行为。

此方法不应抛出异常，并且允许对同一对象多次调用。

注意

仅针对具有本地状态的调度程序实现进行重写 (torchx/schedulers/local_scheduler.py). 简单地封装远程调度程序客户端的调度程序无需实现此方法。

abstract describe(app_id: str) → Optional[torchx.schedulers.api.DescribeAppResponse]

描述指定的应用程序。

Returns

应用程序定义描述或 None 如果应用程序不存在。

exists(app_id: str) → bool

Returns

True 如果应用程序存在（已提交），False 否则

log_iter(app_id: str, role_name: str, k: int = 0, regex: Optional[str] = None, since: Optional[datetime.datetime] = None, until: Optional[datetime.datetime] = None, should_tail: bool = False) → Iterable[str]

返回一个迭代器，用于获取满足条件的日志行。k``th replica of the ``role。 迭代器在所有符合条件的日志行都被读取后结束。

如果调度程序支持基于时间指针获取日志行，则since，until字段会被遵循，否则会被忽略。不指定since和until相当于获取所有可用的日志行。如果until为空，则迭代器的行为就像tail -f一样，跟随日志输出直到作业达到终端状态。

日志的确切定义取决于调度程序的具体设置。有些调度程序可能会将标准错误或标准输出视为日志，而其他调度程序则可能从日志文件中读取日志。

行为和假设：

1. 如果在不存在的应用程序上调用此方法，会产生未定义行为。 调用者应在调用此方法之前使用exists(app_id)检查应用程序是否存在。

2. 不是有状态的，用相同的参数调用此方法两次 会返回一个新的迭代器。之前的迭代 进度会丢失。

3. 不一定始终支持日志追尾功能。并非所有调度器都支持实时日志迭代（例如，在应用程序运行时追尾日志）。有关迭代器的行为，请参阅特定调度器的文档。

3.1 If the scheduler supports log-tailing, it should be controlled

by``should_tail``参数。

4. 不保证日志保留。调用此方法时，底层调度程序可能已经清除了该应用程序的日志记录。如果是这样的话，此方法将引发任意异常。

5. 如果 should_tail 为 True，该方法仅在可访问的日志行已完全耗尽且应用程序达到最终状态时抛出 StopIteration 异常。 例如，如果应用程序卡住且没有生成任何日志行，则迭代器会阻塞直到应用程序最终被终止（通过超时或手动操作），此时它会抛出一个 StopIteration 异常。

   如果 should_tail 是 False，该方法在没有更多日志时抛出 StopIteration。

6. 不一定由所有调度器支持。

7. 某些调度器可能通过支持 __getitem__ （例如，iter[50] 寻找第 50 行日志）来支持行光标。

Returns

一个指定角色副本的日志行上的 Iterator

Raises

NotImplementedError – 如果调度器不支持日志迭代

run_opts() → torchx.specs.api.runopts

返回调度程序所期望的运行配置选项。 基本上是--help的run API。

abstract schedule(dryrun_info: torchx.specs.api.AppDryRunInfo) → str

与 submit 相同，但接受一个 AppDryRunInfo。 建议实现者实现此方法而不是直接实现 submit，因为 submit 可以通过以下方式简单地实现：

dryrun_info = self.submit_dryrun(app, cfg)
return schedule(dryrun_info)

submit(app: torchx.specs.api.AppDef, cfg: torchx.specs.api.RunConfig) → str

提交应用程序给调度器运行。

Returns

提交应用程序的唯一标识符。

submit_dryrun(app: torchx.specs.api.AppDef, cfg: torchx.specs.api.RunConfig) → torchx.specs.api.AppDryRunInfo

而不是提交运行应用程序的请求，返回将要提交给底层服务的请求对象。请求对象的类型取决于调度器。此方法可用于模拟应用程序。请参阅调度器实现文档以获取实际返回类型。

class torchx.schedulers.SchedulerFactory(*args, **kwargs)