Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Ich versuche, einen Job auszuführen
Im folgenden Abschnitt finden Sie mögliche Lösungen zur Problembehandlung, falls Sie beim Versuch, einen Job auszuführen, auf Probleme stoßen.
## `srun`Der interaktive Job schlägt mit einem Fehler fehl `srun: error: fwd_tree_thread: can't find address for , check slurm.conf`
+ **Warum ist es gescheitert?**
Sie haben den `srun` Befehl zum Senden eines Jobs ausgeführt und dann die Größe einer Warteschlange erhöht, indem Sie den `pcluster update-cluster` Befehl verwendet haben, ohne die Slurm Daemons nach Abschluss des Updates neu zu starten.
Slurmorganisiert Slurm Daemons in einer Baumhierarchie, um die Kommunikation zu optimieren. Diese Hierarchie wird nur aktualisiert, wenn die Daemons starten.
Angenommen`srun`, Sie starten einen Job und führen dann den `pcluster update-cluster` Befehl aus, um die Warteschlange zu vergrößern. Neue Rechenknoten werden im Rahmen des Updates gestartet. Stellt Ihren Job dann in eine Slurm Warteschlange auf einen der neuen Rechenknoten. In diesem Fall erkennen sowohl die Slurm Daemons als auch die neuen Rechenknoten `srun` nicht. `srun`gibt einen Fehler zurück, weil die neuen Knoten nicht erkannt werden.
+ **Wie löst man das Problem?**
Starten Sie die Slurm Daemons auf allen Rechenknoten neu und verwenden Sie sie dann, `srun` um Ihren Job einzureichen. Sie können den Neustart der Slurm Daemons planen, indem Sie den `scontrol reboot` Befehl ausführen, der die Rechenknoten neu startet. Weitere Informationen finden Sie in der Dokumentation unter [scontrol reboot](https://slurm.schedmd.com/scontrol.html#OPT_reboot). Slurm Sie können die Slurm Daemons auf den Rechenknoten auch manuell neu starten, indem Sie einen Neustart der entsprechenden Dienste anfordern. `systemd`
## Der Job steckt im `CF` Status mit dem `squeue` Befehl fest
Dies könnte ein Problem beim Einschalten dynamischer Knoten sein. Weitere Informationen finden Sie unter [Fehler bei der Initialisierung von Rechenknoten werden angezeigt](troubleshooting-fc-v3-compute-node-initialization-v3.md).
## Großaufträge ausführen und sehen `nfsd: too many open connections, consider increasing the number of threads in /var/log/messages`
Wenn bei einem Netzwerkdateisystem die Netzwerkgrenzen erreicht werden, erhöht sich auch die I/O Wartezeit. Dies kann zu leichten Blockups führen, da das Netzwerk zum Schreiben von Daten sowohl für Netzwerke als auch für I/O Messdaten verwendet wird.
Bei Instances der 5. Generation verwenden wir den ENA-Treiber, um Paketzähler verfügbar zu machen. Diese Zähler zählen die Pakete, die dadurch AWS geformt werden, dass das Netzwerk die Bandbreitenlimits der Instanz erreicht. Sie können diese Zähler überprüfen, um festzustellen, ob sie größer als 0 sind. Wenn dies der Fall ist, haben Sie Ihre Bandbreitenlimits überschritten. Sie können sich diese Zähler anzeigen lassen, indem Sie den Befehl ausführen`ethtool -S eth0 | grep exceeded`.
Eine Überschreitung der Netzwerkgrenzen ist häufig darauf zurückzuführen, dass zu viele NFS-Verbindungen unterstützt werden. Dies ist eines der ersten Dinge, die Sie überprüfen sollten, wenn Sie Netzwerkgrenzen erreichen oder überschreiten.
Die folgende Ausgabe zeigt beispielsweise gelöschte Pakete:
```
$ ethtool -S eth0 | grep exceeded
bw_in_allowance_exceeded: 38750610
bw_out_allowance_exceeded: 1165693
pps_allowance_exceeded: 103
conntrack_allowance_exceeded: 0
linklocal_allowance_exceeded: 0
```
Um diese Meldung zu vermeiden, sollten Sie erwägen, den Instanztyp des Hauptknotens in einen leistungsfähigeren Instanztyp zu ändern. Erwägen Sie, Ihren Datenspeicher in Dateisysteme mit gemeinsam genutztem Speicher zu verschieben, die nicht als NFS-Freigabe exportiert werden, z. B. Amazon EFS oder Amazon FSx. Weitere Informationen finden Sie unter [Gemeinsamer Speicher](shared-storage-quotas-integration-v3.md) und die [Best Practices](https://github.com/aws/aws-parallelcluster/wiki/Best-Practices) im AWS ParallelCluster Wiki unter GitHub.
## Einen MPI-Job ausführen
### Debug-Modus aktivieren
Informationen zum Aktivieren des OpenMPI-Debug-Modus finden Sie unter [Welche Steuerelemente hat Open MPI, die beim Debuggen helfen](https://www-lb.open-mpi.org/faq/?category=debugging#debug-ompi-controls).
[Informationen zum Aktivieren des IntelMPI-Debug-Modus finden Sie unter Andere Umgebungsvariablen.](https://www.intel.com/content/www/us/en/develop/documentation/mpi-developer-reference-linux/top/environment-variable-reference/other-environment-variables.html)
### Anzeige `MPI_ERRORS_ARE_FATAL` und `OPAL ERROR` in der Jobausgabe
Diese Fehlercodes stammen aus der MPI-Schicht in Ihrer Anwendung. Informationen zum Abrufen von MPI-Debug-Logs aus Ihrer Anwendung finden Sie unter. [Debug-Modus aktivieren](#run-job-mpi-enable-v3)
Eine mögliche Ursache für diesen Fehler ist, dass Ihre Anwendung für eine bestimmte MPI-Implementierung wie OpenMPI kompiliert wurde und Sie versuchen, sie mit einer anderen MPI-Implementierung wie IntelMPI auszuführen. Stellen Sie sicher, dass Sie Ihre Anwendung mit derselben MPI-Implementierung kompilieren und ausführen.
### Verwendung mit `mpirun` deaktiviertem verwaltetem DNS
Bei Clustern, die mit [SlurmSettings](Scheduling-v3.md#Scheduling-v3-SlurmSettings)der Einstellung [DisableManagedDns](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-DisableManagedDns)/Dns/ und [UseEc2Hostnames](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-UseEc2Hostnames) auf erstellt wurden`true`, wird der Slurm Knotenname nicht vom [DNS](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Dns) aufgelöst. Slurmkann MPI-Prozesse booten, wenn sie `nodenames` nicht aktiviert sind und wenn der MPI-Job in einem Kontext ausgeführt wird. Slurm Wir empfehlen, die Anweisungen im [MPI-Benutzerhandbuch zur Ausführung von Slurm MPI-Jobs](https://slurm.schedmd.com/mpi_guide.html) mit zu befolgen. Slurm