• Blue Ocean 1.3, Blue Ocean 1.4 - beta 1, Blue Ocean 1.4 - beta 2

      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.

          [JENKINS-41558] Memory leak in Jenkins stage view

          Cliff Meyers added a comment -

          Just putting this back to "Open" for now as I have a couple of other tickets w/ higher priority to fix first.

          Cliff Meyers added a comment - Just putting this back to "Open" for now as I have a couple of other tickets w/ higher priority to fix first.

          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

          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

          any update about this? happens to me as well.

          Jenkins 2.176.2

          Tidhar Klein Orbach added a comment - any update about this? happens to me as well. Jenkins 2.176.2

          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.

          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.

          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?

          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?

          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.

          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.

          Syed Imran added a comment -

          +1

          Syed Imran added a comment - +1

          Mark Syms added a comment -

          I don't believe there is much correlation to Windows browsers. Plenty of my colleagues have this issue with Linux based browsers, Chrome and Firefox. Leave a pipeline view up in a browser tab and it grows at a phenomenal rate (hundreds of KB per second).

          Mark Syms added a comment - I don't believe there is much correlation to Windows browsers. Plenty of my colleagues have this issue with Linux based browsers, Chrome and Firefox. Leave a pipeline view up in a browser tab and it grows at a phenomenal rate (hundreds of KB per second).

          Sergey Dedik added a comment -

          I would also like to bring developers attention to this, as we are suffering heavily from the issue.

          Sergey Dedik added a comment - I would also like to bring developers attention to this, as we are suffering heavily from the issue.

          alex cuenca added a comment -

          Reproduced on Ubuntu/Firefox

          I close Jenkins tab and retrieve 7 GB

           

          $:~/bulk-data/projects/workspace/all/loaders$ free -h
          
                        total        used        free      shared  buff/cache   available
          
          Mem:           15Gi        14Gi       241Mi       207Mi       751Mi       459Mi
          
          Swap:         4.0Gi       3.2Gi       860Mi
          
          ~/bulk-data/projects/workspace/all/loaders$ free -h
          
                        total        used        free      shared  buff/cache   available
          
          Mem:           15Gi       7.7Gi       7.3Gi       245Mi       628Mi       7.4Gi
          
          Swap:         4.0Gi       3.3Gi       709Mi
          
          ~/bulk-data/projects/workspace/all/loaders$ 
          
          
          
          ing_ is done here

           

          alex cuenca added a comment - Reproduced on Ubuntu/Firefox I close Jenkins tab and retrieve 7 GB   $:~/bulk-data/projects/workspace/all/loaders$ free -h              total        used        free      shared  buff/cache   available Mem:           15Gi        14Gi       241Mi       207Mi       751Mi       459Mi Swap:         4.0Gi       3.2Gi       860Mi ~/bulk-data/projects/workspace/all/loaders$ free -h              total        used        free      shared  buff/cache   available Mem:           15Gi       7.7Gi       7.3Gi       245Mi       628Mi       7.4Gi Swap:         4.0Gi       3.3Gi       709Mi ~/bulk-data/projects/workspace/all/loaders$ ing_ is done here  

            Unassigned Unassigned
            rbjorklin Robin Björklin
            Votes:
            40 Vote for this issue
            Watchers:
            52 Start watching this issue

              Created:
              Updated: