schrecklicher Titel, und ich werde aktualisieren, wenn eine effektivere Frage vorgeschlagen werden kann. Die Pipeline ist in NextFlow geschrieben und verwendet Slurm für das Jobmanagement. Ursprünglich würde FastQC 5-30 Minuten benötigen, um auf einem Satz von Proben zu laufen. Nachdem die Updates jedoch eine deutlich größere Aufgabeparallelisierung ermöglichten, benötigt FastQC nun bis zu 15 Stunden. < /P>
Die Jobs sterben nicht, sie scheitern nicht, sie hängen einfach nicht wirklich rennen. Dies scheint während der Dateilesung vorhanden zu sein (basierend auf den Protokolldateien von FASTQC). Reduzieren Sie die Slurm -Allokation und die Laufzeiten kommen zurück, erhöhen Sie die Zuteilungen und Laufzeiten steigen. Wir haben die Auswirkungen auf die gleichen und verschiedenen Probensätze gezeigt. Zugewiesene RAM, und es wird nie über 50% CPU -Verwendung gehen (Fastqc ist einsthread, wir haben 2 nur zugeteilt, um sicher zu sein). Server und für den Benutzer - keine Auswirkung. /> OpenJDK-Laufzeitumgebung (Build 21-intern-adhoc.conda.src)
OpenJDK 64-Bit-Server VM (Bauung 21-intern-Adhoc.conda.src, gemischter Modus, Sharing) < /p>
Update 1 < /H1> < /H1> < /
FASTQC -Befehl: < /p>
fastqc --nogroup -f fastq --threads $cpus -o /my/drive/my/path/ fastq_R1.fastq.gz fastq_R2.fastq.gz
[/code]
Fastqc -Stallung unter starker Systemlast (JRE/JVM -Ausgabe) [geschlossen] ⇐ Java
-
- Similar Topics
- Replies
- Views
- Last post