sonnenblen.de - Das unabhängige Sun User Forum
Betriebssysteme => Solaris => Thema gestartet von: zyclon am 02. Dezember 2009, 11:41:51
-
Hallo zusammen,
ich habe derzeit ein Problem.
Die bge-NICs unserer SUN T1000/T2000 bringen unserer Meinung nach zu wenig Durchsatz.
Die NICs sind mit Gigabit-Ethernet angebunden und müssten in unserer Backupumgebung inetwa +-85 MB/s Durchsatz bringen. Gemessen haben wir aber nur maximal 65 MB/s.
Auf einer V210 wo ebenfalls bge-NICs verbaut sind, haben wir solche Probleme nicht. Dort erreichen wir im Schnitt locker die erwarteten 85 MB/s.
Habt ihr vielleicht eine Idee, wo der Engpass liegen könnte.
Mir ist aufgefallen, dass die bge auf der T1000/T2000 Onboard per PCI-E bzw. PCI-X angebunden sind. In der V210 nur per PCI. Alle Bus-Arten sollten allerdings ausreichend Bandbreite besitzen und vorallem wäre ein Engpass eher bei PCI zu erwarten.
Meine Vermutung ist jetzt die TCP-Enginge der SparcT1-Prozessoren, aber ich kann das leider nicht nachvollziehen.
Wie sind eure Erfahrungen? Habt ihr ähnliche Durchsatzprobleme und hat sie evtl. jmd. lösen können?
Für Tipps und Infos bin ich sehr dankbar!
Viele Grüße
Sebastian
-
Mahlzeit,
wie sieht es denn auf dem switch, an dem die server angeschlossen sind, aus? durch was fuer netzwerk komponenten muss der datestrom fliesen? sind vlans mit im spiel? kannst du das netzwerk als fehlerquelle komplett ausschliessen? ich wuerde erst einmal mittels 'netio' pruefen was wirklich ueber die leitung gehen kann ohne platten, pci-bus und bandlaufwerk mit einzubeziehen.
ct,
-
Netzwerk und VLAN-Tacking etc. können wir komplett ausschließen.
Wir haben temporär mit einem Crossoverkabel zwischen T1000 und Backupserver eine Verbindung aufgebaut mit dem gleichen Ergebnis.
Die Problematik ist also auf Seite der NICs zu suchen.
Wäre es möglich, da der Storage über FC angebunden ist, dass die FC-Karte evtl. zuviele Interrupts erzeugt oder den BUS blockiert? Wobei die FC per PCI-Express angebunden ist.
Kann man das irgendwie nachvollziehen?
vg
-
Moin,
wie wurde der Durchsatz denn gemessen? Nicht dass du hier in Wirklichkeit die Applikation statt dem Netzwerk misst (bzgl. Durchsatz).
Hast du mal ttcp mit mehreren Threads als Test gemacht?
Tschau,
Drusus.
-
Hallo,
ich hatte mit iperf gemessen und kam entsprechend auf ähnliche Ergebnisse wie unter Legato Networker.
Ergebnis T1000:
# ./iperf -c backupserver -f MBytes
------------------------------------------------------------
Client connecting to backupserver , TCP port 5001
TCP window size: 0.05 MByte (default)
------------------------------------------------------------
[ 4] local <ip host> port 38883 connected with <ip backup> port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 706 MBytes 70.6 MBytes/sec
Ergebnis v210
# ./iperf -c backupserver -f MBytes
------------------------------------------------------------
Client connecting to backupserver , TCP port 5001
TCP window size: 0.05 MByte (default)
------------------------------------------------------------
[ 4] local <ip host> port 37115 connected with <ip backup> port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 929 MBytes 92.8 MBytes/sec
#
Beides geht wie gesagt über NICs vom Typ bge. Bei der Crossover-Verbindung sah das Ergebnis ähnlich schlecht aus.
Grüße
zyclon
-
Moin,
iperf benutzt per Default nur einen Thread und somit misst du hier die CPU und nicht die Netzwerk-Geschwindigkeit. Ich benutze iperf daher fuer Netzwerk-Tests nicht sondern epmfehle ttcp (oder ettcp). Bei iperf scheint es aber auch die Moeglichkeit einer Parallelisierung zu geben (-P Option) aber die habe ich noch nie getestet. Kannst das ja mal ausprobieren (oder eben wie gesagt ttcp/ettcp).
Tschau,
Drusus.
-
Wer nicht im Iostat leben mag der kann auch mal systat installieren um den Systemzusatnd auf einen Blick erstmal einzusehen: http://www.maier-komor.de/sysstat.html
Ist aber einfacher das per pkg-get von OpenCSW zu holen da dann die Abhängigkeiten mit aufgelöst werden: http://www.opencsw.org/packages/sysstat
Alternativ geht auch das se-toolkit: http://www.setoolkit.org/cms/node/2
-
Na das ist doch mal der optimale Einsatzzweck für DTrace.
Snapp dir das Handbuch und prüfe mal die einschlägigen DTrace Script Sammelstellen wie
http://www.brendangregg.com/
-
Unter welcher Solaris-Version wird denn getestet?
-
iperf benutzt per Default nur einen Thread und somit misst du hier die CPU und nicht die Netzwerk-Geschwindigkeit.
Wenn ich iperf mit 6 threads laufen lasse, komm ich auf ähnliche Ergebnisse. Die v210 ist etwa 30% schneller als die T1000.
Na das ist doch mal der optimale Einsatzzweck für DTrace.
Über DTrace habe ich auch schon nachgedacht, nur fehlt mir derzeit der Ansatzpunkt und die Zeit mich da einzuarbeiten. Gibt es im Toolkit schon Scripte die z.B. Hardware Interupts messen? Ich denke das Durchsatzproblem rührt evtl. daher.
Unter welcher Solaris-Version wird denn getestet?
Die Rechner laufen derzeit alle unter Solaris 10u6 respektiv 10/08.
viele Grüße
-
Ich kann insofern etwas zum Thema beitragen, als dass unsere T2000 (root habe sie selig!) mit iperf locker an die 95MB/s gebracht haben.
Gruss
Dominik
-
iperf ist ja Nett - Kannte ich bislang noch nicht.
ich habe hier in unserem RZ mal etwas gespielt:
T2000, e1000g0, iperf -s
Blade-150, hme0, iperf -c --> 10.9 MBytes/sec
Fire-V440, ce0, iperf -c --> 99.5 MBytes/sec
Fire-V445, bge0, iperf -c --> 89.2 MBytes/sec
Fein - die Werte passen sehr schön zu meinem Netzwerk dazwischen (GBit-Switch). Von daher denke ich das iperf (egal ob single/multi thread) brauchbare Werte liefert.
Als nächstes untersuche ich mal unsere WAN-Leitungen. Mal sehen was für Durchsätze da tatsächlich auftauchen oder ob unser Konzern-Provider da etwas die Werte "beschönigt" *g*
Andi
-
Hi,
nach langen suchen mal wieder ein Status zum Thema.
Der Stand ist nun so, dass die T1000/T2000 offensichtlich kein Durchsatzproblem haben, sonder der Fehler auf der Backup-Clientseite zu suchen ist.
Durch Switch-Monitoring haben wir festgestellt, dass die Clients im Schnitt nur um die 500MBit/s bringen. Dabei handelt es sich überwiegend um v890 die mit einer 4port ce-Gigabit-Karte ausgestattet sind. Diese stecken alle in einem PCI-X-Bus der allerdings nur mit 33MHz getaktet ist. Macht also rein rechnerisch auch den geringen Durchsatz.
PCI-X mit 33 MHZ bringt etwa 0,265 GBit/s. Das macht also bei einer 4port-Karte 0,53 GBit/s pro Port.
Der nächste Schritt wird sein, die Karten bei der nächsten größeren Wartung in einen PCI-X Slot umzustecken der mit 66MHz taktet. Derer bietet eine v890 zwei. Damit sollte das Problem gelöst sein - sofern man nicht schon solche Slots belegt hat z.B. mit FibreChannel-Karten...
Dennoch auch bei der T1000 sollte man achten auf welchem NIC man große Last legt. Zwei der OnBoard-NICs sind zusammen mit dem DISK-Backend an einem PCI-X-Bus angehängt. Die zwei weiteren an jeweils einem PCI-E. Wie ich beobachten konnte, bricht bei den NICs am PCI-X der Durchsatz enorm ein, sobald I/O auf den Disks stattfindet. Ist ja auch klar, alle müssen sich den Bus teilen und dazu kommen noch die Interupts...
Für viel Netzwerk-Last wären also auf jeden Fall die NICs am PCI-E-Bus mehr geeignet. Für die T2000 kann ich jetzt leider keine Aussage machen, ich denke aber, dort verhält es sich ähnlich...
so far
Gruß
zyclon
-
Hi zyclon,
weißt du zufällig welche NICs das sind? Bei meinem Link-Aggregation-Thema gehts nämlich auch um eine T1000 ...
Viele Grüße
-
Hi,
hier der Auszug von prtdiag:
# prtdiag
...
========================= IO Configuration =========================
IO
Location Type Slot Path Name Model
----------- ----- ---- --------------------------------------------- ------------------------- ---------
MB/PCIE0 PCIE 0 /pci@780/SUNW,emlxs@0 SUNW,emlxs-pci10df,fc20 LPe11002-S+
MB/PCIE0 PCIE 0 /pci@780/SUNW,emlxs@0,1 SUNW,emlxs-pci10df,fc20 LPe11002-S+
MB/NET0 PCIE MB /pci@7c0/pci@0/network@4 network-pci14e4,1668
MB/NET1 PCIE MB /pci@7c0/pci@0/network@4,1 network-pci14e4,1668
MB/NET2 PCIX MB /pci@7c0/pci@0/pci@8/network@1 network-pci108e,1648
MB/NET3 PCIX MB /pci@7c0/pci@0/pci@8/network@1,1 network-pci108e,1648
MB/PCIX PCIX MB /pci@7c0/pci@0/pci@8/scsi@2 scsi-pci1000,50 LSI,1064
#
MB/NET0 und MB/NET1 sind über PCIE angebunden, sollten also ne exklusive Verbindung zum Chipsatz haben.
MB/NET0 und MB/NET1 enspricht im System bge0 und bge1.
Ich hoffe das Hilft :)
viele Grüße
-
Jo, danke, prtdiag zeigts ja an.
bge2 und bge3 sind natürlich auch genau die, die bei der Link-Aggregation langsam sind...