Verzeichnisse ohne Dateien kopieren mit rsync
Mit Version 3 von rsync lassen sich relativ einfach ganze Verzeichnisbäume inkl. Rechte und User-/Gruppen-IDs ohne Inhalt sprich ohne Dateien kopieren:
rsync -a -f"+ */" -f"- *" source/ destination/
Soweit ich weiß, gibt es die Option -f in Version 2 von rsync noch nicht. Drum wird das in div. Enterprise Linux Versionen nicht funktionieren.
Posted at 04:17nachm. Okt. 29, 2009 by cetixx in Tipps | Kommentare [0]
3D Support Radeon HD 2000 - HD 4000 bzw. R6xx - R7xx
Endlich ist es soweit! Nachdem ich die ATI Radeon Grafikkarte (Radeon HD 3650 - RV635) in meinem Laptop (siehe auch: Elitebook 8530p, Gentoo, Sabayon, Kubuntu - Teil 1 / Elitebook 8530p, Gentoo, Funtoo - Teil 2) am Anfang am liebsten an die Wand geklatscht hätte, weil die propritären ATI einfach nur übel sind und mit neueren sowie (teilweise) selbstkompilierten Kernel überhaupt nicht tun (im Gegensatz zu Nvidia), hab ich das Teil dann doch noch zum Laufen bekommen mit den OpenSource Treibern (radeonhd). Die laufen wirklich gut und die 2D Performance ist inzwischen super. Nur mit 3D war halt nix. Das ist mir prinzipiell egal, aber sowas wie die Desktopeffekte von KDE 4 oder Compiz Fusion is halt dann nicht so richtig (schnell) - und ich mag die Dinger echt gerne, da sie wirklich auch produktiv sind.
Wer Funtoo/Gentoo als Linux-Distribution nutzt und sich rantraut, kann die nötigen Treiber für 3D Unterstützung aber jetzt nutzen. Ich wollte zunächst wie hier beschrieben vorgehen, aber das Ganze kompilierte leider nicht ganz fertig.
Aber Gentoo "to the rescue"! Zunächst habe ich mir mal einen Kernel 2.6.32 (git-sources-2.6.32_rc3-r1) installiert und kompiliert. Verwendet habe ich eine Kernel-Config von Sabayon 5.0, das auf Gentoo aufsetzt, für Desktop-Systeme ist und Kernel 2.6.31 verwendet. Die .config (x86_64 / x86) habe ich fast unverändert übernommen - nur die KMS (Kernel Mode Settings) im Staging-Bereich habe ich aktiviert und alles andere im Staging-Bereich ausgeschaltet, da die Android-Treiber bei mir das Kompilieren des Kernel verhindern (bricht mit Error ... ab).
Das ist prinzipiell eine feine Sache. Man hat hiermit praktisch auf der Console schon die volle Auflösung - in meinem Fall 1600x1050 - und wenn man zwischen X-Server und Konsole mit CTRL+ALT+F1 oder CTRL+ALT+F7 hin und her wechselt, flackert nix, da nicht mehr zwischen den Auflösungen umgeschaltet werden muss. Das Ganze funkt auch wunderbar - prinzipiell. Nur leider sieht der X-Server nach dem Start recht bunt aus und der Cursor ist ziemlich viereckig ;-) Aber gut, das ist ja auch alles noch ziemlich experimentell. Man kann KMS über einen Kernel-Bootparameter wieder ausschalten. Dazu fügt man in der /boot/grub/grub.conf den Parameter radeon.modeset=0 hinten an. Wenn es dann doch mal tut, kann man ja den Parameter wieder weglassen.
Nun aber zur 3D Unterstützung: Zunächst habe ich das X11-Overlay hinzugefügt:
layman -a x11
layman -S
Da man Mesa und die Xorg-Treiber in den neuesten Versionen braucht, habe ich die Pakete unmasked (mit Hilfe des Tools autounmask):
autounmask x11-base/xorg-drivers-9999
autounmask media-libs/mesa-9999
Dann installiert man Folgendes:
emerge -av xorg-server xorg-drivers mesa libdrm
Und schließlich sollte man noch einen
revdep-rebuild
hinterherschicken. Dann muss man eigentlich nur noch Durchstarten und in den System Settings die Desktop Effekte einschalten (soweit nicht schon passiert [waren bei mir bisher auf XRender eingestellt]) und auf OpenGL umstellen. Das war's eigentlich :-) Bei mir laufen fast alle Effekte sehr schnell.
Und fall es jemanden interessiert: glxgears läuft bei mir jetzt mit 2123 FPS ;-)
Posted at 11:25nachm. Okt. 07, 2009 by cetixx in Tipps | Kommentare [0]
KVM Benchmark: Apachebench, IOzone, Graphics Magick
Update 20100115: Bezügl. I/O-Performance und dem qcow2-Format, sollte man das hier noch lesen: Features/KVM qcow2 Performance . Seit Qemu/KVM 0.11.0 hat sich da einiges getan. Vorraussetzung für die bessere Performance ist aber, das man das qcow2-Image mit Qemu >= Version 0.11.0 erzeugt hat. Es kann also durchaus Sinn machen, ein altes Image in ein Neues zu konvertieren.
Ich habe in den letzten Tagen auf einem HP DL 380 G6 Server ein paar Benchmarks mit der Linux Kernel Virtual Maschine (KVM) gemacht. Ich persönlich nutze die KVM schon seit fast zwei Jahren und produktiv laufen aktuell über 40 VMs. Die Stabilität und die Performance hat sich in den letzten Releases sehr gut entwickelt und die Entwicklung geht sehr schnell voran.
Der Host und der Gast liefen mit Gentoo und Kernel 2.6.31.1. Der Host hat folgende Komponeten eingebaut:
2 x Intel Xeon CPU L5520 - 2 Quad-Processors (static performance, VT-d, Hyperthreading eingeschaltet in BIOS)
8 x 300 GB SAS 10k Festplatten (RAID 10)
24 GB RAM
(Einige) Host (kernel) Einstellungen:
I/O scheduler: deadline
Filesystem: xfs
CONFIG_HAVE_KVM=y
CONFIG_HAVE_KVM_IRQCHIP=y
CONFIG_KVM=m
CONFIG_KVM_INTEL=m
CONFIG_VIRTIO_BLK=m
CONFIG_VIRTIO_NET=m
CONFIG_VIRTIO_CONSOLE=m
CONFIG_HW_RANDOM_VIRTIO=m
CONFIG_VIRTIO=m
CONFIG_VIRTIO_RING=m
CONFIG_VIRTIO_PCI=m
CONFIG_VIRTIO_BALLOON=m
(Einige) Gast (Kernel) Einstellungen:
I/O scheduler: deadline/cfq (siehe unten)
Filesystem: ext3 (datamode=ordered/writeback [siehe unten])
VIRTIO Network (VIRTIO_NET) und Block (VIRTIO_BLK) Treiber verwendet.
Der Gast ist ein qcow2-Image, welches ich vorher mit "dd" erweitert habe, damit es für den IO Test groß genug ist und nicht erst während des Tests erweitert wird (was die Werte total verfälscht hätte).
CONFIG_KVM_CLOCK=y
CONFIG_KVM_GUEST=y
CONFIG_HAVE_KVM=y
CONFIG_HAVE_KVM_IRQCHIP=y
CONFIG_VIRTIO_BLK=y
CONFIG_VIRTIO_NET=m
CONFIG_VIRTIO_CONSOLE=y
CONFIG_HW_RANDOM_VIRTIO=y
CONFIG_VIRTIO=y
CONFIG_VIRTIO_RING=y
CONFIG_VIRTIO_PCI=y
CONFIG_VIRTIO_BALLOON=y
CONFIG_PARAVIRT_SPINLOCKS=y
KVM Startup Optionen (die Wichtigsten):
-m "variabel-siehe unten"
-smp "variabel-siehe unten"
-cpu host
-daemonize
-drive file=/data/kvm/kvmimages/gfs1.qcow2,if=virtio,boot=on
-net nic,vlan=104,model=virtio,macaddr=00:ff:48:23:45:4b
-net tap,vlan=104,ifname=tap.b.gfs1,script=no
-net nic,vlan=96,model=virtio,macaddr=00:ff:48:23:45:4d
-net tap,vlan=96,ifname=tap.f.gfs1,script=no
Da wir KVM hauptsächlich für Webserver benötigen, habe ich Benchmarks mit Apachebench, Graphics Magick und IOzone erstellt:
Apachebench mit 4 GB RAM, CFQ Scheduler, 1/2/4/8 vProcs verglichen mit dem Host (der hp380g6 Graph):
http://www.tauceti.net/kvm-benchmarks/merge-3428/
Apachebench mit 2 GB RAM, CFQ Scheduler, 1/2/4/8 vProcs verglichen mit dem Host:
http://www.tauceti.net/kvm-benchmarks/merge-6053/
Mich hat hier u.a. interessiert, ob mehr RAM mehr Durchsatz bringt und ob mehrere virtuelle Prozessoren skalieren. Wenn man die 2xQuadCore + Hyperthreading mit den 8 virtuellen Prozessoren (vProcs) vergleicht, dann kann die KVM hier mithalten. Die Speichergröße spielt keine Rolle.
Graphics Magick resize mit 4 GB RAM, CFQ scheduler, 1/2/4/8 vProcs verglichen mit dem Host (der hp380g6 Graph):
http://www.tauceti.net/kvm-benchmarks/merge-5214/
Graphics Magick resize mit 2 GB RAM, CFQ scheduler, 1/2/4/8 vProcs verglichen mit dem Host (the hp380g6 graph):
http://www.tauceti.net/kvm-benchmarks/merge-7186/
Mit 8 vProcs ist die KVM ungefähr 10% langsamer. Mehr Speicher scheint auch hier nicht zu helfen.
Der folgende IOzone Test lief mit der KVM-Option cache=none. In diesem Fall ist alleine der Host für's Wegschreiben der Daten verantwortlich. Das erscheint mir aktuell immer noch die sicherste Option zu sein, um die Datenintegrität des KVM-Images und der Filesysteme in der KVM sicher zu stellen. Allerdings bremst das die Performance:
IOzone Schreibtest (write) mit 2 GB RAM, CFQ scheduler, ext3 Filesystem und datamode=ordered, 1/2/4/8 vProcs verglichen mit dem Host (der hp380g6 Graph):
http://www.tauceti.net/kvm-benchmarks/merge-3564/
IOzone Schreibtest (write) mit 2 GB RAM, deadline scheduler, ext3 Filesystem und datamode=ordered, 1/2/4/8 vProcs:
http://www.tauceti.net/kvm-benchmarks/merge-4533/
Wie man sieht, bringt das Austauschen des Schedulers ungefähr 10-15 MByte/s mehr an Durchsatz. Die CPU-Auslastung habe ich aber nicht überprüft während des Tests.
Die folgenden IOzone Tests liefen ohne cache-Option und somit mit dem Defaultwert writethrough:
IOzone Schreibtest (write) mit 2 GB RAM, deadline scheduler, ext3-Filesystem und writeback (siehe Testseite), 8 vProcs verglichen mit dem Host (der hp380g6 Graph):
http://www.tauceti.net/kvm-benchmarks/merge-7526/
Die Zahlen sind relativ beeindruckend. Die KVM kann eigentlich fast immer - mit den entsprechenden Einstellungen - mit dem "echten" Host mithalten in diesen Tests. Den Netzdurchsatz müsste man jetzt noch messen, dann wäre der gesamte Benchmark schon fast vollständig.
Posted at 11:32nachm. Okt. 06, 2009 by cetixx in Tipps | Kommentare [3]