[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Debian] xmms & nfs



On Mon, Oct 15, 2001 at 12:53:13AM +0200, Hartmut Figge wrote:

> hrm, hoffentlich langweilen wir nicht zu viele, da das ganze mit debian
> nichts zu tun hat.

Hardwareoptimierungen sind hier finde ich nicht offtopic. Solange es nicht
um die Registry geht oder den Fakt, daß Windows XP den eingebauten
"Firewall" unsichtbar vorübergehend deaktiviert, wenn du den Mediaplayer /
IE / Chat / etc. startest ... und von aussen(!) durch die
"Remoteunterstützung" ebenfalls deaktiviert werden kann.

siehe c't - sehr genialer Firewall. ;)
 
> Jens Benecke wrote:
> > earth:/dat      -> ds9:/tmp     : 31MB in 7s, ca 4 MB/s
> > ds9:/tmp        -> earth:/home  : 106MB in 18s, ca 5.5 MB/s
> > ds9:/tmp        -> earth:/dat   : 106MB in 95s, ca 1.2 MB/s (????)
 
> > Ich vermute daß entweder das daran liegt daß das /dat fast voll ist (8G
> > von 210G noch frei) oder daß LVM die Performance drückt. Mehr
> habe lvm noch nicht eingesetzt, ober obiges sieht nicht danach aus, als
> wuerde es an den 8GB liegen.  bin an deinen benchmarks durchaus
> interessiert.

Auf performance kams mir nicht an, sondern auf die Partitionierflexibilität
bzw. das "zusammenklatschen". für einen FTP Server ist es halt nun mal
deutlich einfacher, _ein 210G Volume zu haben wo _alles_ reinkommt, als
mehrere Unterpartitionen und dann immer symlinken und hin und herschieben
müssen.
 
> > Das sind drei aktuelle Maxtor-Platten (60+80+80G).
> > earth: ~# nice -n -19 hdparm -tT /dev/hd[abcd]
> >  Timing buffer-cache reads:   128 MB in  0.87 seconds =147.13 MB/sec
> >  Timing buffered disk reads:  64 MB in  2.28 seconds = 28.07 MB/sec
> hier faellt mir etwas auf:
> t900:/home/hafi# nice -n -19 hdparm -itT /dev/hda
>  Model=Maxtor 96147H8, FwRev=BAC51KJ0, SerialNo=N80908LC
>  Timing buffer-cache reads:   128 MB in  0.69 seconds =185.51 MB/sec
>  Timing buffered disk reads:  64 MB in  2.41 seconds = 26.56 MB/sec
 
> mir kommen deine ´T´-werte etwas gering vor. meine platte ist auch eine
> maxtor 60GB, 5400U/min, mit sicherheit also nicht schneller als deine

Hm. Chipsatz? (siehe proc/ide/via bei mir, auf beiden Rechnern)

----------VIA BusMastering IDE Configuration----------------
Driver Version:                     3.29
South Bridge:                       VIA vt82c686b
Revision:                           ISA 0x40 IDE 0x6
Highest DMA rate:                   UDMA100
BM-DMA base:                        0xc000
PCI clock:                          33MHz
Master Read  Cycle IRDY:            0ws
Master Write Cycle IRDY:            0ws
BM IDE Status Register Read Retry:  yes
Max DRDY Pulse Width:               No limit

 
> > > nicht die modernste platte, sollte aber fuer die begrenzung nicht
> > > massgeblich sein. auf dem t900 laeuft ne schnellere.
> > Eigentlich nicht. Obwohl die IBM Platte auch in der Realität niemals
> > das schafft, was hdparm behauptet.
> schon wieder fuehle ich zum testen provoziert.
 
> hafi@p166:~$ time cp datei datei2; sync	> real    0m28.936s
> hafi@t900:~$ time cp datei datei2; sync	> real    0m2.968s
> hafi@t900:~$ du -h datei			> 101M    datei
> auch auf p166

-rw-rw-r--    1 jens     jens     106377216 25. Jun 22:16 www2.avi

ds9:disk> time cp www2.avi www2.avi_;sync
real    0m20.846s

auf ds9 (1.4GHz) mit ner uralten IBM-DTTA-371010 10G Platte (nur DMA-33).

server: /dat# nice -n -20 time cp www2.avi www2.avi_;sync
0.07user 2.97system 1:30.07elapsed 3%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (135major+17minor)pagefaults 0swaps

im LVM-Volume auf earth (650MHz) mit den Maxtor Platten.

server: /home# nice -n -20 time cp www2.avi www2.avi_
0.03user 2.24system 0:26.50elapsed 8%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (135major+17minor)pagefaults 0swaps

auf einer normalen Partition. 


Alle Partitionen hier sind ReiserFS.
 
> interessant ist, das auf dem p166 das kopieren der datei laenger dauert
> als die uebertragung per NFS, der limitierende faktor scheint also
> tatsaechlich die platte zu sein.  beim t900 faellt mir auf, dass das
> kopieren schneller geht, als es hdparm fuer moeglich haelt :)

Hier habe ich eine urlahme Platte im 1.4er, dafür im 650er schnelle Platten
aber irgendwie hat das LVM die zahlreichen resize- und move-Experimente
übel genommen, jedenfalls in punkto Performance. Hm.
 
===========================================================================

On Mon, Oct 15, 2001 at 10:57:36AM +0200, Dirk Haage wrote:
> Hi!
> 
> Hmm, dann hätte ich die Erklärung. Der Server hat ein 120GB LV über 3
> Platten. 

Was wäre daran schlimm? LVM's overhead ist laut Entwickler pro
Leseoperation irgendwas mit einer Addition und einer Division mit Rest. Das
machen heutige Prozessoren zigmillionenmal, ohne überhaupt angeschaltet
werden zu müssen.  ;)

> > Das sind drei aktuelle Maxtor-Platten (60+80+80G).
> Die hab ich auch (40G,60G),

Prima, ein Vergleich. :)

> > earth: ~# nice -n -19 hdparm -tT /dev/hd[abcd]
> >  Timing buffer-cache reads:   128 MB in  0.87 seconds =147.13 MB/sec
> >  Timing buffered disk reads:  64 MB in  2.28 seconds = 28.07 MB/sec
> Aber mit ganz anderen Werten :(
> trinity:/home/dh# hdparm -itT /dev/hdb /dev/hde /dev/hdf
>  Timing buffer-cache reads:   128 MB in  4.59 seconds = 27.89 MB/sec
>  Timing buffered disk reads:  64 MB in  6.57 seconds =  9.74 MB/sec

Oops.
 
> Das ist ungefähr 1/3 der Geschwindigkeit :(
> Über NFS bekommen ich damit nicht mehr als 2 MB

Was sagen hdparm /dev/hdb (ohne -I)?
Was sagt 'cat /proc/ide/via' (falls VIA-Chipset)?

siehe oben ...


-- 
Jens Benecke ········ http://www.hitchhikers.de/ - Europas Mitfahrzentrale

Crypto regulations will only hinder criminals who obey the law.

-- 
-----------------------------------------------------------
Um sich aus der Liste auszutragen schicken Sie bitte eine
E-Mail an debian-user-de-request@lehmanns.de die im Subject
"unsubscribe <deine_email_adresse>" enthaelt.
Bei Problemen bitte eine Mail an: Jan.Otto@Lehmanns.de
-----------------------------------------------------------

937 eingetragene Mitglieder in dieser Liste.


Reply to: