Re: (Nachtrag) OT: Treiberauswahl für Diskless-NFS-PXE-System
Am Samstag, 23. Februar 2008 schrieb Thomas Halinka:
> Hallo Markus,
[...]
> > Hmm, klingt interessant (wenn auch jetzt nicht direkt für dieses
> > Projekt). Könntest davon eventuell mal nen bonnie++ Benchmark
> > machen?
>
> Bin zwar grad bei meiner freundin - kann ich quasi erst morgen
> nachreichen, aber hab mal auf die schnelle das hier ergoogelt, was
> soweit realistisch aussieht.
> http://www.paragon-cs.com/wordpress/?p=11
>
> Schick dir aber morgen n bonnie - was interessiert dich genau?
> ext3/ocfs2?
ocfs2 würde mich interessieren und wenn möglich nen bonnie++ von nem
ext3 auf dem gleichen phy-Plattensystem als Vergleichswert.
Hat OCFS eigentlich nennenswerte Vorteile gegenüber GFS?
> > Nach meinen Tests bisher schon. Zumal nach dem Starten der Cache
> > des Clients auch zum Tragen kommt und nicht mehr so viel
> > NFS-Kommunikation stattfindet. Im LAN ist UDP auch sehr zügig und
> > kommt ziemlich nah an die phy. Grenze des Netzes heran.
> >
> :) ne :) http://www.technomagesinc.com/papers/ip_paper.html
Naja, bei GBit muss das Plattensystem natürlich bereits entsprechend
schnell sein. Falls ich am WE mal Zeit habe kann ich nen NFS mal lokal
auf nem 6*15k RAID10 (>300MB/s) benchmarken.
Auf meinem privaten System habe ich mal nen bonnie laufen lassen und bin
mit dem NFS Ergebnis eigentlich zufrieden:
NFS(udp via localhost mit std-blocksize)
------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
4G 40594 77 34751 4 19271 5 35383 64 42414 3 140.5 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 1850 6 +++++ +++ 3518 11 2074 6 +++++ +++ 2470 6
XFS(gleiches Verzeichnis nur direkt im FS)
------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
4G 51480 99 58130 13 29499 9 47148 88 59793 6 195.6 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 2836 13 +++++ +++ 3701 14 2919 13 +++++ +++ 1960 7
Das es langsamer als Blockbasierte Verfahren ist verwundert mich auch
kaum, für meine Anforderungen ist es aber allemal ausreichend. Im
Vergleich da oben wird leider keine Angabe zur NFS/iSCSI Konfiguration
gemacht, es wird nichtmal erwähnt ob bei NFS TCP oder UDP verwendet
wurde.
> Zumal der Ram-Verbrauch Server-seitig doch recht beachtlich ist bei
> NFS, was mich dann wiederum zur Überlegung bringt, warum der Client
> auch "fett" sein soll :)
Hmm, naja ich kann mir erstmal nicht vorstellen was hier so viel
Speicher fressen soll. Wie gesagt es geht um nen read-only share.
Zum Testen hab ich hier zuhause mal mit einer VirtualBox 3 Instanzen
gestartet von einem WRAP Rechner der über 256MB RAM verfügt. Das lief
ohne Probleme und es lies sich auch gut arbeiten. Die CPU Last geht
schon hoch(bei einem 500Mhz Geode wohlgemerkt), aber die
Speicherauslastung ist normal:
# free
total used free shared buffers cached
Mem: 257144 252472 4672 0 23792 173748
-/+ buffers/cache: 54932 202212
--
Markus Schulz
This is Linux Land-
In silent nights you can hear the windows machines rebooting
Reply to: