Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🩹 Fix: Memory leak removal in the idempotency middleware #3263

Merged
merged 7 commits into from
Dec 28, 2024

Conversation

sunnyyssh
Copy link
Contributor

@sunnyyssh sunnyyssh commented Dec 25, 2024

Description

The MemoryLock in locker.go doesn't let GC collect unused mutexes.
I propose key removal from map to let GC collect unused Mutex.

Fixes #3262

Changes introduced

I replaced just sync.Mutex with

type countedLock struct {
    mu     sync.Mutex
    locked int
}

It will count the difference between Lock and Unlock and if it equals 0 then the key can be removed from keys map in the MemoryLock's own mutex lock scope.

type MemoryLock struct {
    keys map[string]*countedLock
    mu   sync.Mutex
}

So, now GC is happy to collect 😊

@sunnyyssh sunnyyssh requested a review from a team as a code owner December 25, 2024 10:41
@sunnyyssh sunnyyssh requested review from gaby, sixcolors, ReneWerner87 and efectn and removed request for a team December 25, 2024 10:41
Copy link

welcome bot commented Dec 25, 2024

Thanks for opening this pull request! 🎉 Please check out our contributing guidelines. If you need help or want to chat with us, join us on Discord https://gofiber.io/discord

Copy link
Contributor

coderabbitai bot commented Dec 25, 2024

Walkthrough

The changes modify the MemoryLock implementation in the idempotency middleware to address potential memory leaks. A new countedLock struct is introduced to track the number of active locks for each key. The implementation now dynamically manages mutex instances by removing them from the map when they are no longer in use, allowing the garbage collector to reclaim unused mutexes and prevent long-term memory accumulation.

Changes

File Change Summary
middleware/idempotency/locker.go - Added countedLock struct with mu and locked fields
- Updated MemoryLock to use map[string]*countedLock
- Modified Lock() and Unlock() methods to manage lock counting and cleanup
middleware/idempotency/locker_test.go - Added benchmark tests: Benchmark_MemoryLock and Benchmark_MemoryLock_Parallel to assess locking performance

Assessment against linked issues

Objective Addressed Explanation
Memory leak prevention [#3262]
Key removal to allow GC collection [#3262]

Poem

🐰 A mutex dance, a memory's grace,

Locks counted with a rabbit's embrace,

No more leaks, no memory strain,

Fiber's performance shall now reign!

Clean and swift, our code takes flight! 🚀

Tip

CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command @coderabbitai generate docstrings to have CodeRabbit automatically generate docstrings for your pull request. We would love to hear your feedback on Discord.


Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR. (Beta)
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (2)
middleware/idempotency/locker.go (2)

13-16: Consider using an atomic integer for locked to reinforce thread safety.

While this approach is acceptable under the current locking scheme, using an atomic integer (e.g., atomic.AddInt32) for locked might eliminate any risk of data races if the usage pattern changes in the future.


62-62: Optional: specify a default map capacity or document capacity assumptions.

When creating the map, consider passing an estimated capacity if usage patterns anticipate a high volume of concurrent keys. This micro-optimization may help reduce rehashing overhead. Otherwise, documenting approximate usage expectations could suffice.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 58677d5 and e9fef50.

📒 Files selected for processing (1)
  • middleware/idempotency/locker.go (1 hunks)
🔇 Additional comments (2)
middleware/idempotency/locker.go (2)

25-30: Initialization logic for countedLock looks correct.

The code correctly initializes a new countedLock as needed and increments its counter. This helps avoid memory leaks by ensuring that locks are properly created and tracked in the map.


47-55: Ensure concurrency remains consistent after map deletion.

Currently, the key is removed from the map (line 51) before unlocking the countedLock (line 55). If a new goroutine tries to lock the same key in the short interval between the delete call and lock.mu.Unlock(), it might create a new countedLock while the old one is still locked. This could be acceptable if ephemeral locks are desired. However, if strict synchronization is a requirement (e.g., not allowing reuse of a key until the prior lock is fully released), consider reversing the unlock and map deletion steps or clarifying this behavior in documentation.

@gaby
Copy link
Member

gaby commented Dec 25, 2024

@sunnyyssh Unit-tests are failing.

Copy link
Member

@gaby gaby left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesnt make sense?

Copy link

codecov bot commented Dec 25, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.35%. Comparing base (57744eb) to head (84ba8eb).
Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3263      +/-   ##
==========================================
- Coverage   84.40%   84.35%   -0.06%     
==========================================
  Files         116      116              
  Lines       11485    11497      +12     
==========================================
+ Hits         9694     9698       +4     
- Misses       1374     1380       +6     
- Partials      417      419       +2     
Flag Coverage Δ
unittests 84.35% <100.00%> (-0.06%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@sunnyyssh sunnyyssh force-pushed the memory-cleansing-idempotency branch from b8d263d to 4dd645b Compare December 25, 2024 16:32
@sunnyyssh
Copy link
Contributor Author

sunnyyssh commented Dec 25, 2024

Oh, but single decreased benchmark doesn't even depend on the changed code...
Actually, no code in the whole repository depends on idempotency package. So, this performance decrease cannot be caused by these commits.
image

@gaby
Copy link
Member

gaby commented Dec 25, 2024

@sunnyyssh Can you add a benchmark in locker_test.go

@sunnyyssh
Copy link
Contributor Author

sunnyyssh commented Dec 25, 2024

@sunnyyssh Can you add a benchmark in locker_test.go

The main idea is that one idempotency key wouldn't be used once again frequently just because the operation completes successfully in most cases. So, trying to benchmark the performance of "key-deleting" MemoryLock with frequently repeated keys, we will have not real-world results.

So, I tried to make benchmarks checking new and old implementations and got interesting result.

func Benchmark_MemoryLock(b *testing.B) {
	keys := make([]string, b.N)
	for i := range keys {
		keys[i] = strconv.Itoa(i)
	}

	lock := idempotency.NewMemoryLock()

	b.ResetTimer()

	for i := 0; i < b.N; i++ {
		key := keys[i]
		if err := lock.Lock(key); err != nil {
			b.Fatal(err)
		}
		if err := lock.Unlock(key); err != nil {
			b.Fatal(err)
		}
	}
}

Old implementation has shown extremely inefficient result

image

Trying to figure out why old implementation has so bad performance and memory allocations I used pprof and got this:
The line I point to
image

map is inefficient for storing big amounts of data because it always re-allocates its buckets when resizing.
So, it improves not only long-running memory allocation.

Also I've written parallel benchmarks that check unique keys and repeated 3 times keys. There is also big difference

image

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 3a5c54a and 98d7ae9.

📒 Files selected for processing (1)
  • middleware/idempotency/locker_test.go (2 hunks)
🧰 Additional context used
🪛 golangci-lint (1.62.2)
middleware/idempotency/locker_test.go

100-100: Error return value of lock.Lock is not checked

(errcheck)


101-101: Error return value of lock.Unlock is not checked

(errcheck)


114-114: Error return value of lock.Lock is not checked

(errcheck)


115-115: Error return value of lock.Unlock is not checked

(errcheck)

middleware/idempotency/locker_test.go Outdated Show resolved Hide resolved
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (3)
middleware/idempotency/locker_test.go (3)

65-84: Consider adding test cases with different key sizes.

The benchmark effectively tests the basic lock/unlock operations. To better understand memory behavior, consider adding test cases with varying key sizes to measure the impact on memory allocation and performance.

Example addition:

func Benchmark_MemoryLock_KeySizes(b *testing.B) {
    sizes := []int{8, 64, 512, 1024} // bytes
    for _, size := range sizes {
        b.Run(fmt.Sprintf("KeySize_%d", size), func(b *testing.B) {
            keys := make([]string, b.N)
            padding := strings.Repeat("x", size-8) // -8 for base number
            for i := range keys {
                keys[i] = fmt.Sprintf("%d%s", i, padding)
            }
            // ... rest of the benchmark
        })
    }
}

88-91: Consider making the key pool size configurable.

The hard-coded pool size of 1,000,000 keys might be excessive for some test environments. Consider making it configurable or scaling it based on b.N.

const defaultKeyPoolSize = 1_000_000

func getKeyPoolSize(b *testing.B) int {
    if b.N < defaultKeyPoolSize {
        return b.N
    }
    return defaultKeyPoolSize
}

115-116: Improve the comment clarity for the repeated keys logic.

The current comment could be clearer about how the division by 3 works.

-				// Division by 3 ensures that index will be repreated exactly 3 times
+				// We increment the counter by 1 each time but divide by 3,
+				// so each index will be used for 3 consecutive increments.
+				// Example: counter values 0,1,2 -> index 0, values 3,4,5 -> index 1
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d765331 and 84ba8eb.

📒 Files selected for processing (1)
  • middleware/idempotency/locker_test.go (2 hunks)
🔇 Additional comments (2)
middleware/idempotency/locker_test.go (2)

4-5: LGTM: Appropriate imports added for benchmarking.

The new imports support the benchmark functionality - strconv for key generation and sync/atomic for thread-safe operations.


86-127: Well-designed benchmarks for memory leak verification.

The parallel benchmarks effectively test the memory leak fix by:

  1. Testing unique keys to establish baseline performance
  2. Testing repeated keys to verify proper cleanup of unused locks
  3. Using parallel execution to ensure thread safety

The combination of these scenarios provides good coverage for verifying the memory leak fix.

@sunnyyssh sunnyyssh requested a review from gaby December 25, 2024 21:21
Copy link
Member

@gaby gaby left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 LGTM

@ReneWerner87 ReneWerner87 added this to the v3 milestone Dec 28, 2024
@ReneWerner87 ReneWerner87 merged commit 775e0a7 into gofiber:main Dec 28, 2024
12 of 14 checks passed
Copy link

welcome bot commented Dec 28, 2024

Congrats on merging your first pull request! 🎉 We here at Fiber are proud of you! If you need help or want to chat with us, join us on Discord https://gofiber.io/discord

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

🐛 [Bug]: Memory leak removal in the idempotency middleware
3 participants