jpatriarca
Members
-
Joined
-
Last visited
-
RAM is not the root cause, at least directly. I detected I had a oom-kill related with qemu and the unique virtual machine that I have with 8GB of RAM and without balooning. Now, with it started, I have this RAM consumption: Another thing I detect is a discrepancy between CPU comsumption graphin in UnRAID comprated with htop. htop gives me 5-10% per core when the UnRAID graphic gives me 80-90% constantly. I'm unable to detect any docker container with such high usage, as all containers have 0-1% CPU usage. The system is not unresponsive when the service is up, or I see slowness on it. Only the high load average that grow along the time due to multiple du -sb hanged commands make the system slower until service hangs. If I kill the PID for those, load average reduced to normal values. I assume the root cause is other.
-
Hi team. I've updated to 7.1.4 at the same time that my USB drive failed and I replaced it using the guidance on UnRAID documentation. After starting using this version, I started to see that, some hours after a reboot, this lines in the syslog file: As you can see, I already raised the max_children value using the /boot/config/go file to change this value from /etc/php-fpm.d/www.conf to no avail. After further review I see that my process list, at the time the service hangs and before I restart it, is flooded with du -sb commands. Using htop, I can see it is related with php-fpm as you can confirm in the screenshot below: If I restart the service, the web portal is restored for some hours and then breaks again. But the list of pending processes are not cleaned up anytime I restart the service. Dozen and dozen of services continue to be listed and my Load Average goes to the roof. I need to use htop to manually kill each process to get load average low and keep system integrity. I haven't determined yet the root cause, but it seems that the command is used in UnRAID to calculate folder size, which I'm not using at all by issuing that command in the web service. Also, it seems the service is executed, and it hangs there without closing. Attached you find my diagnostics file for you review and looking forward to get your time and expertise to identify the root cause and place suggested corrections to avoid it in the future. unraid-diagnostics-20250624-1713.zip
-
I've detected a lot of instability since 7.1.2 version is installed, in a way that I was not seeing and feeling on my UnRAID system since 7.0 RC versions. Despite I'm facing an issue with a disk on my array, these errors are not related with this particular situation. Probably it's a curiosity, but this disk started to behave like this also after 7.1.2 version install. But I'm aware about some instability. Regarding the NFS behavior and issues, these are the situations I'm detecting: - NFS becames unresponsible randomly during the day - I rely on Proxmox LXC with mount points from hosts with NFS.When NFS hangs on UnRAID, all LXC that depends on Proxmox MP on NFS will hang and stop working - The same issues happens with direct NFS connections between physical and virtual machines using NFS connections into UnRAID About the hangings, these are the situations I already faced: - USB pen drive became unavailable. Needed to restart the physical machine As I moved to downgrade to the last installed version 7.1 RC5 which was the last one I used and where I've felt the system was stable, I'm sharing my diagnostics file for your review. Thank you unraid-diagnostics-20250520_1057.zip
-
Hi team, I have a newly installed server with 7.0.0-beta2 and I'm detecting two issues with my install that seems to be related to the same root cause, NFS service Issue #1 Anytime I need to stop my array, I get logs stating that one or multiple mount locations are busy and the system are unable to unmount them. No matter how much time I wait, those will not unmount, even if my mounts in the destination servers (plenty of physical and Proxmox VM and CT) mounts and closed before stopping the array. If I then press the shutdown/reboot, every time the system restart, a new parity-check will start, that will take something like 2 days to complete Issue #2 Regarding the NFS connected servers to unraid, sometimes the NFS service hangs on unraid, which avoids my servers to connect to the server. Even if I restart NFS or RPC services in unraid servers, I'm unable to make unraid NFS shares to be connected. But still, if I use showmounts commands towards unraid, all visible shares are listed in the command execution for any server. I've also tested to restart my servers and try to re-connect to NFS shares, but I get the same timeout error when connecting. Anytime I get these errors, without exception, I'm forced to restart my server and I need to go through issue #1 and the consequences described above. Sharing the diagnostic saved in my USB for the last restart I needed to do this afternoon, related with issue #2 and now my parity-check task is being executed. Both issues has been detected also on 7.0.0-beta1 version. This behavior was not seen on my previous NAS, that was a Synology. Looking forward getting your feedback. unraid-diagnostics-20240813-1621.zip
