Ich bin ein Benutzer eines Clusters, der NFS für unsere Datenspeicheranforderungen verwendet. Vor kurzem habe ich eine Pipeline ausgeführt, die bei einigen Vorgängen sehr hohe E/A-Werte aufweist.
Das Programm, das unserer Meinung nach das Problem verursacht, heißt Bowtie und ist ein Aligner in bioinformatischen Pipelines. Kurz gesagt haben wir alphabetische Sequenzen in fragmentierten Dateien mit 1 Million Zeilen pro Datei, die mit einer anderen Datei verglichen werden, die das gesamte Wörterbuch enthält. (Dies ist eine Vereinfachung des Algorithmus.)
Dieses Wörterbuch wird während des Vorgangs im Speicher abgebildet. Ich habe Rechte zur Warteschlangenübermittlung an drei Knoten im Cluster.
Knoten: Knoten1 Knoten2 Knoten3 Knoten4 Knoten5 Knoten6 Knoten7
Meine Rechte: Knoten1 Knoten2 Knoten3
Anzahl der mir zur Verfügung stehenden Prozessoren: 128 Prozessoren oder 128 laufende Warteschlangenplätze.
Für die Ausführung im Cluster wird die Hauptdatei in Blöcke mit jeweils 1 Million Zeilen aufgeteilt und anschließend alle Jobs mit SGE gestartet.
Das Wörterbuch wird an dieser Stelle in den Speicher auf jeden Knoten geladen, d. h. Knoten 1, 2 und 3.
Für jeden aktiven Job im Warteschlangenslot habe ich die folgenden Dateihandler geöffnet
1 Job-Datei mit dem auszuführenden Code 1 Code-Datei mit dem Exit-Code des Prozesses 1 von SGE generierte STDOUT-Datei 1 von SGE generierte STDERR-Datei 1 Dateiblock 1 Ausgabedatei
Das bedeutet, dass ich während dieses Vorgangs 768+3 Filehandler auf dem Remote-Datenspeicher geöffnet habe, wobei die ersten vier Dateien für jedes einzelne Skript in der Pipeline konstant sind.
Immer wenn dies geschieht, stürzt der NFS-Server auf dem Datenspeicher ab und unser gesamter Cluster fällt aus, weil der Speicher nicht mehr reagiert.
Unser IT-Personal hat darauf hingewiesen, dass dies möglicherweise an der hohen E/A-Auslastung während dieses Vorgangs liegt und dass NFS möglicherweise nur für kleine Cluster und nicht für große gedacht ist.
Daher haben wir uns für eine Lösung entschieden, bei der wir diesen Prozess auf einem der Knoten selbst ausführen möchten. Dann wäre es allerdings nicht mehr sinnvoll, einen Cluster zur Verfügung zu haben, da wir auf die Festplatte des Knotens schreiben würden und nicht auf den von allen Clustern gemeinsam genutzten Datenspeicher.
Ich kann nicht glauben, dass NFS für kleine Cluster entwickelt wurde und nie erfolgreich in großen Unternehmenslösungen implementiert wurde. Kann es einen anderen Grund dafür geben, dass NFS die Netzwerkverbindung plötzlich abbricht?
Ich bin sicher, dass der fragliche Prozess die Ursache für das Einfrieren des Clusters ist, aber ich bin nicht überzeugt, dass die erforderliche Lese-/Schreibgeschwindigkeit die Ursache für den Fehler ist. Hat jemand von Ihnen schon einmal ein solches Problem gehabt? Ist eine vollständige Protokollmigration die einzige Lösung, die wir haben?
Antwort1
Einige im Laufe der Jahre gelernte Vorschläge.
- Minimieren Sie die Belastung des NFS-Servers:
NFS-Exportoptionen festlegen:async,insecure,no_subtree_check
NFS-Mount-Optionen festlegensoft,noatime,nodiratime,nolock,vers=3
auch eingestellt: noatime,nodiratimebei Daten-/Temporär-/Scratch-Mounts. Stellen Sie sicher, dass die NFS-Verschlüsselung ausgeschaltet ist, um die Belastung zu reduzieren. Stoppen Sie den NFS-Sperrvorgang.
Versuchen Sie, die JUMBO-Frames für das Netzwerk auf allen Hosts zu aktivieren (sofern von der Netzausrüstung unterstützt) – stellen Sie die MTU auf etwa 9k ein.
Stellen Sie sicher, dass der RAID10-Speicher für zufällige Schreib-E/A verwendet wird (vermeiden Sie RAID5/6 um jeden Preis). Gibt es SSDs?
Maximieren Sie die Anzahl der geöffneten FS-Handles (der Standardwert liegt bei einigen Systemen bei 2 KB) und stellen Sie ihn auf etwa 1 MB ein.
Besteht die Möglichkeit, die Mapping-Datenbank mit den Eingabedaten in den lokalen Scratch-Node-Speicher zu kopieren und die resultierenden SAM-Dateien dann in einem separaten Schritt zu kombinieren/sortieren?
Erhöhen Sie die Größe des verarbeiteten Blocks (so dass er mindestens 30 Minuten oder länger verarbeitet wird).
Wenn möglichAufteilung der Jobs auf höchstem Niveau(Versuchen Sie, 10 separate Genome/Proben auf 10 verschiedenen Knoten parallel abzubilden/sortieren, anstatt zu versuchen, jedes Genom nacheinander mithilfe von 10 Hosts abzubilden.) Versuchen Sie Checkpoints zu setzen, nachdem alle Prozesse abgeschlossen sind.
Ändern Sie eine Programmquelle, sodass sie Daten in größeren Blöcken liest – etwa 1 MB statt 4 K.
Beachten Sie die CPU/RAM-Verbindungskonflikte (insbesondere bei AMD-Systemen mit 4-8 Sockeln). Manchmal ist das Ausführen von 12-24 Threads auf einer 48-Core-Box viel schneller als das Ausführen von 48 Threads. Probieren Sie verschiedene Auslastungsstufen aus. Stellen Sie sicher, dass NUMA aktiviert und für Multi-CPU-Systeme konfiguriert ist. Kompilieren Sie mit aktiviertem NUMA neu.
PS: Die Verwaltung eines effizienten Clusters ist vergleichbar mit der Planung/Verwaltung einer Baustelle mit mehr als 1.000 Arbeitern …