Künstliche Bremse in PowerShell?

[nerd 28]

Hi,

 

nachdem ich nun alle meine Systemweiten Suchen in Dateien über Powershell durchführe bin ich sehr begeistert von dessen Performance. Es schlägt ein zuvor eingesetzes VBS um längen - aber nicht immer :eek:

 

Folgender Aufbau:

- File liegt auf lokaler Platte D - Output auf C (andere physische Platte)

- File ist ca. 50 GB groß, nicht komprimiert, nicht fragmentiert

- Daten sind Zeilenweise angeordnet (logfile style)

 

Suche ich nach einem String mit diesem Befehl:

select-string testfile.log -pattern "FIND_MICH_01"  >c:\tmp\speedtest.txt

Dann bekomme ich das Ergebnis sehr schnell ausgegeben und die Platte hat einen Durchsatz von 110 MByte/sec.

Erweitere ich die suche um einen weitere strings geschieht folgendes:

10 Strings 26 MByte/sec

20 Strings 14 MByte/sec

40 Strings 7.5 MByte/sec

 

Die CPU bleibt immer recht entspannt (ca. 10 % Auslastung).

 

Gibt es da eine Option in PowerShell die mich hier ausbremst? Logisch finde ich das nicht.

 

LG

[blub 115]

Hi,

Machst du die 40 Strings gleichzeitig oder nacheinander?

 

Vielleicht wirds schneller, wenn du mit

$a=get-content -path c:\testfile.log

das ganze Log erstmal in einem Rutsch einliest und dann die Suche über $a laufen lässt.

 

blub

[nerd 28]

Hi,

Machst du die 40 Strings gleichzeitig oder nacheinander?

Alles im gleichen Befehl:

select-string testfile.log -pattern "FIND_MICH_01","FIND_MICH_02","FIND_MICH_03"  >c:\tmp\speedtest.txt

Das Lustige ist auch wenn ich (bei 10 habe ich es versucht) 10 mal die Einzelsuche als eigenen Prozess starte dann ist das schneller wie bei der o. g. syntax. Allerdings geht dann die CPU auf 100%.

 

 

Vielleicht wirds schneller, wenn du mit

$a=get-content -path c:\testfile.log

das ganze Log erstmal in einem Rutsch einliest und dann die Suche über $a laufen lässt.

 

blub

 

Die Files sind um die 50 GB und ich habe auf der Maschine nur 18 GB RAM - das wird vermutlich nach kurzer Zeit wie **** auslagern oder?

[blub 115]

50 GB für ein Log-Textfile? Was ist das denn für eine Anwendung?

 

Da würde ich im ersten Schritt eher mit kommerziellen Tools wie Totalcommander oder Primalscript rangehen. Mit Trialversionen kannst du ja erstmal testen. Denen traue ich 50GB eher zu als der Powershell

Im zweiten Schritt wäre das Design der Anwendung dran

 

blub

[nerd 28]

Hi,

 

grundsätzlich funktioniert das mit den o. g. PS Befehlen sehr gut. Die Frage ist nur warum es (scheinbar ohne Not) bei mehreren Suchbegriffen langsamer wird.

[NilsK 2.961]

Moin,

 

mich wundert das nicht besonders. Je mehr Strings du suchst, desto mehr muss PowerShell ja pro Element prüfen. Da PowerShell Objekte verarbeitet und nicht auf Performance optimiert ist, halte ich das beobachtete Verhalten für sehr erklärlich (und letztlich auch erwartbar).

 

Wenn du in einer SQL-Query, die nicht gegen den Index läuft, die Zahl der zu suchenden Stringfragmente mit OR erhöhst, wirst du tendenziell denselben Effekt beobachten.

 

Gruß, Nils

[zahni 554]

Ich benutze zum Durchsuchen von LOG-Files u.ä. auch den Total Commander.

 

Wenn Du Dateien nach bestimmten Strings filtern willst, kannst Du dir mal Agrep anschauen: AGREP, an approximate GREP

ist zwar sehr alt, funktioniert aber tadellos, ist sehr schnell. Kommt aber mit Unicode nicht klar.

[nerd 28]

Moin,

 

mich wundert das nicht besonders. Je mehr Strings du suchst, desto mehr muss PowerShell ja pro Element prüfen. Da PowerShell Objekte verarbeitet und nicht auf Performance optimiert ist, halte ich das beobachtete Verhalten für sehr erklärlich (und letztlich auch erwartbar).

 

Wenn du in einer SQL-Query, die nicht gegen den Index läuft, die Zahl der zu suchenden Stringfragmente mit OR erhöhst, wirst du tendenziell denselben Effekt beobachten.

 

Gruß, Nils

 

Bei einem SQL Server sehe ich dann aber auch, dass dieser bestimmte Resourcen stärker verwendet - in meinem Fall geht aber die Auslastung von Festplatte und CPU nach unten - damit ist das für mich nicht erwartet. Es ist grundsätzlich klar, dass die Suche nach 10 Strings länger dauern wird als die Suche nach einem String.