Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-41558

Memory leak in Jenkins stage view

    Details

    • Similar Issues:
    • Sprint:
      Blue Ocean 1.3, Blue Ocean 1.4 - beta 1, Blue Ocean 1.4 - beta 2

      Description

      Leaving a tab open with the stage view plugin active leaks memory with about 200MB every 10 minutes. Closing the tab and forcing a GC under 'about:memory' seems to recover the memory.

        Attachments

          Issue Links

            Activity

            Hide
            pwhoriskey Phillip Whoriskey added a comment -

            Just adding a data point in case it helps: 

             

            On linux/Firefox, I can see a running build page grow from ~40Mb to over 2Gb over the course of an hour or so.  the majority of that space, ~1.6Gb is listed under dom/orphan-nodes.  

            Jenkins 2.190.1

            Firefox 60.9.0esr

            Show
            pwhoriskey Phillip Whoriskey added a comment - Just adding a data point in case it helps:    On linux/Firefox, I can see a running build page grow from ~40Mb to over 2Gb over the course of an hour or so.  the majority of that space, ~1.6Gb is listed under dom/orphan-nodes.   Jenkins 2.190.1 Firefox 60.9.0esr
            Hide
            tizkiko Tizki KO added a comment -

            any update about this? happens to me as well.

            Jenkins 2.176.2

            Show
            tizkiko Tizki KO added a comment - any update about this? happens to me as well. Jenkins 2.176.2
            Hide
            dnusbaum Devin Nusbaum added a comment -

            Here are some notes from when a few developers looked into this a few months back:

            Whenever Stage View receives an event, it re-renders the entire table. When that happens, all of the DOM nodes from the last render pass should become unreachable and be garbage collected, but right now, that does not happen, because there are a bunch of references to those nodes from the page-wide instance of JQuery (definitely via event listeners, but also via other JQuery-internal paths which we did not fully understand), so the old nodes are retained forever, causing the memory leak.

            We did not see an obvious or easy way to fix this, but we are not JavaScript experts, so maybe someone with more experience in the area would be able to quickly figure out how to fix it. Maybe we need to modify all event listener registration so that the listeners are stored at the top level and can be cleared out when an event is received before re-rendering the table, maybe the version of JQuery being used needs to be updated, maybe both, etc.

            Show
            dnusbaum Devin Nusbaum added a comment - Here are some notes from when a few developers looked into this a few months back: Whenever Stage View receives an event, it re-renders the entire table. When that happens, all of the DOM nodes from the last render pass should become unreachable and be garbage collected, but right now, that does not happen, because there are a bunch of references to those nodes from the page-wide instance of JQuery (definitely via event listeners, but also via other JQuery-internal paths which we did not fully understand), so the old nodes are retained forever, causing the memory leak. We did not see an obvious or easy way to fix this, but we are not JavaScript experts, so maybe someone with more experience in the area would be able to quickly figure out how to fix it. Maybe we need to modify all event listener registration so that the listeners are stored at the top level and can be cleared out when an event is received before re-rendering the table, maybe the version of JQuery being used needs to be updated, maybe both, etc.
            Hide
            florianhoffmann Florian Hoffmann added a comment -

            We are being affected by this more and more. In fact we are seeing notebook batteries being sucked dry in 45 minutes because of this. 

            Our stages view spins out of control really quickly, aggregating up to 11 GB RAM in about 20 minutes. The UI also constantly consumes 10-15% of CPU time, which sounds overly high for that tiny bit of visualization; we assume it's related to the browser trying to manage the large amounts of memory.

            BlueOcean, in comparison, remains stable.

            We have confirmed this issue on all common Windows browsers, Firefox, IE, Edge, and Chrome, so added these to the issue's header.

            From the reports above, I deduce that there is nobody actively working on this. And the issue is now > 3 years old, which is quite a shame... Can we help somehow?

            Show
            florianhoffmann Florian Hoffmann added a comment - We are being affected by this more and more. In fact we are seeing notebook batteries being sucked dry in 45 minutes because of this.  Our stages view spins out of control really quickly, aggregating up to 11 GB RAM in about 20 minutes. The UI also constantly consumes 10-15% of CPU time, which sounds overly high for that tiny bit of visualization; we assume it's related to the browser trying to manage the large amounts of memory. BlueOcean, in comparison, remains stable. We have confirmed this issue on all common Windows browsers, Firefox, IE, Edge, and Chrome, so added these to the issue's header. From the reports above, I deduce that there is nobody actively working on this. And the issue is now > 3 years old, which is quite a shame... Can we help somehow?
            Hide
            kshultz Karl Shultz added a comment -

            That's interesting that it's so prevalent on Windows browsers. I think many of us have been able to recreate the problem elsewhere, but your description above sounds more severe than what I've experienced myself.

            From the reports above, I deduce that there is nobody actively working on this. And the issue is now > 3 years old, which is quite a shame... Can we help somehow?

            Yes! Yes please. If someone in the community has the willingness to try and tackle this problem, we'll make sure the PR gets reviewed thoughtfully and quickly.There are a lot of potentially useful notes in the previous comments in this ticket.

            Show
            kshultz Karl Shultz added a comment - That's interesting that it's so prevalent on Windows browsers. I think many of us have been able to recreate the problem elsewhere, but your description above sounds more severe than what I've experienced myself. From the reports above, I deduce that there is nobody actively working on this. And the issue is now > 3 years old, which is quite a shame... Can we help somehow? Yes! Yes please. If someone in the community has the willingness to try and tackle this problem, we'll make sure the PR gets reviewed thoughtfully and quickly.There are a lot of potentially useful notes in the previous comments in this ticket.

              People

              • Assignee:
                Unassigned
                Reporter:
                rbjorklin Robin Björklin
              • Votes:
                36 Vote for this issue
                Watchers:
                47 Start watching this issue

                Dates

                • Created:
                  Updated: