Hallo zusammen, habe einen Rechner eingerichtet, der Log-Verzeichnisse von ca. 20 verschiedenen Windows-Büchsen via "smbmount" mountet. Klappt auch prima, nur hab ich auf der Kiste ein wahnsinniges Performance-Problem. So braucht ein grep-job, den ich auf der Kiste anstosse (laut top erhält der 500MB RAM und 96% Prozessorleistung, kein SWAP) etwa 20 Minuten. Derselbe Job mit denselben Dateien braucht auf meinem Arbeitsplatzrechner (etwa leistungsgleich) ganze 7 Sekunden. Das einzige, was auf dem "langsamen" Server anders ist, sind die 20 gemounteten Resourcen (auf denen auch Dienste arbeiten - logs schreiben). Macht das mein System so langsam und wenn ja, gäbs Alternativen? (Samba würde ja andersrum mounten, das kann ich eigentlich nicht gebrauchen, hmm vielleicht gäbs da ein Workaround, wär das denn schneller?) (Der Rechner hat 1 GB RAM und irgendwas um die 700 MH, mein Arbeitsplatzrechner hat etwas mehr MH dafür weniger RAM, sollte keine Rolle spielen.) Thx für Hinweise, Bernd -- One OS to rule them all, one OS to find them. One OS to bring them all, and in the darkness bind them In the land of Redmond, where the shadows lie.
Bernd Tannenbaum wrote:
Das einzige, was auf dem "langsamen" Server anders ist, sind die 20 gemounteten Resourcen (auf denen auch Dienste arbeiten - logs schreiben).
Auf dem Server "vmstat 1" aufrufen und mal so 10 Zeilen posten. Ausserdem noch interessant: Welcher Kernel laeuft auf dem Server? Ich hab gerade eine SMP-Maschine durch upgrade von 2.4.16 auf 2.4.18 um etliches schneller bekommen. -- Have fun, Peter
Hallo again and thx schonmal :) Am Mittwoch, 1. Oktober 2003 13:23 schrieb Peter Wiersig:
Bernd Tannenbaum wrote:
Das einzige, was auf dem "langsamen" Server anders ist, sind die 20 gemounteten Resourcen (auf denen auch Dienste arbeiten - logs schreiben).
Auf dem Server "vmstat 1" aufrufen und mal so 10 Zeilen posten.
procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 0 0 0 0 370916 76044 349904 0 0 1 23 61 48 3 0 96 0 0 0 0 370916 76044 349904 0 0 0 0 618 104 1 1 98 0 0 0 0 370916 76044 349904 0 0 0 0 525 38 0 0100 0 0 0 0 370916 76044 349904 0 0 0 0 521 41 1 1 98 0 0 0 0 370916 76044 349904 0 0 0 152 531 48 0 1 99 0 0 0 0 370916 76044 349904 0 0 0 0 521 39 1 0 99 0 0 0 0 370916 76044 349904 0 0 0 0 523 30 0 1 99 0 0 0 0 370916 76044 349904 0 0 0 280 586 212 1 1 98 0 0 0 0 370916 76044 349904 0 0 0 0 521 23 1 0 99 0 0 0 0 370916 76044 349904 0 0 0 0 520 42 0 1 99 0 0 0 0 370916 76044 349908 0 0 0 0 526 39 1 0 99 0 0 0 0 370916 76044 349908 0 0 0 0 521 43 0 1 99 0 0 0 0 370916 76044 349908 0 0 0 0 521 24 1 1 98 0 0 0 0 370916 76044 349908 0 0 0 0 521 43 0 0100 0 1 1 0 370916 76044 349908 0 0 0 200 556 111 2 4 94 0 0 0 0 370916 76044 349908 0 0 0 0 520 44 1 0 99 0 0 0 0 370916 76044 349908 0 0 0 0 616 104 2 2 96 0 0 0 0 370916 76044 349908 0 0 0 0 520 41 0 1 99 2 0 0 0 370916 76044 349908 0 0 0 0 525 26 1 0 99
Ausserdem noch interessant: Welcher Kernel laeuft auf dem Server?
Ich hab gerade eine SMP-Maschine durch upgrade von 2.4.16 auf 2.4.18 um etliches schneller bekommen.
Ist ein linux-2.4.18. Kann mir auch nicht vorstellen, das ich damit den nötigen Gewinn machen könnte. Ich mein, ist ja nicht so das ich die Performance um 50% verbessern will oder so, sondern ich hab hier eine Differenz von 7 Sekunden zu 20 Minuten.....das ist ein Unterschied von ca einer Trizillarde Prozent lol. Ok, aber im Ernst, liege ich mit meiner Annahme das das an den mounts liegt im grünen Bereich oder kann das unmöglich sein? Bernd -- One OS to rule them all, one OS to find them. One OS to bring them all, and in the darkness bind them In the land of Redmond, where the shadows lie.
Bernd Tannenbaum wrote:
Am Mittwoch, 1. Oktober 2003 13:23 schrieb Peter Wiersig:
Bernd Tannenbaum wrote:
Das einzige, was auf dem "langsamen" Server anders ist, sind die 20 gemounteten Resourcen (auf denen auch Dienste arbeiten - logs schreiben).
Auf dem Server "vmstat 1" aufrufen und mal so 10 Zeilen posten.
procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 0 0 0 0 370916 76044 349904 0 0 1 23 61 48 3 0 96 0 0 0 0 370916 76044 349904 0 0 0 0 618 104 1 1 98 0 0 0 0 370916 76044 349904 0 0 0 0 525 38 0 0100
Da lief jetzt aber kein grep, oder?
Ok, aber im Ernst, liege ich mit meiner Annahme das das an den mounts liegt im grünen Bereich oder kann das unmöglich sein?
Ich weiss nicht genau, aber kann mir das nicht wirklich vorstellen. -- Have fun, Peter
Am Mittwoch, 1. Oktober 2003 13:42 schrieb Peter Wiersig:
Bernd Tannenbaum wrote:
Am Mittwoch, 1. Oktober 2003 13:23 schrieb Peter Wiersig:
Bernd Tannenbaum wrote:
Das einzige, was auf dem "langsamen" Server anders ist, sind die 20 gemounteten Resourcen (auf denen auch Dienste arbeiten - logs schreiben).
Auf dem Server "vmstat 1" aufrufen und mal so 10 Zeilen posten.
procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 0 0 0 0 370916 76044 349904 0 0 1 23 61 48 3 0 96 0 0 0 0 370916 76044 349904 0 0 0 0 618 104 1 1 98 0 0 0 0 370916 76044 349904 0 0 0 0 525 38 0 0100
Da lief jetzt aber kein grep, oder?
Aaaaahhh, ok erst denken dann poste :) Asche auf mein Haupt, nein das war "vmstat" ohne Job. Nun folgend dazu "vmstat" mit laufendem grep: procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 1 0 0 0 370852 76052 351096 0 0 1 23 64 48 3 0 96 1 0 0 0 370852 76052 351140 0 0 0 0 522 42 99 1 0 1 0 0 0 370852 76052 351192 0 0 0 0 521 22 99 1 0 1 0 0 0 370852 76052 351236 0 0 0 304 532 62 99 0 1 1 0 0 0 370852 76052 351280 0 0 0 0 522 31 99 1 0 1 0 0 0 370708 76052 351324 0 0 0 196 552 124 96 3 1 1 0 0 0 370708 76052 351360 0 0 0 0 520 24 100 0 0 1 0 0 0 370708 76052 351400 0 0 0 0 624 123 98 2 0 1 0 0 0 370708 76052 351444 0 0 0 216 530 36 99 1 0 1 0 0 0 370708 76052 351480 0 0 0 0 521 37 100 0 0 1 0 0 0 370708 76052 351520 0 0 0 0 520 40 99 1 0
Ok, aber im Ernst, liege ich mit meiner Annahme das das an den mounts liegt im grünen Bereich oder kann das unmöglich sein?
Ich weiss nicht genau, aber kann mir das nicht wirklich vorstellen.
Hmm, also SWAP scheint er nicht zu benutzen, also scheint er doch kein RAM-Problem zu haben? Ich werd auf jeden Fall mal alle anderen laufenden Dienste auf der Kiste wegschiessen und weitersehen. Es läuft da noch ein komplettes LAMP, aber das läuft auf meinem Arbeitsplatzrechner auch und benutzt wird es kaum - nur ein paar Testdatenbanken... Bernd -- One OS to rule them all, one OS to find them. One OS to bring them all, and in the darkness bind them In the land of Redmond, where the shadows lie.
Hallo Bernd, On Wed, Oct 01, 2003 at 01:17:02PM +0200, Bernd Tannenbaum wrote:
habe einen Rechner eingerichtet, der Log-Verzeichnisse von ca. 20 verschiedenen Windows-Büchsen via "smbmount" mountet. Klappt auch prima, nur hab ich auf der Kiste ein wahnsinniges Performance-Problem. So braucht ein grep-job, den ich auf der Kiste anstosse (laut top erhält der 500MB RAM und 96% Prozessorleistung, kein SWAP) etwa 20 Minuten. Derselbe Job mit denselben Dateien braucht auf meinem Arbeitsplatzrechner (etwa leistungsgleich) ganze 7 Sekunden. Das einzige, was auf dem "langsamen" Server anders ist, sind die 20 gemounteten Resourcen (auf denen auch Dienste arbeiten - logs schreiben). Macht das mein System so langsam und wenn ja, gäbs Alternativen? (Samba würde ja andersrum mounten, das kann ich eigentlich nicht gebrauchen, hmm vielleicht gäbs da ein Workaround, wär das denn schneller?)
Ich gehe mal davon aus, dass der Rechner ganz normal arbeitet, wenn du das grep nicht auf die per samba gemounteten Verzeichnisse ausdehnst. Im anderen Fall durchsucht grep jede Datei. D.h. er überträgt jede Datei über das Netz. Das führt schnell zu engpässen. Das andere Problem sind Verzeichnisse die über samba eingehängt sind bei denen der remote rechner aber nicht mehr erreichbar ist. Dort treten seeehhhhrrr grosse Verzögerungen auf :) Ein anderes Problem könnte noch auftreten wenn die Windows Kisten die die logs schreiben gut ausgelastet sind. Dann haben die wenig Rechenleistung für den Transport von Daten über's Netz übrig. Greetings Daniel -- #!/bin/bash X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H* # for file in *.sh ; do head -n 3 $0 > $file ; done
Am Mittwoch, 1. Oktober 2003 14:02 schrieb Daniel Lord: Hallo auch,
Hallo Bernd,
On Wed, Oct 01, 2003 at 01:17:02PM +0200, Bernd Tannenbaum wrote:
habe einen Rechner eingerichtet, der Log-Verzeichnisse von ca. 20 verschiedenen Windows-Büchsen via "smbmount" mountet. Klappt auch prima, nur hab ich auf der Kiste ein wahnsinniges Performance-Problem. So braucht ein grep-job, den ich auf der Kiste anstosse (laut top erhält der 500MB RAM und 96% Prozessorleistung, kein SWAP) etwa 20 Minuten. Derselbe Job mit denselben Dateien braucht auf meinem Arbeitsplatzrechner (etwa leistungsgleich) ganze 7 Sekunden. Das einzige, was auf dem "langsamen" Server anders ist, sind die 20 gemounteten Resourcen (auf denen auch Dienste arbeiten - logs schreiben). Macht das mein System so langsam und wenn ja, gäbs Alternativen? (Samba würde ja andersrum mounten, das kann ich eigentlich nicht gebrauchen, hmm vielleicht gäbs da ein Workaround, wär das denn schneller?)
Ich gehe mal davon aus, dass der Rechner ganz normal arbeitet, wenn du das grep nicht auf die per samba gemounteten Verzeichnisse ausdehnst. Im anderen Fall durchsucht grep jede Datei. D.h. er überträgt jede Datei über das Netz. Das führt schnell zu engpässen.
Nope, der grep wird nicht in den dateien ausgeführt, die eingehängt sind. Dann hätt ich mir das ganze auch so erklärt, ist aber nicht der Fall.
Das andere Problem sind Verzeichnisse die über samba eingehängt sind bei denen der remote rechner aber nicht mehr erreichbar ist. Dort treten seeehhhhrrr grosse Verzögerungen auf :)
Ja kenn ich, ist hier aber ebenfalls nicht der Fall.
Ein anderes Problem könnte noch auftreten wenn die Windows Kisten die die logs schreiben gut ausgelastet sind. Dann haben die wenig Rechenleistung für den Transport von Daten über's Netz übrig.
Das stimmt soweit schon, die sind ganz gut ausgelastet....konnte allerdings eben ausprobieren, das es tatsächlich nicht an den smbmounts liegt. Hab die nach Absprache mit Kollegen unmountet, der grep ist genau so langsam wie vorher... Werde mich jetzt wohl auf andere Dinge konzentrieren müssen, die verantwortlich sein können....vielleicht die Festplatten, da ist ein Hardware-Array dran. Bernd -- One OS to rule them all, one OS to find them. One OS to bring them all, and in the darkness bind them In the land of Redmond, where the shadows lie.
Hallo, noch ein kleines Update meinerseits, falls jemand mitliest und ggf. noch ne Idee hat. Also: Ein grep-job, der auf anderen Maschienen 3-7 Sekunden dauert, dauert auf dem "Problemkind" 20 Minuten. Meine erste Vermutung, das 20 gemountete Windows-Verzeichnisse schuld waren, hat sich nicht bestätigt. Hab alle ungemountet, derselbe Effekt. An dem Rechner hing ein Hardware-Array, dachte dies könnte vielleicht aufgrund eines schlechten Treibers schuld sein. Also array weg, einfache Platte dran, dieselbe Installation, derselbe Effekt. Nun meine Frage: Was kann auf dem Rechner krumm sein, das er so langsam ist? Ein veralteter Kernel oder ähnliches kann nicht schuld sein, das eine Rechenoperation statt 7 Sekunden 20 Minuten dauert. da is doch bestimmt was in der Hardware im Eimer? Evtuell der RAM, oder sonstige Ideen? Bernd -- One OS to rule them all, one OS to find them. One OS to bring them all, and in the darkness bind them In the land of Redmond, where the shadows lie.
Hallo Bernd, On Wed, Oct 01, 2003 at 05:36:31PM +0200, Bernd Tannenbaum wrote:
noch ein kleines Update meinerseits, falls jemand mitliest und ggf. noch ne Idee hat.
hdparm -Tt /dev/XXX bonnie nachschauen ob du nicht zufällig irgend eine mega Datei "grepst" time dd if=/dev/zero of=100MB.zero bs=1M count=100 time dd if=/dev/zero of=100MB.zero bs=4M count=25 time dd if=/dev/zero of=100MB.zero bs=1k count=100000 lsof /dev/XXX Greetings Daniel -- Linux - life is too short for reboots.
Hallo, Am Mittwoch, 1. Oktober 2003 17:36 schrieb Bernd Tannenbaum:
Rechenoperation statt 7 Sekunden 20 Minuten dauert. da is doch bestimmt was in der Hardware im Eimer? Evtuell der RAM, oder sonstige Ideen?
Wirf doch mal memtest an und schau nach, was dein Arbeitsspeicher/Cache so für nen' Durchsatz hat!? Gruß Werner -- Werner Scharinger Geschäftsführender Gesellschafter der soft & hard Computerservice GmbH * Am Erlenbach 8 * 94032 Passau Tel. +49 851 33025 * Fax. +49 851 31725 * www.shcs.de Fördermitglied der Wirtschaftsjunioren Passau Mitglied der Strategiekommission der Wirtschaftsjunioren Deutschland c/o IHK für Niederbayern in Passau * Nibelungenstr. 15 * 94032 Passau
participants (4)
-
Bernd Tannenbaum -
Daniel Lord -
Peter Wiersig -
Werner Scharinger