spall Posted February 26 Share Posted February 26 So I had this idea (maybe bad) to try and use /tmp for an intermediate directory in nzbget. I thought it could be faster than just hitting a cache pool with all the unpacking and moving etc. So I set it up and everything was cruising fine until it hit roughly 60% RAM usage, and my Unraid GUI started freaking out. It was constantly reloading itself, all the drives in the array would be missing, and then suddenly around a third would be present. The flash drive and everything in unassigned devices disappeared and had the loading icon constantly. Then the log went crazy with this on a loop: Feb 25 20:20:16 spock rc.diskinfo[27686]: PHP Warning: syntax error, unexpected end of file, expecting TC_DOLLAR_CURLY or TC_QUOTED_STRING or '"' in /var/local/emhttp/disks.ini on line 258 Feb 25 20:20:16 spock rc.diskinfo[27686]: in /usr/local/emhttp/plugins/unassigned.devices.preclear/scripts/rc.diskinfo on line 294 Feb 25 20:20:16 spock rc.diskinfo[27686]: PHP Exception: array_map(): Argument #2 ($array) must be of type array, bool given in /usr/local/emhttp/plugins/unassigned.devices.preclear/scripts/rc.diskinfo on line 295 I was able to shut the array down and reboot. I removed the /tmp from the container and everything is normal. But.. what happened here? And while I'm asking the question: Why was this a bad idea? Thanks! Quote Link to comment
itimpi Posted February 26 Share Posted February 26 Not clear from your description if the /tmp in the nzbget container was mapped to anything at the Unraid level? If it was mapped what was the location on the Unraid side? Quote Link to comment
spall Posted February 26 Author Share Posted February 26 @itimpi Sorry! I meant /tmp on the Unraid side. I was trying to use RAM as the intermediate directory. Quote Link to comment
itimpi Posted February 26 Share Posted February 26 13 minutes ago, spall said: @itimpi Sorry! I meant /tmp on the Unraid side. I was trying to use RAM as the intermediate directory. Did you map directly to /tmp or to a folder under /tmp at the Unraid level? Just asking if it was not to a folder under /tmp then the container could have been deleting some of Unraid’s /tmp files that Unraid expects to be there thus causing problems. The other possibility is that more was being put into /tmp than you expected and eventually caused RAM usage issues at the Unraid host level. Quote Link to comment
spall Posted February 26 Author Share Posted February 26 @itimpi I mapped to a folder inside: /tmp/intermediate. Your second point is what was confusing me, because the dashboard was reporting in the 60% range, and that was jiving with the amount of RAM use at the start of the download + the size of the file in /tmp. The server should have, at that point, had >40GB of RAM left to muck with. Am I correct in my understanding that /tmp will use whatever RAM is available? /tmp isn't the one that's only 1/2 RAM? If the latter, it would have filled it up and maybe that caused the muck up. Quote Link to comment
itimpi Posted February 26 Share Posted February 26 2 hours ago, spall said: Am I correct in my understanding that /tmp will use whatever RAM is available? /tmp isn't the one that's only 1/2 RAM? If the latter, it would have filled it up and maybe that caused the muck up. I thought it could use more than 1/2 but may be wrong about that. Quote Link to comment
spall Posted February 26 Author Share Posted February 26 That was the assumption I was under. Hmm. Ok. Maybe someone will chime in with the definitive on that. Otherwise, I have no idea what went south. Thanks again for commenting! Quote Link to comment
JorgeB Posted February 27 Share Posted February 27 21 hours ago, itimpi said: I thought it could use more than 1/2 Pretty sure /tmp is limited to half the installed RAM. Quote Link to comment
Solution Kilrah Posted February 27 Solution Share Posted February 27 (edited) /tmp is not a mount so it's in the rootfs, that's half the installed ram and as you saw things will go south if it gets full and there's no space for the OS to work with anymore. /dev/shm is a separate tmpfs in RAM with size being half the installed capacity too, better to use that since if it fills up it won't clog the rootfs that still has the other half to work with. Edited February 27 by Kilrah Quote Link to comment
spall Posted February 28 Author Share Posted February 28 All right. Thanks everyone. I'm gonna consider the mystery solved. So much for that idea. Unless I want to replace all sticks for a higher density. Much appreciated. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.