Beiträge von blue_focus

Wäre vielleicht mal ne überlegung das über Telegraf in meine InfluxDB zu saugen. Dan hätte man das im zeitlichen Verlauf.

Da der Telegraf das aber vermutlich nicht nativ unterstützt müsste man ein Scriptbasteln, welches die Daten korrekt für Influx aufbereitetet. sed und awk sind leider nicht so meine Freunde

------ Korrektur

Telegraf hat da doch schon was. Wenn Slab auch nur als gesamtes gesehen wird und nicht einzeln nach Kernel-Modul.

pasted-from-clipboard.png

So schaut das bei mir aus. Das hellblaue Dings unten ist der Slab-Space über die letzten 30 Tage.

Das schaut dann bei mir so aus ->

632 MB : buffer_head
568 MB : ext4_inode_cache
420 MB : radix_tree_node
258 MB : ovl_inode
226 MB : dentry
46 MB : kmalloc-512
44 MB : proc_inode_cache
38 MB : ext4_groupinfo_4k
32 MB : kmalloc-192
26 MB : dm_bufio_buffer-16
25 MB : kmalloc-64
16 MB : inode_cache
16 MB : filp
15 MB : shmem_inode_cache
15 MB : raid5-md2-alt
13 MB : vm_area_struct
13 MB : task_struct
12 MB : kmalloc-2k
11 MB : kernfs_node_cache
8 MB : kmalloc-1k
7 MB : kmalloc-256
6 MB : kmalloc-rcl-96
5 MB : kmalloc-4k
5 MB : biovec-max
4 MB : kmalloc-32
4 MB : ext4_extent_status
4 MB : anon_vma_chain
3 MB : sock_inode_cache
3 MB : skbuff_head_cache
3 MB : sighand_cache
3 MB : kmalloc-rcl-64
3 MB : kmalloc-8k
3 MB : anon_vma
2 MB : vmap_area
2 MB : kmalloc-128
1 MB : signal_cache
1 MB : request_queue
1 MB : pid
1 MB : mnt_cache
1 MB : lsm_file_cache
1 MB : kvm_mmu_page_header
1 MB : ext4_system_zone
1 MB : drbd_req
1 MB : drbd_ee
1 MB : UNIX
1 MB : Acpi-Namespace
0 MB : xfrm_state
0 MB : x86_lbr
0 MB : x86_fpu
0 MB : x86_emulator

Schaut bei mir wie folgt aus. Ich muss aber gestehen, dass ich hier nicht tief genug drinnen bin das zu interpretieren.

Wo hast du dir dann den angesehen, wie viel Swap freigegeben wurde?
Die qBoost UI zeigt hier nämlich Mist an, weil sie nicht darauf wartet, bis das swapoff wirklich fertig ist. Bei mir wird der Swap wirklich komplett ausgeleert, auch wenn qBoost was Anderes behauptet. Ohne Änderung der Swappiness bläst sich der Swap aber recht schnell wieder auf den ursprünglichen Wert auf.

Viel wichtiger als die Swappiness per se finde ich die Deaktivierung der Swap-Partitions auf den drehenden Platten, wenn eh auch SSD dafür da wären. DAS find ich das wirkliche Manko bei QTS, dass man das nicht selbst einstellen "darf".

duke-f

Hast du schon mal den Swap mit "swapoff" oder qBoost in der WebUI aufräumen lassen?
Bei mir wurde der verwendete swap space nun deutlich geringer, seit ich die swappiness von 25 auf 5 reduziert habe.
pasted-from-clipboard.png

Doch doch, das ist schon das normale QTS

pasted-from-clipboard.png

QTSHero würde mich eh auch interessieren und läuft auch auf meiner TVS. Aber mir fehlt da irgendwie die Zeit und Lust alle meine Services und Daten migrieren zu müssen.

Hab was gefunden:

echo 5 > /proc/sys/vm/swappiness

Hab das jetzt mal von 25 auf 5 reduziert. Somit sollte der Kernel noch etwas mehr zum RAM tendieren, denn zum Swap-Space. Ist natürlich nicht persistent und müsste dann in das Autostart.sh, wenn sichs bewährt.

Also der swapped schon nicht unerheblich.

pasted-from-clipboard.png

Da wo es fast bei null ist, hab ich den mal ausgeleert. Aber man sieht, es dauert ca. 1 Tag dann ist er wieder bei so 10GB.

Hallo zusammen,

gibt es in QTS irgendwo die Möglichkeit die "swappiness" zu konfigurieren. Mir ist das Teil definitiv zu swap freudig. Ich meine, es sind 64GB RAM verbaut, wovon selten mehr als 30GB verwendet werden. Trotzdem fängt das System an mit der Zeit immer mehr in den Swap raus zu pagen. Ich merke es dann bei VMs, die sich dann von der Performance her wie ein Gummiband anfühlen können. Wenn man QTS machen lässt, dann werden auch gerne die drehenden Platten dazu vergewaltigt, obwohl mehr als genug NVM oder SATA SSD Space da wäre. Die HDD Swaps hab ich schon abgedreht, das hilft schon mal viel. Aber es wäre generell toll, wenn das System seinen RAM auch ausnützen würde, wenn er schon da ist.

Oder man verwendet anstatt der Containerstation einfach ne alternative UI, wie zB.: den Portainer. Der kann das Updaten der images out of the box per Klick ->

Mir gefällt der Beitrag. Danke hierfür

Ich stelle selbst bei meiner recht dicken QNAP mit 64GB RAM fest, dass sie ohne Not immer wieder die lahmen HDDs den beiden SSDs oder gar NVMes vorzieht... Warum auch immer. Zumal mein System hier selten mehr als 50% RAM-Load sieht. Muss mit der globalen Swappines - Einstellung in QTS zusammenhängen. Oder an RAM-Limitierten Docker-Containern, die dann meinen swappen zu müssen, anstatt einfach neuzustarten, wenn sie out of mem laufen. Allerdings versteh ich trotzdem nicht, warum dann manchmal die QTS-Angelegten Swap-Spaces auf den SSDs leer sind, aber die HDDs schon gut verwendet werden. Jetzt könnte man sagen: Eh egal! Aber NEIN! ist es nicht! Hab die letzten 5 Tage meine 3x 10TB Ironwolfs gegen 4x 20TB Toshiba Cloud Scales getauscht. Dadurch war das RAID 5 ständig im Rebuild/Resync und hat die HDDs gut beschäftigt. Da schon 4-5GB in den SWAP-Partions der HDDs waren, wurde das ganze System extremst laggy. Grafana, Influx, SQLDB. Alles furchtbar zäh, obwohl das eigentlich alles auf dem NVMe RAID laufen sollte und keine nennenswerte CPU-Load zu sehen war. QTS läuft auch auf SSDs. Aber der IOWait ist eben ein Hund und wenn dann auch ausgelagerte Daten wieder ewig auf sich warten lassen, machts das auch nicht besser.

Finde es ja echt bescheiden, dass so performancerelevante Tweakeinstellungen nicht in der UI eingestellt werden können.

Guter Punkt, das hätte ich sogar gemacht. Allerdings funktioniert das leider nur mäßig mit Tagged VLANs. Am meisten Probleme hatte ich dann mit Docker Containern mit direktem Portforwarding auf die QNAP Host-IPs. Denn da greift dieses Service Binding leider überhaupt nicht.

Ich glaub ich habs jetzt hinbekommen. Meinen "Traefik"-Reversproxy, der mir die ganzen Docker-Container Frontends durchschleift nach draußen,hab ich auf eine eigene IP in meiner MGMT-DMZ gelegt, anstatt des Host-Portmappings. Das war das Teil, welches am meisten Probleme gemacht hat.

Dann als nächstes hab ich die QuFirewall so konfiguriert, dass auf dem Interface in der Client DMZ nur Port TCP 445 (SMB) erlaubt wird. Denn obwohl ich im Service Bindung nur MS Networking angehakt hätte auf der Client DMZ NIC komm ich über diese IP trotzdem super auf den QTS Desktop.

So schaut es jetzt fürs erste mal ganz gut aus. Werde es weiter beobachten, ob ich noch auf etwaige Probleme stoße.

So, der Titel ist jetzt wirklich doof, mir fällt nur leider nix besseres ein

Es geht um Folgendes:

Meine QNAP steht managementtechnisch in einem abgeschottetem VLAN. Dieses soll auch das default Netzwerk für alles sein, was mir die QNAP serviert. Allerdings gibt es einzelne Services, welche ich gerne nicht durch die Firewall lassen würde... aus Performancegründen.

zB.: hätte ich gerne SMB direkt in meinem Client-LAN und zwar nur dieses. QTS-Desktop, SSH und alles Andere "gefährliche" soll schön hinter der Firewall (pfsense netgate 2100) bleiben.

Grundsätzlich krieg ich das auch hin für SMB, in dem ich einfach in meinem Client-LAN einem QNAP-Interface eine IP gebe.

Nur hab ich dann folgendes Problem. Greife ich über das im Client-VLAN befindliche Interface auf SMB zu, geht alles wunderbar. Will ich aber von meinem Client zB.: auf ein Management-Service (SSH, QTS-Desktop,...) über die IP im MGMT-Netz, geht meine Anfrage zwar schön über die Firewall, die Antwort kommt dann aber Random-Mäßig auch über die NIC in meinem Client LAN, was dann zu asynchronen Routing führt. Die pfSense mag das so überhaupt nicht und dropped mal alle Response-Pakete, deren Request sie aber nicht kennt (weil falsch abgebogen). Bislang konnte ich QTS diese interne Routing-Abkürzung noch nicht abgewöhnen, da alle Netze zu denen QTS eine eigene IP-Adresse hat eine default Route mit Metrik 0 über die entsprechende NIC anlegt.

Kurz zum Verständnis:

IP-MGMT: 192.168.178.x

IP-Client: 192.168.102.x

Was ich jetzt verhindern will:

Sende ich eine Anfrage direkt an 192.168.178.x -> will ich die Antwort NICHT von 192.168.102.x erhalten!

Hat wer eine Idee, wie man das "umbiegen" kann? Über die UI gehts ja nicht und mit einer static route kann ich ja eine Metrik 0 Route auch nicht overrulen, oder?

Danke für etwaigen Input

Zitat von tiermutter

Tja, es gibt halt die einfachen Fälle auf die ein Support vorbereitet ist und... Dich.

Genau. Wenn ich zum Supp komme, hab ich idR schon alles nahe und nicht nahe Liegende durch. Da bin ich dann oft schon vor beim Initialmail schon am Ende der Checkliste vom Supp angekommen

Daher sagen die mir ja dann meistens -> Mach QTS neu.

Nur, da ich ja eh kaum Apps installiert habe und alles nur als Container oder VM am Laufen habe, geh ich mal von aus, dass mein QTS an sich noch so Clean wie nur was sein müsste, habs auch erst vor ein paar Monaten neu gemacht. Von daher weiß ich, es kostet mich Tage bis wieder alles läuft wie es soll.

Ich bin nun nen Schritt weiter, wenn auch das Problem noch nicht behoben ist.

Wenn ich die snmpd binary manuell starte mit dem -Lo Parameter (Log wird in die Console geschrieben) kommt dieses Fehlerbild und endet in nam Crash mit Return Code 1

$SNMPD -c /etc/config/snmpd.conf -Lo
+ /usr/local/bin/snmpd -c /etc/config/snmpd.conf -Lo
MIB search path: /share/homes/admin/.snmp/mibs:/./share/snmp/mibs
Cannot find module (SNMPv2-MIB): At line 0 in (none)
Cannot find module (IF-MIB): At line 0 in (none)
Cannot find module (IP-MIB): At line 0 in (none)
Cannot find module (TCP-MIB): At line 0 in (none)
Cannot find module (UDP-MIB): At line 0 in (none)
Cannot find module (HOST-RESOURCES-MIB): At line 0 in (none)
Cannot find module (NOTIFICATION-LOG-MIB): At line 0 in (none)
Cannot find module (DISMAN-EVENT-MIB): At line 0 in (none)
Cannot find module (DISMAN-SCHEDULE-MIB): At line 0 in (none)
Cannot find module (NAS-MIB): At line 0 in (none)
Cannot find module (QTS-MIB): At line 0 in (none)
Cannot find module (SNMP-TARGET-MIB): At line 0 in (none)
Cannot find module (NET-SNMP-AGENT-MIB): At line 0 in (none)
Cannot find module (HOST-RESOURCES-TYPES): At line 0 in (none)
Cannot find module (SNMP-FRAMEWORK-MIB): At line 0 in (none)
Cannot find module (SNMP-MPD-MIB): At line 0 in (none)
Cannot find module (SNMP-USER-BASED-SM-MIB): At line 0 in (none)
Cannot find module (SNMP-VIEW-BASED-ACM-MIB): At line 0 in (none)
Cannot find module (SNMP-COMMUNITY-MIB): At line 0 in (none)
Cannot find module (IPV6-ICMP-MIB): At line 0 in (none)
Cannot find module (IPV6-MIB): At line 0 in (none)
Cannot find module (IPV6-TCP-MIB): At line 0 in (none)
Cannot find module (IPV6-UDP-MIB): At line 0 in (none)
Cannot find module (IP-FORWARD-MIB): At line 0 in (none)
Cannot find module (SNMP-NOTIFICATION-MIB): At line 0 in (none)
Cannot find module (SNMPv2-TM): At line 0 in (none)
Cannot find module (NET-SNMP-VACM-MIB): At line 0 in (none)
Error opening specified endpoint "udp:172.29.0.1:161"
Server Exiting with code 1

Interessant da bei ist

Error opening specified endpoint "udp:172.29.0.1:161"

Das ist bei mir der vSwitch für das Docker Netzwerk.

Warum genau das jetzt auf diesem Interface nicht starten will, weiß ich nicht, weder Netstat noch ps aux bescheinigen mir irgendetwas Laufendes auf diesem Port. Reboot tut gut... aber befriedegend ist die Lösung auf Dauer nicht.

NACHTRAG:

Also der Reboot richtets jetzt auch nicht mehr. Was mich total irritiert ist, warum kann ich den snmpd nicht auf eine bestimmte IP binden. Also ich kanns zwar in die snmpd.conf schreiben und auch als startparameter mit geben. wird mir aber komplett ignoriert und er versucht erst wieder auf allen interfaces zu starten

Ha... Jetzt hab ich ihn

Irgend ein Update muss mir den Netzwerstack vermurkst haben. Ich hatte jede Menge Virtuelle Switches mit teilweise gleichen IP Adressen, dafür aber für nix in Verwendung. Eben auch diese eine IP die er bemängelt war gleich 3x vorhanden

pasted-from-clipboard.png

pasted-from-clipboard.png

Hab die unnötigen vSwitches mal entfernt und tadaaaaa. SNMP läuft sofort wieder los.

BTW:

Gut dass ich vor 2h nen Ticket geschrieben habe

Genau, ich krieg immer Schüttelfrost, wenn nen Support-Case ansteht, daher versuch ichs immer vorher selbst (was meistens auch funktioniert)

Wie gesagt, ich hatte abseits von Lizenzthemen, deren Cases immer super funktioniert haben, leider nur schlechte Erfahrungen mit dem Tech-Support gemacht. War eigentlich immer nur ne Menge Zusatzarbeit für mich und der Outcome meistens, dass ich dem Support dann meine eigenen Problemlösung mitgeteilt habe.

Zitat von tiermutter

Ich hätte jetzt gesagt /usr/local/bin/snmpd

Das ist denke ich eher die binary die startet. Nicht das Service Managescript.

Ich kann mit oben besagtem Script den snmpd starten/stoppen. Allerdings finde ich danach keinen snmpd Prozess via ps aux.

auch ein nmap bestätigt mir ein Port closed.

root@284224ede480:/# nmap -sU -p 161 homeserver
Starting Nmap 7.70 ( https://nmap.org ) at 2022-11-29 14:17 UTC
Nmap scan report for homeserver (10.0.3.1)
Host is up (0.000053s latency).
rDNS record for 10.0.3.1: HomeServer


PORT    STATE  SERVICE
161/udp closed snmp


Nmap done: 1 IP address (1 host up) scanned in 0.52 seconds

Wo versteckt QTS nur die snmpd logs. Wieder find ich nix unter den üblichen Pfaden. Auch das /var/log/messages ist immer leer

Ja, bei mir kommt nicht alles aus dem snmpd. CPU, MEM, Disk IOPS usw. hole ich über andere Scripts, oder telegraf native ab.

Aber Temperaturen, SMART-Status etc. bekomm ich so einfach nicht raus ohne SNMP.

Wenn ich den CLI command wüsste um den snmpd neu zu starten ohne über die services.sh gleich alles zu restarten wäre ich fürs erste schon happy.

Hab mir die services.sh schon etwas angesehen. Konnte die für mich relevante Info aber noch nicht so recht herausfinden. Sowas wie nen sysctl oder servicectl scheints unter QTS ja nicht zu geben. Auch finde ich allerhand Scripts für alles Mögliche in etc/init.d. Aber eben nix für den snmpd.

Ich hatte schon einige Cases bei QNAP. In den seltesten Fällen waren die von Erfolg gekrönt und endeten oft mit der Bitte QTS doch bitte neu aufzusetzen... na sicher nicht... schon wieder

Nachtrag:

Hab dich!

. /etc/rcS.d/S95snmp restart

Aber mein Problem hat es eh nicht behoben. Da dürfte sich irgendein zugrunde liegendes Services verabschiedet haben. Fakt ist, nach nem Reboot tut es meistens wieder für ein paar Tage/Wochen.

Ich sehe, dass seit diesem Zeipunkt hier, wo die Lüfter RPM Kurve aufhört keine Daten mehr vom snmpd mehr bezogen werden konnten:
pasted-from-clipboard.png

Auch die Temperaturen werden nicht mehr aktualisiert. Die Werte die man hier sieht sind nur noch extrapoliert vom letzten gültigen Wert, da hier in der InfluxQL ein "fill(previous)" eingestellt ist.

Lasse ich mir nur die letzten 6h anzeigen sind die ganzen Widgets leer, weil grafana keine Daten mehr zum extrapolieren hat.

pasted-from-clipboard.png

Hallo zusammen,

bei meiner QNAP passiert es leider in unregelmäßigen Abständen, dass sich der snmpd verabschiedet. Ich kann dann via telegraf viele der Performance Metriken nicht mehr abfragen.

Wie starte ich den wieder manuell neu. Früher gabs da ja die entsprechenden init.d Scripts. Leider kann ich das unter QTS 5.0.1 nirgends mehr finden und jedesmal die ganze QNAP rebooten finde ich jetzt auch nicht so die tolle Lösung.

BTW: Einfach den SNMP-Zugriff in den QTS-Einstellungen deaktivieren und wieder aktivieren funktioniert leider auch nicht.

Modell: TVS-672X

QTS (non Hero): 5.0.1.2194

Danke für Input

Ich glaub ja langsam dieses Zugrundeliegende RTRR Zeugs zickt da gerne mal. Einer meiner SyncJobs via VPN hat bei mir regelmäßig dazu geführt, dass der QNAP der RAM restlos überging. Jedes Mal wars der RTRR-Prozess des besagten Jobs der sich einfach mal > 40GB RAM allokierte (von installierten 32GB) und QTS restlos zum erliegen brachte bis man den Prozess mit kill -9 abgestochen hat. QNAP Support meinte auch. HBS3 neu installieren

Für OS Backups verwende ich auch Veeam. Allerdings hab ich da ne NFR-Lizenz mit VeeamBackupServer + Repo-Server usw., da wir das in der Firma auch im großen Stil einsetzen, komm ich da recht leicht ran.

Für Ordner die ich einfach nur mit nem Share synchen will verwende ich den FreeFileSync (FFS). Veeam gefällt mir nicht, wenn man einfach nur ne kleine Auswahl an Files synchronisieren will. Denn es braucht schon Äonen bei der Enumeration was er jetzt überhaupt backupen soll. FFS macht das deutlich performanter und eleganter. Bei mir vergleicht es ca. 180.000 Files zwischen D:\ u. QNAP Share in ca. 10 Sekunden, sofern keine größeren Deltas zu übertragen sind.

FFS kann in der Free Version eigentlich schon alles was man braucht. Aber ich war davon so begeistert, dass ich mir da sogar die Spendenversion rausgelassen habe und das heißt bei mir Knauserer schon was