XCP-ng
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    Alert: Control Domain Memory Usage

    Scheduled Pinned Locked Moved Solved Compute
    194 Posts 21 Posters 201.3k Views 16 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • G Offline
      garyabrahams
      last edited by

      The boxes that I have do not have dynamic memory (never used it), and we are getting the issue.

      Some feedback on my test box running 8.0 alternative kernel. Been running it for a week and getting this.

      04be28e3-1c89-4e8b-8c02-754a3909759a-image.png

      As you can see there was a increase in memory of the first few days, but then it seemed to level off. I'll continue to do some tests, then I'm intending to upgrade to 8.2 and see if I can replicate (both with the standard and alternative kernels).

      I'll provide feedback once I have it.

      Gary

      1 Reply Last reply Reply Quote 0
      • G Offline
        garyabrahams
        last edited by

        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 -n
        

        Not sure why I have 6337 processes for CROND and sadc, but going to do some investigations

        stormiS 1 Reply Last reply Reply Quote 0
        • daveD Offline
          dave
          last edited by

          [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
          1
          
          

          BTW: All my affected pools never had dynamic memory.

          1 Reply Last reply Reply Quote 0
          • stormiS Offline
            stormi Vates 🪐 XCP-ng Team @garyabrahams
            last edited by stormi

            @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.

            1 Reply Last reply Reply Quote 0
            • F Offline
              fasterfourier @fasterfourier
              last edited by

              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.

              1 Reply Last reply Reply Quote 0
              • G Offline
                garyabrahams
                last edited by

                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 time

                Below the first increase is 8.0 alt kernel, 2nd increase was 8.2 standard and 3rd 8.2 alt kernel.

                f93cf91b-910b-47b8-a1d4-0883b7f9a20a-image.png

                1 Reply Last reply Reply Quote 0
                • olivierlambertO Offline
                  olivierlambert Vates 🪐 Co-Founder CEO
                  last edited by

                  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?

                  1 Reply Last reply Reply Quote 0
                  • O Offline
                    OlivierD
                    last edited by

                    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.

                    1 Reply Last reply Reply Quote 2
                    • olivierlambertO Offline
                      olivierlambert Vates 🪐 Co-Founder CEO
                      last edited by olivierlambert

                      Yes, please, keep us posted 🙂

                      Thank for your feedback!

                      1 Reply Last reply Reply Quote 0
                      • F Offline
                        fasterfourier
                        last edited by

                        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.

                        1 Reply Last reply Reply Quote 1
                        • stormiS Offline
                          stormi Vates 🪐 XCP-ng Team @stormi
                          last edited by

                          @stormi said in Alert: Control Domain Memory Usage:

                          Before I realized that not every affected host was using the ixgbe driver, 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
                          reboot
                          

                          Has anyone tested the updated ixgbe driver?

                          daveD 1 Reply Last reply Reply Quote 2
                          • daveD Offline
                            dave @stormi
                            last edited by

                            @stormi

                            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

                            c53f2add-8bbe-4203-bba8-97e94b466c56-image.png

                            Stromis Driver:

                            57bf6a63-eff5-47ca-a155-b918c12b95b2-image.png

                            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.

                            1 Reply Last reply Reply Quote 1
                            • olivierlambertO Offline
                              olivierlambert Vates 🪐 Co-Founder CEO
                              last edited by

                              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!

                              1 Reply Last reply Reply Quote 0
                              • olivierlambertO Offline
                                olivierlambert Vates 🪐 Co-Founder CEO
                                last edited by

                                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 🙂

                                1 Reply Last reply Reply Quote 2
                                • M Offline
                                  MrMike
                                  last edited by

                                  Good job guys!

                                  1 Reply Last reply Reply Quote 0
                                  • olivierlambertO Offline
                                    olivierlambert Vates 🪐 Co-Founder CEO
                                    last edited by

                                    A big thanks for the link that @andyhhp provided to confirm the problem 🙂

                                    delafD D 2 Replies Last reply Reply Quote 1
                                    • delafD Offline
                                      delaf @olivierlambert
                                      last edited by

                                      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!

                                      1 Reply Last reply Reply Quote 0
                                      • D Offline
                                        daKju @olivierlambert
                                        last edited by

                                        @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 👍 😊

                                        1 Reply Last reply Reply Quote 0
                                        • stormiS Offline
                                          stormi Vates 🪐 XCP-ng Team
                                          last edited by

                                          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.

                                          delafD 1 Reply Last reply Reply Quote 0
                                          • delafD Offline
                                            delaf @stormi
                                            last edited by delaf

                                            @stormi
                                            Screenshot 2021-03-04 at 21.21.16.png
                                            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.

                                            J 1 Reply Last reply Reply Quote 1
                                            • First post
                                              Last post