April 3, 20179 yr I was hoping to be able to run several dockers and 4 VMs on a server with dual xeons (8 threads each, 12MB cache), and 20gb RAM in a 4x2x2x2 configuration for each CPU (balanced so that the QPI link doesn't get saturated one way more than the other). The problem I'm having is that i appear to be running out of memory, the system is crashing, then restarting, i haven't been able to capture the log confirming this, but having reduced the amount of resources allocated to the VMs, the system uptime was extended. I have since added a swap file as a further test. My last crash/restart was when moving data around over SMB. I have my VMs configured as follows: Windows 7 - 2 threads, 3GB Ram Ubuntu running in text mode console - 2 threads, 1GB Ram pfSense - 2 threads, 512MB Ram Server 2016 - 8 threads, 8GB Ram That's 12.5GB but I've read in other threads that's the VMs can end up consuming more than specified? Dockers: Jackett Sonarr Radarr Rutorrent Plex Memtest passed the memory no issue, i ran it in SMT mode with round robin core selection. Tgis is my TOP output, sorted by memory usage top - 19:54:51 up 8:24, 1 user, load average: 0.67, 1.25, 1.73 Tasks: 427 total, 1 running, 426 sleeping, 0 stopped, 0 zombie %Cpu(s): 1.3 us, 1.1 sy, 0.0 ni, 96.9 id, 0.6 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 20568732 total, 2572296 free, 11700848 used, 6295588 buff/cache KiB Swap: 4194300 total, 310896 free, 3883404 used. 7740096 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10932 root 20 0 9352092 6.784g 17424 S 3.0 34.6 59:42.08 qemu-syste+ 10886 root 20 0 4004788 2.415g 17376 S 7.9 12.3 41:48.72 qemu-syste+ 10672 root 20 0 1252048 682148 16972 S 14.9 3.3 96:24.86 qemu-syste+ 10981 root 20 0 1977268 198000 17316 S 0.3 1.0 1:45.62 qemu-syste+ 10238 nobody 20 0 1571400 131740 6000 S 0.0 0.6 2:56.77 mono 9298 nobody 20 0 215168 109760 5036 S 0.0 0.5 1:45.74 mono 9781 nobody 20 0 1150092 103264 4060 S 0.0 0.5 2:07.42 mono 9967 nobody 20 0 543296 67484 14684 S 0.0 0.3 4:14.73 Plex Media+ 26312 nobody 20 0 414768 46392 21572 S 12.3 0.2 2:35.49 smbd 10211 nobody 35 15 1772904 43776 1452 S 0.0 0.2 0:42.53 Plex Scrip+ 8264 root 20 0 1736076 41872 23452 S 0.0 0.2 0:22.08 dockerd 24839 nobody 20 0 71992 37164 3124 S 0.0 0.2 1:55.56 rtorrent 11243 nobody 20 0 257056 31076 2768 S 0.0 0.2 0:19.52 Plex DLNA + 11328 root 20 0 421240 26168 17744 S 0.0 0.1 1:44.07 smbd 14164 root 22 2 173504 21752 16628 S 0.0 0.1 0:00.13 startDiagn+ 1866 root 20 0 300656 15560 13024 S 0.0 0.1 0:00.20 smbd 8280 root 20 0 1062124 15264 7328 S 0.0 0.1 0:03.19 docker-con+ Edited April 3, 20179 yr by Spies
April 3, 20179 yr What you want to do is install the Fix Common Problems plugin, then set it to troublshooting mode and it will capture the logs to your flash drive when the server crashes. I would also suggest reducing the RAM in Server 2016 to 4GB unless you are running any applications, I would also reduce it to two cores, two threads, again unless you are doing anything CPU intensive.
April 3, 20179 yr Author i am using fix common problems but it is yet to capture anything useful. unfortunately it stopped tailing the syslog at 4am this morning but the crash was around 11am.
April 3, 20179 yr Keep in mind each VM requires a chunk of RAM to manage the emulation. The exact amount needed doesn't seem to be easily determined ahead of time, but I figure on keeping at least 2GB free for unraid and its plugins and dockers, plus about 1-2GB per each VM for management purposes. Using those figures, you are probably oversubscribed by at least 2.5GB.
April 3, 20179 yr i just learned this the other day but it helped the resources, when using multiple cpus make sure you use the correct pair. I was not, you can see the pairs in the dashboard. Made a difference for me.
April 3, 20179 yr Author 11 minutes ago, ijuarez said: i just learned this the other day but it helped the resources, when using multiple cpus make sure you use the correct pair. I was not, you can see the pairs in the dashboard. Made a difference for me. As far as I'm aware the pairings are: 0,4 1,5 2,6 3,7 8,12 9,13 10,14 11,15
April 3, 20179 yr Author Interesting, I was under the impression that the pairs listed under the VM creation were correct but when I ran the following command, it confirms that the dashboard is indeed right where the core id and physical id match. cat /proc/cpuinfo |egrep "processor|physical id|core id" | sed 's/^processor/\nprocessor/g' processor : 0 physical id : 0 core id : 0 processor : 1 physical id : 1 core id : 0 processor : 2 physical id : 0 core id : 1 processor : 3 physical id : 1 core id : 1 processor : 4 physical id : 0 core id : 9 processor : 5 physical id : 1 core id : 9 processor : 6 physical id : 0 core id : 10 processor : 7 physical id : 1 core id : 10 processor : 8 physical id : 0 core id : 0 processor : 9 physical id : 1 core id : 0 processor : 10 physical id : 0 core id : 1 processor : 11 physical id : 1 core id : 1 processor : 12 physical id : 0 core id : 9 processor : 13 physical id : 1 core id : 9 processor : 14 physical id : 0 core id : 10 processor : 15 physical id : 1 core id : 10
April 3, 20179 yr I don't understand this output, there are multiple duplicates for physical id's and core id's?
April 3, 20179 yr Author Logical core processor : 0 physical id : 0 core id : 0 and hyperthread processor : 8 physical id : 0 core id : 0
April 4, 20179 yr Author Since creating a swapfile I haven't had another crash, so I've bought 32GB or RDIMM ECC which should solve the issue. Edited April 4, 20179 yr by Spies
Archived
This topic is now archived and is closed to further replies.