Samba schmiert ab -> Server stirbt

Errorsmith

Kompiliertier
Moin

Ich hatte hier schonmal wegen einem unkillbaren Prozess gepostet. Leider hat sich das Problem nicht "von selbst" erledigt sondern tritt immer wieder auf.

Ich habe zunächst nach Hardwareproblemen gesucht, aber - auf der auch noch recht neuen - Hardware keine Probleme gefunden. Das Problem äußert sich in der Art, das smbd, wenn ich auf eine Freigabe zugreifen möchte, anfängt 100% CPU zu ziehen und das Netzwerk nahezu zum Stillstand kommt. Der Prozess hängt dann irgendwo fest und reagiert nicht mehr. Der Sambaserver ist dann garnicht mehr ansprechbar, andere Netzwerkdienste auf dem gleichen Rechner reagieren sehr sehr langsam.

Ausgabe von top:
Code:
  PID USERNAME  THR PRI NICE  SIZE  RES STATE  C  TIME  WCPU COMMAND
30048 errorsmith  1  20  0  99M 11504K CPU2  2  15:47  100% smbd

ps aux liefert dieses:
Code:
USER  PID  %CPU %MEM  VSZ  RSS TT  STAT STARTED  TIME COMMAND
errorsmith 30048 100.0  0.1 101012 11504  -  RJ  3:53PM 16:27.58 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf

Das Verhalten ist reproduzierbar, das heißt, wenn ich auf die fragliche share zugreife, passiert es definitiv, Es passiert auch mit zwei unterschiedlichen Samba Installationen. In der Freigabe liegen dieverse TV Mitschnitte, also wenige, aber große Dateien zwischen 300 und 1500MByte. Mit NFS kann ich ohne Probleme darauf zugreifen (Read: 90MB/s, Write: 60MB/S) und auf andere Freigaben kann ich auch normal zugreifen (Read / Write ca 90MB/s)

Der Server läßt sich nicht einmal mehr herunterfahren: Er hängt nach "syncing disks, vnodes remaining..." und reagiert nicht mehr. Die einzige Lösung ist dann der RESET Knopf.


Die Maschine ist ein FreeBSD 10, die Freigaben liegen auf einem zraid (2.8TB) und mit GBit Ethernet ans Netz angebunden. CPU ist ein i3 mit 3GHz, RAM sind 16GB verbaut. Samba ist in der Version 3.6.22 installiert. Die - in diesem Fall genutzte - Netzwerkkarte ist eine 82574L Gigabit Network Connection (em Treiber), mit einer bce Karte tritt das Probelm aber auch auf ('NetXtreme II BCM5706 Gigabit Ethernet)

Wie komme ich dem Problem nun auf die Spur? Die Logs geben soweit nichts her das auf ein Problem hindeuten würde.

Grüße,
errorsmith
 
Auch wenn mir die Angaben vermutlich nichts bringen um dir zu helfen, vielleicht anderen: Was sagt testparm? Wie sieht deine Config aus? Kannst du das debugging erhöhen?
 
Hi

Ja, natürlich. Testparm gibt keine Fehler aus, hier die Ausgabe (und damit auch die Serverconfig):
Code:
[root@vault ~]# testparm
Load smb config files from /usr/local/etc/smb.conf
Loaded services file OK.
Server role: ROLE_DOMAIN_MEMBER
Press enter to see a dump of your service definitions

[global]
  workgroup = Heimnetz2
  server string = Data Server
  security = DOMAIN
  password server = ambassador
  log file = /var/log/samba/log.%m
  max log size = 500
  load printers = No
  os level = 10
  local master = No
  domain master = No
  dns proxy = No
  wins server = 192.168.81.7, 192.168.81.254
  idmap config * : backend = tdb
[Video]
  path = /data/video
  writable = yes
  create mask = 666
  directory mask = 755

Das logging steht auf 8, noch weiter bringt auch nicht wirklich was... :(

Grüße,
errorsmith
 
Hallo

Mhh also du könntest mal den Content von dem Share welcher nicht funktioniert und einen anderen Share kopieren. Hast du dann auf dem anderen Share auch das Problem, ist wohl etwas mit dem Content. Weiter hier mal ein paar FreeBSD/Samba Tweaks:

etc/sysctl.conf
Code:
net.inet.tcp.nolocaltimewait=1
net.inet.tcp.sendbuf_max=16777216
net.inet.tcp.recvbuf_max=16777216
net.inet.tcp.sendspace=262144
net.inet.tcp.recvspace=262144
net.inet.tcp.mssdflt=1440
net.inet.tcp.rfc1323=1
net.inet.tcp.rfc3390=0
kern.ipc.somaxconn=1024
kern.ipc.maxsockbuf=16777216
kern.ipc.nmbclusters=32768
kern.ipc.somaxconn=32768
kern.maxfiles=65536
kern.maxfilesperproc=32768
kern.maxvnodes=800000

boot/loader.conf
Code:
hw.memtest.tests=0
aio_load="YES"
autoboot_delay="3"

usr/local/etc/smb.conf
Code:
[global]
  # Performance Tweaks!
  socket options=SO_RCVBUF=131072 SO_SNDBUF=131072 TCP_NODELAY SO_KEEPALIVE
  min receivefile size = 16384
  aio read size = 16384
  aio write size = 16384
  use sendfile = true
  max protocol = SMB2
  unix extensions = yes

Kiste rebooten und ja vielleicht hilft es :)
 
Zuletzt bearbeitet:
Hi

@Columbo0815: Ich werde das mal versuchen. Schaden kann es nichts. Ich habe eine Box mit "Mythbuntu" laufen. Auf der habe ich 3.6.3. Wenn ich testweise die Share mit NFS mounte und freigebe zeigt er keine Probleme damit.

@foxit: Soweit ich das bisher sagen kann, passiert es nur mit dieser einen share. Ich habe es aber nicht komplett durchgetestet: Da mir jedesmal der komplette Server "crasht" wollte ich da kein Risikio eingehen. Getestet habe ich mit diesen Varianten:
- Samba im VNET jail (funktioniert übrigens hervorragend ansonsten) => Problem tritt auf
- Samba auf dem Host => Problem tritt auf
- Samba auf der o.g. Linux Maschine, Verzeichnis via NFS gemountet => Problem tritt nicht auf

Was die Tweaks betrifft: Bis auf die Socket-Options kannte ich die meisten davon nicht. Da ich ansonsten keine Performanceprobleme mit dem Samba hatte, hab ich da aber auch nicht nicht weiter gesucht. Die Socketoptions hingegen funktionieren bei mir sozusagen "andersrum": Wenn ich die einschalte, bremst er den Durchsatz auf ca 20MB/s...

Danke für eure Hinweise, ich werde nun erstmal den Samba updaten und dann sehen ob es hilft...

Grüße,
errorsmith
 
Nachtrag:
Das Update scheint ersteinmal was gebracht zu haben, die "Problemshare" reißt mir zumindest nicht sofort den Server runter. Ich werde mal bis morgen abwarten, wenns dann noch funktioniert nehme ich nach und nach die anderen shares wieder mit in die Konfiguration auf.

foxit: du hast in Deinem Schnipsel die "socket options" zweimal drin, am Anfang und am Ende. Absicht?

semi-OT: Kann mir jemand sagen was es mit aio auf sich hat? Die manpage ist nicht gerade sehr ausführlich...
Verträgt sich das mit zfs und vimage?

Grüße,
errorsmith
 
AIO ist ansynchrones IO. Soweit wirst du aber auch schon gewesen sein. ;) Normalerweiser ist IO unter unixoiden Systemen synchron. Die Anwendung feuert einen IO-Request per System Call an den Kernel ab. Das System löst einen Kontextwechsel aus, wechselt also unter recht hohen Kosten vom Userland-Prozess in den Kernel. Der Kernel bearbeitet das IO-Request, erst wenn er fertig ist, läuft der Userland-Prozess weiter. Oder anders gesagt muss deine Anwendung warten, bis der Kernel das IO-Request bearbeitet hat. Da IO-Requests teuer sind und lange dauern, verpuffen dadurch Milliarden CPU-Zyklen im Nichts. AIO versucht dieses Problem zu lösen. Die Anwendung feuert einen AIO-Request ab, kann sofort weiterlaufen und der Kernel bearbeitet ihn im Hintergrund. Die sonst verlorenen CPU-Zyklen können genutzt werden. Das Problem dabei ist, dass die Anwendung die Kontrolle verliert. Sie kann nur sehr eingeschränkt sehen und so gut wie gar nicht beeinflussen, was nach dem Absetzen des AIO-Requests passiert. Ob man AIO guten Gewissens nutzen kann, hängt also vom Zweck der Anwendung ab. Bei Samba ist es meiner Erfahrung nach problemlos. Nur mit "aio wirte behind" wäre ich vorsichtig, da damit der Client ein "vollständig geschrieben" Signal bekommt, während der Server noch am Abarbeiten ist. Das kann im Fall eines Absturz böse weh tun.

Ihr solltet am besten auch noch Sendfile einschalten: "use sendfile = yes". Macht unter FreeBSD lesende Requests (sende Daten von dem Server an den Client) deutlich schneller.

Ist nicht böse gemeint, aber deine Lifelocks (Maschine läuft, macht auch etwas, aber funktioniert nicht mehr richtig) könnten durchaus an vimage hängen. So ganz koscher ist das Ding nicht und in Endlosschleife laufende, unkillbare Prozesse gehören neben klassischen deadlockenden Prozessen mit zum bekannten Fehlerbild. Also wenn es gar nicht will, evtl. man ohne vimage probieren. Oder eine Mail an freebsd-net@ schreiben, wobei ich mir aber aufgrund des allgemeinen Desinteresses an vimage dort keine großen Hoffnungen auf Hilfe machen würde.
 
Moin!

Danke für die ausführliche Erklärung. In welcher Hinsicht muß ich bezüglich aio aufpassen? Auf der Maschine laufen noch dhcp, ein lokaler resolver und ein tftp. Dazu exportiert er diverse Verzeichnisse via NFS. Zuletzt noch ein (nur intern genutzer) Apache. Da ich - außer dem beschriebenen - keine Probleme mit Samba habe, möchte ich vermeiden, irgendwelche Tweaks zu aktivieren die sich negativ auf den Rest auswirken. Was vimage betrifft: Ich habe bisher keine Probleme damit. Und es ist für mich das Ding überhaupt, da ich damit wirklich alles in eine jail packen kann und im Prinzip auf dem Host keine Anwendungen mehr laufen habe (außer dem NFS Server). Das oben beschriebene Problem trat übrigens auch auf wenn ich Samba nicht gejailt habe. Komplett VIMAGE aus dem Kernel zu schmeißen habe ich allerdings nicht versuscht.

foxit: Bisher habe ich nur das Update gemacht. Und während ich das immer noch argwöhnisch beobachte, scheint es zu laufen. Wenn bis morgen keine Probleme auftauchen werde ich mich mit deinen Tweaks auseinandersetzen.

Grüße,
errorsmith
 
Zurück
Oben