VS is Consistently Taking Up Massive Memory



  • Since I upgraded to Build 28, I've been seeing frequent situations where my application memory used by VS is incredibly high. I'm not sure what's causing it as I'm working on one or two VS files at a time and not doing anything different than other times I've used VS prior. This was also occurring yesterday as I worked. The second screenshot was after i quit VS and started working again. It was climbing back up consistently

    0_1718124696973_0a14ec1f-721a-49bf-890b-35c19da5a953-BLD 2024-06-11 at 12.36.10.png

    0_1718124723002_9d3ff10c-2fff-4af0-b7f8-83f8c317d986-BLD 2024-06-11 at 12.50.49.png

    0_1718125332581_eef5b8ed-b8a8-47bb-abca-2c7dfe148f80-BLD 2024-06-11 at 13.01.46.png


  • administrators

    @Boldline How long was VS running when reached this memory.

    I will try to replicate this, but it might be task dependent.



  • It starts to build almost immediately after I open a fresh VS and start working. I did not check to see if it's related to a brand new file or only for files that are existing prior to the new VS session. I will test that next.

    With an existing file, it took 15 minutes for it to climb up to 5GB of RAM. Sometimes it would hold steady or decline slightly, but then it would methodically keep climbing. By the time I've been working for an hour or two, it's at 75-80BG and the force-quit warning panel appears


  • administrators

    @Boldline said in VS is Consistently Taking Up Massive Memory:

    it took 15 minutes for it to climb up to 5GB of RAM

    I have to replicate this, can you send me a file and some steps to get this memory use.
    It might be a bug or a regression introduced recently.



  • It may or may not be related to @Boldline's issue, but I had a blacking out of the application canvas (like video failure/Black Screen of Death-ish). I didn't know the cause at the time but I noted later in Event Viewer a few of these kinds of entries for each of those events when the canvas blacked out.

    0_1718148551138_1db0a7ee-14be-479c-9245-387fb4ffaa92-image.png

    "Windows successfully diagnosed a low virtual memory condition. The following programs consumed the most virtual memory: VectorStyler.exe (33228) consumed 63186677760 bytes, sihost.exe (4648) consumed 2389098496 bytes, and obs64.exe (4276) consumed 1856397312 bytes."

    63186677760 bytes = 63.18GB

    Note: RAM was not full:
    0_1718148560853_72a32809-5a68-4d54-b38b-b78b283419a5-image.png

    MemoryExhaustionInfo

    • SystemInfo
      SystemCommitLimit 96692113408
      SystemCommitCharge 96424468480
      ProcessCommitCharge 85513814016
      PagedPoolUsage 1338548224
      PhysicalMemorySize 34263310336
      PhysicalMemoryUsage 17896673280
      NonPagedPoolUsage 1621086208
      Processes 328

  • administrators

    @debraspicher I might have identified the issue in VS from @Boldline , but that was MacOS related.
    This looks different, how long was VS used when reached this state?



  • @VectorStyler said in VS is Consistently Taking Up Massive Memory:

    I might have identified the issue in VS from @Boldline

    I emailed you the file. I also recorded 13 minutes or so of my process and this time it only got up to 5.88GB when I stopped to prep the video and file, etc. It's been holding steady at 5.88Gb, but I also have not been doing any activity on the open file. I was trying to keep the size down since it's so large a video file already, but I ended up overdoing the compression and made it fuzzy to view. I will continue to work on it and can make a new video , time lapse this time, if that should be more useful to you.

    You mentioned you may have solved the problem! I hope that is the case - if not I am happy to contribute more info as needed to help solve it