Unifi: Aufruf der Seite "Client Devices" endlos langsam

Infrastruktur WLAN
1

Hallo zusammen.
Wir haben kürzlich unseren Unifi-Controller auf die Datenbank Version mongoDB 4.4 angehoben. Das lief alles problemlos durch und ich weiß auch nicht, ob das folgende Problem damit zusammenhängt und ob das nur bei uns so ist:

Wenn man die Seite „Client Devices“ (5. Icon von oben im Controller) aufruft, sollten alle Clients, die zZ mit dem WLAN verbunden sind, angezeigt werden. Diese Seite reagiert bei uns jedoch dermaßen langsam und träge, dass sie faktisch nicht benutzbar ist. Nach einer Weile meldet Firefox immer „Anhalten“ und dann kann man’s meistens gleich ganz vergessen.
Ist das bei Euch auch so?

Seltsamerweise läuft das im alten Controller-Interface nach wie vor schnell und flüssig. Beim Umschalten auf das neue Interface wird’s jedoch extrem träge.

Hintergrund der Frage ist: Uns sind ein paar Geräte aufgefallen, die dort mit einem anderen VLAN angezeigt werden als sie eigentlich verbunden sind. Das kann ein Darstellungsproblem im Controller sein oder etwas anderes – aber mit der Seite lässt sich leider nicht gescheit arbeiten, da sie praktisch nicht nutzbar ist, wenn da >1000 Devices gelistet werden.

Daher die Frage, ob wir die einzigen mit diesem Problem sind oder ob Ihr das unter Version 8.0.7 auch so gesehen habt?

Viele Grüße,
Michael

2

… scheint ein allgemeines Problem zu sein :man_shrugging: :thinking: :interrobang:

https://www.google.com/search?channel=fs&client=ubuntu-sn&q=unifi+controller+client+devices+page+slow

3

Hallo Michael,
das war bei mir auch Schnecken lahm. Schau mal, wie viele Clients bei dir dauerhaft „offline“ sind und nur „gespeichert“ wurden. Bei mir waren das ca. 5000, die ich alle einzeln im alten User Interface im Bereich „Insights“ gelöscht habe.

Es gibt wohl auch ein Prune-Script. Das war mir aber zu heikel.

Ich konnte zum Teil mehrere hundert identische Clients löschen, die aufgrund von maskierten Macs immer wieder neu im Controller erschienen sind. Danach war das UI deutlich schneller.

Und dann kannst du zusätzlich an den Einstellungen in der System.properties Datei herumspielen.

LG Daniel

4

Hi. Ja, das wird’s vermutlich sein! :+1:

Ich bin gerade mal auf das alte Interface zurück gegangen
(… zuerst war die Umstellung ja etwas zäh, weil das nicht fertig war – aber mittlerweile habe ich mich an das neue Design gewöhnt …)

Mir ist noch nicht ganz klar, wo Du die alten Offline-Verbindungen gelöscht hast. Ich kann die wohl anzeigen lassen – aber entfernen???

Das Prune-Script ist 2 Jahre alt. Der Link auf die Datei mongo_prune_js.js funktioniert leider nicht. Es gibt auf github eine Version (die gleiche?) → mongo_prune_js.js · GitHub
Leider weiß ich auch nicht, ob man da evtl zuviel löscht … und ich wüsste auch mal gerne, warum man das im neuen Look nicht mittlerweile auch löschen kann!?
Ich nutze eigentlich das Easy-Update-Script aber selbst da kann man nur „Alarm und Systemmeldungen“ aber nicht das ganze andere Zeug löschen.

Nebenbei: ist das bei Dir auch so, dass diverse Clients immer mal wieder „disconnected“ melden, obwohl das nicht stimmt?

Viele Grüße,
Michael

5

Ok – Finger weg von dem Prune-Script im Zusammenhang mit der mongoDB 4.4. Ich habe das gerade mal gemacht und siehe da: Nix geht mehr!

sudo /usr/bin/mongo --port 27117 < mongo_prune_js.js
MongoDB shell version v4.4.27
connecting to: mongodb://127.0.0.1:27117/?compressors=disabled&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("3ffb1-be3c-") }
MongoDB server version: 4.4.27
1702662410.41
pruning data older than 0 days (1702662410410)... 
switched to db ace
pruning 11 entries (total 11) from alarm... 
pruning 110084 entries (total 110084) from event... 
pruning 4039 entries (total 4096) from user... 
{ "bytesFreed" : 1294336, "ok" : 1 }
uncaught exception: TypeError: db.repairDatabase is not a function :
@(shell):1:14
bye

Danach startet service unifi start nicht mehr.
Ich hole mal kurz das Backup zurück …

6

Hallo Michael,

Mir ist noch nicht ganz klar, wo Du die alten Offline-Verbindungen gelöscht hast. Ich kann die wohl anzeigen lassen – aber entfernen???

in der alten UI auf Insights ( ich glaube das Glühbirnen Symbol), dann die Clients sortieren nach den gewünschten Filterregeln. Und dann hast du bei jedem Client ganz rechts den Button „remove“. Und ja, ich habe das für jeden Client einzeln gemacht.

Mir werden auch immer wieder Clients als offline angezeigt, die eigentlich online sind. Das Verhalten beobachte ich allerdings erst seit der
Controller Version 8.

LG Daniel

7

:flushed: bei 5000 (alten) Verbindungen???

Seit gerade bin ich auf 8.0.24. Hier das aktuelle Changelog:
https://community.ui.com/releases/UniFi-Network-Application-8-0-24/43b24781-aea8-48dc-85b2-3fca42f758c9

Gerade nochmal mit dem Easy-Update-Script nachgesehen:


# Deleting all Alerts and Events...

# Deleting Alerts...
# Successfully deleted 7 Alerts
# Deleting Events...
# Successfully deleted 66182 Events

Ich bin nicht sicher, ob damit auch die alten Verbindungen gelöscht werden.

Aber … eine Beobachtung: Entweder das Löschen der Alerts & Events oder das Zurückholen des Backups hat den erwünschten Effekt gebracht: Bei den Client Devices sind im Moment nur noch ganz wenige Geräte gelistet und die Seite reagiert flüssig wie „nie“!

8

Danke für den Tipp mit dem Update Script. Ist mir bisher gar nicht aufgefallen, dass hier auch noch ein Reinigungsprozess angeboten wird. Das hat auch nochmal über 70000 Events und Alerts gelöscht.

9

Hallo zusammen,

ich bin jetzt auf 8.0.24, hab aber MongoDB noch nicht upgedatet auf 4.4. Würdet Ihr mir das empfehlen?

Danke und Gruß,
Jochen

10

Hallo Jochen,
ich habe das gemacht, weil das EUS zuletzt gemeckert hat und die 3.6er Repos scheinbar nicht mehr richtig liefen?! Ob das teilweise träge Verhalten der Tabs im Controller nun mit dem Update zusammenhängt oder nicht, kann ich nicht 100%ig sicher sagen. Es ergibt aber eigentlich keinen Sinn, dass es da einen Zusammenhang gibt, da das alte User-Interface ja weiterhin flüssig lief :thinking:

Eine Sache ist aber auf jeden Fall merkwürdig und anders als vorher: Wir haben ein paar wetterfeste „Außen-Accesspoints“ der Sorte „UAP AC M Pro“. Die zeigen seit kurzem Quatsch an, wo/wie sie verbunden sein sollen. Da taucht ein falsches VLAN auf und es werden verbundene Clients gezeigt, die so wie es dort angezeigt wird, garantiert nicht verkabelt sind. Das ist aber vermutlich eher ein Firmware-Problem und hat nix mit der mongoDB zu tun…

Man liest ja auch über den Reiter „Topologie“, dass der nur dann halbwegs brauchbare Ergebnisse liefert, wenn das Netz nur aus Unifi-Komponenten besteht?! Das ist hier aber nicht der Fall – wir haben viele Cisco-Switches dazwischen…

So long,
Michael

11

Hallo Michael,

danke Dir für die Rückmeldung.
Dann bleibe ich vorerst mal auf 3.6 und schiebe das Update auf einen Zeitpunkt, wo ich vorher einen Snapshot gemacht habe und anschließend ausreichend Zeit zum Testen (huh, ob das so schnell sein wird???)

Vielen Dank und liebe Grüße,
Jochen

12

Hallo,
ich kann mir vorstellen, dass die fehlerhaften Anzeigen im UI eher an dem Controller-Update liegen als am Update der Datenbank. Ist halt unifi-üblich, dass die Endnutzer auch im stable-release als Betatester fungieren.
Wir haben mongodb nachdem wir das Update auf 8.07 gemacht haben (auf 8.0.24 bin ich noch nicht) durchgezogen.
Vorher Backup und Snapshot anlegen und dann einfach ausprobieren. Bei uns ist das Update der Datenbank anstandslos durchgelaufen.
Das Update hat aber nicht merklich zu einer Steigerung der Geschwindigkeit des UI beigetragen. Auch das Bereinigen von Events und Alerts über das Update-Script ist sicher nice to have abaer hat auch nicht merklich für Speed gesorgt.
Den deutlichen Performancegewinn habe ich dann aber tatsächlich durch das Löschen von tausenden alten Offline-Clients erreicht.

LG
Daniel

13

Hi Jochen,
ich bin auf 8.07, hab das Mongo-Update gemacht (lösche aber auch immer die Events mit dem EUS und so). Bei mir läuft alles flüssig.
Bisher gabs Probleme beim 4.4 Update von Mongo. Falls Du die Möglichkeit für einen Snapshot hast, würde ich es durchziehen, einfach damit es gemacht ist, weil es ja gerade funktioniert… Nicht dass es später wieder Probleme beim Datenbank"umzug" gibt (das ist es letztendlich, es wird ein Backup (bei mir 1,5GB groß, vielleicht hätte man vorher Events löschen sollen?) gemacht, die alte DB gelöscht, eine neue angelegt und das Backup zurückgespielt)
Ist aber nur so ein Gefühl…
LG
Max