Guten Tag Dennis Peterson, am Donnerstag, 28. Dezember 2017 um 20:25 schrieben Sie:
> If I were debugging this I'd want to know if all the vm's run on the same or > different hosts, Different hosts, while the both host are absolutely identical: Same Ubuntu 16.04 LTS Server with same patchlevel, same Xeon X5675 CPUs, same 144 GBs of RAM, same HDDs and amount of storage, same file systems with BTRFS and ZFS, same version of VirtualBox etc. > what the allocation of resources to each vm is, That's the main difference, the VM where I have the problems has 48 GB of RAM and currently 10 assigned vCPUs, formerly 6. The VMs where this is not happening have only 2 vCPUs and 6 or 8 GB of RAM, where only 2-4 GB are in use by apps and else is cache. The problematic VM has ~10 GB in use by apps and everything else for caches and buffers. Therefore I suspected scanning of RAM, especially as the problem doesn't seem to happen directly after restarts of the VM where caches etc. are empty. > if different > hosts then what each host's base loads are for cpu, memory, and disk caching. The load on both hosts is less than 1 in htop and 1-2% in top most of the times. The host were the problem doesn't happen has a slighter higher load in the middle and even more processes and threads, 73/215 vs. 69/160, simply because it hosts more VMs. ~50% of the memory on both hosts is consumed by ZFS ARC, but both hosts have plenty of free RAM available, the one with the problematic VM still ~15 GB, the other even 30. So I'm pretty sure it's not about exhausting resources on the host. > Then I'd compare the output of > sysctl -a on each vm to see if something jumps out. There are few kernel and file system related differences in the VMs I will have a more detailled look at. The hosts seem absolutely identical, the only difference is runtime data of the the kernel, stuff like "max_newidle_lb_cost", "perf_event_max_sample_rate", "ns_last_pid" and "random.*". > Check sar reports, lsof, and > other tools to check ram usage and disk iowaits, and how much free memory is > available for caching. The only thing that really jumps out is the number of context switches in the host and how long this happens. On the working host those climb from ~6'500 to 10-15'000 for very few seconds, while on the "non-working" host those climb from ~5'000 to 50'000 for a much longer period of time. While in all cases the VMs itself don't have many context switches themselfs. So I'm not ruling out problems with the VMs/virtualization itself as well, but didn't find anything obvious yet. https://forums.virtualbox.org/viewtopic.php?f=7&t=86041 Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...........05151- 9468- 55 Fax...............05151- 9468- 88 Mobil..............0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow _______________________________________________ clamav-users mailing list clamav-users@lists.clamav.net http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
