Kub*_*oMD 13 bash telnet jobs expect background-process
我需要使用期望脚本在 700 个网络设备上做一些工作。我可以按顺序完成，但到目前为止运行时间约为 24 小时。这主要是由于建立连接所需的时间以及这些设备（旧设备）的输出延迟。我能够建立两个连接并让它们并行运行就好了，但是我能推多远呢？
我不认为我可以一次完成所有 700 个，肯定有一些限制。我的 VM 可以管理的 telnet 连接数。
如果我确实尝试在这样的某种循环中启动其中的 700 个：
for node in `ls ~/sagLogs/`; do
foo &
done
和
CPU 12 个 CPU x Intel(R) Xeon(R) CPU E5649 @ 2.53GHz
内存 47.94 GB
我的问题是：
foo还是盒子会崩溃？不幸的是，我在公司生产环境中运行，所以我不能完全尝试看看会发生什么。
Aus*_*arn 17
所有 700 个实例可能同时运行吗？
这取决于你所说的并发是什么意思。如果我们很挑剔，那么不，他们不能，除非您的系统上有 700 个可以使用的执行线程（所以可能不会）。但实际上，是的，它们可能可以，只要您在系统上有足够的 RAM 和/或交换空间。UNIX 及其各种子类非常擅长管理大量并发，这也是它们在大规模 HPC 使用中如此受欢迎的部分原因。
在我的服务器达到极限之前我还能走多远？
如果没有更多信息，这是不可能具体回答的。差不多，你需要有足够的内存来满足：
假设您遇到了（同样，只有 50GB 的 RAM，您仍然需要处理其他问题：
当达到该限制时，它会等待从 foo 开始下一次迭代还是盒子会崩溃？
这取决于达到什么限制。如果是内存，系统上的某些东西会死掉（更具体地说，被内核杀死以试图释放内存）或者系统本身可能会崩溃（将系统配置为在内存不足时故意崩溃并不罕见）。如果是 CPU 时间，它会继续运行而不会出现问题，只是不可能在系统上做很多其他事情。如果是网络，您可能会崩溃其他系统或服务。
您在这里真正需要的是不要同时运行所有作业。相反，将它们分成批次，并同时运行批次内的所有作业，让它们完成，然后开始下一批。GNU Parallel ( https://www.gnu.org/software/parallel/ ) 可用于此目的，但在生产环境中以这种规模不太理想（如果您使用它，请不要太激进，就像我说的，你可能会淹没网络并影响你本来不会接触的系统）。我真的建议你研究一个合适的网络编排工具，比如 Ansible ( https://www.ansible.com/)，因为这不仅可以解决您的并发问题（Ansible 会像我上面提到的那样自动执行批处理），还可以为您提供许多其他有用的功能（例如任务的幂等执行、良好的状态报告以及与大量其他工具）。
lae*_*eio 12
很难具体说明有多少实例可以按照您描述的方式作为后台作业运行。但是一个普通的服务器当然可以保持700个并发连接，只要你做对了。网络服务器一直这样做。
我可以建议您使用 GNU 并行 ( https://www.gnu.org/software/parallel/ ) 或类似的东西来完成此操作吗？它会给您带来后台作业方法的许多优势：
看看这里的快速入门：https : //www.gnu.org/software/parallel/parallel_tutorial.html#A-single-input-source
Ole*_*nge 10
使用&并行处理是罚款做了几个时，当你监测进展情况。但是，如果您在企业生产环境中运行，则需要一些可以让您更好地控制的东西。
ls ~/sagLogs/ | parallel --delay 0.5 --memfree 1G -j0 --joblog my.log --retries 10 foo {}
这将运行foo在每个文件~/sagLogs。它每 0.5 秒启动一个作业，只要 1 GB RAM 空闲，它就会并行运行尽可能多的作业，但会遵守系统的限制（例如文件和进程的数量）。通常这意味着如果您没有调整允许打开的文件数，您将并行运行 250 个作业。如果调整打开文件的数量，并行运行 32000 应该没有问题——只要你有足够的内存。
如果作业失败（即返回错误代码），它将重试 10 次。
my.log 会告诉你一项工作是否成功（可能重试后）。