Hallo, bitte nicht böse sein, irgendwie ist mir das Folgende ziemlich lang geraten, auch weil ich noch einige Bonnie-Testergebnisse eingefügt habe. Es ist eben, wie so oft: Eine Antwort zieht 10 neue Fragen nach sich ... Ich hoffe aber, daß sie, wie vielleicht auch die Bonnie-Tests, doch auch ein wenig erhellend wirken. Am Mi, den 08.08.2007 schrieb David Haller um 4:38:
Hallo,
Am Die, 07 Aug 2007, Thomas Michalka schrieb:
Am Mo, den 06.08.2007 schrieb David Haller um 14:48:
Am Mon, 06 Aug 2007, Thomas Michalka schrieb:
Nun, ich habe einen schon etwas betagten Rechner mit ASUS-Board A7V8X mit einem VIA KT400 Chipsatz, mit einem Athlon XP 1800+ (1533 MHz) und 1 GByte RAM. Zwei UDMA-(PATA)-Platten nicht zu vergessen. [..] Laufen tut darauf eine SuSE 9.1 mit dem urspr. Kernel 2.6.4-52 der Distribution und dem KDE 3.2.1. [..]
der Platten. Auf beiden Platten gibt es eine Swap-Partition, eine mit 1 GB, die andere mit 3 GByte (wollte mal mit großem Swap-Space
Das ist zuviel des guten. Bei Swap hilft "viel" nicht viel, weil das System beim ein- und ausswappen mehr oder weniger unbenützbar wird.
Als ich vor langen Zeiten sie 7.3 installierte, habe ich nach einem Beispiel im SuSE- Handbuch partitioniert, und da war Swap-Space = RAM, allerdings bei weniger als 1 GB. Trotzdem dachte ich, für 1 GB RAM ungefähr nochmal soviel Swap-Space.
Nuja, wenn du mal guckst wie lange die Platte rödelt um 1 GB ein- oder auszuswappen... Ich denke nicht, daß mehr als das 1 GB sinnvoll ist (modulo STD, s.u.).
Zuerst hatte ich nur eine Platte im System. Auf der zweiten hätte ich also nur noch wenig Swap-Space vorsehen müssen. Aber eben schon etwas, damit, wie Andre Tann schrieb, das System sich die vielleicht gerade nicht aktive Platte für's Paging aussuchen kann. Andererseits: selbst wenn 2 GB = 1 GB RAM + 1 GB Swap belegt sind, so wird doch in der Praxis nicht ständig 1 GB am Stück hin- und hergeschoben, sondern nur Programmteile bzw. Daten, die gerade nicht oder gerade wieder benötigt werden. Wäre es nicht eine gute Strategie, etwas mehr als nur ca. 4 MB RAM freizuhalten? Damit neue Programme und/oder Daten schnell geladen werden können. Dann ist das RAM zwar wieder fast voll, aber in ruhigeren Zeiten könnte das System wieder Daten und Code auslagern, so daß wieder RAM, z.B. für Platten-Cache frei wird. Ich beobachte nämlich eindeutig, daß das System beim Hintereinander-Beenden vieler Programme tendenziell das tut, aber für meinen Geschmack zu wenig. Natürlich, wenn man dieselben Programme erneut starten würde, wäre das ein Schuß ins Bein. Aber ist es nicht wahrscheinlicher, daß man ein Programm, wenn man es beendet, nicht mehr braucht und eher der Start anderer Anwendungen ansteht? Naja, das hängt wohl äußerst stark vom Nutzer ab. Folglich sollte so ein Systemverhalten auf die Benutzergewohnheiten anzupassen sein, oder es sollte selber aus der Erfahrung lernen. Ich wiederhole mich jetzt in der folgenden Passage vielleicht teilweise, aber konkretisiere auch etwas meine Vorstellung, wie ich hoffe.
Die 3 GB auf der zweiten Platte waren nur wegen der Erfahrung mit Mozilla. Wieviel Spap-Space braucht man eigentlich. wenn man ein System in den Suspend- To-Disk-Zustand bringt? Wird dann nicht der gesamte Hauptspeicher in den Swap- Space ausgelagert?
Ja, d.h. dafür muß swap >= RAM sein.
Dann sind unter dem Aspekt meine insgesamt 4 GB auch zuviel des Guten. Aber ist diese Menge auch schädlich? Wohl nur, wenn mehr als 2 GB ausgelagert wären. Ich hatte aber fast nie mehr, als ca. 1,9 GB virtuelle Speicherbelegung, allerdings damals noch bei insgesamt 2 GB virtuellem Speicher. Übrigens beobachtete ich einen Unterschied zwischen 2 GB und 5 GB virtuellem Speicher (immer 1 GB RAM): Bei dem kleineren virtuellen Speicher wurde das System, wenn der Speicher nahezu voll war, so gut wir unbenutzbar, will heißen, es konnte nicht mal mehr "normal" heruntergefahren werden (Alt+Druck + u, + s, + b gingen schon noch). Das ist klar, weil das System nur noch kleine Häppchen zwischen Swap und RAM hin- und herschieben kann. Und das kann dauern ... Bei dem größeren virtuellen Speicher mit entsprechender Belegung wird das System zwar ziemlich träge, aber man kann, wenn man die nötige Geduld aufbringt, nach und nach Anwendungen beenden. Nebenbei: Wie funktionieren 5 GB virtueller Speicher auf einem 32-Bit-System überhaupt (s. u. zu maximaler Dateigröße von 2 oder 4 GB)?
Sprich swap ist für "länger nicht gebrauchtes" und als Notnagel da. Und wenn man doch mal mehr braucht kann man "mal eben" ein swapfile verwenden.
Kann man jede Datei mit "swapon <filename>" als Spapfile verwenden? Oder muß man vorher noch was anderes beachten?
Z.B. für ein 500 MB Swapfile:
1. Datei erzeugen: dd if=/dev/zero of=SWAPFILE bs=1M count=500 2. Swap anlegen: mkswap SWAPFILE 3. aktivieren: swapon SWAPFILE ... 4. deaktivieren: swapoff SWAPFILE [5. löschen]
Ist ja cool, was alles geht im laufenden Betrieb ... So habe ich den 3-GB-Swap-Bereich gestern einfach mal ausgeschaltet. Seither läuft das System nur noch mit 1 GB Swap bei 450 MB Belegung desselben. Die Performance ist fühlbar weder schlechter noch besser. Ich schließe daraus, daß "zuviel" Swap nicht unbedingt schädlich sein muß. Aber vielleicht überlagert ein Problem mit meinen Platten das ganze einfach.
Ich hab hier zu meinen 320 MB RAM 3x~512 MB Swap und das auch nur, weil ich die Platten halt so partitioniert hab. Belegt sind im Swap selten mehr als 100 MB, und da fast nur Teile von spamd, mozilla und X.
Wenn ich das SuSE-Handbuch richtig verstanden habe, dann sollte auf jeder Platte im System ein Swap-Bereich sein? Habe aber keine Begründung gelesen.
Nö, von "sollen" kann keine Rede sein. Aber es kann sinnvoll sein, denn bei gleicher Priorität wird automatisch auf alle Platten mehr oder weniger gleichmäßig verteilt geswappt.
Noch eine Überlegung dazu: Sollte der Swap-Space nicht am besten im "schnellsten" Bereich einer Platte liegen, also da, wo die Bits am schnellsten am Kopf vorbeirasen, d.h. am äußeren Rand der Scheiben? Sind das die niedrigen oder die hohen Zylindernummern? Die Transferraten wären höher und die Zugriffzeiten wären kleiner (wg. kleinerer Latenzzeiten). Wenn das grundsätzlich richtig ist, dann wären bei mehreren Platten auch mehrere kleinere Swap-Spaces günstiger, als ein großer, womöglich auf nur einer Platte - nicht zuletzt auch wegen der möglichen Zugriffsverteilung - vorausgesetzt, die Platten sind alle einigermaßen flott.
[...]
$> hdparm -v /dev/hda [..] geometry = 19929/255/63, sectors = 320173056, start = 0 $> hdparm -v /dev/hdb [..] geometry = 65535/16/63, sectors = 160836480, start = 0
Sieht ok aus, aber kontrolliere mal, wie die Geometrie im BIOS eingestellt ist und wie die Partitionierungsgeometrie ist. Bei Abweichungen kann die Platte durchaus unerträglich lahm werden.
Mache ich - vorher wollte ich aber noch mit bonnie die Platten-Performance testen.
Geht das mit bonnie denn, ohne dabei die Daten zu schreddern?
Habe es gestern probiert mit einer 2047 MB großen Datei. Es wurde nix geschreddert :-) Ich dachte zuerst, daß man einen gewissen Bereich im RAM frei haben muß, sonst würde Paging das Meßergebnis verfälschen. Andererseits könnte es sein, daß bei so wenig freiem Speicher, wie gerade bei mir (ca. 4 MB), es so gut wie unmöglich ist, daß das System Schreib- und Leseaktionen cached. Damit wäre das Ergebnis einigermaßen realistisch, zumal beim Lesen eine gewisse Datenmenge im Speicher immer wieder überschrieben werden kann. Beim Schreiben kann und wird wohl immer wieder auf denselben Bereich im Speicher zugegriffen werden (ohne, daß es dieselben Daten sind, denn sonst könnte ja der platteninterne Cache die Ergebnisse verfälschen). Um es vorwegzunehmen: 1. Paging verbraucht tatsächlich einiges an CPU-Zeit und kostet Plattendurchsatz. 2. Caching gibt es, und das nicht unerheblich (bis 45-MB-Platten-Cache im RAM, s.u.) Das Ergebnis des ersten Tests von Bonnie: ---Sequential Output (nosync)--- ---Sequential Input-- --Rnd Seek- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --04k (03)- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU terra 1*2047 19762 75.8 21130 16.7 10458 10.0 16437 67.2 30065 13.0 91.8 1.1 ... und des zweiten Tests unter gleichen äußerlichen Bedingungen: ---Sequential Output (nosync)--- ---Sequential Input-- --Rnd Seek- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --04k (03)- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU terra 1*2047 19674 75.5 14788 12.0 10915 10.6 21260 86.8 30187 13.2 51.5 0.6 ... und des dritten Tests unter gleichen äußerlichen Bedingungen (hier setzte das System den Platten-Cache im RAM auf bis 45 MB herauf!): ---Sequential Output (nosync)--- ---Sequential Input-- --Rnd Seek- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --04k (03)- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU terra 1*2047 18815 72.2 22696 18.0 10291 10.1 19764 81.3 30046 13.1 79.8 0.9 Zum Vergleich mit einer nur 100 MB großen Testdatei (hier setzte das System den Speicherbereich für Platten-Cache auch nur auf bis zu 40 MB herauf!): Bonnie: Warning: You have 1012MB RAM, but you test with only 100MB datasize! Bonnie: This might yield unrealistically good results, Bonnie: for reading and seeking and writing. [...] ---Sequential Output (nosync)--- ---Sequential Input-- --Rnd Seek- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --04k (03)- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU terra 1* 100 21847 83.7 26477 20.2 9224 8.6 10777 43.1 16793 7.1 116.8 1.1 Einige Teilergebnisse sind fast identisch, andere signifikant unterschiedlich, insgesamt also recht uneinheitliche Ergebnisse. Bei der 100-MB-Testdatei ist das Random-Seek-Ergebnis "viel zu gut", da in einem RAM-Plattencache von bis zu 40 MB keine Latenzzeiten auftreten. Warum aber beim sequentiellen und blockweisen Lesen nur halb so schnelle Transferraten auftreten, erschließt sich mir nicht. Offensichtlich ist auch, wenn man die drei Tests mit der 2047-MB-Datei vergleicht, daß man nicht so einfach für vergleichbare Testbedingungen sorgen kann. Auffällig ist, daß bei den sequentiellen Operationen die Last extrem hoch wird (> 13) und heftiges Paging auftritt. Beides korrespondiert wohl miteinander angesichts der durchaus nicht 100-prozentigen CPU-Auslastung durch Bonnie selber. Vielleicht sollte ich für die Bonnie-Tests auch noch den verbliebenen Swap ausschalten, dann kann der Kernel weder CPU-Zeit noch Platten-Performance für Paging verbrauchen, oder? Aber das traue ich mich nicht recht, denn was passiert mit den Programmen, deren Daten dann nicht mehr ins RAM passen? Allerdings gibt's bei Bonnie, und damit bei obigen Testergebnissen noch einen Haken, und das ist die Größe der Testdatei, die mindestens viermal so groß, wie das RAM sein sollte. Aus der Bonnie-Anleitung: "-s size-in-Mb The number of megabytes to test with. If you do not use this, Bonnie will test with a 100Mb file. In this discussion, Megabyte means 1048576 bytes. If you have a computer that does not allow 64-bit files, the maximum value you can use is 2047. It is important to use a file size that is several times the size of the available memory (RAM) - otherwise, the operating system will cache large parts of the file, and Bonnie will end up doing very little I/O. At least four times the size of the available memory is desirable." Ich kann mit einem 32-Bit-System 4096 MB = 4 x 1024 MB nicht adressieren? Allerdings sollte ich mit 32-Bit-Adressen doch 2^32 = 4096 x 1024^2 Adressen bei byte-weiser Adressierung ansprechen können. Das wäre doch 4096 MByte. Warum dann doch nur 2047 MB = (2^31 - 1) MB? Bei mehr bekomme ich eine Fehlermeldung (s.u.). Eine Workaround wäre vielleicht, wenn man das Caching ebenso wie das Swapping komplett ausschalten könnte, weil dadurch die Lese- und Schreiboperationen einerseits weniger ausgebremst (Paging) und andererseits nicht noch beschleunigt (Caching) würden. Das System sollte mit der Platte nicht viel anderes zu tun habe, als die Testdatei zu transferieren. Kann man das Caching ausschalten, und wenn ja, wie? Wenn man Bonnie übrigens mit einer Testdateigröße über der für das System maximal zulässigen aufruft, dann bekommt man folgende Fehlermeldung: $> bonnie -d /local/6Y16/backup -s 8191 | tee 2007-07-08\:\:05__bonnie.log Bonnie: Warning: You have 1012MB RAM, but you test with only 8191MB datasize! Bonnie: This might yield unrealistically good results, Bonnie: for reading and seeking and writing. File too large for 32-bit machine, sorry Use multiple volumes instead (option -v) Witzig ist ja gleich die erste Zeile der Meldung - die kommt wohl immer ;-) Aufschlußreich hingegen letzte Zeile! Leider ist diese Option weder in der manpage noch auf der Website von Tim Bray erklärt. Anhand der Meldungen wird man wohl nur eine Volume-Zahl angeben müssen. Mal sehen ... es geht: $> bonnie -d /local/6Y16/backup -s 2047 -v 6 -p 10 -S 10000 | tee 2007-07-08\:\:07__bonnie.log Bonnie 1.4: File '/local/6Y16/backup/Bonnie.31488', size: 2146435072, volumes: 6 [...] ---Sequential Output (nosync)--- ---Sequential Input-- --Rnd Seek- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --10k (10)- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU terra 6*2047 17859 69.6 20482 16.6 8837 8.7 17319 70.5 12255 5.7 76.5 1.0 $> bonnie -d /local/6Y16/backup -s 2047 -v 2 -p 10 -S 10000 | tee 2007-07-08\:\:08__bonnie.log Bonnie 1.4: File '/local/6Y16/backup/Bonnie.31941', size: 2146435072, volumes: 2 [...] ---Sequential Output (nosync)--- ---Sequential Input-- --Rnd Seek- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --10k (10)- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU terra 2*2047 19419 74.0 22816 17.8 9806 9.5 21211 85.9 26811 11.5 88.1 1.2 Auch hier wieder uneinheitliche Ergebnisse, besonders, was das blockweise Lesen von Platte angeht. Im zweiten Versuch mehr als doppelt so schnell bei doppelter CPU-Nutzung. Ich denke, das hier die oben genannten und vielleicht noch andere Einflüsse eine erhebliche Rolle spielen. Ich muß mir mal überlegen, ob und wie man reproduzierbar gleiche Testbedingungen erreichen kann. Zwischenfazit: Sollten die Ergebnisse mit großen "multiple volumes" aber doch einigermaßen aussagekräftig sein, dann hätte ich ja mit der ca. 2 Jahre alten Platte eigentlich gar kein Performance-Problem (hoffentlich fühlt Ihr Euch jetzt nicht auf den Arm genommen ...), sondern ich bräuchte, wenn ich viele Anwendungen geladen haben will, einfach nur mehr RAM. Was mir nur seltsam vorkommt: ich konnte unter der 7.3 mit gleicher Hardware viiiel mehr Anwendungen geladen halten, als heute unter der 9.1. Wenn ich nur daran denke, daß ich immer zig Webseiten in Mozilla-Fenstern offen hatte ... Deswegen doch noch ein paar Fragen ... :-\
Also 'fdisk -l', die Geometrie wird in der zweiten Zeile angezeigt.
$> fdisk -l /dev/hda Platte /dev/hda: 163.9 GByte, 163928604672 Byte 255 Köpfe, 63 Sektoren/Spuren, 19929 Zylinder Einheiten = Zylinder von 16065 * 512 = 8225280 Bytes
$> fdisk -l /dev/hdb Platte /dev/hdb: 82.3 GByte, 82348277760 Byte 255 Köpfe, 63 Sektoren/Spuren, 10011 Zylinder Einheiten = Zylinder von 16065 * 512 = 8225280 Bytes
Eieiei... Die Platten sind beide mit */255/63 partitioniert ...
Ist das generell ungünstig, wenn sie entgegen ihrer physischen Geometrie anders partitioniert sind? Ich kann mich auch gar nicht erinnern, daß ich etwas anderes als die Zylindergrenzen zur Festlegung der Partitionsgrenzen wählen konnte. Wie stellt man die Geometrie beim Partitionieren ein?
Auch interessant ist die Ausgabe von 'cat /proc/ide/hd?/geometry'
$> cat /proc/ide/hda/geometry physical 16383/16/63 logical 19929/255/63
hda wird also logisch so angesprochen, wie sie partitioniert ist, aber dennoch entspricht die logische Geometrie nicht der physischen. Könnte das auch eine Bremse sein?
$> cat /proc/ide/hdb/geometry physical 16383/16/63 logical 65535/16/63
... aber /dev/hdb wird logisch mit einer (Dummy-[1]) */16/63 Geometrie angesprochen. Das kann durchaus eine erstklassige Bremse sein.
Hier entspricht zwar die logische z.T. der physischen Geometrie, aber wiederum nicht der partitionierten Geometrie in der Kopfzahl. Also hier vielleicht eine andere Bremse als bei der hda?
Wie sieht's mit den Daten auf hdb aus? Gibt's ein Backup?
Keines der ganzen Platte, aber der wichtigen Daten schon.
Evtl. hilft übrigens ein Kernelparameter:
hdb=10011,255,63
Verliere ich hiermit evtl. Daten (hast oben nach einem Backup gefragt)?
Wobei du im BIOS ja erstmal nur schauen sollst, was da eingestellt ist. Relevant sind die Einstellungen nur bedingt, und man kann die auch ohne Probleme an die Realität auf der Platte anpassen ;)
Klar, wenn das System mal läuft, sind die BIOS-Einstellungen für das Linux-System ja wurscht ... Viele Grüße, Tom -- 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