[linux-l] Schlechte Fileserver Performance

[Stephan A. Schier]

Jan-Benedict Glaw schrieb:
> On Sat, 2005-01-22 01:15:47 +0100, Stephan A. Schier <Stephan.Schier at dai-labor.de>
> wrote in message <41F19B33.5000408 at dai-labor.de>:
> 
>>Jan-Benedict Glaw schrieb:
>>
>>>On Fri, 2005-01-21 20:03:00 +0100, Stephan A. Schier 
>>><Stephan.Schier at dai-labor.de>
>>>wrote in message <41F151E4.2070600 at dai-labor.de>:
>>>
>>>>Hat irgentwer Vorschläge oder Tips wo man mit der Optimierung anfangen 
>>>>könnte? Mir fällt langsam nichts mehr ein.
>>>
>>>
>>>Fang' doch erstmal mit den offensichtlichen Dingen an. Bevor Du Fragen
>>>zu Lösungen stellst, solltest Du erstmal sagen, was denn so *wirklich*
>>>am Laufen ist:
>>
>>Okay, ich wusste erstmal nicht welche Parameter wirklich 
>>relevat/interessant sind.
> 
> 
> Alle.
> 
> 
>>>- Kernel-Version. (Debian-Kernel oder selbstgebaut? 4GB-Unterstützung
>>> auch wirklich vorhanden?)
>>>
>>
>>derzeit noch ein 2.4.26 mit acl-Patches, bigmem ist an, es werden auch die 
>>4GB erkannt.
> 
> 
> gerade Highmem-Konfigurationen laufen mit 2.6.x besser; das VM-Subsystem
> geht sinnvoller mit den Highmem-Pages um und kopiert nicht soviel Daten
> hin und her...
> 

Ich hatte erst einen 2.6.x Kernel zu laufen, aber als die ersten User anfingen 
darauf zu arbeiten, hatte ich des öffteren Kernel-Panics, was nicht wirklich 
gut für die Uptime war. So bin ich dann zurück zu 2.4 gegangen. Ich hab letzte 
Nacht auch mal auf den aktuellen 2.4.29 upgedatet.


> 
>>>- Was für Netzwerkkarten? Exakter Typ und benutzter Treiber wären
>>> interessant... Wie werden die betrieben? Interrupt-Betrieb oder NAPI?
>>
>>Intel E1000, Interrupt, mit Gigabit Link (hängt an einem Cisco 3750).
> 
> 
> Welche davon? PCI-IDs und Revision-Nummer wären interessant...
> 
> Wenn Du real > 100MBit durch die Karte schiebst, solltest Du auf NAPI
> umsatteln; das verringert die Interrupt-Last. (Sinn macht das aber nur,
> wenn Du die teureren Karten mit größeren Buffern im Einsatz hast.)
> 

Intel Corp. 82546EB Gigabit Ethernet Controller (Copper) (rev 01)
8086:1010 (rev 01)

Ist onboard in der Maschine (Sun V65x).

> 
>>>- Wie ist das U320 RAID Array angebunden? Was für ein SCSI-Controller?
>>> Welcher Treiber?
>>
>>Adaptec AIC-7902 U320 (onboard auf der Sun V65x)
>>Treiber: aic79xx
>>
>>
>>>- Was für ein Dateisystem wird auf den Partitionen des Arrays benutzt?
>>> Welche Optionen wurden gegeben, falls denn?
>>
>>ext3 (mit ACL)
>>
>>
>>>- Wie groß sind die Dateisysteme (in MB, inodes, Anzahl Dateien und
>>> Verteilung der Größe der Dateien)?
>>
>>Partition1 187739MB, 24428544 inodes
>>Partition2 375487MB, 48840704 inodes
>>Partition3 191995MB, 24969216 inodes
>>
>>wie bekommt man die Anzahl der Dateien ohne grossen aufwand raus? Und die 
>>Verteilung der Größe?
> 
> 
> df -i
> 
> Die Größe kannst Du auch schätzen; es geht nur um ungefähre Werte.
> ext[23] reagiert z.B. nicht allzu gut, wenn Du große Mengen von Dateien
> in einzelnen Verzeichnissen hast und dann getdents machst...
> 
Partition1 1355638 (Benutze inodes)
Partition2  730295 (Benutze inodes)
Partition3  187499 (Benutze inodes)

Die Dateien sind im allgemeine über viele Verzeichnisse verteilt. Partition1 
enthält dabei User-Home Directories, Partition2 primär Project-Verzeichnisse 
und Partition3 Backups.


> 
>>>- Was für ein NFS-Server findet Verwendung?
>>
>>nfs-kernel-server 1.0.6-3.1 (standard Debian Package)
>>
>>
>>>- Wie ist der Workload, wenn's so langsam wird? Sind in den
>>> Verzeichnissen tausende von Dateien?
>>
>>Die Verzögerung beim Anzeigen der Dateien ist unabhängig von der Anzahl 
>>der Dateien, kommt auch bei leeren Verzeichen vor.
>>
>>load average: 0.04, 0.04, 0.01
>>
>>
>>>- Sind eventuell irgendwelche Logging- oder Debug-Optionen
>>> eingeschaltet, sodaß selbst beim Lesen die Schreib-Performance (für
>>> die Log-Daten) das Nadelöhr ist?
>>
>>Maximal das ext3 Journal, Logfiles sind schon sehr weit runtergedreht.
> 
> 
> Das Journal ist kann eine echte Spaßbremse sein; falls die atime nicht
> wichtig ist, kannst Du die FS auch mit der Option "noatime" mounten. In
> dem Fall wird etwas weniger beim Lesen auf die Platte geschrieben...

Okay guter Tipp. Werde ich mal probieren.

> 
> 
>>>- Bei Samba: sind socket options gesetzt?
>>
>>socket options = TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_RCVBUF=16192 
>>SO_SNDBUF=1619
> 
> 
> So ein kleiner Sendbuffer? ...oder nur'n Tippfehler?

Hat beim kopieren wohl die letzte 2 verschluckt sollte SO_SNDBUF=16192 heissen.
> 
> 
>>Ach ja die Verzögerung bei anzeigen des Verzeichnisinhalt hab ich auch auf 
>>der Maschine direkt (da blos nicht so häufig). Deshalb gehe ich auch von 
>>einem lokalen (und nicht Netzwerk) Problem aus.
> 
> 
> Gefühlsmäßig hatte ich bei den Adaptec-Controllern schon immer das
> Gefühl, daß die manchmal "langsam" sind. Könnte natürlich auch das
> externe RAID-Chassis sein. (Was ist das eigentlich für ein Modell? Was
> für Platten sind da drin?)

Das Raid ist ein Sun StorEdge 3310 (mit RAID-Controller und 512MB RAM).

Mit 12x74GB SCSI Platten (Seagate, 10000 U/min).

> 
> 
>>Nach einem Reboot der Maschine ist auch alles wieder schön flott, bis der 
>>Speicher wieder mit der Cache voll ist, dann wirds wieder langsam.
> 
> 
> Hört sich an, als ob der 2.4.x'er immer schon Daten zwischen <1GB und
>  >1GB hin- und herkopiert. Wenn das der Fall ist, kannst Du mal mit den
> 2.6.x'ern testen, oder mir einfach den überflüssigen RAM schenken :-)
> 
Ich wollte eigentlich erst auch den 2.6er nehmen hatte aber wie gesagt 
Stabilitätsprobleme unter Last.


Gruß,
Stephan