Optimierungs-Möglichkeiten
Aus NAS-4220
Inhaltsverzeichnis |
Leistungs-Grenzen der NAS 4220-B
Bevor man die Performance optimieren kann, muss man die max. erreichbaren Grenzen kennen.
Die Idee auf dieser Seite ist, die max. Grenzen auszutesten und Konfigurations-Tipps zu beschreiben, wie man diesen Grenzen näher kommt.
Bei der IcyBox NAS4220B sind folgende Faktoren limitierende Grenzen:
CPU-Leistung
todo: Wer kann hier weiterhelfen mit weiteren Ideen, Test-Skripten etc.? Z. B. wäre eine kompilierte Version von nbench sehr interessant.
Ein Vergleich der verwendeten ARM9-CPU (mit 400 MHz) ist in einem Wiki zur DLink DNS 323 dokumentiert und zeigt (neben den Vorteilen wie sparsamen Stromverbrauch) vor allem folgende generelle Schwächen der ARM9-CPU:
- Sehr langsame Floating-Point-Verarbeitung, da diese in Software emuliert werden muss
BogoMIPS
Einen einfachen CPU-Benchmark liefert Linux mit folgendem Kommando:
cat /proc/cpuinfo
Das Ergebnis sieht so aus:
Processor : FA526id(wb) rev 1 (v4l) BogoMIPS : 230.19 Features : swp half
Zum Vergleich hier die Werte einer (älteren) AVM Fritz!Box FON WLAN, auf der ebenso ein Embedded Linux läuft:
cpu model : MIPS 4KEc V4.8 BogoMIPS : 149.91
Weitere Vergleiche:
- Ein Acer-Notebook mit einem Pentium-M (Centrino von 2003) mit 1,5 GHz hat ca. 3000 BogoMIPS (BogoMIPS angaben verschiedener Architekturen können jedoch nicht so einfach miteinander verglichen werden!)
IO-Leistung (IO-Subsysteme und angeschlossene Festplatten)
Allgemeines
Die maximale IO-Leistung ist von der Leistung der angeschlossenen Festplatte, der Datei-Fragmentierung, der Position der Datei auf der Festplatte und natürlich dem Embedded Linux und der CPU abhängig.
Die maximale Lese- und Schreibleistung ist auf jeden Fall durch die verwendete Festplatte beschränkt. Gute Messwerte hierfür kann man mit dem kostenlosen Tool HDTune ermitteln. Hier stehen auch die Test-Ergebnisse für viele aktuelle Festplatten.
Aktuelle Festplatten mit 500 GB Kapazität haben typischerweise eine durchschnittliche Leserate von 60 MB/s (bei minimal 30, max. 80 MB/s). Die IcyBox schafft es nach den bisherigen Test-Ergebnissen nicht, diese Leseraten auch nur annähernd auszunutzen.
Die nachfolgenden Tests verwenden oft Zugriffe auf virtuelle Geräte (NULL und ZERO), um Daten zu erzeugen oder zu konsumieren.
Das Erzeugen von Nullen benötigt nur sehr wenig Zeit, weshalb dieser zusätzliche Zeitaufwand bei den Tests hier ignoriert wird. Nachweis:
# Overhead für Zero-Erzeugung ermitteln. # Ergebnis: 358 MB/s !!! root@IB-NAS4220-B /mnt/ide1/public $ time dd if=/dev/zero of=/dev/null bs=1M count=1000 1000+0 records in 1000+0 records out real 0m 2.79s user 0m 0.00s sys 0m 2.79s
Ähnliches wäre auch mit folgendem Befehl möglich, der statt Nullen Zufallswerte erzeugt, das scheint auf der IcyBox 4220 aber sehr langsam zu sein und sollte daher nicht verwendet werden:
# Performance des Hash-Random-Generators # bei Generierung von 100 MByte Zufallszahlen: 0,459 MB/s root@IB-NAS4220-B /mnt/ide1/public $ time dd if=/dev/urandom of=/dev/null bs=1M count=100 100+0 records in 100+0 records out real 3m 38.74s user 0m 0.00s sys 3m 38.56s
Test-Skript S2:
time dd if=/dev/urandom of=<Name der zu schreibenden Datei> bs=1M count=1000
Festplatten-Tests
todo: Wer kann hier weiterhelfen mit Ideen und genaueren Test-Skripten? Toll wäre ein Sammlung an Linux-Skripten, die man auf jedem Rechner laufen lassen kann (zum Vergleich)!
Test-Skripte
Die nachfolgenden Test-Skripte müssen (soweit nicht anders angegeben) über die SSH-Konsole direkt auf der IcyBox ausgeführt werden, wenn man als Benutzer root (Passwort wie bei der Web-GUI) angemeldet ist.
Durch das Ausführen der Skripte direkt auf IcyBox vermeidet ihr, die Test-Ergebnisse durch Einflüsse außerhalb der IcyBox zu verfälschen (z. B. langsames Netzwerk, langsame Client-Rechner etc.).
Einen ersten guten Maximal-Wert für die Lese-Geschwindigkeit kann man durch Kopieren einer großen Datei ins Nirwana (Null-Device) ermitteln:
Test-Skript L1Null:
time cp <Name der großen Input-Datei> /dev/null
Dieses "Skript" zeigt die Ausführungsdauer an (der time-Befehl liefert am Ende die Ausführungsdauer des Kommandos, das danach aufgerufen wurde).
Ein ähnlicher Lese-Test ist mit folgendem Kommando möglich:
Test-Skript L2DD:
time dd if=<Name der großen Input-Datei> of=/dev/null
Zum Testen von USB-Festplatten an der NAS 4220 kopiert man einfach eine Datei zwischen interner und externer (USB-)Festplatte und misst die Zeit dafür:
Test-Skript L3hdparm:
hdparm -tT /dev/hda
Mit diesem Befehl erhält man eine gute Vergleichs-Möglichkeit mit anderen NAS-Systemen, da deren Werte in anderen Wikis wie NAS-Central dokumentiert sind.
Bei einer WD500AAKS (500 GB) sind z. B. folgende Werte typisch:
/dev/hda: Timing buffer-cache reads: 280 MB in 2.00 seconds = 140.00 MB/sec Timing buffered disk reads: 62 MB in 3.04 seconds = 20.39 MB/sec
Test-Skript USB1:
time cp <Input-Datei> <Output-Datei>
Durch Dividieren der Dateigröße durch die Anzahl der benötigten Sekunden kann die Lese-Geschwindigkeit ermittelt werden.
Ein Schreibtest ist schwieriger, da man ja eine neue Datei erzeugen will, ohne das Meßergebnis gleichzeitig durch das Lesen einer anderen Datei zu verfälschen. Hier bietet sich an, eine Datei mit "Nullen" zu erzeugen:
Test-Skript S1:
time dd if=/dev/zero of=<Name der zu schreibenden Datei> bs=1M count=1000
Dieser Befehl erzeugt eine 1 GB große Datei mit lauter Nullen, die in 1-MB-Blöcken geschrieben werden (hier könnte man noch die Blockgröße durchvariieren!).
Test-Skript S3:
time cp /mnt/ide1/<Name der zu kopierenden Datei> /mnt/ide2/
Diese Befehl kopiert eine Datei von der ersten auf die zweite Platte (JBOD-Modus)danach wird die dafür benötigte Zeit ausgegeben.
Mess-Ergebnisse
Folgende Ergebnisse liegen bisher vor:
| Test-Skript | Dateigröße in MB | Test-Dauer | Durchsatz in MB/s | Quell-Laufwerk | Ziel-Laufwerk | Anmerkungen |
| L1Null (Datei lesen von NAS) | 610 MB | 22 Sekunden | 27,73 MB/s | HDA (WD500AAKS) | /dev/null | EXT3-Dateisystem, nur eine Festplatte eingebaut, Datei mit cp-Kommando "kopiert" |
| L2DD (Datei lesen von NAS) | 979 MB | 42 Sekunden | 23,31 MB/s | HDA (WD500AAKS) | /dev/null | EXT3-Dateisystem, nur eine Festplatte eingebaut, Datei mit dd-Kommando gelesen |
| S1 (nur schreiben auf NAS) | 1000 MB | 73 Sekunden | 13,70 MB/s | /dev/null | HDA (WD500AAKS) | EXT3-Dateisystem, nur eine Festplatte eingebaut |
| S1 (nur schreiben auf NAS) | 1000 MB | 69 Sekunden | 14,49 MB/s | /dev/null | HDB (HD403LJ T166) | EXT3-Dateisystem, nur eine Festplatte eingebaut |
| S3 (IDE1 nach IDE2 kopiert) | 801,9 MB | 56 Sekunden | 14,36 MB/s | HDA (WD500AAKS) | HDB (WD500AAKS) | EXT2-Dateisystem und EXT3-Dateisystem, Datei mit cp kopiert |
| USB1 (kopieren USB -> NAS) | 979 MB | 176 Sekunden | 5,56 MB/s | Ext. HD (IBM IC35L120 AVVA07-0 mit 120 GB) an USB | HDA (WD500AAKS) | EXT3-Dateisystem, nur eine Festplatte eingebaut, ext. USB-HD an Front-USB-Stecker angeschlossen |
| USB1 (kopieren USB -> NAS) | 979 MB | 164 Sekunden | 5,97 MB/s | Ext. HD (IBM IC35L120 AVVA07-0 mit 120 GB) an USB | HDA (WD500AAKS) | EXT3-Dateisystem, nur eine Festplatte eingebaut, ext. USB-HD an rückseitigem USB-Stecker angeschlossen |
| USB1 (kopieren NAS-> USB) | 979 MB | 137 Sekunden | 7,15 MB/s | Ext. HD (IBM IC35L120 AVVA07-0 mit 120 GB) an USB | HDA (WD500AAKS) | EXT3-Dateisystem, nur eine Festplatte eingebaut, ext. USB-HD an Front-USB-Stecker angeschlossen |
| USB1 (kopieren NAS -> USB) | 979 MB | 133 Sekunden | 7,36 MB/s | Ext. HD (IBM IC35L120 AVVA07-0 mit 120 GB) an USB | HDA (WD500AAKS) | EXT3-Dateisystem, nur eine Festplatte eingebaut, ext. USB-HD an rückseitigem USB-Stecker angeschlossen |
todo: Bitte helft mit und tragt eigene Werte ein...
USB-Schnittstelle
Interessant sind auch die Geschwindigkeits-Grenzen der USB-Schnittstelle der NAS4220-B.
Test-Skripte
Die reine Schreib-Performance auf die USB-Festplatte (ohne die Daten von internen Festplatten der NAS4220-B zu lesen) ermittet dieses Skript:
Test-Skript USBWriteOnly1:
time dd if=/dev/zero of=<Name der zu erzeugenden Test-Datei auf der USB-Platte> bs=1M count=1000
Den reinen Lese-Durchsatz von der USB-Platte ermittelt man mit diesem Skript (ohne die Daten auf internen NAS4220-B-Festplatten zu speichern). Die einzulesende Datei muss zuerst mit dem obigen Skript in der richtigen Größe angelegt worden sein:
Test-Skript USBReadOnly1:
time dd if=<Name der einzulesenden Datei> of=/dev/null
Mess-Ergebnisse
Ergebnisse:
| Test-Skript | Dateigröße in MB | Test-Dauer | Durchsatz in MB/s | USB-Festplatte | Anmerkungen |
| USBWriteOnly1 | 1000 MB | 115 s | 8,70 MB/s | IBM IC35L120 AVVA07-0 (120 GB) | Die Festplatte hat lt. HDTune folgende Leseraten: Min. 22, max. 46, durchschnittlich 37 MB/s |
| USBReadOnly1 | 1000 MB | 103 s | 9,71 MB/s | IBM IC35L120 AVVA07-0 (120 GB) | Die Festplatte hat lt. HDTune folgende Leseraten: Min. 22, max. 46, durchschnittlich 37 MB/s |
| USBWriteOnly1 | 950 MB | 108 s | 8,80 MB/s | 1-GB-USB-Stick | USB-Stick mit USB 2.0 und 20 MB/s schreibend, 24 MB/s lesend unter Windows (lt. H2testw.exe von www.heise.de) |
| USBReadOnly1 | 950 MB | 93 s | 10,22 MB/s | 1-GB-USB-Stick | USB-Stick mit USB 2.0 und 20 MB/s schreibend, 24 MB/s lesend unter Windows (lt. H2testw.exe von www.heise.de) |
todo: Bitte helft mit und tragt eigene Werte ein (vor allem, wenn diese schneller sind!)...
Bewertung
- Trotz des theoretisch möglichen max. Durchsatzes der USB-2.0-Spezifikation von 480 MBit/s (= 60 MB/s) schafft die NAS4220-B kaum 10 MB/s.
- Die max. Übertragungs-Geschwindigkeit der USB-Schnittstelle der NAS4220-B ist in beiden Richtungen (Lesen und Schreiben) annähernd gleich.
Interpretation der Mess-Ergebnisse
Aus den bisherigen Meß-Ergebnissen kann man folgendes ableiten:
- Die interne Lese-Geschwindigkeit liegt deutlich (ca. 50 %) unter den Möglichkeiten der eingebauten Festplatte(n)
- Die interne Lese-Geschwindigkeit ist deutlich (ca. 100 %) schneller als die interne Schreibgeschwindigkeit
- Die USB-Schnittstellen der NAS-4220-B sind für eine schnelle Datei-Übertragung nicht besser geeignet als der Zugriff über das Netzwerk.
- Die Mess-Ergebnisse zeigen immerhin, dass theoretisch noch Optimierungs-Potenzial vorhanden ist (wenn sich nicht die Hardware als begrenzender Faktor herausstellen sollte)
Netzwerk-Leistung
Die NAS4220B hat ein GBit-LAN-Anschluß mit 1000 MBit Bandbreite. Welche Bandbreite davon wirklich genutzt wird, hängt von der Netzwerk-Infrastruktur ab, die angeschlossen ist (z. B. Netzwerkkabel Cat 5, 6e, 7 - je höher, umso besser)
Die Netzwerkleistung unterliegt folgenden (groben) Grenzen:
- Bei 100 MBit
100 MBit / 8 = 12,5 MBytes rohe Übertragungsgeschwindigkeit pro Sekunde
- Bei 1000 MBit
1000 MBit / 8 = 125 MBytes rohe Übertragungsgeschwindigkeit pro Sekunde
Diese theoretischen Grenzen werden durch den Overhead der verwendeten Netzwerk-Protokolle weiter reduziert.
todo: Wer hat eine Idee für ein isoliertes Test-Szenario und kann hier ein kleines Test-Skript schreiben? Gut wäre z. B. netcat, da es wenig Overhead erzeugt, aber ich finde leider keine ARM9-Binary davon...
Vergleich mit anderen NAS
NSLU2
Siehe wwww.nslu2-linux.org
Optimierungs-Tipps
Samba optimieren
todo: Welcher Samba-SpezialistIn kann hier weiterhelfen?
Auf der ICY BOX ist folgende Samba-Version installiert:
$ smbd -V Version 3.0.20
Der für die Windows-Freigaben verwendete Samba-Dienst bietet vielfältige Einstellungs-Möglichkeiten, die vor allem in der Konfigurations-Datei zu finden ist:
/system/hddapp/etc/samba/smb.conf
Zum Neustart (nach Änderungen an der Konfigurations-Datei) gibt man folgenden Befehl ein:
/system/hddapp/etc/rc.d/S80samba.sh restart
Eine gute freie (deutsche) Anleitung gibt es von O'Reilly (Samba 2). Das Buch ist von 2003, beschreibt aber die Einstellungen recht gut.
Eine ausführliche und aktuelle Dokumentation der Konfigurations-Parameter gibt es bei Samba.org.
Im JBOD Modus ( beide Platten laufen eigenständig ) wird die zweite Platte von Samba nur als [ide1 bzw. ide2] freigegeben. Es können zwar Ordner angelegt werden, die aber im Windows nicht direkt als Netzwerklaufwerke eingebunden werden können. Abhilfe schafft die Konfiguration per Hand in der smb.conf
1. Schritt: öffnen der smb.conf mit vi als Root
2. Schritt: neue Freigabe eintragen
[neuer Ordner]
path = /mnt/IDE2/neuer Ordner {Pfad zum Ordner, bitte ggf. IDE1 angeben!}
write list = @users,@nobody {Benutzer oder Gruppen die schreiben dürfen}
read only = no {Schreibschutz}
create mask = 0777 {Rechtevergabe für die Dateien die in den Ordner gelegt werden}
directory mask = 0777 {Rechtevergabe für Unterordner}
use sendfile = yes
use receivefile = yes
3. Schritt: speichern und vi beenden 4. Schritt: ./S80samba.sh restart
Tuningeinstellungen in der smb.conf
[Global]
getwd cache = yes {beschleunigt die Anzeige der Ordner unter Windows}
dead time = 5 {wann eine tote Verbindung gelöscht wird}
log level = 1 {es werden nur die notwendigsten Log aufgezeichnet}
read raw = yes {ermöglichen Samba, große Lesevorgänge auf dem Netzwerk zu benützen}
write raw = yes {ermöglichen Samba, große Schreibvorgänge auf dem Netzwerk zu benützen}
oplocks = yes {erlauben Clients Dateien lokal zu cachen und steigern die Performance in der Größenordnung von 30 Prozent}
max xmit = 65535 {diese Option setzt den größten Datenblock, den Samba auf einmal zu schreiben versucht}
lpq cache time = 30 {Wenn dein lpq (Inhalt der Drucker-Warteschlange)-Befehl lange Zeit zum Beenden braucht,}
{solltest du die lpq cache time auf einen höheren Wert als die momentane Zeitdauer hinaufsetzen, }
{die für die Ausführung von lpq nötig ist, damit Samba vom Start einer neuen Anfrage zurückgehalten wird, }
{wenn schon eine läuft. Die Vorgabe ist 10 Sekunden, was angemessen ist.}
Ob eine Option wirklich erkannt wurde, kann nach dem restart von Samba mit
cat /var/log/log.smbd
ermittelt werden:
smbd version 3.0.20 started. Copyright Andrew Tridgell and the Samba Team 1992-2004 [2008/01/16 15:17:31, 0] param/loadparm.c:map_parameter(2547) Unknown parameter encountered: "lpq cache" [2008/01/16 15:17:31, 0] param/loadparm.c:lp_do_parameter(3288) Ignoring unknown parameter "lpq cache" [2008/01/16 15:17:31, 0] param/loadparm.c:map_parameter(2547) Unknown parameter encountered: "read size" [2008/01/16 15:17:31, 0] param/loadparm.c:lp_do_parameter(3288) Ignoring unknown parameter "read size" [2008/01/16 15:17:31, 1] param/loadparm.c:lp_do_parameter(3294) WARNING: The "write cache size" option is deprecated
Der Parameter write cache size sollte übrigens nicht gesetzt werden (oder auf "=0"), da er veraltet ist und die Performance z. B. bei einem Wert von 65535 um ca. 15 % reduziert (beim Lesen und Schreiben!).
Bisher nicht weiter untersucht sind noch folgende Parameter zum asynchronen Datei-IO (seit Samba 3.0.20 und nur bei entsprechender Kompilierung):
- aio write size = 16384 # Use asynchronous I/O for writes bigger than 16KB request size
- aio read size = 16384 # Use asynchronous I/O for reads bigger than 16KB request size
Ergebnisse erster Performance-Tests:
Ein erster Test aller Optionen hat keine Performance-Verbesserungen bewirkt. Die von Windows-XP angezeigte Netzwerk-Auslastung bei einer direkten Verbindung der NAS mit Windows über ein 100-MBit-Kabel und einem Notebook mit Intel-Centrino-CPU (1500 MHz Taktfrequenz) war
- beim Schreiben auf die NAS über Windows immer bei ca. 75 % und
- beim Lesen bei ca. 60 %.
Dieses Ergebnis bestätigt die Vermutung, dass die Gigabit-Netzwerkschnittstelle der NAS (noch) keinen Performance-Vorteil bringt, weil selbst die Netzwerk-Auslastung eines 100-MBit-Netzwerkes nicht voll ausgelastet wird!
Bitte die Diskussion Seite Beachten. Tester für die Einstellungen gesucht.
FTP optimieren
Der FTP-Server-Dienst ProFTPd der ICY BOX ist leider sehr schlecht eingestellt. Es gibt verschiedene Tuningeinstellungen die einen schnelleren Login ermöglichen. Auch ist es möglich die FTP-Userrechte besser zu verteilen und die Homeverzeichnisse zu verändern.
/system/hddapp/etc/proftpd.conf
/system/hddapp/etc/rc.d/S91proftpd.sh
# Tuning Einstellungen IdentLookups off UseReverseDNS off WtmpLog off ListOptions "-l" DenyFilter \*.*/
# Downloadresume <global> AllowOverwrite on AllowRetrieveRestart on AllowStoreRestart on </global>
NFS optimieren
Die ICY BOX kommt mit kleineren Blockgrößen besser zurecht als mit großen.
Daher gibt man bei Mounten die Blockgröße als Parameter (rsize und wsize) mit an.
Folgende Werte haben sich aus Performance-Sicht bewährt:
- rsize=8192,wsize=32768
rsize sollte auf keinen größeren Wert als 8192 gesetzt werden, weil das i. V. mit der NAS dann Pausen oder Verbindungs-Abbrüche beim Übertragen von größeren Dateien führt.
Auf dem Client-Rechner mountet man die NAS z. B. mit folgendem Konsolen-Kommando:
sudo mount -t nfs -o rw,async,rsize=8192,wsize=32768,tcp 192.168.178.1:/mnt/ide1/myfiles /mnt/nas
Vorher muss man in der NAS-Weboberfläche eine Freigabe für NFS einrichten.
Dann sollte man auf der NAS die NFS-Freigaben in der Datei (über eine SSH- oder Telnet-Konsole als root anmelden!)
/etc/exports
anpassen um nachfolgende Parameter (Beispiel-Zeile in exports!)
/mnt/ide1/myfiles 192.168.178.0/255.255.255.0(rw,no_root_squash,no_all_squash,async)
und den NFS-Server-Dienst dann neu starten:
/system/hddapp/etc/rc.d/S85nfs.sh restart
Diese Einstellungen bleiben auch beim Neustart der NAS erhalten.
Mit diesen Einstellungen erreiche ich beim Schreiben auf die NAS ca. 12 MB/s (Durchschnitt) bei einer 1,5-GB-Datei. Das Lesen einer 1,5-GB-Datei von der NAS erreicht 8,9 MB/s im Durchschnitt (ja: Lese-Geschwindigkeit ist kleiner als die Schreibgeschwindigkeit, das ist ein NAS-4220-B-Phänomen!).
Dauerhafte Speicherung der Änderungen
Variante1: Die Änderungen ausserhalb von /mnt/xy werden bei jedem Systemneustart aus dem ROM heraus neugeschrieben. Hier ein kleiner Lösungsansatz damit die selbsterstellten Configs trotzdem geladen werden. Gilt für Samba und Proftp gleichermaßen.
- Installation der aktuellen Firmware (2.6.0.IB.1.RS.1)
- Installation des SSH-Server Pakets
- Kopieren der smb.conf und/oder proftpd.conf auf die Platte (/public/applications/conf/)
- .conf nach eigenen Vorstellungen editieren
- mit vi die init Datei im Verzeichnis /public/applications/ssh-server/ öffnen (Rootrechte)
- ans Ende der Datei folgende zwei Zeilen einfügen
cp $HD_MNT_POINT/public/applications/conf/smb.conf /system/hddapp/etc/samba/
cp $HD_MNT_POINT/public/applications/conf/proftpd.conf /system/hddapp/etc/ - Datei speichern und schließen
- NAS neustarten
($HD_MNT_POINT ist eine vorher festgelegte Variable und gibt die richtige Bootpartition/Platte an, funktioniert also mit allen Modi)
Nun sollten bei aktivierten Servern beide mit den eigenen Configs laufen.
Dies dürfte mit einem eigenem Paket auch funktionieren! Damit die Dateien nicht zu früh beim Systemstart geändert werden, bitte diese Informationen beachten.
Hinweis: Diese Anleitung zeigt den grundsätzlichen Ansatz, anstatt allerdings die Start-Datei einer vorhandenen Installation zu modifizieren, ist es sinnvoller, eine eigene Applikation anzulegen, die nur zum Durchführen von System-Modifikationen nach dem Neustart verwendet wird. Wie das geht, ist ist unter FAQs beschrieben.
Variante2: Es steht ein Package zur Verfügung welches u.a. die geänderten Config´s beim Start nutzt und die Server dementspechend startet. userscript
