STAR TREK 2d20
Page 4 of 8 First ... 23456 ... Last

Thread: FGU Memory Leak

  1. #31
    Quote Originally Posted by Weissrolf View Post
    What makes your FGU use so much RAM? Is this specific to the Mac OS version of FGU or something about your campaign/extensions?

    Your session start at close to 40 GB virtual memory on top of those 5 GB. My (Windows) sessions starts at 15 GB virtual memory on top of 1.6 GB physical, which I already consider too much to begin with.
    Interesting. Not sure. I have a bunch of modules loaded and images shared. But I don’t understand why that would cause so much RAM usage. Unless the image is open or a client is requesting it, why should it? Are all modules loaded into RAM too? Even so, it shouldn’t be causing a leak.

  2. #32
    Images inside modules are not loaded to memory until you open them for the first time, albeit loading (and unloading?) a module already eats some memory even with nothing but a single image inside. I created a test module with a single 19200 x 25200 px JPEG file, compressed JPG size 471 mb, uncompressed RGB size 1384 mb.

    Empty PF2E campaign (no modules loaded):

    Image module loaded:

    Image opened:

    Image closed:

    One minute later:

    Five+ minutes later:

    Module unloaded:

    Return to Launcher:

    No further comment, else this thread gets locked like so many before.
    Last edited by Weissrolf; December 9th, 2021 at 15:14.

  3. #33
    Quote Originally Posted by Weissrolf View Post
    Images inside modules are not loaded to memory until you open them for the first time, even though loading a module already eat memory even with nothing in it but a single image. I created a test module with a single 19200 x 25200 px JPEG file, compressed JPG size 471 mb, uncompressed RGB size 1384 mb.

    Empty PF2E campaign (no modules loaded):

    Image module loaded:

    Image opened:

    Image closed:

    One minute later:

    Five+ minutes later:

    Module unloaded:

    Return to Launcher:

    No further comment, else this thread gets locked like so many before.
    Very interesting. Is that… 8 Gigabytes of ram usage… after opening the image??

    It would be a clue then as to why I used so much RAM last session but didn’t lag as much as before. I only alternated between 2 maps. I usually do 4 or 5 (if the party is traveling or have random encounters.)

    The fact that the RAM is not free’d after the image is closed, to me, indicates that is the culprit. Hard to say, but I have a sneaking suspicion there’s at least one leak or issue with regards to images and how that memory is managed.

    Edit: And if you look at my leaks files, the first one, it mentions a lot about what seems to be display related drivers. And of course, images.

  4. #34
    Quote Originally Posted by Weissrolf View Post
    Images inside modules are not loaded to memory until you open them for the first time, albeit loading (and unloading?) a module already eats some memory even with nothing in it but a single image. I created a test module with a single 19200 x 25200 px JPEG file, compressed JPG size 471 mb, uncompressed RGB size 1384 mb.

    Empty PF2E campaign (no modules loaded):

    Image module loaded:

    Image opened:

    Image closed:

    One minute later:

    Five+ minutes later:

    Module unloaded:

    Return to Launcher:

    No further comment, else this thread gets locked like so many before.
    Can you attach the module? I wanna run the same steps myself on my PC and my Mac.

  5. #35
    Quote Originally Posted by seansps View Post
    Very interesting. Is that… 8 Gigabytes of ram usage… after opening the image??
    Indeed.

    The fact that the RAM is not free’d after the image is closed, to me, indicates that is the culprit. Hard to say, but I have a sneaking suspicion there’s at least one leak or issue with regards to images and how that memory is managed.
    It makes sense to not remove every image from memory the moment its window is closed, else they would have to be reloaded every time (takes a lot of time to load this large image). I mean to remember that once I saw memory being unallocated after a few minutes, but in this test 5+ minutes obviously were not enough.

    Unloading the whole module also does not release the image from memory. I can re-load the module after some minutes again and open the image and it is still displayed immediately from memory, instead of loaded from disk.

    There also is the problem of (every 5 minute) Autosave messing with FGU's memory management (and maybe other things) when saving happens while FGU is busy doing other stuff. So this may play into this on top of already high usage.

    Memory not being freed up when FGU is returned to its Launcher is another red flag. Everything about this is known for quite some time, but these reports are not understood as pointing to a general issue, but always only connected to single (test) usage cases. So don't get your hopes up too much.
    Last edited by Weissrolf; December 9th, 2021 at 15:43.

  6. #36
    Quote Originally Posted by Lo Zeno View Post
    Can you attach the module? I wanna run the same steps myself on my PC and my Mac.
    https://1drv.ms/u/s!AsEwNk439-yxi6Fd...0P0oQ?e=gsPxRb

    Link active until 18-12-2021.

  7. #37
    I waited some more minutes after unloading the module and did other stuff at the computer. FGU's memory load decreased from 8 GB to 6 GB. Re-loading the module and image then had the image being loaded from disk again with FGU's memory increasing back to 8 GB. So the image was removed from memory at some point, but FGU kept the memory allocated. Once the image was re-loaded FGU did not allocate new memory, but reuse the already allocated memory.

    This is similar to what I remember to have reported quite some time ago in some other thread. The wildcard here likely is Autosave, because from other tests I know that it can mess with FGU's memory management.

  8. #38
    Loading the same image in...

    Irfanview:

    Photoshop:

    Anyway, that was more than I intended to post. You will have to handle this on a single case basis with Smiteworks, they don't believe in bigger pictures solutions when it comes to FGU performance.

  9. #39
    Quote Originally Posted by Weissrolf View Post
    Downloaded, thx

  10. #40
    @seansps It might be better to share your campaign or e-mail to SW if you've got 4.9 GB RAM usage at the start of the session, that seems unnatural.

    More of a real life example instead of some theoretical bingo:

    Dev Campaign opened, DB size: 4.08 MB, 75 images, 43 MB all images in sum, all jpeg
    ~600 MB RAM usage at the start
    ~1350 MB RAM usage after opening and closing all 75 images
    ~ 850 MB RAM usage after ~5min

    In over 2 years of playing I haven't gotten over 2 GB RAM usage even after 5-6 hours. A look into the specific campaigns is necessary... otherwise we're running circles.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
DICE PACKS BUNDLE

Log in

Log in