You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The MemoryLock in locker.go is implemented so that allocated mutexes won't be collected by GC because it holds pointers to them even when it is not needed.
To be accurate:
It allocates new mutex for every idempotency key (and removes nowhere)
It might seem be okay until some calculations are made:
Imagine we have a server handling 1000 rps with idempotency keys. Every mutex holds 8 bytes.
So in 1 month of continuous work it will be 8 * 1000 * 60 * 60 * 24 * 30 = 20736000000 B = 19.312 GB
I propose key removal from map to allow GC collect unused Mutex. (Associated PR is created)
Thanks for opening your first issue here! 🎉 Be sure to follow the issue template! If you need help or want to chat with us, join us on Discord https://gofiber.io/discord
gaby
changed the title
📝 [Proposal]: Memory leak removal in the idempotency middleware
🐛 [Bug]: Memory leak removal in the idempotency middleware
Dec 25, 2024
Feature Proposal Description
The MemoryLock in locker.go is implemented so that allocated mutexes won't be collected by GC because it holds pointers to them even when it is not needed.
To be accurate:
It allocates new mutex for every idempotency key (and removes nowhere)
It might seem be okay until some calculations are made:
Imagine we have a server handling 1000 rps with idempotency keys. Every mutex holds 8 bytes.
So in 1 month of continuous work it will be 8 * 1000 * 60 * 60 * 24 * 30 = 20736000000 B = 19.312 GB
I propose key removal from map to allow GC collect unused Mutex. (Associated PR is created)
Alignment with Express API
N/A
HTTP RFC Standards Compliance
N/A
API Stability
N/A
Feature Examples
Checklist:
The text was updated successfully, but these errors were encountered: