我们是微软公司环境中的一个小团队。我们的核心任务是运行一组大约 100 次内部工具的独立运行。每次运行都有一个输入文件和多个输出文件，单个作业的运行时间约为一小时（作业是单线程的，但经过大量优化：单个作业的运行时间不会减少）。
我们正在寻找一种方法将这些运行分配到可用的 CPU 内核，以将整套运行的挂钟时间缩短至一小时（即单个作业的运行时间）。
我们完美的设置可能是这样的：
- 简单安装工作客户端（如果有），让用户可以轻松地让自己的工作站加入队列。
- 工作者可以动态加入池（具有指定数量的核心）
- 实时作业队列操作，包括添加和取消作业
有很多作业调度系统，但大多数似乎比我们需要的复杂得多（作业依赖性、重复作业等）。这可能不是问题——但在所有这些复杂性中，很难找出哪些系统符合我们的需求。您是否有使用满足我们需求的现有系统的经验？
我还考虑过一个简单的工作守护进程来监视网络驱动器上的作业文件。你有使用这种方法的经验吗？
答案1
如果不知道内部工具在做什么，我不确定如何回答这个问题。是什么让它变慢了？瓶颈在哪里？作业运行有多独立，作业的每个部分有多独立，以便可以分解？应用程序是否已经是多线程的，或者支持多线程以利用系统上的内核？
您可能希望分析应用程序以了解瓶颈所在，然后集中精力对其进行重构。对执行该任务的应用程序进行小幅更改可能会产生巨大的效果。
如果不知道任务是什么以及速度变慢的原因，就很难知道如何拆分批处理任务。如果不知道如何拆分任务流程，您可能必须确定最大的瓶颈是什么，并向其投入更多硬件（更快的磁盘子系统、更多内存、更快的处理器……）
编辑 - 如果这些是完全独立的作业，那么可能值得考虑一下您的瓶颈是否仅仅是序列化，也许您可以在虚拟服务器上运行它们，或者在类似 Amazon 的“云”实例中运行它们，或者获得一组运行作业并将它们提交回主程序的廉价系统。我只是不确定您是否应该考虑如何将这种支持构建到您的内部应用程序中，而不是尝试使用某种外部作业调度程序。