Skip to content

Commit e8e3ae4

Browse files
authored
feat(taskworker) Collect another metric from workers (#94960)
We have some pools that run really smoothly, and other that don't run as smoothly. I think that the number of times after startup that we call this method to fill the child_tasks queue is contributing to broker processing deadlines occurring.
1 parent 4711321 commit e8e3ae4

File tree

1 file changed

+12
-0
lines changed

1 file changed

+12
-0
lines changed

src/sentry/taskworker/worker.py

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -153,6 +153,17 @@ def _add_task(self) -> bool:
153153
Add a task to child tasks queue. Returns False if no new task was fetched.
154154
"""
155155
if self._child_tasks.full():
156+
# I want to see how this differs between pools that operate well,
157+
# and those that are not as effective. I suspect that with a consistent
158+
# load of slowish tasks (like 5-15 seconds) that this will happen
159+
# infrequently, resulting in the child tasks queue being full
160+
# causing processing deadline expiration.
161+
# Whereas in pools that have consistent short tasks, this happens
162+
# more frequently, allowing workers to run more smoothly.
163+
metrics.incr(
164+
"taskworker.worker.add_tasks.child_tasks_full",
165+
tags={"processing_pool": self._processing_pool_name},
166+
)
156167
return False
157168

158169
inflight = self.fetch_task()
@@ -344,6 +355,7 @@ def fetch_task(self) -> InflightTaskActivation | None:
344355
extra={"processing_pool": self._processing_pool_name},
345356
)
346357

358+
# TODO cap backoff to 5 seconds instead?
347359
self._gettask_backoff_seconds = min(self._gettask_backoff_seconds + 1, 10)
348360
return None
349361

0 commit comments

Comments
 (0)