Fileserver Schreibperformance bricht ein durch IPFW

martin.feiss

martin.feiss

Member
Hallo,
ich wollte FreeBSD als Gateway (WAN=re0) benutzen und zum LAN (re1) hin als Fileserver mittels Netatalk. Nun tritt folgender Effekt auf:
Das Schreiben auf den Fileserver bricht von ca. 80 auf 2 MB/sec ein, wenn ich IPFW aktiviere. Konkurrierender Netzwerkzugriff vom gleichen Client fühlt sich dabei so an, als wäre die Netzwerkleitung komplett ausgelastet. Das Lesen geht genauso schnell wie ohne IPFW. Ich habe die Firewall so konfiguriert wie hier beschrieben:
https://www.freebsd.org/doc/de_DE.ISO8859-1/books/handbook/firewalls-ipfw.html
Ich habe das vorletzte Beispiel zugrunde gelegt und die Regeln Richtung mehr Durchlässigkeit verändert.

Code: 
# ipfw list
00002 allow ip from any to any via re1
00003 allow ip from any to any via lo0
00100 divert 8668 ip from any to any in via re0
00101 check-state
00120 skipto 500 ip from any to any out via re0 keep-state
00301 deny ip from 172.16.0.0/12 to any in via re0
00302 deny ip from 10.0.0.0/8 to any in via re0
00303 deny ip from 127.0.0.0/8 to any in via re0
00304 deny ip from 0.0.0.0/8 to any in via re0
00305 deny ip from 169.254.0.0/16 to any in via re0
00306 deny ip from 192.0.2.0/24 to any in via re0
00307 deny ip from 204.152.64.0/23 to any in via re0
00308 deny ip from 224.0.0.0/3 to any in via re0
00400 allow udp from any to any dst-port 68 in keep-state
00420 allow tcp from any to any dst-port 80 in via re0 setup
00420 allow tcp from any to any dst-port 443 in via re0 setup
00420 allow tcp from any to any dst-port 143 in via re0 setup
00420 allow tcp from any to any dst-port 993 in via re0 setup
00450 deny log ip from any to any
00500 divert 8668 ip from any to any out via re0
00510 allow ip from any to any
65535 deny ip from any to any

In die /etc/sysctl.conf habe ich diese Zeilen eingefügt, um nichts zu verpassen:

Code: 
# IPFW justage
net.inet.ip.fw.verbose=1
net.inet.ip.fw.verbose_limit=0

Die Ernüchterung: in /ver/log/security laufen genug Blockier-Meldungen rein, aber nichts, was irgendwie mit Netatalk zu tun haben könnte. Auch in /var/log/messages schreibt keiner rein, was ich falsch gemacht habe.
Ich denke, es ist wieder ein peinlicher Anfängerfehler – hat da jemand eine Idee?
 
Code: 
00100 divert 8668 ip from any to any in via re0
Falls da ein natd für NAT läuft, wäre er mein erster Verdächtiger. natd ist sehr langsam, da die Daten mindestens 2x umkopiert werden müssen. Einmal vom Kernel ins Userland, anschließend vim Userland zurück in den Kernel. Man sollte stattdessen In-Kernel-NAT nutzen. Als sehr simples Beispiel zum Beispiel:

Code: 
# NAT
$cmd nat 1 config if $lan_if

$cmd add 50 nat 1 all from $vm_net to not $vm_net
$cmd add 60 nat 1 all from any to $ipaddr
 
Danke für die schnelle Antwort! Mit meinem AFP-Client hänge ich an re1, hingegen NAT läuft auf re0. Verstehe nicht, warum das NAT den Traffic der anderen Schnittstelle verwursten sollte. Nun gut, um diesen Fall auszuschließen habe ich nun fast alle Regeln auskommentiert und alles aufgemacht:
Code: 
# ipfw list
00001 allow ip from any to any via re0
00002 allow ip from any to any via re1
00003 allow ip from any to any via lo0
65535 deny ip from any to any
Damit ist NAT unwirksam und alles offen – oder habe ich da einen Denkfehler? Trotzdem habe ich den Effekt, dass Daten, die von außen reinkommen, extrem gebremst werden. Nächste Stufe: ich schalte mit:
# service ipfw stop
NAT und IPFW ab. Immer noch alles langsam. NATD läuft nicht mehr, wie ich mich überzeugt habe. Jetzt kommentiere ich IPFW und NAT in der rc.config aus und starte die Kiste kurzerhand neu: AFP ist nun wieder pfeilschnell. Nur noch Fragezeichen. Kann das jetzt noch am NAT liegen?
 
Ich habe nun einen Kernel mit IPFW und IPFW_NAT kompiliert und eingesetzt und komme nun auf etwas höhere Geschwindigkeit – allerdings nur bei kleinen Kopierjobs. Ab ca. 1 GB bricht mir nun die Geschwindigkeit massiv ein. Ich habe daraufhin die Firewall wieder komplett abgeschalten und marginale Geschwindigkeitsgewinne verzeichnet.

Das Zielvolume ist ein ZFS-RAID aus 3 Stück 4GB-Platten mit einfacher Parität. Kopiere ich große Dateien von einer lokalen Platte auf das ZFS-RAID, geht das mit deutlich über 100 MB/sec von der Hand, auch bei großen Jobs.

Schiebe ich jetzt ein Image mit 1,7 GB auf den Server, braucht es ca. 90 Sekunden zum kopieren. Vom Server zum Mac hin dauert es 15 Sekunden. Ich habe noch ein NFS-Share eingerichtet – dort bekomme ich ein ähnliches Ergebnis.

Während der Kopiervorgänge zum Server hin reagiert die ssh-Shell auf dem Server kaum noch – als wäre die Netzwerkkarte völlig dicht.

Hat irgendjemand eine Idee oder einen Tipp, wo ich hier weitersuchen soll?
 
Zwei hätte ich auch noch:
  • Hat das ZFS ein Log-Device? Ansonsten könnte es vielleicht ein Performance-Einbruch durch Sambas ungesunden drang fast ausschließlich synchron zu schreiben sein.
  • Hättest du die Möglichkeit einmal eine andere NIC zu probieren? Die Realtek-Chips sind nicht mehr so schlecht wie früher, aber je nach Version des verbauten und de facto die aktualisierbaren ROMs kann es durchaus interessante Effekte geben.
 
OK, danke erstmal für die vielen Tipps. Ich habe es gefunden, Yamagi lag richtig. Es liegt defintiv am Zusammenspiel von NIC und re-Treiber, denn während der übel langsamen Kopier-Jobs schläft meine ssh-Konsole gleich mit mit ein, nichtmal das Tippen geht mehr flüssig. Die Systemlast bleibt immer völlig marginal. Der Treiber kommt nicht mit dem Netzwerkchip RTL8111F klar. Auch der heruntergeladene und kompilierte Treiber von der Realtec-Website brachte keine deutliche Besserung.
Nun habe ich ein anderes Mainboard probiert, da ich beim genutzten Mini-ITX-Board keinen freien Steckplatz für ein NIC hatte. Dummerweise musste ich auch noch neu installieren, weil kein vorhandenes Board meine UEFI-Installation booten wollte *grrr*. Habe der Einfachheit halber erstmal ein NFS aufgesetzt – und siehe da – es geht deutlich schneller.

Vielen Dank für Eure Hilfe!
 
Das klingt sehr nach dem Standardproblem bei allem was libalias verwendet: die arme NAT-Implementierung sieht nicht die Originalpackete sondern die von LRO/TSO zusammengefasste Version. Schalte mal TSO und LSO ab (auch für VLANs).
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben