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
Copy file name to clipboardExpand all lines: context/getting-started.md
+35-2Lines changed: 35 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -139,13 +139,46 @@ The {ruby Async::Container::Supervisor::MemoryMonitor} will periodically check w
139
139
140
140
The supervisor can collect various diagnostics from workers on demand:
141
141
142
-
-**Memory dumps**: Full heap dumps for memory analysis
143
-
-**Thread dumps**: Stack traces of all threads
142
+
-**Memory dumps**: Full heap dumps for memory analysis via `ObjectSpace.dump_all`.
143
+
-**Memory samples**: Lightweight sampling to identify memory leaks.
144
+
-**Thread dumps**: Stack traces of all threads.
144
145
-**Scheduler dumps**: Async fiber hierarchy
145
146
-**Garbage collection profiles**: GC performance data
146
147
147
148
These can be triggered programmatically or via command-line tools (when available).
148
149
150
+
#### Memory Leak Diagnosis
151
+
152
+
To identify memory leaks, you can use the memory sampling feature which is much lighter weight than a full memory dump. It tracks allocations over a time period and focuses on retained objects.
153
+
154
+
**Using the bake task:**
155
+
156
+
```bash
157
+
# Sample for 30 seconds and print report to console
result = connection.call(do::memory_sample, duration:30)
166
+
puts result[:data]
167
+
```
168
+
169
+
This will sample memory allocations for the specified duration, then force a garbage collection and return a JSON report showing what objects were allocated during that period and retained after GC. Late-lifecycle allocations that are retained are likely memory leaks.
170
+
171
+
The JSON report includes:
172
+
-`total_allocated`: Total allocated memory and count
173
+
-`total_retained`: Total retained memory and count
174
+
-`by_gem`: Breakdown by gem/library
175
+
-`by_file`: Breakdown by source file
176
+
-`by_location`: Breakdown by specific file:line locations
177
+
-`by_class`: Breakdown by object class
178
+
-`strings`: String allocation analysis
179
+
180
+
This is much more efficient than `do: :memory_dump` which uses `ObjectSpace.dump_all` and can be slow and blocking on large heaps. The JSON format also makes it easy to integrate with monitoring and analysis tools.
Copy file name to clipboardExpand all lines: guides/getting-started/readme.md
+35-2Lines changed: 35 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -139,13 +139,46 @@ The {ruby Async::Container::Supervisor::MemoryMonitor} will periodically check w
139
139
140
140
The supervisor can collect various diagnostics from workers on demand:
141
141
142
-
-**Memory dumps**: Full heap dumps for memory analysis
143
-
-**Thread dumps**: Stack traces of all threads
142
+
-**Memory dumps**: Full heap dumps for memory analysis via `ObjectSpace.dump_all`.
143
+
-**Memory samples**: Lightweight sampling to identify memory leaks.
144
+
-**Thread dumps**: Stack traces of all threads.
144
145
-**Scheduler dumps**: Async fiber hierarchy
145
146
-**Garbage collection profiles**: GC performance data
146
147
147
148
These can be triggered programmatically or via command-line tools (when available).
148
149
150
+
#### Memory Leak Diagnosis
151
+
152
+
To identify memory leaks, you can use the memory sampling feature which is much lighter weight than a full memory dump. It tracks allocations over a time period and focuses on retained objects.
153
+
154
+
**Using the bake task:**
155
+
156
+
```bash
157
+
# Sample for 30 seconds and print report to console
result = connection.call(do::memory_sample, duration:30)
166
+
puts result[:data]
167
+
```
168
+
169
+
This will sample memory allocations for the specified duration, then force a garbage collection and return a JSON report showing what objects were allocated during that period and retained after GC. Late-lifecycle allocations that are retained are likely memory leaks.
170
+
171
+
The JSON report includes:
172
+
-`total_allocated`: Total allocated memory and count
173
+
-`total_retained`: Total retained memory and count
174
+
-`by_gem`: Breakdown by gem/library
175
+
-`by_file`: Breakdown by source file
176
+
-`by_location`: Breakdown by specific file:line locations
177
+
-`by_class`: Breakdown by object class
178
+
-`strings`: String allocation analysis
179
+
180
+
This is much more efficient than `do: :memory_dump` which uses `ObjectSpace.dump_all` and can be slow and blocking on large heaps. The JSON format also makes it easy to integrate with monitoring and analysis tools.
0 commit comments