sort Befehl Status

Probiere doch mal deine Konfiguration erst mal einer kleinen Datei aus.

> 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.

Es ist gar nicht möglich einen Fortschritt anzuzeigen.
Wenn man wüsste, wie viel noch zu sortieren ist, dann wäre man ja 
fertig.

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.

Kernspaltung:

https://blog.mafr.de/2010/05/23/sorting-large-files/

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

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)

resort schrieb:
> 8.6 passt aber nicht zu 2010
>
> 8.26? ;)

8.6 passt schon.
https://savannah.gnu.org/forum/forum.php?forum_id=6553

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.