"Memory Leak" Problem from hestiaHUGO

[hollowaykeanho]

Description

Please provide a short description of what feature you're looking forward to
enhance below. Please include the story behind your idea as well to give a
better visualization of your idea.

Follow up with Bep and his latest release about Go's LRU optimization. It has the ability to garbage collect at will to reduce the memory consumption down effectively.

Discussion: https://discourse.gohugo.io/t/how-to-instruct-hugo-pipe-not-to-cache/44467/3

UPDATE:

It was detected that some part of the contents in hestiaHUGO is holding up the memory but inaccessible, behaving like a "memory leak".

Expected Behavior

Please specify the expected behavior of your requested enhancement. Some great
and helpful pointers are your expected interface (e.g. command patterns,
simple sketches of the user interface, etc).

Lower memory consumption usage.

Current Behavior

Please specify the current behavior (e.g. workaround, blockage, etc).

Hugo + Blink Engine Brower + Gecko Engine Browser can really saturate the RAM easily when used simultenously for building the page contents.

Using ZORALab's Hestia 1.2.0 with the following stat:

Start building sites … 
hugo v0.111.3-5d4eb5154e1fed125ca8e9b5a0315c4180dab192 linux/amd64 BuildDate=2023-03-12T11:40:50Z VendorInfo=gohugoio

                   | EN   
-------------------+------
  Pages            |   6  
  Paginator pages  |   0  
  Non-page files   |  97  
  Static files     | 574  
  Processed images |  27  
  Aliases          |   0  
  Sitemaps         |   0  
  Cleaned          |   0  

Built in 6503 ms
Watching for changes in /home/u0/Documents/zoralab/Hestia/{hestiaHUGO,sites}
Watching for config changes in /home/u0/Documents/zoralab/Hestia/sites/config/_default, /home/u0/Documents/zoralab/Hestia/sites/config/development, /home/u0/Documents/zoralab/Hestia/hestiaHUGO/config/_default, /home/u0/Documents/zoralab/Hestia/hestiaHUGO/config/development
Environment: "development"
Serving pages from memory
Web Server is available at http://localhost:8080/ (bind address 127.0.0.1)
Press Ctrl+C to stop

Memory consumption is at: (about 240MB, 2% of 12GB RAM)

Attachment

Please drag and drop the necessary data files (e.g. screenshot, logs, etc)
below.

[hollowaykeanho]

Pending Hugo release of feature.

[hollowaykeanho]

Attempted 7811dcd first patch to observe for same pattern.

[hollowaykeanho]

Attempted 0ac8d8a second patch to observe for same pattern. Automation and cached .Contributors data are completely removed.

[hollowaykeanho]

Shown positive sign. Memory caching capability positively have to be removed. Can't use Hugo's .Store feature.

[hollowaykeanho]

Memory did return back to its initial position rather than holding up similar to memory leak. Observe more once the remaining spec documentations are ported safely without needing more patches.

[hollowaykeanho]

When refactoring at rapid speed, Hugo tends to occupy so much memory (upto 50% of 12GB) per its rendering and it looks like the garbage collection is very slow. We need a way to profile the memory hold up.

[hollowaykeanho]

Applying 3rd attempt here 5440022. Hugo server have to be killed periodically in order to keep the memory consumption at the sane level.

[corygalyna]

Finally, some release quality. How did the Hugo central team respond?

[hollowaykeanho]

Haven't contact them yet... I want to root out everything before contacting them.

[hollowaykeanho]

Issue raised in https://discourse.gohugo.io/t/memory-profiling-in-hugo-server/44728

[hollowaykeanho]

Tracking: gohugoio/hugo#11262

[ytrepidorosonomous]

Tracking: gohugoio/hugo#11262

That was merged and closed.

[corygalyna]

Thanks @flexxgaad for informing but we're likely going to pivot from Hugo soon.

No, it's not because of Hugo but rather we had go beyond with our clients and is in need of going into Go Programming Language itself.