Extrem hohe CPU-Auslastung durch Samba

dsjiern · 26. September 2022 um 17:36

Hallo liebes Forum,

wir haben schon seit längerer Zeit ein Problem was ich jetzt aber erst eingrenzen konnte. Und zwar haben wir immer gemerkt, dass Anmeldungen an den PCs - LinuxMint und iMacs - immer recht lange dauern. Insbesondere bei den iMacs (per Kabel verbunden) ist es so, dass die Anmeldung nach dem Boot bzw. Standby erst nach ca. 30 Sekunden möglich ist, wenn sich viele gleichzeitig anmelden dauert es noch länger. Auch die WLAN-Anmeldung per RADIUS braucht teilweise sehr(!!) lange, dort erscheinen im Unifi-Controller inzwischen auch permanent Meldungen, dass die Anmeldung lange gedauert hat.

Unser Setup:

Hardware-Server mit proxmox, darauf 2 VMs:

lmn.net mit installiertem freeradius
- 16GB RAM
- 8 Core
sonstige Netzwerk-Verwaltung mit Unifi-Controller, DHCP (für die anderen VLANs, pädNetz macht lmn.net), mdns-responder, zabbix
- 16GB RAM
- 4 Core

(Wir nutzen nicht die Firewall, wir nutzen die Firewall von Unifi in Verbindung mit einem Pi-Hole, das reicht für unsere Zwecke)

Jetzt habe ich beobachtet, dass in den Zeiten, in denen sich viele entweder an einem Laptop/PC/iMac oder am WLAN anmelden (regelmäßig nach den Pausen), der load auf der lmn.net-VM extrem ansteigt (ca. 8-10) und dort auch einige Minuten (ca. 15-20) bleibt bevor das ganze sich in der nächsten Pause wiederholt…

top gibt mir hierbei aus, dass mehrere Samba-Prozesse bei 100% CPU-Auslastung laufen:

(teilweise werden auch noch mehr sambas mit jeweils ~10-20% CPU angezeigt)

Wenn ich das so sehe, liegen unsere Anmeldeprobleme an dieser extremen Auslastung, die aber meines Erachtens doch nicht normal ist??

Wir haben insgesamt rund 1000 Schüler, wobei für ca. 400 Schüler das WLAN freigegeben ist. (Wir machen das nicht über die Funktion von lmn.net weil die für uns einige Nachteile hat sondern wir haben ein Projekt angelegt und überprüfen dann im freeradius, ob der Schüler Mitglied in dieser Gruppe p_wlan ist.)

Auch die externen Dienste (Moodle, Nextcloud, Untis,…) greifen per LDAP darauf zu, hier entsteht keine so große Auslastung, nur bei einer AD-Anmeldung. (freeradius läuft auch über AD)

Jetzt die Frage: liegt das an irgendeiner Einstellung, dass der Samba so extrem langsam ist, oder ist unsere - zugegeben recht alte - Hardware schuld?

Als Hardware haben wir einen

Fujitsu-Server
12-Core Intel Xeon E5-2420 (2,2GHz)
32GB RAM
700GB HDD (hdparm liefert ca. 300-400MB/s lesend ohne Cache, ~8-9GB/s mit Cache)
1G-Netzwerk

Okay, ist inzwischen 7 Jahre alt und insbesondere die Festplatte nicht die schnellste… Aber top zeigt mir bei Samba ja volle CPU-Auslastung an und das wundert mich…

In den Samba-Logs steht eigentlich nicht wirklich viel drin, lediglich einige von diesen Einträgen: macOS-AD-DNS-Bug was aber soweit ich das sehe einfach nur fehlerhafte Log-Einträge erzeugt und damit die Auslastung nicht erklärt.

Außerdem hin und wieder noch solche Einträge:

Failed to connect host 10.16.0.1 (4fab88b9-4fbe-4afd-aff1-7a98a1621bdc._msdcs.schulelocal.de) on port 135 - NT_STATUS_HOST_UNREACHABLE

Was mich daran wundert ist, dass es kein 10.16.0.1 mehr gibt (das gab es auch nur mal kurzzeitig zu Testzwecken)

Soo, vielleicht hat ja jemand eine Idee, ob es eine Einstellungssache ist, oder ob wir mal neue Hardware anschaffen müssen. (Da kommt Freude auf, wenn man das mit der Stadt verhandeln muss )

Danke und Grüße
Alex

baumhof · 26. September 2022 um 18:18

Hallo,

also wir haben 1400 Nutzer und 200 Arbeitsstationen am Netz und ich habe
solche Probleme noch nicht beobachten können.
(Ryzen 2700 mit 16 Kernen und 32GB RAM).
Bei mir läuft das Storage aber auch 6 WD Black Platten im RAID5: das
wuppt schon ganz anderes weg.
Ist das bei dir eine einzelne Festplatte?
Was hat die den für Rotationsgeschwindigkeiten?
Ich hab extra Black genommen, weil die 7200 U/Min haben.
Ich denke auch dass eher I/O der Flaschenhals ist nicht die
Datentransferrate, die du mit hdparm gemessen hast.

Ein Load von 5 find ich jetzt auch nicht so groß: meine Nextcloud hat
einen Ruhepuls von 3,0 …
Du kannst aber trotzdem mal der lmn mehr Kerne zur Verfügung stellen.
Da brauchst du auch anderen nix abziehen: Kerne können übervergeben
werden (anders als bei Hauptspeicher).

Die Gigabit/s am Server als Uplink sind vielleicht auch ein Problem: das
ganze Netz teilt sich das ja.
Ich hab früher Netzwerkkarten gebündelt (4 Stück) bevor ich auf 10 GB/s
upgegraded habe.

LG

Holger

dsjiern · 26. September 2022 um 19:08

Hallo Holger,

Nutzer auch per WPA-Enterprise im Netz?

Gerade nochmal geschaut: ist ein Hardware-RAID5 (+1 Hotspare) mit 5 SAS 6G Platten.

unser extern angemieteter Server auf dem Nextcloud, Moodle, BBB, Mail und noch einige andere Dienste laufen hat unter Last grad mal nen Load von 1,5… Wenn da nix geht ist der eher bei 0,3…

Unser lmn-Server in der Schule hat nen „Ruheload“ von ca. 0,5-1 und macht immer bei einem Load > ~3 Probleme mit der Anmeldung

Grad mal geschaut: es fließen im Vollbetrieb in der Regel maximal 40MBit/s, zu Spitzenzeiten auch mal 150MBit/s über die Leitung.
Es läuft ja eigentlich ausschließlich die Anmeldung darüber, sonst fast nichts*. Und eine Anmeldung sollte ja nicht viele Daten brauchen.

(*fast nichts, weil die iMacs sich nach der Abmeldung im Hintergrund einige Daten auf den Server schieben bzw. von dort holen. Deswegen auch die Spitzenzeiten mit 150MBit/s. Aber das betrifft nur die Abmeldung, nicht die Anmeldung)

Das komische ist ja, es passiert nur bei einer Anmeldung per AD, und eben nicht bei einer reinen LDAP-Anmeldung!

Zum Vergleich: ein per for-Schleife 1000 Mal ein radtest ausgeführt bringt den Samba auf mehrere 100% CPU-Auslastung und load auf ~4.

Das selbe 1000 Mal ein ldapsearch (ist ja sogar noch mehr als ein reiner Auth) belässt Samba bei 5-10% CPU, Load bei ~1 und braucht auch ca. 25% weniger Zeit!
(Die Tests hab ich lokal auf dem Server direkt ausgeführt, also da kann ich das Netzwerk schonmal ausschließen)

Grüße
Alex

baumhof · 26. September 2022 um 20:07

Hallo Alex,

Nutzer auch per WPA-Enterprise im Netz?

ja: wir machen das WLAN mit WPA2 Enterprise. FreeRadius läuft auf der lmn.

Gerade nochmal geschaut: ist ein Hardware-RAID5 (+1 Hotspare) mit 5 SAS
6G Platten.

… das sollte schon flocken …

LG

Holger

dsjiern · 27. September 2022 um 08:20

wir hatten allerdings auch bei zabbix am Anfang Probleme, dass der die Daten nicht schnell genug in die DB/auf die Festplatten schreiben konnte. Also vielleicht gängt es doch damit irgendwie zusammen?

Weil der Wert den hdparm ausspuckt schon sehr niedrig ist…

Grüße

dsjiern · 6. Oktober 2022 um 07:00

Gestern nochmal direkt erlebt: 30 Schüler wollen sich gleichzeitig an den iMacs im Computerraum anmelden: es ging ca. 1 Minute, bis das Anmeldeformular verschwunden ist (das ist eigentlich das Zeichen dafür, dass die Authentifizierung am Server erfolgreich war und dann das Benutzerprofil eingerichtet wird). Wenn sich nur ein einzelner Nutzer anmeldet geht das keine 5 Sekunden!

Zeitgleich wollte ich von den Schülern einige Passwörter über die Schulkonsole zurücksetzen: Wenn ich das „Erstpasswort anzeigen“ geöffnet habe, hat es über eine Minute gedauert, bis mir angezeigt wurde, ob das Passwort „vom Nutzer geändert“ wurde oder noch das Erstpasswort ist.

Auch eine Passwortänderung hat ~30s gedauert, bis dann endlich die Bestätigung (in dem grünen Feld) kam.

Zeitgleich per SSH auf den Server geschaut: hat auch recht lange gedauert bis ich drauf war und eine Shell angezeigt wurde (~10s), Load lag dann bei ca. 5

Da läuft doch irgendwas extrem schief bei uns, das ist doch alles andere als normal?

irrlicht · 15. Oktober 2024 um 13:37

Tag auch,
ist schon etwas aelter der Thread, aber bei uns taucht das gleiche Problem im Moment auf, hohe ldap-Last auf dem Server welche den Login massiv verzoegert.

Hat jemand noch eine Idee was da schief laeuft bzw. ob man da etwas optimieren kann ausser das Problem mit Geld zu bewerfen?

Gruss Harry

baumhof · 15. Oktober 2024 um 15:24

Hallo Harry,

beobachte doch mal den server mit htop, wenn so ein Problem auftritt: dann bekommst du raus, welcher Prozess da so viel Benötigt und ob das Storage IO das Problem ist, oder die CPUs oder der Speicher.

Schreib auch mal stats zum System:

Anzahl der Devices
Anzahl der CPUs die dem lmnserver zugeordnet sind
Hauptspeicherzuweisung zur lmn
art des Storage auf dem die lmn läuft und was für eien Art, also z.B. qcow2 auf RAID5 über 4 SATA 4GB Platten.
Art der Clientbetriebsystem
Version der lmn (cat /etc/issue )

LG
Holger

irrlicht · 10. Januar 2025 um 09:26

Morgen alle,
das Problem mit der hohen Last durch den ldap-Prozess beim Anmelden ist immer noch vorhanden, er geht auf 100%. Das Anmelden eines Users dauert manchmal knapp eine Minute, minimal so 10 Sekunden.
Unser Server hat 12 Kerne zugeordnet, Arbeitsspeicher genuegend und laeuft auf M2-SSDs, da sollte also nicht das Nadeloehr sein. Clients haben wir nur Linux.

Hat jemand eine Loesung gefunden bzw. die Ursachen? Hab schon Logs durchgeackert und sicher einige Stunden ChatGPT-Loesungsansaetze durchprobiert.

Wenn man den Server so beobachtet, stellt man recht schnell fest, dass Samba bzw. die Ursache des ganzen Uebels, also Windows, ganz schoen beschissen designt ist, unzaehlige Prozesse, die jede Menge Last machen obwohl eigentlich genau gar nix passiert, weder Traffic im Netz, noch auf der Platte.

Wir authentifizieren ueber LDAP noch einige externe Dienste, falls diese Info wichtig ist.

Gruss Harry

baumhof · 12. Januar 2025 um 16:25

Hallo Harry,

nach deine Nachricht hab ich mal meine Server bei der Anmeldung angeschaut:
3 Computerräume, insgesammt 82 Anmeldungen innerhalb von 2 Minuten.
Keine dauerte lang und der Server erreichte nie die von dir beobachteten 100%.
62 der Rechner waren Windows 10 und 20 Linux (Debian 12).

Welches linuxmuster-client Paket verwendest du den?
linuxmuster-client-ad-???
oder
linuxmuster-linicxlient7 (so in etwa heißt es).
Und in welcher Version?

Morgen schau ich mir das im Semianr an, wenn sich meine 12 Referendare an den Rechner anmelden. Da hab ich ubuntu 22.04 drauf mit linuxmuster-linuxclient7

LG
Holger

irrlicht · 12. Januar 2025 um 19:44

Abend Holger,

linuxmuster-linuxclient7 1.0.9

Hab die Vermutung, dass da auch die Nextcloudauthentifikation per LDAP hohe Last macht, im Moment macht die auch einen Kern fast dicht obwohl keine Schule ist und fast nix passiert.

Gruss Harry

Edith: Laesst sich natuerlich nicht simulieren, jetzt ist wieder Ruhe.

Michael · 12. Januar 2025 um 20:47

Hallo Harry
Hast Du zufällig den Mailcow Server installiert, der den Abgleich mit den LDAP Konten macht? Da hatte ich mal so ein Problem!
Viele Grüße
Michael

irrlicht · 13. Januar 2025 um 19:39

Abend Michael,

den Thread mit Mailcow hatte ich schon gelesen, laeuft bei uns aber nicht. Keycloak, Moodle, Nextcloud und weiss der Teufel noch was authentifizieren aber bei uns ueber den Samba-LDAP.

Gruss Harry

michael_kohls · 14. Januar 2025 um 11:03

Hallo Harry,
ich hatte vor längerer Zeit mal ein ähnliches Problem. Ist aber schon über 3 Jahre her. Da hat der smbclient von der Nextcloud den Samba-Server derart beschäftigt, dass mehrere Prozesse über Stunden auf Volllast gingen. Auslöser war der Cronjob zum Filescannen. Also sowas:
sudo -u www-data php occ files:scan --all
Falls du einen solchen Cronjob laufen hast, würde ich den temporär deaktivieren und schauen, ob das Problem aufhört.

Die Lösung brachte damals eine Umstellung von PHP auf PHP-fpm in der Nextcloud.

Viele Grüße
Michael

irrlicht · 2. April 2025 um 11:26

Tag auch,
wir sind mal wieder am Ende der Fahnenstange, die Musterloesung macht eigentlich fast nur noch Aerger und er ganze Samba4-Wahnsinn ist schwierig zu debuggen. Kann ja auch nur Mist rauskommen, wenn man ein kaputtes System wie Windows nachbaut.

Der LDAP-Task laeuft immer mal wieder schick auf 100% und das Anmelden dauert > 60 Sekunden, paar Sekunden/Minuten spaeter geht das wieder weitgehend flott (14s).

Hat noch jemand eine Idee ausser das Problem mit Geld zu bewerfen, sprich dickere Hardware? 12 Cores sollten eigentlich reichen, RAM ist auch genuegend da, es wird nicht geswapt.
Wir denken schon ernsthaft darueber nach die ganze Musterloesung zu entsorgen und das selbst zu bauen, haben ja sowieso nur Linuxclients und brauchen diesen SMB-Schmonz eigentlich gar nicht.

Gruss Harry

Raphael · 2. April 2025 um 12:31

Hallo Harry,

wenn ihr Linuxclients verwendet. Kann es sein, dass er beim Anmelden die ganzen (nested) Gruppen auflöst und das sowohl deinen Client als auch den Server beschäftigt. Wir hatten ein Ähnliches Verhalten auch einmal beobachtet. Das Phänomen trat nur beim ersten Anmelden eines Users auf.

Das war dann die Lösung.

Lieben Gruß

Raphael

irrlicht · 2. April 2025 um 14:21

Wenn das die Loesung waere, hast Du jetzt wirklich was gut bei mir, ich mach da seit Wochen mit rum, leg’s wieder zur Seite, fang wieder an zu debuggen…

Gruss Harry

Edith: Da codeberg.org recht schnell dicht macht, das waere die Loesung:
in /etc/sssd/sssd.conf auf dem Client folgende Zeile hinzufuegen, ich teste das morgen mal im Grossen:
ignore_group_members = True

irrlicht · 5. April 2025 um 08:06

Morgen,
das war die Loesung, ~~allerdings seh ich mit smbstatus auf dem Server jetzt keine angemeldeten User mehr~~ (stimmt nicht) und ich kann auch noch nicht abschaetzen, welche Folgen das noch fuer Berechtigungen und sonstigen Kram hat.

Ich vermute (!), dass diejenigen die hier keine Probleme mit der Last haben, ordentlich ueberdimensionierte Server haben haben oder irgendwelche magischen Einstellungen, die wir bisher nicht gefunden haben, Caching und Co.

Falls wir nix falsch gemacht haben, dann sollte das Problem geloest werden, ich fuehle mich dazu aber nicht berufen, da ich schon Stunden in den SambakerberosLDAP-Abgruenden rumgetaucht bin, mit bisher mehr als begrenztem Erfolg.
Unser Ziel ist mittlerweile ganz klar davon wegzukommen, wenn man ein kaputtes Betriebssystem wie Windows nachbaut, muss der Nachbau ja auch irgendwie kaputt sein. Shit in, shit out.

Gruss Harry