Optimierung der Du-Berichte über Petabyte-Datensätze?
322
Jules Kerssemakers
Ich versuche, täglich einen Bericht über die Dateigröße eines Datensatzes mit mehreren Petabytes an Genomdaten zu erhalten. Unser aktueller Bericht verwendet mehrere überlappende duAufrufe, um das Ergebnis zu erzielen. Die Ausführung dauert jedoch über 24 Stunden. Ich suche nach einer Möglichkeit, dies effizienter / schneller / "sauberer" zu machen.
derzeit machen wir:
# broad overview of dozens of projects + grand total du -chd1 /petastorage/projects/ # detailed look at some 'special' projects, # each of these has huge sub-dirs we want to track individually du -hd1 /petastorage/projects/special_project_A/ du -hd1 /petastorage/projects/special_project_B/ du -hd1 /petastorage/projects/special_project_C/
Was mich stört ist, dass special_project_[ABC]zwei mal gecrawlt werden, einmal in der Gesamtsumme, einmal für den detaillierten Blick. Da diese speziellen Projekte einen großen Teil der Daten ausmachen, ist das zweifache Durchforsten (Warnung: Annahme) wahrscheinlich ein erheblicher Teil der Laufzeit. Da wir hier von Petabytes sprechen, glaube ich nicht, dass das Zwischenspeichern von Dateisystemen die Wiederholungsaufrufe beschleunigen wird.
Ich habe versucht, "zu optimieren", du -d1 /petastorage/projects/ /petastorage/projects/special_project_[ABC]/ aber es scheint duklug genug zu sein, um zu erkennen, dass Spezialprojekte untergeordnete Verzeichnisse des ersten Verzeichnisses sind, und "optimiert" sie somit aus dem Berichtswesen heraus. Gah!
Hat jemand eine Idee, wie ich überzeugen kann du, meine Petabytes nur einmal zu crawlen, und zwar sowohl alle Projekte einzeln als auch die (um eine Ebene tiefer liegende) Detailansicht der drei Spezialprojekte ausgeben.
Hinweis: Das aktuelle Du-Output wird bereits durch eine Art / Uniq-Pipeline durchlaufen, um die Anzeige im E-Mail-Bericht übersichtlicher und ohne Duplikate zu machen. Daher sind Lösungen mit Nachbearbeitung akzeptabel. Jede Nachbearbeitungslaufzeit ist null im Vergleich zu Petabytes von rotierendem Rost.
Hintergrund, falls es darauf ankommt: Dies ist ein NFSv3-Mount für EMC-isilon-Storage-Nodes, der unter OpenSuse 11.4 bereitgestellt wird. Alle Projekte teilen derzeit einen einzigen Speicherpool auf den Isilonen, sodass freier Speicherplatz zwischen Projekten verschoben werden kann. Die "speziellen" Projekte in ihre eigenen Dateisysteme zu verschieben, damit wir "betrügen" können, dfist aufgrund ihrer Größe nicht machbar.
2 Antworten auf die Frage
0
Jules Kerssemakers
Nachdem wir ein oder zwei Tage mit diesem Thema verbracht hatten, entschlossen wir uns, den einfachen Weg zu gehen und nicht weiter zu optimieren. Am Ende ist die Entwicklungszeit teurer als die Skriptlaufzeit.
Wenn / Wenn ich auf dieses Problem zurückkomme, werde ich wahrscheinlich einen duDurchlauf für die Unterprojekte, einen zweiten duDurchlauf für die großen Ordner (mit einem --excludedurch die ersten abgedeckten Projekten) durchführen und die Gesamtsumme gemeinsam in der Post berechnen -Verarbeitung (judidicious Verwendung awk, sedoder grep | paste -sd'+' | bcsollte ausreichen)
Wenn noch jemand bessere Ideen hat, würde ich mich freuen, sie zu hören :-)
0
Jules Kerssemakers
Um es zu berichten, sind wir seitdem die "unlösbare" Route als Teil einer größeren Umgestaltung unseres Speichers gegangen.
Unsere neuen Dateiserver unterstützen ein Kontingent pro Sub-Mount. Daher haben wir im Laufe der Zeit Projekte in Sub-Mounts extrahiert, anstatt "normale" Ordner in einem großen, gemeinsam genutzten Dateisystem / Mount. Dies war ein Back-Burner-Migrationsprojekt über mehrere Wochen / Monate. Dies hat es uns ermöglicht, Quota auf alle gewünschten "Ordner" zu setzen.
Wir fragen jetzt den Kontingentstatus ab (der live und sofort von den Dateiservern verwaltet wird).