Les 700 instances pourraient-elles éventuellement s'exécuter simultanément?
Cela dépend de ce que vous entendez par simultanément. Si nous sommes pointilleux, alors non, ils ne peuvent pas sauf si vous avez 700 threads d'exécution sur votre système que vous pouvez utiliser (donc probablement pas). De manière réaliste, oui, ils le peuvent probablement, à condition que vous ayez suffisamment de RAM et / ou d'espace d'échange sur le système. UNIX et ses divers enfants sont remarquablement bons pour gérer d'énormes niveaux de simultanéité, c'est en partie pourquoi ils sont si populaires pour une utilisation HPC à grande échelle.
Jusqu'où pourrais-je aller jusqu'à ce que mon serveur atteigne sa limite?
Il est impossible de répondre concrètement sans beaucoup plus d'informations. À peu près, vous devez avoir suffisamment de mémoire pour répondre:
- La totalité de la mémoire requise pour l'exécution d'un travail, 700 fois.
- Les besoins en mémoire de bash pour gérer autant de tâches (bash n'est pas horrible à ce sujet, mais le contrôle des tâches n'est pas exactement efficace en mémoire).
- Tout autre besoin de mémoire sur le système.
En supposant que vous rencontriez cela (encore une fois, avec seulement 50 Go de RAM, vous devez toujours faire face à d'autres problèmes:
- Combien de temps CPU va être perdu par bash sur le contrôle des tâches? Probablement pas beaucoup, mais avec des centaines d'emplois, cela pourrait être important.
- De quelle bande passante réseau aura-t-elle besoin? L'ouverture de toutes ces connexions peut submerger votre réseau pendant quelques minutes en fonction de votre bande passante et de votre latence.
- Beaucoup d'autres choses auxquelles je n'ai probablement pas pensé.
Lorsque cette limite est atteinte, attendra-t-il simplement de commencer la prochaine itération hors de foo ou la boîte plantera-t-elle?
Cela dépend de la limite atteinte. S'il s'agit de mémoire, quelque chose va mourir sur le système (plus précisément, être tué par le noyau dans une tentative de libérer de la mémoire) ou le système lui-même peut se bloquer (il n'est pas rare de configurer des systèmes pour qu'ils se bloquent intentionnellement en cas de manque de mémoire). Si c'est le temps CPU, cela continuera sans problème, il sera tout simplement impossible de faire beaucoup d'autres choses sur le système. Si c'est le réseau, vous risquez de planter d' autres systèmes ou services.
Ce dont vous avez vraiment besoin ici, ce n'est pas d'exécuter tous les travaux en même temps. Au lieu de cela, divisez-les en lots et exécutez tous les travaux d'un lot en même temps, laissez-les terminer, puis démarrez le lot suivant. GNU Parallel ( https://www.gnu.org/software/parallel/ ) peut être utilisé pour cela, mais c'est loin d'être idéal à cette échelle dans un environnement de production (si vous y allez, ne soyez pas trop agressif, comme je l'ai dit, vous pourriez submerger le réseau et affecter des systèmes que vous ne toucheriez pas autrement). Je recommanderais vraiment de rechercher un outil d'orchestration réseau approprié comme Ansible ( https://www.ansible.com/), car cela résoudra non seulement vos problèmes de concurrence (Ansible effectue automatiquement le traitement par lots comme je l'ai mentionné ci-dessus), mais vous offre également de nombreuses autres fonctionnalités utiles (comme l'exécution idempotente des tâches, de beaux rapports d'état et l'intégration native avec un très grand nombre d’autres outils).
parallel
utilisant environ 50 emplois simultanés. C'est un excellent moyen entre le parallélisme de 1 et 700. L'autre chose intéressante est que c'est sans lot. Une seule connexion bloquée ne se bloquera que sur elle-même, pas sur les autres. Le principal inconvénient est la gestion des erreurs. Aucune de ces approches basées sur le shell ne gèrera correctement les erreurs. Vous devrez vérifier manuellement le succès vous-même et faire vos propres tentatives.