ubuntu 10.10 amd64 + brtfs

easteregg

easteregg

0
Heyho

ich hab das gefühl hier stimmt was nicht. ich hab maverick mit btrfs auf ner 500gb seagate sata platte installiert und (mit ahci aktiv) und hab das gefühl irgendwie läuft das system nur mit angezogener bremse!

alleine um gimp zu installieren (ings. 6 pakete über apt) warte ich hier mittlerweile 6minuten (ohne dl)

wenn ich in dem laufwerksmanager die benchmarks laufen lasse stimmt alles, sowohl transferrate (70mb) und zugriffszeit (13ms) (is ne 7,2k rpm platte)

aber ich hab das gefühl, ich bin bei allem was ich starte mit angezogener handbremse unterwegs

ne wahllos gegriffene datei macht scheinbar keine probleme


Code: 
easteregg@x2-ee:~$ dd if=/home/easteregg/Games/StarCraft\ II/Mods/Core.SC2Mod/Backup.MPQ of=/dev/null bs=1M
235+1 records in
235+1 records out
246912155 bytes (247 MB) copied, 3.53245 s, 69.9 MB/s

is das jetzt mein subjektives empfinden und liegt daran, dass ich im laptop mit ubuntu 10.10 mit ner intel ssd verwöhnt ist oder kanns sein, dass btrfs scheinbar doch noch nich so alltagstauglich ist?

hat jemand ne idee, wie ich das ganze mal sinvoller benchen könnte?
oder allgemein tuningtipps zu btrfs ?

der vollständigkeit halber:

Code: 
easteregg@x2-ee:~$ uname -a
Linux x2-ee 2.6.35-27-generic #48-Ubuntu SMP Tue Feb 22 20:25:46 UTC 2011 x86_64 GNU/Linux
 
Mit hdparm lassen sich die Festplatten-Durchsätze zumeist besser ermitteln. Wenn es Probleme beim Installiere, also Schreiben auf die HDD gibt, sollte man auch den Schreibdurchsatz messen und nicht nur das Lesen: dd if=/dev/zero of=foo bs=1024k count=100 conv=fsync (wichtig: Um Caching zu vermeiden, die fsync-Option setzen). Außerdem sollte man mit iostat im Auge behalten was sonst noch auf der HDD los ist und diese Werte zu den Messergebnissen dazu addieren. Gerade bei Ubuntu rödelt ja im Hintergrund gern mal ein Indexing-Tool usw. rum. Allerdings sind knapp 70MB/s für eine 7200rpm-Platte eigentlich normal.
 
benchmark ergebnisse sind alle top, aber wie gesagt, wenn man zum installen von gimp mehr als 5min braucht kommt mir das irgendwie komisch vor.


Code: 
easteregg@x2-ee:~$ dd if=/dev/zero of=foo bs=1024k count=100 conv=fsync
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 2.18697 s, 47.9 MB/s

schreibraten sind auch normal.
ich hab halt das gefühl , dass das dateisystem irgendwie probleme bereitet, kanns aber nicht irgendwie überprüfen.
 
hm also iotop is deutlich unter 2mb/s im schnitt...

hier ist mal der getimte installlog

Code: 
easteregg@x2-ee:~$ time sudo apt-get install gimp
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
  gimp-data libbabl-0.0-0 libgegl-0.0-0 libgimp2.0 libhal1 libmng1
Suggested packages:
  gimp-help-en gimp-help libgimp-perl gimp-data-extras
The following NEW packages will be installed:
  gimp gimp-data libbabl-0.0-0 libgegl-0.0-0 libgimp2.0 libhal1 libmng1
0 upgraded, 7 newly installed, 0 to remove and 17 not upgraded.
Need to get 0B/8,245kB of archives.
After this operation, 25.5MB of additional disk space will be used.
Do you want to continue [Y/n]? y
Selecting previously deselected package libgimp2.0.
(Reading database ... 177104 files and directories currently installed.)
Unpacking libgimp2.0 (from .../libgimp2.0_2.6.10-1ubuntu3.1_amd64.deb) ...
Selecting previously deselected package gimp-data.
Unpacking gimp-data (from .../gimp-data_2.6.10-1ubuntu3.1_all.deb) ...
Selecting previously deselected package libbabl-0.0-0.
Unpacking libbabl-0.0-0 (from .../libbabl-0.0-0_0.0.22-1build1_amd64.deb) ...
Selecting previously deselected package libgegl-0.0-0.
Unpacking libgegl-0.0-0 (from .../libgegl-0.0-0_0.0.22-2ubuntu2_amd64.deb) ...
Selecting previously deselected package libhal1.
Unpacking libhal1 (from .../libhal1_0.5.14-0ubuntu6_amd64.deb) ...
Selecting previously deselected package libmng1.
Unpacking libmng1 (from .../libmng1_1.0.10-1_amd64.deb) ...
Selecting previously deselected package gimp.
Unpacking gimp (from .../gimp_2.6.10-1ubuntu3.1_amd64.deb) ...
Processing triggers for hicolor-icon-theme ...
Processing triggers for man-db ...
Processing triggers for menu ...
Processing triggers for desktop-file-utils ...
Processing triggers for python-gmenu ...
Rebuilding /usr/share/applications/desktop.en_US.utf8.cache...
Processing triggers for python-support ...
Setting up libgimp2.0 (2.6.10-1ubuntu3.1) ...
Setting up gimp-data (2.6.10-1ubuntu3.1) ...
Setting up libbabl-0.0-0 (0.0.22-1build1) ...
Setting up libgegl-0.0-0 (0.0.22-2ubuntu2) ...
Setting up libhal1 (0.5.14-0ubuntu6) ...
Setting up libmng1 (1.0.10-1) ...
Setting up gimp (2.6.10-1ubuntu3.1) ...
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place
Processing triggers for menu ...

real	3m16.423s
user	0m3.620s
sys	0m4.650s

rein von dem was isntalliert werden sollte (25.3mb / 203s) = 0.124630542mb/s
sprich im schnitt ~125kb/s

den io diskcache habsch vorher rausgeworfen und die libs und gimp selbst vorher gepurged, also wirklich neuinstallation.

cpu last selbst war verschwindent gering.
ist halt die frage ob das "normal" is und ich nur von der ssd verwöhnt, oder ob da irgendwo was klemmt ....
 
>3 Minuten für die paar MB ist tatsächlich kein normaler Zustand, auch wenn man das nicht in der Art umrechnen kann, wie du es getan hast. Schliesslich wird zeitgleich auch auf die Apt-DB zugegriffen, es werden Zugriffsrechte gesetzt, Skripte aus den Paketen ausgeführt etc.. Es scheint also ggf. ein Problem mit gleichzeitigen Zugriffen von mehreren Programmen auf die HDD vorzuliegen. Ob das ggf. am Dateisystem liegt kann ich allerdings nicht sagen, da ich mit BTRFS noch nicht gearbeitet habe. Ich kann mir da nur vorstellen, dass es ggf. an der Datenkompression liegt, sofern diese aktiviert ist. Bei ZFS z.B. reisst diese die Performance auch ziemlich in den Keller, was sich in einem ähnlichen Verhalten zeigt... Benchmarks laufen total flott, aber im Betrieb gibt's dann Probleme. Allerdings müsste dann auch die CPU-Last wesentlich höher sein und time zeigt ja, dass nur knapp 8s mit der CPU verbracht werden. Ggf. machen auch die vielen kleinen Dateien Probleme, weil ja beim Anlegen der Dateien Prüfsummen erstellt werden. Lass doch mal dd in einer Schleife laufen und lasse viele (>100) wenige kb (1-2kb) große Dateien erstellen. Dann sollte sich zumindest zeigen ob das Problem bei den vielen kleinen Dateien liegt. Ob es an den parallelen Zugriffen liegt könntest du rausbekommen indem du mehrere dd-Prozesse gleichzeitig laufen lässt.
 
ich sehe, das is mal nen grund mich mit simplen bash scripten zu beschäftigen, *finger knack*, *tee koch* ... auf gehts ! ;D
ich melde mich sobald ich mehr infos hab....

ansonst bin ich wohl laut google nich der einzige mit dem problem!
 
ha nich schlecht her specht.
dpkg nutzt ziemlich häufig sync um die daten auch wirklich auf der hdd geschrieben zu wissen.

es gibt in den launchpads ne no-sync version, weil eben genau das btrfs extremst bremst, da gibts auch diverse bugreports dazu!

fakt ist, das hier is ne reine testkiste, damit habsch keine schmerzen beim crash (wie oft kommt schon nen stromausfall oder nen total kernelcrash vor :D ) und vondaher ganz smooth die no-sync version einsetzen kann... :)

Code: 
easteregg@x2-ee:~$ time sudo apt-get install gimp
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
  gimp-data libbabl-0.0-0 libgegl-0.0-0 libgimp2.0 libhal1 libmng1
Suggested packages:
  gimp-help-en gimp-help libgimp-perl gimp-data-extras
The following NEW packages will be installed:
  gimp gimp-data libbabl-0.0-0 libgegl-0.0-0 libgimp2.0 libhal1 libmng1
0 upgraded, 7 newly installed, 0 to remove and 36 not upgraded.
Need to get 0B/8,245kB of archives.
After this operation, 25.5MB of additional disk space will be used.
Do you want to continue [Y/n]? y
Selecting previously deselected package libgimp2.0.
(Reading database ... 177104 files and directories currently installed.)
Unpacking libgimp2.0 (from .../libgimp2.0_2.6.10-1ubuntu3.1_amd64.deb) ...
Selecting previously deselected package gimp-data.
Unpacking gimp-data (from .../gimp-data_2.6.10-1ubuntu3.1_all.deb) ...
Selecting previously deselected package libbabl-0.0-0.
Unpacking libbabl-0.0-0 (from .../libbabl-0.0-0_0.0.22-1build1_amd64.deb) ...
Selecting previously deselected package libgegl-0.0-0.
Unpacking libgegl-0.0-0 (from .../libgegl-0.0-0_0.0.22-2ubuntu2_amd64.deb) ...
Selecting previously deselected package libhal1.
Unpacking libhal1 (from .../libhal1_0.5.14-0ubuntu6_amd64.deb) ...
Selecting previously deselected package libmng1.
Unpacking libmng1 (from .../libmng1_1.0.10-1_amd64.deb) ...
Selecting previously deselected package gimp.
Unpacking gimp (from .../gimp_2.6.10-1ubuntu3.1_amd64.deb) ...
Processing triggers for hicolor-icon-theme ...
Processing triggers for man-db ...
Processing triggers for menu ...
Processing triggers for desktop-file-utils ...
Processing triggers for python-gmenu ...
Rebuilding /usr/share/applications/desktop.en_US.utf8.cache...
Processing triggers for python-support ...
Setting up libgimp2.0 (2.6.10-1ubuntu3.1) ...
Setting up gimp-data (2.6.10-1ubuntu3.1) ...
Setting up libbabl-0.0-0 (0.0.22-1build1) ...
Setting up libgegl-0.0-0 (0.0.22-2ubuntu2) ...
Setting up libhal1 (0.5.14-0ubuntu6) ...
Setting up libmng1 (1.0.10-1) ...
Setting up gimp (2.6.10-1ubuntu3.1) ...
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place
Processing triggers for menu ...

real	0m7.934s
user	0m2.900s
sys	0m1.360s
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben