Hi
ich wollte bei einer 200GB großen txt Datei (auf einer über USB3.0
angeschlossenen Festplatte) doppelte Einträge entfernen und verwende
dazu den sort -u Befehl im Ubuntu SubSystem. Die Ausgabedatei wurde
sofort angelegt, allerdings ist sie bislang 0b groß - der Befehl läuft
sei 10 Stunden
Im Taskmanager wird bei sort eine durchschnittliche Auslastung von 13,5%
angezeigt und eine Festplattentransferrate von etwa 20MB/s
wird irgendwo eine temporäre Datei angelegt? Habe ich andere
Möglichkeiten zu sehen, wie lang der Vorgang noch dauern wird?
> 200GB großen txt Datei
Die Datei wird in handliche Chunks zerlegt, die werden sortiert
und dann wieder konkatiniert.
Wenn die Datei fertig sortiert ist, kannst du die SSD auf der
die Chunks angelegt werden, dem Rundordner zufuehren.
Viel schlauer waere es, die Datei z.B. nach den Anfangsbuchstaben
jeder Zeile, schon mal in Einzeldateien zu zerlegen und die
dann zu sortieren.
Evtl. sogar nach den beiden ersten Zeichen jeder Zeile.
Das sind "nur" 26*26 Dateien.
Das koennte deinem schwaechlichen Rechner entgegenkommen.
Gargamel schrieb:> wird irgendwo eine temporäre Datei angelegt? Habe ich andere> Möglichkeiten zu sehen, wie lang der Vorgang noch dauern wird?
In /proc/PID/fd/ stehen die offenen Files, auch strace liefert weitere
Infos.
c-hater schrieb:> Wenn man wüsste, wie viel noch zu sortieren ist, dann wäre man ja> fertig.
Naja, man kann die Worst-Case-Zeit berechnen und den aktuellen Stand
damit vergleichen. Bei Quicksort kann man die aktuelle Rekursionsstufe
mit der maximalen und der mittleren vergleichen, so kriegt man immerhin
einen ungefähren Bereich.
Ich würde die Datensätze in eine Datenbank überführen (z.B. PostgreSQL),
dann sind Sortieren und sonstige Operationen einfacher und
wahrscheinlich auch schneller.
Gargamel schrieb:> ich wollte bei einer 200GB großen txt Datei (auf einer über USB3.0> angeschlossenen Festplatte) doppelte Einträge entfernen und verwende
Baust Du Dir ein Wörterbuch für eine Brute Force Attacke? Wenn Du daran
schon scheiterst lass' es besser :-)
> wird irgendwo eine temporäre Datei angelegt? Habe ich andere
üblich irgendwo unterhalb /tmp oder falls definiert $TMPDIR
lsof -c sort
> Möglichkeiten zu sehen, wie lang der Vorgang noch dauern wird?
Eher nicht.
Jemand schrieb:> resort schrieb:>> Kernspaltung:>>>> https://blog.mafr.de/2010/05/23/sorting-large-files/>> Seit coreutils 8.6 (2010-10-15) kann GNU sort parallel arbeiten. Artikel> ist völlig obsolet
dann schreib ihm.
8.6 passt aber nicht zu 2010
8.26? ;)
Jo Kernspaltung mag man nicht mehr
---
>>> durchschnittliche Auslastung von 13,5%
kann man das nicht pushen?
Anzahl der threads erhöhen, wenn man noch was anderes machen will ggf.
in Kombination mit z.b. nice -19
hier grad geschaut; sort --version
sort (GNU coreutils) 8.26
man sort
--parallel=N
change the number of sorts run concurrently to N
Core GNU utilities for version 8.26, 24 November 2016
https://people.cs.clemson.edu/~jmarty/courses/LinuxStuff/BashGuides/GNU-CoreUtils-Manual.pdf
gnu coreutils
sort
‘--parallel=n’
Set the number of sorts run in parallel to n. By default, n is set to
the number of available processors, but limited to 8, as there are
diminishing performance gains after that. Note also that using n threads
increases the memory usage by a factor of log n. Also see Section 21.3
[nproc invocation], page 186.
---
aktuell wäre
https://www.gnu.org/software/coreutils/manual/coreutils.pdf
gleicher text
> ggf in Kombination mit z.b. nice -19
crap bevor gleich wieder einer aufschlägt, typo nicht minus 19:
nice -n 19 ... dann macht er Platz
Niceness values range from -20 (most favorable to the process)
to 19 (least favorable to the process)
Alonzo Mutex schrieb:> Das Problem wird wohl eher das lahme USB sein. Da nützen n Threads auch> nix wenn die um die Wette auf die Daten warten.
die temporären Dateien von sort lassen sich mit "-T /irgendwo" auf einen
schnelleren Speicher verlagern.
Und wenn dann immer noch das Temp-File Disk-I/O limitierend ist, kann
man mit "--compress-program=gzip" deren Größe auf ca. 1/8 (bei Text)
reduzieren.
Ich wuerd das Maximum an Hauptspeicher verwenden zum Vorsortieren. Also,
die 200 GB in Kloetzen von zB 20GByte oder so in den Hauptspeicher
laden, und mit einem Quicksort drueber. Dann zurueck auf die Platte. Das
waeren dann 20 solche Blocke. Nachher mit einem Mergesort die 20 offenen
Streams zusammenfuegen. Ich denke, ein paar 10 Minuten sollten genuegen.
Das Limitierende wird die Datentransferrate der disk sein. zB 200
MByte/sek. Der Vorgang ist im Wesentlichen 200 GB linear Lesen, linear
Schreiben, random Lesen, linear Schreiben - Fertig. Allenfalls eine
Stunde.
Die Laufzeit hängt von verschiedenen Parametern ab; bei HDDs dürfte IO
der Engpass sein (sowohl IO der Quell/Zieldatei als auch IO für
temporäre Dateien). 20 MB/s hört sich nicht gut an: USB 2 statt 3 Port;
NTFS; .... ?!
Die übrigen Parameter sind Sortierkriterium, Threads, zugewiesener
Speicher (sort_size) und Chunk Size (nmerge).
https://github.com/coreutils/coreutils/blob/master/src/sort.c
Die Defaults sind konservativ (was u.a. zu mehr als einen Merge Lauf
führen kann und damit zuätzliche IO). Die Werte können erhöht/optimiert
werden. (siehe man page)
Den aktuellen Stand kannst du im $TMPDIR Verzeichnis sehen (wo für jeden
Chunk -- vor dem Merge -- eine separate Datei erzeugt wird).
20 MB/s und 13,5% CPU deuten auf einen IO Engpass. Monitoring kann u.a.
mit iostat durchgeführt werden.
