Mbeco

As I am just another one in this long list: Could you kindly guide me to how you monitored Dirty Memory Writeback? That is a bit out of my depth, but I have tried almost everything else suggested in this thread and many others that I read over the past months. So if nothing else, maybe I could at least support your working hypothesis

Just to update this again: Problem appeared again this morning, cannot access UI (after half an hour of loading or so I get a 500 Internal Server Error). Can still access via SSH, CPU load in htop is at normal levels, /var/log/syslog shows Aug 6 14:12:15 Tower nginx: 2023/08/06 14:12:15 [error] 958#958: *2832760 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.178.53, server: , request: "GET /Docker HTTP/1.1", subrequest: "/auth-request.php", upstream: "fastcgi://unix:/var/run/php5-fpm.sock", host: "192.168.178.55", referrer: "http://192.168.178.55/Dashboard" Aug 6 14:12:15 Tower nginx: 2023/08/06 14:12:15 [error] 958#958: *2832760 auth request unexpected status: 504 while sending to client, client: 192.168.178.53, server: , request: "GET /Docker HTTP/1.1", host: "192.168.178.55", referrer: "http://192.168.178.55/Dashboard" Restarting nginx didn't help for now. Starting to write this post did, however. While writing my dashboard suddenly loaded again. CPU load pinned to 100% while htop shows low CPU load... Edit: Curiously, my syslog only goes back to 4am at which point it seems some dockers restarted... Might be a trace Aug 6 04:40:04 Tower kernel: docker0: port 5(veth34bdb38) entered blocking state Aug 6 04:40:04 Tower kernel: docker0: port 5(veth34bdb38) entered disabled state Aug 6 04:40:04 Tower kernel: device veth34bdb38 entered promiscuous mode Aug 6 04:40:12 Tower kernel: eth0: renamed from veth6ae1c22 Aug 6 04:40:12 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth34bdb38: link becomes ready Aug 6 04:40:12 Tower kernel: docker0: port 5(veth34bdb38) entered blocking state Aug 6 04:40:12 Tower kernel: docker0: port 5(veth34bdb38) entered forwarding state Aug 6 04:44:49 Tower kernel: veth6ae1c22: renamed from eth0 Aug 6 04:44:49 Tower kernel: docker0: port 5(veth34bdb38) entered disabled state Aug 6 04:44:50 Tower kernel: docker0: port 5(veth34bdb38) entered disabled state Aug 6 04:44:50 Tower kernel: device veth34bdb38 left promiscuous mode Aug 6 04:44:50 Tower kernel: docker0: port 5(veth34bdb38) entered disabled state Aug 6 04:50:01 Tower rsyslogd: [origin software="rsyslogd" swVersion="8.2102.0" x-pid="1095" x-info="https://www.rsyslog.com"] rsyslogd was HUPed Aug 6 06:06:19 Tower kernel: vetha224743: renamed from eth0 Aug 6 06:06:59 Tower kernel: eth0: renamed from veth713ced8 Aug 6 09:30:18 Tower kernel: veth713ced8: renamed from eth0 Aug 6 10:02:09 Tower kernel: eth0: renamed from vethed83cb5 Aug 6 12:16:49 Tower kernel: vethed83cb5: renamed from eth0 Aug 6 12:49:40 Tower kernel: eth0: renamed from veth3842221 Aug 6 13:55:26 Tower webGUI: Successful login user root from 192.168.178.53 Aug 6 13:56:55 Tower sshd[10509]: Connection from 192.168.178.53 port 50425 on 192.168.178.55 port 22 rdomain "" Aug 6 13:56:55 Tower sshd[10509]: Postponed keyboard-interactive for root from 192.168.178.53 port 50425 ssh2 [preauth] Aug 6 13:56:58 Tower sshd[10509]: Postponed keyboard-interactive/pam for root from 192.168.178.53 port 50425 ssh2 [preauth] Aug 6 13:56:58 Tower sshd[10509]: Accepted keyboard-interactive/pam for root from 192.168.178.53 port 50425 ssh2 Aug 6 13:56:58 Tower sshd[10509]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0) Aug 6 13:56:58 Tower elogind-daemon[1306]: New session c3 of user root. Aug 6 13:56:58 Tower sshd[10509]: Starting session: shell on pts/2 for root from 192.168.178.53 port 50425 id 0 Aug 6 14:00:26 Tower root: geth-ethereum: Could not download icon https://geth.ethereum.org/static/images/favicon.png Aug 6 14:12:15 Tower nginx: 2023/08/06 14:12:15 [error] 958#958: *2832760 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.178.53, server: , request: "GET /Docker HTTP/1.1", subrequest: "/auth-request.php", upstream: "fastcgi://unix:/var/run/php5-fpm.sock", host: "192.168.178.55", referrer: "http://192.168.178.55/Dashboard" Aug 6 14:12:15 Tower nginx: 2023/08/06 14:12:15 [error] 958#958: *2832760 auth request unexpected status: 504 while sending to client, client: 192.168.178.53, server: , request: "GET /Docker HTTP/1.1", host: "192.168.178.55", referrer: "http://192.168.178.55/Dashboard" Aug 6 14:28:42 Tower root: geth-ethereum: Could not download icon https://geth.ethereum.org/static/images/favicon.png Aug 6 14:28:43 Tower root: geth-ethereum: Could not download icon https://geth.ethereum.org/static/images/favicon.png Aug 6 14:28:45 Tower emhttpd: read SMART /dev/sdc Aug 6 14:30:35 Tower root: geth-ethereum: Could not download icon https://geth.ethereum.org/static/images/favicon.png Aug 6 14:30:35 Tower root: geth-ethereum: Could not download icon https://geth.ethereum.org/static/images/favicon.png

Thank you @DrSpaldo. I have two Ubuntu VMs running, but they are on dedicated cores. I might still try to move them and see if it solves the problem, although tbh I have little hope. Re Immich: I have tried that, but had a very weird problem with the database that changed its permissions everytime I started the docker. Might try it again in the future.

TBH, I use the services I host so frequently that I cannot afford that much downtime. What's interesting is that this has happened somewhere around the time I upgraded from 6.11.X to 6.12.X. I cannot 100% but quite certainly rule out the VMs, as they are on their dedicated cores, so should not have an influence. As for the dockers, I could turn of all but 5 of them and see how the system behaves, but the remaining 5 are quite crucial for me.

18 Dockers (most of them low- to no-effort) 2 VMs (one on 2 shared cores, one on 4 dedicated cores totalling 20GB of RAM) I am running a Ryzen 7 with 64GB of RAM, which is at an expected 42% utilisation. The CPU however is locked to 100% except for the dedicated cores, sometimes going down for a bit only to go up again. Nothing that is running would justify that level of CPU utilisation. Edit: Adding to that, my docker CPU utilisation in the advanced view shows 0-0.02% utilisation per docker. Full list of dockers I am running: Cloudflared wishthis MariaDB-Monica MariaDB-WishThis pairdrop duplicati PaperlessRedis paperless-ngx PasswordPusherEphemeral send SendRedis storagenode-v3 PhotoprismMariaDB-Official PhotoPrism AdGuard-Home Cloudflare-DDNS WireGuard-Easy scrutiny The Parity sync is PAUSED right now, utilisation is still close to 100%.

Yes, I am following your thread. I have been using Unraid for years, this is the first time I feel they messed up and not me. It is a bit unsatisfactory to not have any proper solution to this problem.

After killing nginx (not stopping it) and starting it again, I can at least access the GUI again, although CPU usage is still high. I expect the problem to occur again soon

Yes, it has and currently still is

Hi, I have had a problem with my Unraid server for a while now. Upfront, I think my problem might be related to this one: Essentially, my Ryzen 7 CPU spikes to 100%, which leads to a currently running parity sync (had to change a disk, so my data is not even secure right now) progressing with ~5KB/s, my dockers being barely accessible, the Unraid GUI itself being barely accessible to the level where it does not load at all anymore. Rebooting only solves the problem for a couple of minutes. The problem only seems to exist when the array is on. I can still access the server via SSH, which is how I exported the attached diagnostics. I am not sure where to continue looking, would appreciate any help. tower-diagnostics-2023.zip

I did set it up for remote use before, I just can't remember how exactly, unfortunately. But I was able to connect using the myunraid FQDN at some point.

So, I'm pretty sure I messed this up, but I guess I hope someone has a solution. I went for a vacation today. Yesterday my parity started throwing smart errors, so I swapped it. Done that before, always worked. But the parity sync was slow, I assume CPU capped. Today noon it was at 50% after ~1 day. 1 hour ago it seems the entire system went down. As the parity was not synced it did not restart the array. I usually connect via VPN with a wireguard container, which I know is not optimal. But I had Unraid myServer connected, so I figured I had a backup. I tested the connection and it did work. Now it doesn't. The qualified domain name from the Unraid Connect dashboard does not work and I don't find any other way to connect. Am I missing something? Is there any way to connect? Unraid connect shows my server as online.

Hi, I tried following your hints to the last details, it's probably me, but for the life of it I can not get it to run. I have tried connecting via the local and external IP, I have tried 27016 and 27500 (the only discrepancy I could find in the manuals), I cannot even get it to connect, the logs show absolutely nothing. I am sorry for being persistent here, but do you maybe have another idea on where to check?

I have already found that, but I just used the template today and it already has the latest parameters, I double-checked that though and it is correct. So I would highly appreciate some help from @Marcel40625. Thank you!

Hi ich777, great work on all the game servers, thank you so much. I seem to be messing up on the Stationeers Server quite a bit: I install the app from CA and start it and the last lines of the log are [39;49m[37m[1;1H [1;1H> [1;1H [1;1H[33m16:59:47: Auto save stopped [39;49m[37m[1;1H [1;1H> [1;1H [1;1H[33m16:59:47: Auto save started (300) [39;49m[37m[1;1H [1;1H> [1;1H [1;1H[32mReady which does seem alright to me. However, I cannot connect, so I did some digging: Neither RCON nor the game itself can connect. setting.xml contains the gameport, which is set to 27016, however in the docker there is only UDP port 27500 as the gameport. Just to test I added 27016, but neither 27500 nor 27016 nor 27015 seem to do the job, neither in LAN nor online. Can you help me out here on what to check next?