Hi,

 

Unraid RAM showed 90% while I typically sit around 55%.

Executed the command below and the biggest entry was

 

> ps aux | awk '{print $6/1024 " MB\t\t" $11}' | sort -n
[...]
2459.91 MB              /usr/local/bin/unraid-api/unraid-api

 

I killed the process and restarted it using the UI and its back to normal usage (~145.051 MB)

 

unraid version: 6.11.3 

My servers version: 2022.11.29.0742 

 

Thanks, we'll keep an eye out for that. BTW the easiest way to restart the api is `unraid-api restart`

Ah thanks! that works better than killing it and i can cron this every day or so until it is fixed

PS: After one day, its up to 191.9 MB (from 145MB)

likewise here noticed it slowly increases: 

 

Uptime 16 Days

Version: 6.11.5 

my servers: 2022.11.29.0742 

 

I updated my Servers to 2023.01.23.1223 and the api seems to have stabilised, will monitor it.

Edited January 29, 20233 yr by Jarryd
updated myServers plugin

On 1/4/2023 at 6:24 PM, JonD said:

Hi,

 

Unraid RAM showed 90% while I typically sit around 55%.

Executed the command below and the biggest entry was

 

> ps aux | awk '{print $6/1024 " MB\t\t" $11}' | sort -n
[...]
2459.91 MB              /usr/local/bin/unraid-api/unraid-api

 

I killed the process and restarted it using the UI and its back to normal usage (~145.051 MB)

 

unraid version: 6.11.3 

My servers version: 2022.11.29.0742 

 

Thank you for this command - useful

On 1/29/2023 at 4:01 AM, Jarryd said:

I updated my Servers to 2023.01.23.1223 and the api seems to have stabilised, will monitor it.

 

Yes we didn't call it out in the release notes but the current version does make some improvements here.

is this normal for unraid-api to use 73M of ram?

 

root@Tower:~# df /h /var/log
df: /h: No such file or directory
Filesystem     1K-blocks   Used Available Use% Mounted on
tmpfs             131072 103604     27468  80% /var/log
root@Tower:~# du -sm /var/log/*
1       /var/log/apcupsd.events
1       /var/log/apcupsd.events.1
1       /var/log/apcupsd.events.2
1       /var/log/apcupsd.events.3
1       /var/log/apcupsd.events.4
0       /var/log/btmp
0       /var/log/cron
0       /var/log/debug
1       /var/log/dmesg
1       /var/log/docker.log
0       /var/log/faillog
0       /var/log/lastlog
1       /var/log/libvirt
0       /var/log/maillog
0       /var/log/messages
0       /var/log/nfsd
0       /var/log/nginx
0       /var/log/packages
1       /var/log/pkgtools
0       /var/log/plugins
0       /var/log/pwfail
0       /var/log/removed_packages
0       /var/log/removed_scripts
0       /var/log/removed_uninstall_scripts
4       /var/log/samba
0       /var/log/scripts
0       /var/log/secure
0       /var/log/setup
0       /var/log/spooler
0       /var/log/swtpm
5       /var/log/syslog
11      /var/log/syslog.1
10      /var/log/syslog.2
73      /var/log/unraid-api
1       /var/log/vfio-pci
0       /var/log/vfio-pci-errors
1       /var/log/wg-quick.log
1       /var/log/wtmp

I'm looking at a similar situation with stdout.log.1 not-so-slowly filling up /var/log.  It seems to be set to DEBUG level logging and is not rotating despite being >10MB in size.

 

root@Unplucky:/var/log# ls -alh unraid-api/
total 37M
drw-r--r--  2 root root 100 Jan 11 04:40 ./
drwxr-xr-x 13 root root 780 Jan 11 03:00 ../
-rw-------  1 root root 146 Jan  3 12:40 stderr.log
-rw-------  1 root root   0 Jan 11 04:40 stdout.log
-rw-------  1 root root 37M Jan 12 08:05 stdout.log.1

 

Also interesting that it's writing to ".1" and not the standard named file.

Well, I think updating unraid-api has resolved my issue.  After the update it wrote INFO level logs into stdout.log and hasn't written anything more to stdout.log.1.  I'll continue to monitor but I believe that "fixed" it.

root@Unplucky:/var/log/unraid-api# ls -alh
total 37M
drw-r--r--  2 root root  100 Jan 11 04:40 ./
drwxr-xr-x 13 root root  780 Jan 12 08:11 ../
-rw-------  1 root root  146 Jan  3 12:40 stderr.log
-rw-------  1 root root 2.8K Jan 12 08:11 stdout.log
-rw-------  1 root root  37M Jan 12 08:11 stdout.log.1