我们经常被问到，Qube! 的全部或部分组件能否自动更新，例如：
Qube! Supervisor 自动升级渲染农场中全部或部分 Worker
客户端具备“检查更新”功能
遗憾的是，简短的回答是“目前还不能”。
这已列入我们的路线图，并应在未来的 Qube! 版本中提供。
Worker 可执行文件带有一个 --console 参数，允许从命令行启动的 Worker 向另一个用户账户进行身份验证，就像它以服务方式运行时那样。
在 Windows 上，默认的“本地安全策略”通常会阻止这一操作，因此为了让用户能够运行“控制台 Worker”，必须授予以下用户权限分配：
一旦将这些用户权限分配（URA）授予该用户，如果该用户当前已登录，则必须登出并重新登录，以便新的 URA 生效。
这是问题少数客户提出过，但并不常见。
Supervisor
在发生硬件故障时，替换的硬件需要将其 MAC 地址映射到 Supervisor，因此，保留一台冷备与向 PipelineFX 申请替换许可证之间的差别可以忽略不计。如果计划是在热备上同时保留硬件和 Qube! Supervisor，那么你需要将备用和生产环境的 Supervisor 一起升级，以免两者不同步。与此同时，你还需要确保数据库和资产能够立即供这对热备的硬件/软件使用。这并不是常见做法，也不是我们客户经常提出的需求，因此按照行业惯例，我们不提供此项服务。
worker
Worker 基本上可以部署在任何硬件上，几乎没有例外。因此，备用机并不需要，也无需担心。针对非常短期的许可证需求，我们提供按天、按月或按年租用 Worker 许可证的选项。此外，你还可以使用计量授权（Metered Licensing）来突发超出当前容量，并且只需为实际用量付费。
影响 Supervisor 线程池大小的参数
Supervisor 的线程数旨在随需求的瞬时高峰而增加，随后再回落。直接影响 Supervisor 线程数量的三个参数是：
Supervisor线程池大小行为
supervisor_max_threads 和 supervisor_idle_threads 设定 Supervisor 进程池大小的上限和下限，而 supervisor_max_clients 影响单个 Supervisor 进程的生命周期长度，从而间接影响需求高峰过后进程池收缩的速度。
当有请求进来时，主 Supervisor 进程会在进程池中查找空闲进程。如果有空闲线程，就将请求分配给它；但如果没有空闲进程，就会再启动一个 Supervisor 进程，将其加入 Supervisor 线程池，并分配该请求。
supervisor_max_clients 通过设定单个线程在退出前将处理的事务数量，间接影响现存线程的数量。一旦某个 Supervisor 进程处理完一个请求，它就会检查自己的 supervisor_max_clients 值；如果它尚未处理这么多请求，就会进入空闲状态，等待下一个请求，否则就会退出。
将 supervisor_max_clients 设置为较低的值，会使线程数在瞬时需求高峰过后下降得稍快一些，但代价是可能产生过多的线程创建——这是在可用内存与进程创建开销之间的一种平衡。
启动新的 Supervisor 线程
当所有 Supervisor 进程都在忙于处理事务（可能只是因为某个耗时操作卡在数据库那一环），而此时又有新的请求进来，主 Supervisor 线程就会再启动一个线程，直到达到 supervisor_max_threads 的值。
当线程池持续处于上限时
当进程数量达到上限并持续一段时间，就说明 Supervisor 主机的配置存在性能问题。
当你看到这种行为时，增加 supervisor_max_threads 的数量就像提高信用卡额度；以小幅增量逐步提高可能是合适的，以观察主机是否能够处理额外的进程，但到某个点，进程数会达到一个临界点，此时更多的 Supervisor 进程反而会让问题更糟，所以如果你把进程数画成图，你会看到它逐渐上升，然后曲线几乎垂直向上。
此时，你可能需要向 PipelineFX 提交支持工单，以进一步排查任何性能瓶颈。
