Richtige Fehleranalyse bei extrem langsamen Zugriff auf SMB-Freigabe von UCS

UCS - Univention Corporate Server
#1

Seit gestern habe ich zweimal für 1h das seltsame Phänomen erfahren, dass der Zugriff auf eine SMB-Freigabe unseres UCS extrem langsam war. Das hat sich bei allen Windows Clients dadurch gezeigt, dass in einem unserer Hauptverzeichnisse zuerst nur wenige Ordner und Dateien aufgelistet wurden, nach mehreren Minuten aber wieder der komplette Ordnerinhalt. Ein Refresh der Anzeige hat zum selben Problem geführt. Der Zugriff von Linux Clients auf dieses Verzeichnis war ohne Verzögerung möglich.

Es scheint auch nur ein Problem mit diesem bestimmten Verzeichnis innerhalb der SMB-Freigabe zu sein, da andere Verzeichnisse ähnlicher Größe zur selben Zeit keine Verzögerungen aufwiesen.

Auf dem UCS konnte ich keine besondere Belastung feststellen, weder im syslog noch in den Auslastungsstatistiken (CPU, RAM, Netzwerk oder Storage) des Virtualisierungshosts, auf dem der UCS läuft.

Ich tappe momentan im Dunkeln und bin für Ratschläge zur Fehleranalyse dankbar.

Gruß,
Peter Schöttler

#2

Könnte vielleicht was mit dem Cachingverhalten zu tun haben. Betraf es definitiv nu reine Freigabe? Poste doch bitte mal die Config der Freigabe. Sollte sich ein Schnipsel unter /etc/samba/shares.conf.d/ befinden.

#3

Mir ist es nur bei dieser Freigabe aufgefallen. Wie gesagt, schien es auch nur einen Unterordner auf der Freigabe zu betreffen.

cat /etc/samba/shares.conf.d/Company

[Company]
path = /data/shares/Company
vfs objects = acl_xattr
msdfs root = no
writeable = yes
browseable = yes
public = no
dos filemode = no
hide unreadable = no
create mode = 0744
directory mode = 0755
force create mode = 00
force directory mode = 00
locking = 1
blocking locks = 1
strict locking = Auto
oplocks = 1
level2 oplocks = 1
fake oplocks = 0
csc policy = manual
valid users = @s_Company_Freigabe
force group = s_Company_Freigabe
nt acl support = 1
inherit acls = 1
inherit owner = no
inherit permissions = no
#veto files = /._*/.DS_Store/Thumbs.db/
#delete veto files = yes

#4

Verwendest du Freigaben auch mit NFS oder nur Samba?

#5

Ich verwende nur Samba.

#6

Gut, dann würde ich dir empfehlen global auf deinem Sambaserver per UCR die Kernel Oplocks ab zu schalten.

ucr get samba/kernel_oplocks
yes

Hier wird bei dir ein “yes” stehen. Dies deaktivieren und Samba neu starten. Bei all unseren Installationen Wunder gewirkt. Wobei es bei uns Linuxcients waren. Aber generell, wenn du keine Freigaben hast wo NFS und Samba auf einer Freigabe zur gleichen Zeit genutzt werden, kannst die Kernel Oplocks getrost ausschalten.

ucr set samba/kernel_oplocks=no

#7

Ich habe den Wert auf ‘no’ gesetzt. Aber es gibt noch eine Variable samba/oplocks, die ich weiterhin auf ‘yes’ belassen habe.

Gerade eben hatten wir erneut das Phänomen. Im syslog konnte ich wieder nichts finden. Mit einem ‘service samba restart’ konnte ich das Problem beheben.

Wie kann ich Samba detailierter beobachten, um die Ursache zu finden?

#8

Hmm, gute Frage. Da es von Linuxclients aus geht, und Windows in der Hinsicht was Samba angeht ja eigentlich robuster ist. Event. ein Windowsupdate? Haben da alle den gleichen Updatestand mit WSUS? Was wäre wenn du das Verzeichnis um kopierst, in z.b. meinshare --> meinshare1. Dann muss alles neu geschrieben werden.
Ist schon ein sehr seltsames verhalten was du da aufgerissen hast…
Was ist denn der Inhalt dieses einen Ordners? Ist das vielleicht das Ausschlag gebende?

#9

Soeben wieder das selbe Problem gehabt und nur ein samba restart hat geholfen.

Der Verzeichnisinhalt ist nicht ähnlich wie bei den anderen Verzeichnissen auf der selben Ebene, die zT deutlich mehr Inhalt haben. Es handelt sich um Bürozeugs. Keine Anwendung, Datenbank oder ähnliches.

Mastodon