Neuer FC3/CentOS4-Server
 

Servus@all,

nachdem im Thread "Performance Debian-Server (alte HW)" geklärt wurde, dass die HW nix taugt, und weil ebendort der Thread-Titel mittlerweile unpassend wurde, geht's hier weiter: ich richte auf neuer HW

• testweise einen FC3-Server ein,
• den ich dann - bei Verfügbarkeit - auf Centos4OS umstelle und in "Produktion" nehme.

Momentan teste ich mit IDE-Platten, wenn mein Debian-Server außer Betrieb geht, kommen die SCSI-HDDs herüber. Mittlerweile hab' ich

• die neue HW zusammen geschraubt,
• MemTest gefahren (OK - :))
• FC3 installiert
• und versucht, den Samba-Server zu konfigurieren.

"Versucht" deshalb, weil ich noch keinen Zugriff von woanders her auf den Fedora-Server krieg' :(.

Wenn ich im Netzwerk-Adapter herum konfiguriere, kommt auch mal die Meldung:Aber der Internet-Zugriff über diese Netzwerkkarte funzt bereits....!

Brauch' ich trotzdem noch einen NIC-Treiber, weil ihn FC3 nicht drin hat? Woher und wie bind' ich ihn ein?

Thx
Quintus


MSI K8T Neo2 FIR, A64 Winchester 3k, 512 MB Corsair CL2

NACHTRAG: auf der Motherboard-CD gibt's einen Treiber- allerdings für Kernel 2.4.x...

...und warum funzt das Internet schon ...?

Was tun?

-----

Und wenn wir schon beim Thema Treiber sind - muss ich sonst noch welche installieren?


Thx
Quintus

Mangels Verfügbarkeit eines aktuelleren Treibers fürs Gigabit-LAN versuch' ich nun den Treiber für Kernel 2.4 zu installieren.

Auf der MoBo-CD finden sich diesbezüglich 3 Dateien:

• ein 'Makefile'
• ein 'r8169.c'
• und eine 'readme.txt'.

Ich hab' nun alle drei in mein home-Verzeichnis gestellt, den Schreibschutz der 'Makefile'-Datei aufgehoben und eben darin die Pfade angepasst:

• NEW_INCLUDE_PATH=-I /lib/modules//2.6.9-1.667/build/include/
• r8169.o:_______r8169.c /lib/modules/2.6.9-1.667/build/include/linux/version.h

Mit 'make' schreibt er mal eine Warnung wegen modification time 3,01e+07 s in future, dann
make: gcc: Kommando nicht gefunden
make: ***[r8169.o] Fehler 127

Wenn ichs richtig verstanden hab', sollte irgendwie aus dem r8169.c dann ein r8169.o werden und letzteres nach .../kernel/drivers/net kopiert werden. Wie mach' ich's richtig bzw. wie krieg' ich den Treiber rein (die readme ist da etwas dürftig...)?

Thx
Quintus


NACHTRAG: gcc nachinstalliert - danach hat er eine ganze Seite Fehler raus geschrieben....

Update: Plan-B: ich hab' kurzerhand die 3Com rein gesteckt.....(um dem Gigabit-onboard-Chip können wir uns ja später kümmern)...

... jetzt seh' ich den Fedora-Server bereits von einem Windows-Rechner aus - aber ich krieg' ums Verrecken keinen Zugriff :(:

• Samba läuft,
• User angelegt (auch in Samba),
• Arbeitsgruppe eingetragen,
• Freigabename vergeben,
• Freigabeverzeichnis mit 'chmod -r *' behandelt...

...ich glaub', ich hab' alles getan, was ich vor ein paar Tagen auf der FC3-Workstation auch schon getan hab'.

Trotzdem kann ich noch immer nicht zugreifen Ich kann mich dunkel erinnern bei der FC3-Installation "Firewall" angekreuzt zu haben - ich find' aber nirgends was zum Konfigurieren einer selbigen (möglicherweise müsste ich die IP-# der Windows-WS wo eintragen).

Was kann ich noch nachschauen, damit der Zugriff klappt?

Thx
Quintus

Firewall config:

GUI Main Menu > System Settings > Security Level

console: /etc/sysconfig/iptables mit dem editor deines Vertrauens


du musst die Ports
TCP 135, 139, 445
UDP 135, 137, 138

für deine lokalen ! Rechner freigeben.

Falls der Server nicht am i-net hängt, kannst auch mal mit 'service firewall stop'kurz die Samba Verbindung testen.

die Realtek 8169 wird von FC3 automatisch erkannt.

Überprüfe mal die Ausgaben von lsmod und ifconfig.

Das mit dem Deaktivieren der Firewall hat vorerst(!) nichts gebracht. Und weil ich mich nicht rausgesehen hab', hab' ich den Rechner in der Zwischenzeit nochmals neu aufgesetzt

• mit etwas geänderter Partioniererei,
• mit der onboard-Realtek 8169,
• und zwar so, wie ich FC3 testweise vor einigen Tagen auf den Debian-Server drauf getan hab'.
• Aber diesmal mit Firewall...

..vorerst mit demselben Ergebnis.

Nach einigem Herumdrehen, funzte es plötzlich (bei abgedrehter Firewall) - ich glaub', ich hab' einfach nicht begriffen, dass wenn man was in der grafischen Netzwerkkonfiguration herum dreht, dass man dann "Datei/speichern" machen muss... *schäm*.

Danke und liebe Grüße,
Quintus


P.S.: Jetzt - äh - nein, morgen - versuch' ich die Firewall zu konfigurieren, wie schon dankenswerter Weise oben angegeben, damit es auch mit aktivierter FW funzt. Die Firewall-Regeln werden dann überhaupt ein eigenes Kapitel, wenn der Server in Echtbetrieb geht...


--------------


NACHTRAG: irgendwas passt aber trotzdem nicht - Windows-WS neu gebootet - jetzt kann ich wieder nicht verbinden. Ping geht, aber Fedora-Server findet er nicht, wenn ich Netzlaufwerk verbinden will (obwohl ich mit der IP-# verbinde).....so ein sh*t

1.) Ich bin jetzt drauf gekommen, dass smb nicht nach dem Booten automatisch gestartet wird - man muss den Dienst immer händisch starten. Muss ich morgen suchen, wo die Autostart sitzt.


2.) Erste Performancetests "Videoschnitt übers Netz" zeigen teilweise hervorragende Zugriffswerte :) - die kurz darauf wieder in den Keller gehen und Abbrüche verursachen :( - irgendwie ein "sprunghaftes" Verhalten. Weil das System auf derselben HDD liegt, wie das Capture-Verzeichnis? Oder hat jemand sonst eine Idee dazu?


Thx
Quintus

Die Performance ist teilweise(!) wirklich im Keller - macht es tatsächlich so viel aus, wenn es nur EINE physische HDD gibt? D.h. muss Fedora auf der Systempartition auch in irgendwelchen Logfiles herum schreiben, während es eigentlich zügig Daten liefern soll? Wenn ja, wär' dies eine Erklärung und sollte sich mit dem Einbau einer 2. HDD beheben lassen.

Ich hab's sowohl mit der 3Com-NIC als auch mit der onboard-NIC versucht

• manchmal hervorragende Zugriffe (in 3 Zeitsteps auf 100% Netzauslastung - der Debianserver hatte in 4-5 Zeitsteps nur 30-40% erreicht)
• dann wieder einige Zugriffe, die dem alten Debian-Server entsprechen.

*beunruhigt* - woran liegt's?

Thx
Quintus

Am einfachsten ist wohl das:
In der Konsole setup eingeben und unter dem Punkt System Services smb aktivieren.

Danke :)... auch eine Möglichkeit.

Vor ein paar Minuten bin ich auch auf eine Möglichkeit gestoßen: SMB-Dienst mit "Systemeinstellungen / Servereinstellungen / Dienste" starten - und dann abspeichern! Bis vor wenigen Minuten wusste ich nicht, dass man das auch abspeichern kann...

Niemand eine Idee zur Performance? Ich such' mal eine andere HDD, um sie testweise einzubauen...

MfG
Qunitus

Die Performance passt noch nicht: ich hab' nun eine 40GB/7200 IDE-HDD, die mir jahrelang als Videoschnitt-Platte gute Dienste geleistet hat, als reine Datenplatte zusätzlich in den Fedora-Server gehängt, ext3-paritioniert und formatiert.

Wie gehabt: auch wenn die AVIs auf dieser HDD liegen, ist das Ansprechverhalten des Netzwerks lau, für Videoschnitt zu langsam :( : es dauert also einen Gedanken zu lang, bis die Netzwerkauslastung 100% erreicht!

Wie öffne ich die Handbremse?

Thx, Quintus

DMA aktiviert?
hdparm -i

Sloter

Mit 'hdparm -i' verrät die 1. HDD nichts - es sollte ein '*' vorm aktuellen DMA-Modus sein.

Mit 'hdparm -d' heißt es 'using_dma=1 (on). Die 2. HDD zeigt das '*', also auch on.

Und in '/etc/resolv.conf' hab' ich die IP des Windows-Videorechners eingetragen.

MfG, Quintus

Und was sagt z.B. top? Die Ramauslastung wäre interessant.

Läuft eigentlich GNOME auf dem Server? Wenn Ja, würde ich X-Windows standardmäßig deaktivieren und nur bei Bedarf starten.

Um das zu machen musst Du in /etc/inittab:
auf
ändern. Das spart beim nächsten Reboot ca. 250MB Ram.

wie Philipp schon geschrieben hat, solltest mit 'top -d 1'in einem 2. Fenster während des Capturen CPU Belastung, Load, Ram und Swap beobachten.

Mit 'vmstat 1 100' kannst auch zuschauen ob das System zu swappen anfängt ( die beiden Spalten mit si und so ), wenn ja, mehr Ram. ;)

#######
weitere Möglichkeit Dienste zu konfigurieren ( die beste ... ;) ):

chkconfig smb on Dienst für aktuellen Runlevel aktivieren

chkconfig --level 35 smb on Dienst für Runlevel 3 und 5 altivieren

chkconfig smb off deaktivieren

chkconfig --list alle Dienste anzeigen mit Status für alle Runlevel

chkconfig --list|grep smb Status für smb dienst anzeigen für alle runlevel
########

Hier die ersten Antworten:

• Swappen tut er nicht :)!
• load average beim Abspielen des AVIs: 0,15 bis 0,22
• einen Dienst "Gnome" find' ich keinen, mit 'locate gnome' findet er jede Menge. 'id:5:initdefault:' auf 'id:3:initdefault:' geändert - dann war der Zugriff auf den Server nicht mehr möglich!
• Aha - jetzt hab' ich's verstanden: in Runlevel 3 muss ich smb mit 'chkconfig smb on' starten - das Abdrehen des X-Windows nutzt aber auch nichts :(.

Schaut Euch mal die Netzwerkauslastung an: ich hab' das Videoschnittprogramm gestartet - es sollte mal den Buffer voll räumen, also zuerst einmal die Netzwerkauslastung auf 100% gehen, bis der Buffer voll ist...

Oder narrt mich der D-Link-Switch, der dazwischen hängt? Mittlerweile hab' ich auch von der Windows-Maschine dieselbe schlechte Performance...

MfG
Quintus


Nachtrag: kann es was mit den Schreibberechtigungen zu tun haben - hängt's davon ab, von wem der File ursprünglich gecapturt wurde, wer owner des Files oder des Verzeichnisses ist etc., kann es da einen Zusammenhang geben? Ich vermute da irgend einen Zusammenhang...

Am besten überprüfe das einmal. Ich glaube eher nicht das es an den Schreibberechtigungen liegt.

Der Verdacht erhärtet sich - verschiedene AVIs verhalten sich unterschiedlich:

• ein frisch gecapturtes AVI (am Server abgelegt) lässt sich mit guter Performance abspielen :),
• während ein AVI, das im selben Verzeichnis liegt, aber von einem anderen User gecapturt wurde bzw. vom Fedora-Root in dieses Verzeichnis kopiert wurde, sich ganz anders verhält - es performt viel schlechter :(!

Fällt Euch dazu etwas ein???

Parameter gibt's da jede Menge - Owner des Verzeichnisses / Owner des AVIs vs. User, mit dem ich mich connecte, ...

Das ganze kreuz und quer zu testen ist eine Sysyphusarbeit.


Thx, Quintus


P.S.: Dass der Switch damit was zu tun haben soll, glaub' ich mittlerweile nicht mehr, nachdem sich im selben Projekt 2 AVIs auf derselben Timeline unterschiedlich verhalten.

Nachtrag: mich hält das Teil zum Narren...:(.

Ich hab' in der Zwischenzeit auch den Switch und die Kabel getauscht - ich kann keinen Zusammenhang erkennen.

Nur ein Zusammenhang ist deutlich - und bitte verzeiht mir die laienhafte Ausdrucksweise: "frisch" aufgenommene AVIs performen deutlich besser! So füllt ein "frisches" AVI den Buffer in 7-8 Sekunden, während ein anderes AVI 13 Sekunden und mehr benötigt (oder ganz abbricht).

*kopfschüttel*

Bitte schaut Euch mal das GIF an:

• Im Bereich A, C und D kommen die Daten wie geplant - zuerst (fast) auf 100% - und wenn der Buffer voll ist, fällt es auf die DV-Datenrate von 3,6 MB/s - so sollte es IMMER sein!
• Im Bereich B und E Startversuche mit Abbrüchen.
• Im Bereich F ist es - vermutlich zufällig - NICHT abgebrochen, die Daten kommen schleppend daher, erreichen nur 50-60% und der Buffer braucht natürlich 2-3x so lang, bis er voll ist!

Alle AVIs liegen im selben Verzeichnis, wurden mit den selben Systemeinstellungen gecapturt, liegen auf derselben Timeline.

Fazit: verschiedene AVIs performen unterschiedlich - nur wovon hängt's ab?

MfG
Quintus

Noch ein Test:

Ganz stinknormal Kopieren eines 3.741MB großen Files

1. vom Videoschnitt-PC (Win) auf eine andere Windows-Maschine.
2. Kopieren desselben Files auf den Fedora-Server -

- es wurden dazwischen das Netzwerkkabel umgesteckt, d.h. bei beiden Versuchen wurde derselbe Switch / dasselbe Kabel verwendet.

Beim Kopieren auf eine Windows-Maschine verläuft die Netzwerkauslastung wie vermutet: um die 90% Netzwerkauslastung, fast aalglatt - siehe GIF

(Fortsetzung folgt)

Beim Kopieren auf den Fedora-Server sieht die Netzwerkauslastung völlig krakelig aus ... siehe GIF!

Auf den Windows-Rechner kopiert sich das File in 330 Sekunden, auf den Fedora-Server in 525 Sekunden!

Irgend etwas muss die Ursache dafür sein, dass der Datenstrom auf den / vom Fedora-Server nicht gleichmäßig fließt! Aber was?

So ist jedenfalls die Sache unbrauchbar.

MfG
Quintus

Teste auch mit ftp oder netio, um das Problem weiter einzugrenzen.
Verwendest du die Onboard NIC?
Schau mal mit hdparm (IIRC -t, bitte man-page dazu anschauen), ob die Festplatte vernünftige Werte liefert.
Steht im syslog was relevantes?

• ich hab's in der Zwischenzeit auch mit runlevel 3 versucht - dasselbe in lila.
• Die HDDs laufen DMA, das Kopieren großer Files von HDD zu HDD funzt mit ca. 23MB/sec - was der Datentransferrate der älteren HDD enspricht. Die Festplatten sind also OK.
• Ich hab's sowohl mit der onBoard-NIC als auch mit einer 3ComCombo versucht - überall dasselbe.

Was meinst damit genau?

In der Syslog fällt mir nichts auf - hab' allerdings zum ersten mal da rein geschaut, daher seh' ich vielleicht den Wald vor lauter Bäumen nicht. Schlimmes sah ich nicht...ich stell' die Datei auf einen Webspace - messages.zip (73kB).

Kann smb zu wenig Priorität haben, was macht die Netzwerkauslastung so "pulsierend" (siehe GIF oberhalb)?

MfG
Quintus

Ich hab' das Problem "Datenübertragung zum FC3-Server schleppend (pulsierend)" auf dieser Seite nochmal anschaulich - inklusive der Screenshots der Netzwerkauslastung - zusammen gestellt.

Hat jemand eine Idee dazu?

Thx, Quintus

Such mal in /etc/samba/smb.conf die Zeile:

socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

ändere die beiden 8192 Werte auf 65536 und füge hinten noch: IPTOS_LOWDELAY hinzu


also:


socket options = TCP_NODELAY SO_RCVBUF=65536 SO_SNDBUF=65536 IPTOS_LOWDELAY


sollte die Netzwerkauslastung verbessern, sagt O'Reilly

Nutzt leider überhaupt nichts (auch nicht nach restart von smb bzw. reboot).

MfG, Quintus

Hi Quintus!

Ich teste auch (schon den ganzen Tag) in diese Richtung ;)

ähnliche Ergebnisse, sprich:
Datenübertragung VOM Linux (Debian) zu (verschiedenen) Windows-Rechnern TOP!
samba ~ 8-9 MB/s
ftp ~ 11 MB/s

... außerdem im Taskmanager kaum "Zacken"

Datenübertragung ZUM Linux-Rechner zeigt ähnlich "zackiges" Bild (vielleicht nicht ganz so schlimm) samba/ftp ~ 7,5 MB/s

... werde weiter testen ;)

Grüße

Manx

Anscheiend dürfte Samba 3.0.8 einige Bugs haben. Am besten probiere einmal ob sich die Situation mit Samba 3.0.10 ändert.

Um Samba 3.0.10 zu installieren:
Oben rechts auf das Rufzeichen klicken und Samba bei den Updates markieren. Alle verfügbaren Updates einzuspielen würde über ISDN wahrscheinlich einen Tag dauern. Ich würde eventuell aber noch Kernel 2.6.10 mitinstallieren.

:) :) :)

Ich hab' jetzt testweise auf dem Fedora-Problemrechner WinXP (pfui?) aufgesetzt, indem

• ich einfach im BIOS die 1. (Fedora-)HDD außer Betrieb gesetzt,
• und auf der 2. (langsameren!) HDD XP installiert hab'.

Was soll ich sagen? Datentransfer ZUM (nun XP-)Server - 90% Netzwerkauslastung, aalglatt! Und 345 Sekunden für das 3,74GB-AVI! VOM (nunmehr XP-)Server geht es genau so aalglatt, nur geringfügig weniger (85%, 408 Sekunden).

Ich schau' mir jetzt noch die Übertragung VOM FC3-Server an.

MfG
Quintus

P.S.: ich hab' übrigens in Google jede Menge Threads mit den Stichworten samba, throughput, performance etc. gefunden - sichtlich haben mehrere Leute so ein Problem. Nur Lösung hab' ich keine gesichtet.

Callas Einwurfhab' ich auch gefunden - bringt nur marginal was.

Ich hab' am Wochenende alle Updates eingespielt (hat auch fast einen Tag gedauert), d.h. ich hab' kein rotes Rufzeichen, sondern ein blaues Häkchen - und bin aktuell!

Die Frage ist: ist nur FC3 davon betroffen oder andere Distributionen auch?

------

@ MANX: bei mir kommt auch der Download VOM Server unter Fedora nicht aalglatt - er hat aalglatt begonnen, dann wurde es krakelig...siehe GIF.

------

@ Callas: wie verhält sich Dein CentOS3.4-Beta in der Richtung?

------

Ich fasse zusammen:

• unter WinXP: 3,74GB ZUM Server: 330 Sekunden, VOM Server 408 Sekunden.
• unter FC3: 3,74 GB ZUM Server: 640 Sekunden, VOM Server 610 Sekunden.

Wenn wir das Problem nicht lösen, stell' ich Linux als Serverplattform dann schon irgendwie in Frage....

Hier noch mal das Problem zusammen gefasst in einem Dokument.

MfG
Quintus

Soweit ich gelesen habe dürften die neueren Versionen von Samba einige Probleme haben. Interessant wäre aber so ein Test sicherlich auch unter CentOS 3.3/3.4 x86_64, da dort noch einige ältere Komponenten eingesetzt werden.

Ich hab' jetzt testweise das File auf den Debian-Server kopiert - da ist sicher eine ältere Version von Samba drauf (ich hab' vor ca. 3 Monaten mal ein 'yum update' gemacht). Schaut auch nicht viel besser aus - siehe GIF.
Das würd' mich jetzt auch interessieren - hoffentlich meldet sich Callas.

MfG, Quintus

Sorry, GIF ist nicht mitgerutscht - und beim Edit geht's nimma...

Hi!

... ich stell auch mal ein paar Bilder rein ;)

paar Infos:

Windows XP SP2 Rechner:
AMD XP 2400+
512 MB RAM
NIC: onboard 3COM 3C920
Systemauslastung beim Kopieren ~ 30%
Dateisystem: NTFS

Linux Rechner:
Debian Sarge (netinstall)
Samba 3.0.10 => default konfig nur das Home-Directory auf "writeable" gesetzt
proftpd
Pentium III 700Mhz
128 MB RAM
NIC: D-Link DFE530Tx (via-rhine)
Sysauslastung beim Kopieren ~ 35%
Dateisystem: ext3 bzw. xfs (beides probiert)

Hab mit dd if=/dev/urandom usw. ein 1GB großes File erzeugt, das Win_XP-SP2.iso file verhält sich auch gleich!

ftp_down: 1GB
Dauer 1:30
11,4 MB/s
http://members.aon.at/~dfidesse/ftp_down.png

ftp_up: 1GB
Dauer 1:55
8,9 MB/s
http://members.aon.at/~dfidesse/ftp_up.png

smb_down: 1GB
Dauer 1:59
8,6 MB/s
http://members.aon.at/~dfidesse/smb_down.png

smb_up: 1GB
Dauer 2:08
8 MB/s
http://members.aon.at/~dfidesse/smb_up.png

... interessant auf alle Fälle!

Grüße

Manx

ftp wird immer deutlich schneller sein als die smb bremse ;)

Hi!

... :) ftp hab ich ja nur als Vergleich herangezogen.
Interessant find ich den kontinuierlichen DOWN- und den etwas "pulsierenden" UP-Stream.
Ned unbedingt ein großes Performance Problem, aber insteressant ist's allemal.

Grüße

Manx

Ich bin eigentlich erschüttert .... wozu halte ich mir dann einen Linux-Server, wenn er dermaßen schwächelt(?):

• 330 (Windows) vs. 640 Sekunden (Linux/smb) beim Upload,
• 408 (Windows) vs. 610 Sekunden (Linux/smb) beim Download.

Ich find' den Unterschied heftig - und frag' mich mittlerweile, warum ich die "Linux-Krot g'fressen hab'"...

... es macht ja dann - von der Lebensdauer abgesehen - überhaupt keinen Sinn, in einen Linux-Server hurtige SCSI-Platten einzubauen, wenn man die Performance nicht aufs Netzkabel bringt.

Ich hab' die Zahlen jetzt hier ergänzt.

Interessant wäre, WARUM smb so "pulst" - und wie man das abdreht. Das wäre IMHO der springende Punkt.

Vielleicht findet sich noch eine Lösung und vielleicht weiß Callas von CentOS3.4 Besseres zu berichten.

MfG, Quintus

In der Arbeit habe ich einen Dual P-3 1Ghz mit CentOS 3.3. Da werde ich morgen mal Samba konfigurieren und testen.

Stay tuned ...

Ich verwende SCSI Hardware auf zwei Linux Server. Vor allem bei vielen gleichzeitigen Zugriffen ist der Unterschied deutlich spürbar.