Alert: Control Domain Memory Usage
-
I have another production box that has this issue.. and noticed this
[10:41 host ~]# free -m total used free shared buff/cache available Mem: 7913 6445 77 210 1390 284 Swap: 1023 41 982 [10:41 host ~]# ps -ef | grep sadc | wc -l 6337 [10:41 host ~]# ps -ef | grep CROND | wc -l 6337 [10:41 host ~]# ps -ef | grep 32766 root 306 32766 0 Jan31 ? 00:00:00 /usr/lib64/sa/sadc -F -L -S DISK 1 1 - root 32766 2898 0 Jan31 ? 00:00:00 /usr/sbin/CROND -nNot sure why I have 6337 processes for CROND and sadc, but going to do some investigations
-
[10:36 xs03 ~]# free -m total used free shared buff/cache available Mem: 11921 11322 171 151 427 175 Swap: 1023 37 986 [10:36 xs03 ~]# ps -ef | grep CROND | wc -l 1BTW: All my affected pools never had dynamic memory.
-
@garyabrahams I think this is a separate issue that would deserve a separate thread, though it's interesting to have mentioned it here just in case someone else would have noticed something similar (I don't remember anyone mentioning such proliferation of processes in this thread).
Now, maybe that host also is affected by the memory leak, but for now nothing allows to think both issues are related. Or maybe the lack of free memory is what caused the processes to never quit.
-
Update: we have disabled dynamic memory on all VMs in our pool and the issue is still occurring.I expect this to be sent to the citrix developers shortly, since the normal support team has exhausted their troubleshooting options.
-
An update from my side.
I have tried 8.0 alt kernel, 8.2 standard kernel and 8.2 alt kernel and in each case the memory usage increased over timeBelow the first increase is 8.0 alt kernel, 2nd increase was 8.2 standard and 3rd 8.2 alt kernel.
-
I don't think there's enough time to really be sure about the memory leak. It's normal to see raising RAM usage, what's not is to consume all the dom0. Can you wait a bit longer between 2 tests?
-
Hello,
I can confirm we encountered this issue on several hosts in the past few months.Config :
- Server is Dell PowerEdge M630
- local storage on SSD + remote SR on ISCSI
- kernel used: kernel-4.19.19-6.0.11.1.xcpng8.1.x86_64
- we use ixgbe (intel-ixgbe-5.5.2-2.xcpng8.1.x86_64) and network cards are Intel 82599 10 Gigabit dual Port (with bonding on XCP NG).
- firmwares up to date (less than 6 months, when we updated to XCP-NG 8.1+).
Additional informations :
- we don't have any VM with memory ballooning
- shutting down VMs does not free memory
- we don't do many operations each day (less than 5 reboots/stop/start).
- size of pools does not matter (bug happened with two hosts and on another pool with 10 hosts).
According to some messages, it seems kernel-alt fixes the issue ... We'll try to switch kernel when we encounter the issue again.
-
Yes, please, keep us posted
Thank for your feedback!
-
One more observation here. This issue does not occur on a different pool of ours that's also running CH8.2LTSR. That pool has lower loading overall, 2 hosts instead of 7, and does not contain any NICs using the ixgbe driver. Other aspects of the pool are identical.
-
@stormi said in Alert: Control Domain Memory Usage:
Before I realized that not every affected host was using the
ixgbedriver, contrarily to what I initially thought, I built an alternate driver from the latest sources from Intel.So, even if there's little hope that it will fix anything, here's how to install it (on XCP-ng 8.1 or 8.2):
yum install intel-ixgbe-alt --enablerepo=xcp-ng-testing rebootHas anyone tested the updated ixgbe driver?
-
I upgraded a pool which was affected from 8.1 to 8.2 this weekend and installed the driver on one of the Hosts. Its a little early, but as you can see, there seems to be a difference in the memory usage:
Stock Driver
Stromis Driver:
One can allready see a constanty, slowly growing mem-usage in "small steps" on the Server with the stock driver, wheras the server with stormis driver seems to be stable.
-
Indeed, sounds better in any case! Thanks a lot @dave for the feedback.
For everyone else with the issue: please try the same and report. Maybe we found the culprit!
-
That's really likely the problem all along.
See https://sourceforge.net/p/e1000/bugs/633/#af80/154d
So our alt driver is indeed fixing it
-
Good job guys!
-
A big thanks for the link that @andyhhp provided to confirm the problem
-
I have installed intel-ixgbe-alt-5.9.4-1.xcpng8.1.x86_64 on my server (268).
I'll check in some days if I still have the problem or not.Thank you guys!
-
@olivierlambert is there a plan to deploy the alt-driver over the xcp-ng update or should we installed by the xcp-ng-testing repo?
THX for the good job guys
-
I'm going to build a driver package that only has the patch that is thought to fix the memory issue and let everyone here test it. If the results are good, then it will become an official update.
-
@stormi
The 2 servers have been reinstalled with an up to date 8.2. They host each 2 VMs that are doing the same thing (~100Mb/s of netdata stream).The right one has the 5.9.4-1.xcpng8.2, the left one has 5.5.2-2.xcpng8.2.
The patch seem to be OK for me.
-
Announcement
Here's an updated
ixgbedriver package that is meant as an update candidate without updating to a higher version. If need all feedback we can get on this one, because this is the candidate for the official fix as would be delivered to everyone. Of course theintel-igb-altwill remain available for those who need a more recent driver, and I even moved it to theupdatesrepository so that one doesn't need to add--enablerepo=xcp-ng-testingto install it anymore.To test the official update candidate on XCP-ng 8.1 or 8.2.
- If you had previously installed
intel-ixgbe-alt:yum remove intel-ixgbe-alt -y- Check that the
/lib/modules/4.19.0+1/override/ixgbe.kofile was properly deleted. I've seen, once, a situation where a .ko file from an-altpackage wasn't deleted, so I'm being cautious here and ask you to report you see that it is still present. In theory, this is impossible, but as I've seen it once I don't know anymore - Run
depmod -a
- Update the
intel-ixgbepackage from the testing repo:yum update intel-ixgbe --enablerepo=xcp-ng-testing - Reboot
Note: I'm not 100% sure that I picked the right patch, nor that this patch alone is sufficient.
- If you had previously installed
