Hallo, damit ich mein neues System testen kann, habe ich mir mal eine Verzeichnisstruktur mit ca. 23.000 Dateien drauf kopiert. Das sind gute 13GB gemischte Daten jeglicher Couleur. Dann habe ich mal folgenden Befehl abgesetzt: time find /mnt/* -type f -exec grep -iH "suchbegriff" {} \; Die Ausführung habe ich dann nach ca. 30 min abgebrochen, da der gleiche Befehl, mit dem gleichen Dateibaum, auf einem 10 Jahre alten System "nur" 6 Minuten braucht. Da das neue System SSD-Platten in einem RAID1-Verbund hat, dachte ich sofort, es würde daran liegen. Dagegen spricht allerdings, dass z.B. eine Dateisuche in dem Verzeichnisbaum time find /mnt/* -name "*suchbegriff*" gerade mal 0,3 dauert. Und selbst ein komplettes kopieren des Baumes dauert ja auch "nur" 3 Minuten. Okay, der Prozessor, ein Atom D525, ist nicht gerade der Heuler, aber ich habe mal mit dem Systemmonitor drauf geguckt und der ist nicht permanent am Limit bei diesem Befehl. Was ist das denn bitte schon wieder? -- Herzliche Grüße Tao -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Tao te Puh schrieb:
Hallo,
damit ich mein neues System testen kann, habe ich mir mal eine Verzeichnisstruktur mit ca. 23.000 Dateien drauf kopiert. Das sind gute 13GB gemischte Daten jeglicher Couleur.
Dann habe ich mal folgenden Befehl abgesetzt:
time find /mnt/* -type f -exec grep -iH "suchbegriff" {} \;
Die Ausführung habe ich dann nach ca. 30 min abgebrochen, da der gleiche Befehl, mit dem gleichen Dateibaum, auf einem 10 Jahre alten System "nur" 6 Minuten braucht.
Da das neue System SSD-Platten in einem RAID1-Verbund hat, dachte ich sofort, es würde daran liegen. Dagegen spricht allerdings, dass z.B. eine Dateisuche in dem Verzeichnisbaum
time find /mnt/* -name "*suchbegriff*"
gerade mal 0,3 dauert.
Und selbst ein komplettes kopieren des Baumes dauert ja auch "nur" 3 Minuten.
Okay, der Prozessor, ein Atom D525, ist nicht gerade der Heuler, aber ich habe mal mit dem Systemmonitor drauf geguckt und der ist nicht permanent am Limit bei diesem Befehl.
Was ist das denn bitte schon wieder?
Klingt ein bißchen viel. Ich habe hier einen AMD Athlon 2200+ / 1,3 GB RAM der auf einer IDE-HD 16 min braucht, um 8 GB nach "start" zu durchsuchen (viele Treffer). Nach einer nie gefundenen Zeichenkette braucht er 13 min. Es sind aber auch jede Menge Binärdateien (pdf...) darunter. Und außerdem 11 Nutzer an unserer DB angemeldet, deren Arbeit kaum beeinträchtigt wird durch die Suche. Es sieht so aus, als würde ich mir demnächst keine SSD kaufen, wenn ich die threads der letzten Zeit so lese ;-) Allerdings ist es natürlich ein gravierender Unterschied, ob Du Namen suchst oder in Dateien "grep"st. Das reine find braucht bei mir auch nur 0,374 sec. cu -- Joerg Thuemmler www.teddylinx.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Tao te Puh, Donnerstag 16 Juni 2011:
time find /mnt/* -type f -exec grep -iH "suchbegriff" {} \;
Wenn man es schnell(er) haben will, dann würde es auch ein grep -ril "suchbegriff" /mnt tun. -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am 16. Juni 2011 04:50 schrieb Tao te Puh <taotepuh@e-sol.utions.de>:
Dann habe ich mal folgenden Befehl abgesetzt:
time find /mnt/* -type f -exec grep -iH "suchbegriff" {} \;
man xargs :-) Gruß Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hi Martin! On Do, 16 Jun 2011, Martin Schröder wrote:
Am 16. Juni 2011 04:50 schrieb Tao te Puh <taotepuh@e-sol.utions.de>:
Dann habe ich mal folgenden Befehl abgesetzt:
time find /mnt/* -type f -exec grep -iH "suchbegriff" {} \;
man xargs :-)
man find (suche nach -exec command {} +) ;) Mit freundlichen Grüßen Christian -- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am 16.06.2011 12:11, schrieb Christian Brabandt:
Hi Martin!
On Do, 16 Jun 2011, Martin Schröder wrote:
Am 16. Juni 2011 04:50 schrieb Tao te Puh<taotepuh@e-sol.utions.de>:
Dann habe ich mal folgenden Befehl abgesetzt:
time find /mnt/* -type f -exec grep -iH "suchbegriff" {} \;
man xargs :-)
man find (suche nach -exec command {} +)
Danke für die Tipps, auch wenn sie mein eigentliches Problem, nämlich den Vergleich des alten Systems mit dem neuem System, nicht wirklich lösen. Vorausgesetzt ich habe mir aus den manpages das Richtige rausgesucht, habe ich nun 3 unterschiedliche Kommando-Varianten, die alle das Gleiche erledigen und sich zeitlich, innerhalb eines Systems, nur marginal unterscheiden: Anmerkung: Ich habe die Suche auf PDF-Dateien begrenzt, damit ich überhaupt mal ein aussagekräftiges Ergebnis auf dem neuen System erhalte. In dem Dateibaum gibt es u.a. 4162 PDF-Dateien mit einem Volumen von ca. 1,3G. Neues System (SuSE 11.4, Tumbleweed) ------------------------------------ time find /mnt -name "*.pdf" -exec grep -iH "hurz" '{}' \; 5m56.177s time find /mnt -name "*.pdf" -print0 | xargs -0 grep -iH "hurz" 5m42.663s time find /mnt -name "*.pdf" -exec grep -iH "hurz" '{}' + 5m43.021s Altes System (SuSE 9.3) ----------------------- time find /mnt -name "*.pdf" -exec grep -iH "hurz" '{}' \; 1m8.548s time find /mnt -name "*.pdf" -print0 | xargs -0 grep -iH "hurz" 1m3.492s time find /mnt -name "*.pdf" -exec grep -iH "hurz" '{}' + funktioniert nicht -> find: grep: Die Argumentliste ist zu lang Das bedeutet, dass das alte System 5,2x schneller ist als das Neue. Wenn dem wirklich so ist, wäre ich sehr enttäuscht. Hier noch einige Infos zu den Systemen Neues System ------------ Intel Atom D525, 1.80GHz, 4096 MB, 2xSSD als RAID 1 Altes System ------------ Pentium 4 , 1.80GHz, 768 MB, 4xSATA an 3ware als RAID 5 Da muss es in dem neuen System doch irgendeinen Flaschenhals geben. Wie komme ich dem auf die Spur? -- Herzliche Grüße Tao -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am 17. Juni 2011 00:18 schrieb Tao te Puh <taotepuh@e-sol.utions.de>:
Da muss es in dem neuen System doch irgendeinen Flaschenhals geben. Wie komme ich dem auf die Spur?
man vmstat man iostat man sar Gruß Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am 17.06.2011 00:59, schrieb Martin Schröder:
Am 17. Juni 2011 00:18 schrieb Tao te Puh<taotepuh@e-sol.utions.de>:
Da muss es in dem neuen System doch irgendeinen Flaschenhals geben. Wie komme ich dem auf die Spur?
man vmstat man iostat man sar
Oops, na das ist ja wohl eher Stoff für die großen Jungs :-) In jedem Fall aber: Danke! Es wird eine Weile dauern, bis ich diese Tools verstehe und sinnvoll einsetzen kann, aber ich werde es versuchen. Bis dahin habe ich aber mal ein bisschen, mit den Hausmitteln die kenne, weiter getestet und habe folgende Neuigkeiten: 1.) Ich habe mal die SSD-Platten durch eine SATA ersetzt, openSuSE 11.4 installiert und mit dem gleichen Datenbestand getestet. Das Ergebnis ist 6m10.894s (Vergleich: SSD=5m56.177s), also etwas langsamer als die SSD-Platten und ebenfalls sehr viel langsamer als das Alt-System (1m8.548s). 2.) Damit ich einen Hardware-Problem ausschließen kann, habe ich das System mal mit Tiny Core Linux gestartet und den gleichen Test mit dem gleichen Datenbestand von der SATA-Platte gemacht und das Ergbnis ist 0m34.74s und wenn ich den Befehl gleich nochmal starte, sogar nur 0m14.84s. Na das ist doch mal ein Unterschied !!! Aus dem Bauch heraus, ist es das Ergebnis das was ich mir von dem neuen System versprach - ungefähr doppelt so schnell wie das Alt-System. Aber was fange ich mit diesem Ergebnis an? Gerechnet ist das gleiche System mit Tiny Core Linux 11-26 mal schneller als wie mit openSuSE. Wie kann das denn sein? Wo ist die angezogene Handbremse in openSuSE versteckt? -- Herzliche Grüße Tao -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am 17.06.2011 07:28, schrieb Tao te Puh:
Am 17.06.2011 00:59, schrieb Martin Schröder:
Am 17. Juni 2011 00:18 schrieb Tao te Puh<taotepuh@e-sol.utions.de>:
Da muss es in dem neuen System doch irgendeinen Flaschenhals geben. Wie komme ich dem auf die Spur?
man vmstat man iostat man sar
Oops, na das ist ja wohl eher Stoff für die großen Jungs :-) In jedem Fall aber: Danke! Es wird eine Weile dauern, bis ich diese Tools verstehe und sinnvoll einsetzen kann, aber ich werde es versuchen.
Bis dahin habe ich aber mal ein bisschen, mit den Hausmitteln die kenne, weiter getestet und habe folgende Neuigkeiten:
1.) Ich habe mal die SSD-Platten durch eine SATA ersetzt, openSuSE 11.4 installiert und mit dem gleichen Datenbestand getestet. Das Ergebnis ist 6m10.894s (Vergleich: SSD=5m56.177s), also etwas langsamer als die SSD-Platten und ebenfalls sehr viel langsamer als das Alt-System (1m8.548s).
2.) Damit ich einen Hardware-Problem ausschließen kann, habe ich das System mal mit Tiny Core Linux gestartet und den gleichen Test mit dem gleichen Datenbestand von der SATA-Platte gemacht und das Ergbnis ist 0m34.74s und wenn ich den Befehl gleich nochmal starte, sogar nur 0m14.84s.
Na das ist doch mal ein Unterschied !!!
Aus dem Bauch heraus, ist es das Ergebnis das was ich mir von dem neuen System versprach - ungefähr doppelt so schnell wie das Alt-System.
Aber was fange ich mit diesem Ergebnis an? Gerechnet ist das gleiche System mit Tiny Core Linux 11-26 mal schneller als wie mit openSuSE.
Wie kann das denn sein? Wo ist die angezogene Handbremse in openSuSE versteckt?
Mir hat das keine Ruhe gelassen. Deshalb habe nach der angezogenen Handbremse in openSuSE gesucht und auch einen heißen Anwärter ermitteln können: Es ist die Lokalisierung ! Szenario: Ich habe mir ein Verzeichnis mit 4162 PDF-Dateien erzeugt (~1,3GB). Darin suche ich mit grep: time grep -i "hurz" /mnt/tmp_pdf/* Das dauert 5m42.398s. Dann stelle ich die Lokalisierung um auf C (das ist der Standard bei Tiny Core Linux): export LANG=C export LANGUAGE=C export LC_ALL=C und führe genau die gleiche Suche durch: time grep -i "hurz" /mnt/tmp_pdf/* Das dauert lediglich 0m7.566s. Die Suche ist also 48x schneller. Kann mir das jemand erklären? -- Herzliche Grüße Tao -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On 18.06.2011 16:59, Tao te Puh wrote:
Es ist die Lokalisierung !
Szenario: Ich habe mir ein Verzeichnis mit 4162 PDF-Dateien erzeugt (~1,3GB). Darin suche ich mit grep:
time grep -i "hurz" /mnt/tmp_pdf/*
Das dauert 5m42.398s.
Dann stelle ich die Lokalisierung um auf C (das ist der Standard bei Tiny Core Linux):
export LANG=C export LANGUAGE=C export LC_ALL=C
und führe genau die gleiche Suche durch:
time grep -i "hurz" /mnt/tmp_pdf/*
Das dauert lediglich 0m7.566s.
Die Suche ist also 48x schneller.
Kann mir das jemand erklären?
Hast du vor dem zweiten Versuch auch den Rechner neu gestartet? Wenn nicht, dann hast du deine Suche aus dem Cache bedient. Versuche es doch mal anders herum: erst auf C umstellen (NACH Neustartt!!), messen, dann auf UTF8 noch einmal messen. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@)drobic (.) de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am 18.06.2011 19:30, schrieb Sandy Drobic:
On 18.06.2011 16:59, Tao te Puh wrote:
Es ist die Lokalisierung !
Szenario: Ich habe mir ein Verzeichnis mit 4162 PDF-Dateien erzeugt (~1,3GB). Darin suche ich mit grep:
time grep -i "hurz" /mnt/tmp_pdf/*
Das dauert 5m42.398s.
Dann stelle ich die Lokalisierung um auf C (das ist der Standard bei Tiny Core Linux):
export LANG=C export LANGUAGE=C export LC_ALL=C
und führe genau die gleiche Suche durch:
time grep -i "hurz" /mnt/tmp_pdf/*
Das dauert lediglich 0m7.566s.
Die Suche ist also 48x schneller.
Kann mir das jemand erklären?
Hast du vor dem zweiten Versuch auch den Rechner neu gestartet? Wenn nicht, dann hast du deine Suche aus dem Cache bedient. Versuche es doch mal anders herum: erst auf C umstellen (NACH Neustartt!!), messen, dann auf UTF8 noch einmal messen.
Ich habe, innerhalb einer Sitzung, mehrfach gemessen. Dabei habe ich die Lokalisierung auch mehrfach hin- und zurückgestellt. Die Ergebnisse differieren minimal (-> Cache spielt hier also keine Rolle), der Unterschied zwischen den Lokalisierungen, bleibt aber immens. Auch auf einem anderen System, dort läuft 11.2, habe ich diesen Effekt nachvollziehen können. Interessant ist aber vielleicht das Folgende: Auf einem Alt-System mit SuSE 9.3, ist der Unterschied zwischen unterschiedliche Lokalisierung nur minimal, also praktisch 0. Ansonsten kannst Du das sehr einfach und schnell selber testen: Folgende Kommandos erzeugen ein Verzeichnis (/mnt/tmp_nullfiles) und darin 1000 Dateien mit jeweils 1MB. Dann wird mit grep getestet, die Lokalisierung gewechselt und erneut getestet: mkdir /mnt/tmp_nullfiles # 1000 Dateien mit jeweils 1MB anlegen i=1; while [ $i -le 1000 ]; do dd if=/dev/zero of=/mnt/tmp_nullfiles/nullfile-$i bs=1M count=1; i=$(( $i + 1 )); done; # Test mit locale=de_DE.UTF-8 time grep -i "hurz" /mnt/tmp_nullfiles/* # Lokalisierung wechseln export LANG=C export LANGUAGE=C export LC_ALL=C # Test mit locale=C time grep -i "hurz" /mnt/tmp_nullfiles/* # Lokalisierung wieder zurückstellen export LANG=de_DE.UTF-8 export LANGUAGE=de_DE.UTF-8 export LC_ALL=de_DE.UTF-8 -- Herzliche Grüße Tao -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Samstag, 18. Juni 2011, 23:44:54 schrieb Tao te Puh:
Am 18.06.2011 19:30, schrieb Sandy Drobic:
On 18.06.2011 16:59, Tao te Puh wrote:
Es ist die Lokalisierung !
Szenario: Ich habe mir ein Verzeichnis mit 4162 PDF-Dateien erzeugt (~1,3GB). Darin suche ich mit grep:
time grep -i "hurz" /mnt/tmp_pdf/*
Das dauert 5m42.398s.
Dann stelle ich die Lokalisierung um auf C (das ist der Standard bei Tiny Core Linux):
export LANG=C export LANGUAGE=C export LC_ALL=C
und führe genau die gleiche Suche durch:
time grep -i "hurz" /mnt/tmp_pdf/*
Das dauert lediglich 0m7.566s.
Die Suche ist also 48x schneller.
Kann mir das jemand erklären?
Hast du vor dem zweiten Versuch auch den Rechner neu gestartet? Wenn nicht, dann hast du deine Suche aus dem Cache bedient. Versuche es doch mal anders herum: erst auf C umstellen (NACH Neustartt!!), messen, dann auf UTF8 noch einmal messen.
Ich habe, innerhalb einer Sitzung, mehrfach gemessen. Dabei habe ich die Lokalisierung auch mehrfach hin- und zurückgestellt. Die Ergebnisse differieren minimal (-> Cache spielt hier also keine Rolle), der Unterschied zwischen den Lokalisierungen, bleibt aber immens. Auch auf einem anderen System, dort läuft 11.2, habe ich diesen Effekt nachvollziehen können.
Interessant ist aber vielleicht das Folgende: Auf einem Alt-System mit SuSE 9.3, ist der Unterschied zwischen unterschiedliche Lokalisierung nur minimal, also praktisch 0.
Ansonsten kannst Du das sehr einfach und schnell selber testen:
Folgende Kommandos erzeugen ein Verzeichnis (/mnt/tmp_nullfiles) und darin 1000 Dateien mit jeweils 1MB. Dann wird mit grep getestet, die Lokalisierung gewechselt und erneut getestet:
mkdir /mnt/tmp_nullfiles
# 1000 Dateien mit jeweils 1MB anlegen i=1; while [ $i -le 1000 ]; do dd if=/dev/zero of=/mnt/tmp_nullfiles/nullfile-$i bs=1M count=1; i=$(( $i + 1 )); done;
# Test mit locale=de_DE.UTF-8 time grep -i "hurz" /mnt/tmp_nullfiles/*
# Lokalisierung wechseln export LANG=C export LANGUAGE=C export LC_ALL=C
# Test mit locale=C time grep -i "hurz" /mnt/tmp_nullfiles/*
# Lokalisierung wieder zurückstellen export LANG=de_DE.UTF-8 export LANGUAGE=de_DE.UTF-8 export LC_ALL=de_DE.UTF-8
Mach mal "strace" statt time für ein einzelnes nullfile, dann dürfte der Unterschied klar werden. Die Variante mit einer locale <> "C" versucht, jede Menge Dateien zu öffenen, in denen die Lokalisierungen beschrieben sind (/usr/lib/locale/ ...). mfg Hendrik -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am 19.06.2011 15:25, schrieb Hendrik Woltersdorf:
Am Samstag, 18. Juni 2011, 23:44:54 schrieb Tao te Puh:
Am 18.06.2011 19:30, schrieb Sandy Drobic:
On 18.06.2011 16:59, Tao te Puh wrote:
Es ist die Lokalisierung !
Szenario: Ich habe mir ein Verzeichnis mit 4162 PDF-Dateien erzeugt (~1,3GB). Darin suche ich mit grep:
time grep -i "hurz" /mnt/tmp_pdf/*
Das dauert 5m42.398s.
Dann stelle ich die Lokalisierung um auf C (das ist der Standard bei Tiny Core Linux):
export LANG=C export LANGUAGE=C export LC_ALL=C
und führe genau die gleiche Suche durch:
time grep -i "hurz" /mnt/tmp_pdf/*
Das dauert lediglich 0m7.566s.
Die Suche ist also 48x schneller.
Kann mir das jemand erklären?
Hast du vor dem zweiten Versuch auch den Rechner neu gestartet? Wenn nicht, dann hast du deine Suche aus dem Cache bedient. Versuche es doch mal anders herum: erst auf C umstellen (NACH Neustartt!!), messen, dann auf UTF8 noch einmal messen.
Ich habe, innerhalb einer Sitzung, mehrfach gemessen. Dabei habe ich die Lokalisierung auch mehrfach hin- und zurückgestellt. Die Ergebnisse differieren minimal (-> Cache spielt hier also keine Rolle), der Unterschied zwischen den Lokalisierungen, bleibt aber immens. Auch auf einem anderen System, dort läuft 11.2, habe ich diesen Effekt nachvollziehen können.
Interessant ist aber vielleicht das Folgende: Auf einem Alt-System mit SuSE 9.3, ist der Unterschied zwischen unterschiedliche Lokalisierung nur minimal, also praktisch 0.
Ansonsten kannst Du das sehr einfach und schnell selber testen:
Folgende Kommandos erzeugen ein Verzeichnis (/mnt/tmp_nullfiles) und darin 1000 Dateien mit jeweils 1MB. Dann wird mit grep getestet, die Lokalisierung gewechselt und erneut getestet:
mkdir /mnt/tmp_nullfiles
# 1000 Dateien mit jeweils 1MB anlegen i=1; while [ $i -le 1000 ]; do dd if=/dev/zero of=/mnt/tmp_nullfiles/nullfile-$i bs=1M count=1; i=$(( $i + 1 )); done;
# Test mit locale=de_DE.UTF-8 time grep -i "hurz" /mnt/tmp_nullfiles/*
# Lokalisierung wechseln export LANG=C export LANGUAGE=C export LC_ALL=C
# Test mit locale=C time grep -i "hurz" /mnt/tmp_nullfiles/*
# Lokalisierung wieder zurückstellen export LANG=de_DE.UTF-8 export LANGUAGE=de_DE.UTF-8 export LC_ALL=de_DE.UTF-8
Mach mal "strace" statt time für ein einzelnes nullfile, dann dürfte der Unterschied klar werden. Die Variante mit einer locale <> "C" versucht, jede Menge Dateien zu öffenen, in denen die Lokalisierungen beschrieben sind (/usr/lib/locale/ ...). mfg Hendrik
hi, soweit ich mich erinnern kann, liegt das an einem sog. UTF-Patch für die coreutils und/oder "grep" (ist schon etwas länger her). Eine Suche nach "grep utf performance" ergibt auch bei anderen Distris entsprechende Meldungen. Vor allem die Kombination von Multibyte und --ignore-case (-i) sorgt für einen spürbaren Einbruch der Performance (alle Tests mit de_DE.UTF-8): paolo@worker:/tmp> time grep -i "hurz" /tmp/_nullfiles/* real 0m36.063s user 0m35.805s sys 0m0.248s paolo@worker:/tmp> time grep "hurz" /tmp/_nullfiles/* real 0m1.961s user 0m1.715s sys 0m0.244s Es existieren scheinbar schon einige Patches, um das Ganze für "grep" zu beschleunigen - vielleicht bekomme ich das mal zum Testen zusammen. Alternativ könnte man "ack" verwenden, damit geht es auch mit --ignore-case (-i) deutlich flotter: paolo@worker:/tmp> time ack -i "hurz" /tmp/_nullfiles/* real 0m4.056s user 0m3.746s sys 0m0.307s Ciao, Paolo -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am 19.06.2011 16:05, schrieb Paolo Pantò:
Am 19.06.2011 15:25, schrieb Hendrik Woltersdorf:
Am Samstag, 18. Juni 2011, 23:44:54 schrieb Tao te Puh:
Am 18.06.2011 19:30, schrieb Sandy Drobic:
On 18.06.2011 16:59, Tao te Puh wrote:
Es ist die Lokalisierung !
Szenario: Ich habe mir ein Verzeichnis mit 4162 PDF-Dateien erzeugt (~1,3GB). Darin suche ich mit grep:
time grep -i "hurz" /mnt/tmp_pdf/*
Das dauert 5m42.398s.
Dann stelle ich die Lokalisierung um auf C (das ist der Standard bei Tiny Core Linux):
export LANG=C export LANGUAGE=C export LC_ALL=C
und führe genau die gleiche Suche durch:
time grep -i "hurz" /mnt/tmp_pdf/*
Das dauert lediglich 0m7.566s.
Die Suche ist also 48x schneller.
Kann mir das jemand erklären?
Hast du vor dem zweiten Versuch auch den Rechner neu gestartet? Wenn nicht, dann hast du deine Suche aus dem Cache bedient. Versuche es doch mal anders herum: erst auf C umstellen (NACH Neustartt!!), messen, dann auf UTF8 noch einmal messen.
Ich habe, innerhalb einer Sitzung, mehrfach gemessen. Dabei habe ich die Lokalisierung auch mehrfach hin- und zurückgestellt. Die Ergebnisse differieren minimal (-> Cache spielt hier also keine Rolle), der Unterschied zwischen den Lokalisierungen, bleibt aber immens. Auch auf einem anderen System, dort läuft 11.2, habe ich diesen Effekt nachvollziehen können.
Interessant ist aber vielleicht das Folgende: Auf einem Alt-System mit SuSE 9.3, ist der Unterschied zwischen unterschiedliche Lokalisierung nur minimal, also praktisch 0.
Ansonsten kannst Du das sehr einfach und schnell selber testen:
Folgende Kommandos erzeugen ein Verzeichnis (/mnt/tmp_nullfiles) und darin 1000 Dateien mit jeweils 1MB. Dann wird mit grep getestet, die Lokalisierung gewechselt und erneut getestet:
mkdir /mnt/tmp_nullfiles
# 1000 Dateien mit jeweils 1MB anlegen i=1; while [ $i -le 1000 ]; do dd if=/dev/zero of=/mnt/tmp_nullfiles/nullfile-$i bs=1M count=1; i=$(( $i + 1 )); done;
# Test mit locale=de_DE.UTF-8 time grep -i "hurz" /mnt/tmp_nullfiles/*
# Lokalisierung wechseln export LANG=C export LANGUAGE=C export LC_ALL=C
# Test mit locale=C time grep -i "hurz" /mnt/tmp_nullfiles/*
# Lokalisierung wieder zurückstellen export LANG=de_DE.UTF-8 export LANGUAGE=de_DE.UTF-8 export LC_ALL=de_DE.UTF-8
Mach mal "strace" statt time für ein einzelnes nullfile, dann dürfte der Unterschied klar werden. Die Variante mit einer locale<> "C" versucht, jede Menge Dateien zu öffenen, in denen die Lokalisierungen beschrieben sind (/usr/lib/locale/ ...). mfg Hendrik
hi,
soweit ich mich erinnern kann, liegt das an einem sog. UTF-Patch für die coreutils und/oder "grep" (ist schon etwas länger her).
Eine Suche nach "grep utf performance" ergibt auch bei anderen Distris entsprechende Meldungen.
Vor allem die Kombination von Multibyte und --ignore-case (-i) sorgt für einen spürbaren Einbruch der Performance (alle Tests mit de_DE.UTF-8):
paolo@worker:/tmp> time grep -i "hurz" /tmp/_nullfiles/*
real 0m36.063s user 0m35.805s sys 0m0.248s
paolo@worker:/tmp> time grep "hurz" /tmp/_nullfiles/*
real 0m1.961s user 0m1.715s sys 0m0.244s
Es existieren scheinbar schon einige Patches, um das Ganze für "grep" zu beschleunigen - vielleicht bekomme ich das mal zum Testen zusammen.
Alternativ könnte man "ack" verwenden, damit geht es auch mit --ignore-case (-i) deutlich flotter:
paolo@worker:/tmp> time ack -i "hurz" /tmp/_nullfiles/*
real 0m4.056s user 0m3.746s sys 0m0.307s
Danke für die ganzen Tipps und Erklärungen. Ich werde das alles mal versuchen zu verstehen und auszuprobieren. Bis dahin frustriert mich aber, dass mein Alt-System mit SuSE 9.3, ungefähr 6x so schnell ist wie mein neues System mit besserer Hardware und SuSE 11.4. Und das Alt-System war ja auch schon UTF-8 und ich habe dort grep über Jahre hinweg, ohne irgendwelche Auffälligkeiten, benutzt. Da wurde also irgendwas, vielleicht ja durch den angesprochenen Patch, "Verschlimmbessert". -- Herzliche Grüße Tao -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
* Tao te Puh (taotepuh@e-sol.utions.de) [20110618 16:59]:
Es ist die Lokalisierung !
Das ist bekannt! Mit der Unterstützung für Multibyte-Lokales (also z.B. alles was utf8 zur Zeichenkodierung verwendet) wird es deutlich langsamer. Natürlich kannst Du die C/Posix Locale verwenden, dann *dürfen* aber dann dürfen weder der Suchbegriff noch die Dateinamen/der Dateiinhalt in etwas anderem als ASCII kodiert sein damit es unter allen Umständen funktioniert. Philipp -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am 20.06.2011 19:05, schrieb Philipp Thomas:
* Tao te Puh (taotepuh@e-sol.utions.de) [20110618 16:59]:
Es ist die Lokalisierung !
Das ist bekannt! Mit der Unterstützung für Multibyte-Lokales (also z.B. alles was utf8 zur Zeichenkodierung verwendet) wird es deutlich langsamer. Natürlich kannst Du die C/Posix Locale verwenden, dann *dürfen* aber dann dürfen weder der Suchbegriff noch die Dateinamen/der Dateiinhalt in etwas anderem als ASCII kodiert sein damit es unter allen Umständen funktioniert.
Das es so ist, habe ich ja am eigenen Leib erfahren. Warum es so ist, mag mir aber nicht so recht einleuchten. Unwissend wie ich bin, stelle ich mir vor, dass da einfach Bytes miteinander verglichen werden. Ob das Byte dabei ein "ü" oder lediglich ein "u" repräsentiert, sollte doch egal sein. Aber vermutlich ist das alles viel komplizierter. Und wie geschrieben, unter oS 9.3, war das alles schon mal schneller. -- Herzliche Grüße Tao -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Mon, 20 Jun 2011 19:22:49 +0200 schrieb Tao te Puh <taotepuh@e-sol.utions.de>:
Am 20.06.2011 19:05, schrieb Philipp Thomas:
* Tao te Puh (taotepuh@e-sol.utions.de) [20110618 16:59]:
Es ist die Lokalisierung !
Das ist bekannt! Mit der Unterstützung für Multibyte-Lokales (also z.B. alles was utf8 zur Zeichenkodierung verwendet) wird es deutlich langsamer.
Warum es so ist, mag mir aber nicht so recht einleuchten. Unwissend wie ich bin, stelle ich mir vor, dass da einfach Bytes miteinander verglichen werden. Ob das Byte dabei ein "ü" oder lediglich ein "u" repräsentiert, sollte doch egal sein. Aber vermutlich ist das alles viel komplizierter.
Ein Zeichen kann aus 1-4 (theoretisch sogar bis zu 8) Bytes bestehen. Du musst also jede Bytefolge erst einmal auseinandernehmen um einen Zeichenvergleich machen zu können. Zwei Bytefolgen mit gleicher Länge können ja durchaus unterschiedlich viele Zeichen beinhalten. Gruß, Michael -- ____ / / / / /__/ Michael Höhne / / / / / / mih-hoehne@web.de / ________________________________/ -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am 21.06.2011 09:38, schrieb Michael Höhne:
Am Mon, 20 Jun 2011 19:22:49 +0200 schrieb Tao te Puh<taotepuh@e-sol.utions.de>:
Am 20.06.2011 19:05, schrieb Philipp Thomas:
* Tao te Puh (taotepuh@e-sol.utions.de) [20110618 16:59]:
Es ist die Lokalisierung !
Das ist bekannt! Mit der Unterstützung für Multibyte-Lokales (also z.B. alles was utf8 zur Zeichenkodierung verwendet) wird es deutlich langsamer.
Warum es so ist, mag mir aber nicht so recht einleuchten. Unwissend wie ich bin, stelle ich mir vor, dass da einfach Bytes miteinander verglichen werden. Ob das Byte dabei ein "ü" oder lediglich ein "u" repräsentiert, sollte doch egal sein. Aber vermutlich ist das alles viel komplizierter.
Ein Zeichen kann aus 1-4 (theoretisch sogar bis zu 8) Bytes bestehen. Du musst also jede Bytefolge erst einmal auseinandernehmen um einen Zeichenvergleich machen zu können. Zwei Bytefolgen mit gleicher Länge können ja durchaus unterschiedlich viele Zeichen beinhalten.
Danke für die Ausführungen. Aber erklärt das wirklich den immensen Laufzeitunterschied zur Lokalisierung "C"? Der beträgt ja immerhin Faktoren von 15 und größer. Und warum konnte oS 9.3 das besser? -- Herzliche Grüße Tao -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
* Tao te Puh (taotepuh@e-sol.utions.de) [20110621 15:23]:
Aber erklärt das wirklich den immensen Laufzeitunterschied zur Lokalisierung "C"? Der beträgt ja immerhin Faktoren von 15 und größer.
Ja, tut es! Die Multibytes unterstützenden Stringfunktionen sind deutlich langsamer als ihre ASCII-Varianten (z.B. mblen und strlen). Möglicherweise lässt sich der verwendete Patch optimieren, aber das erfordert dann einen echten Spezialisten und das bin ich nicht.
Und warum konnte oS 9.3 das besser?
Konnte es das besser? Auf jeden Fall ist es schwer, jetzt exakt zu sagen, was die Ursache ist. Der verwendete i18n-Patch war ein anderer und lässt sich nicht auf die aktuellen coreutils anwenden und auch die glibc war eine ganz andere Version. Philipp -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am 21.06.2011 19:43, schrieb Philipp Thomas:
* Tao te Puh (taotepuh@e-sol.utions.de) [20110621 15:23]:
Aber erklärt das wirklich den immensen Laufzeitunterschied zur Lokalisierung "C"? Der beträgt ja immerhin Faktoren von 15 und größer.
Ja, tut es! Die Multibytes unterstützenden Stringfunktionen sind deutlich langsamer als ihre ASCII-Varianten (z.B. mblen und strlen). Möglicherweise lässt sich der verwendete Patch optimieren, aber das erfordert dann einen echten Spezialisten und das bin ich nicht.
Und warum konnte oS 9.3 das besser?
Konnte es das besser?
Ja. Die Maschine die hier bei mir ersetzt werden soll erledigt mit 9.3, eine gestellte Aufgabe 6x so schnell wie die neue Maschine die schnellere Hardware besitzt.
Auf jeden Fall ist es schwer, jetzt exakt zu sagen, was die Ursache ist. Der verwendete i18n-Patch war ein anderer und lässt sich nicht auf die aktuellen coreutils anwenden und auch die glibc war eine ganz andere Version.
Ich habe bei meinen bescheidenen Recherchen, glaube ich, etwas von einem glibc-Patch gelesen der diesbezüglich ganz schreckliche Auswirkungen hatte. Aber da ich davon praktisch überhaupt nichts verstehe, muss ich das wohl alles so hinnehmen. -- Herzliche Grüße Tao -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On Thu, 16 Jun 2011 04:50:00 +0200, Tao te Puh <taotepuh@e-sol.utions.de> wrote:
time find /mnt/* -type f -exec grep -iH "suchbegriff" {} \;
Versuch mal LANG=C time find /mnt/* -type f -exec grep -iH "suchbegriff" {} \; Sprich setz die Standard-Locale, da grep in Multibyte-Locales *deutlich* langsamer ist. Eine andere Möglichkeit wäre, statt eines grep-Aufrufs für jede gefundene Datei xargs zu verwenden, um die Anzahl der Grep-Aufrufe zu minimieren. Phllipp -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am 29.06.2011 01:44, schrieb Philipp Thomas:
On Thu, 16 Jun 2011 04:50:00 +0200, Tao te Puh <taotepuh@e-sol.utions.de> wrote:
time find /mnt/* -type f -exec grep -iH "suchbegriff" {} \;
Versuch mal
LANG=C time find /mnt/* -type f -exec grep -iH "suchbegriff" {} \;
Sprich setz die Standard-Locale, da grep in Multibyte-Locales *deutlich* langsamer ist. Eine andere Möglichkeit wäre, statt eines grep-Aufrufs für jede gefundene Datei xargs zu verwenden, um die Anzahl der Grep-Aufrufe zu minimieren.
Danke für Deine Anregungen. Ja, die Lokalisierung spielt dabei eine große Rolle - xargs weniger. Das wurde aber, etwas später im Thread, auch bereits erörtert. Eigentlich ist nur noch offen, warum das bei SuSE 9.3 besser geklappt hat. -- Herzliche Grüße Tao -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (11)
-
Andre Tann -
Christian Brabandt -
Hendrik Woltersdorf -
Joerg Thuemmler -
Martin Schröder -
Michael Höhne -
Paolo Pantò -
Philipp Thomas -
Philipp Thomas -
Sandy Drobic -
Tao te Puh