Re: [1/2 OT] MySQL Storage Files
On Day 48 of Chaos 3171, Hagen Kuehnel wrote:
> On Thu, Feb 17, 2005 at 03:17:53AM +0100, Thomas Kosch wrote:
>
>> Wobi ich diese Aussage bezweifeln möchte. Ich hatte ende letzten Jahres
>> das "Vergnugen" das ganze mit einem Gesamtdatenbankvolumen von 20 GB
>> durchziehen zu dürfen. Mit dem Weg mysqldump | gzip | ssh | gunzip |
>> mysqldump war das ganze in rund 8 Minuten gegessen. Ich glaube nicht das
>> ich schneller gewsen wäre wenn ich das Ganze "binär" kopiert hätte.
>
> nette Performance. Das dürfte das absolute Minimum für den Transfer
> gewesen sein, gzip sollte in 0,nichts komprimiert haben.
Wie kommst du auf das schmale Brett?
>
> Du arbeitest mits SCSI-320? Darf man fragen, warum dann der Server
Nein
> ausgetauscht werden sollte? ;)
>
> 1min 320MBit/s dump der Daten von scb nach sca
Nein, rund 8 min. (was meinst du mit scb und sca?)
> 1min 320MBit/s gzip mit read von sca und write scb
Nein, rund 8 min. (was meinst du mit scb und sca?)
> 3,5min Transfer der Daten via 100MBit/s
Nein, rund 8 min.
> 2min zurückspielen mit optimierten I/O auf zwei Platten
Nein, rund 8 min.
> CPU-Zeit entfällt, da es wohl ein Quad-Opteron war und diese nicht ins
> Gewicht fiel (Ironie). Obiges zeigt, dass mit guter Hardware allein
> deine ermittelten Grenzen gesetzt werden, von der CPU-Last durch das
Nein. Ich hatte das was ich geschrieben habe nicht ohne Grund so
geschrieben wie ich es gschrieben hatte.
ttyl8er, t.k.
--
Ich vergleiche normalerweise auch nicht im Nahverkehr eingesetzte Transrapids
mit im Fernverkehr eingesetzten Planierraupen, auch wenn beide Sitze haben
(wobei ich, nach kurzen Nachdenken, die Rolle der Planierraupe an Emacs
vergeben würde). -- Uwe Ohse über emacs vs. Visual C++ in d.a.s.r
Reply to: