On Fri, 19 Jun 2009, 11:43:56 +0200, Heinz Diehl wrote:
On 18.06.2009, Manfred Hollstein wrote:
1. Hauptspeicher auf 2GB beschraenkt (mem=2G) 2. Eine 16 GiB grosse Datei erzeugt 3. Diese Datei wird per "cp -va src dst" kopiert 4. 45 Sekunden, nachdem der Kopiervorgang gestartet wurde, versuche ich, einen Firefox zu starten; danach werden weitere Prozesse gestartet.
Mit dem Erzeugen einer 16 GB Datei erzeugst du auch gleichzeitig massiven I/O. Dafuer ist ext3 nur bedingt ausgelegt.
Unter Anderem deshalb benutze ich standardmaessig auch nur XFS, aber viele Leute wollen/muessen leider mit den Defaults leben...
Als Ergebnis muss man leider feststellen, dass im Default-Setup (openSUSE-11.1, XFS oder ext3 spielen keine Rolle
Die Betonung liegt auf "default setup".
Yep.
Wenn man aber den Default-Elevator von "cfq" auf "deadline" stellt, hat man voellig ohne Aufwand ploetzlich ein benutzbaren System; man verliert kaum I/O Performance, gewinnt aber deutlich an Interaktion bei solchen I/O intensiven Jobs. Auch hier war der Firefox bereits nach 18 Sekunden da.
Nach 18 sekunden? Das ist ja unertraeglich!
Wohl gemerkt, waehrend des Kopierens; normalerweise ist Firefox frisch gestartet bei mir nach ca. 8 Sekunden da, was auch eher sehr schlecht ist, aber da hatten wir ja auch schon diverse Threads...
Ich denke, dass alle Desktops oder sonstigen Systeme, bei denen eine gewisse Interaktion gefordert ist (ich wuerde einen Webserver z.B. durchaus dazu zaehlen), aktuell mit dem "deadline" Elevator viel besser funktionieren (und werde das auch intern bei Novell/SUSE propagieren); der "cfq" hat entweder einen richtig dicken Bug, oder er funktioniert eben nur richtig gut mit den ganz dicken DB oder sonstigen Workloads.
Dieses Thema wurde vor ca. 2 Monaten intensivst auf der lkml diskutiert, und ich habe selber mit Benchmarks und Tests beigetragen. CFQ hat so einige sehr performante Updates erfahren, die man allerdings mit den "veralteten" Distributions Kernen nicht mitbekommt. Ausserdem liegt das Hauptproblem am Filesystem.
Ich weiss.
elevator=deadline
Der dl Scheduler hat einige richtig dicke Bremsen, bei unbelastetem Betrieb setzt er naemlich die Latenz enorm hoch.
Wiederhole doch deinen Versuch bitte nochmal, wenn du alle beteiligten ext3 Partitionen vorher mittels
mount -o rw,noatime,data=writeback
gemountet und den Kernel auf 2.6.30 upgedatet hast (mit cfq).
Den Test mit "noatime,data=writeback" habe ich gemacht, wodurch die Responsiveness zwar (etwas) besser wurde, dafuer aber die Zeit fuers Kopieren erstaunlicherweise deutlich laenger wurde... Ich kann Kernels (leider) nicht beliebig wechseln, stimme dir aber sehr wohl zu, dass mit einem 2.6.30 dieses Szenario wahrscheinlich besser laufen wuerde; ich habe aber auch lange genug selber entwickelt, um zu wissen, dass mit jeder neuen Version oftmals in anderen Bereichen dann wieder etwas verschlimmbessert wurde... Im Produktiveinsatz gibt es aber Gruende (Applikationszertifizierungen etc.), warum das eben nicht geht. Den Upgrade auf 2.6.30 werde ich dann machen, wenn er auf meinen ansonsten produktiv genutzten Systemen moeglich sein wird, soll heissen, dann, wenn's ihn in einem offiziell gewarteten Zustand in einem SLES geben wird, also wohl eher nie...
Ich habe noch irgendwo den fsync-tester von Theodore Tso auf der Platte, den kann ich dir fuer solche Zwecke gerne raussuchen, wenn du willst.
Ich selber benutze xfs und habe keine Latenz-Probleme :-)
Hmm, auch nicht mit dem cfq, dem 2.6.27.23-0.1 Kernel, und in einem vergleichbaren Anwendungs-Szenario? Cheers. l8er manfred -- 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