Created: 2/9/2026 11:22
Updated: 2/9/2026 11:59
Exported: 2/9/2026 13:26
我私有化部署sentry，但是遇到一个性能问题，就是我的部署机器是8c16g的配置，我采用的是self-hosted项目私有化的，拉起服务时看到日志中有一些timeout什么的，我查过好像是我这台机器资源较低，所以需要修改一些参数，那我需要修改哪些参数呢。你需要注意我是基于self-hosted 26.1.0版本私有化的。有些配置参数或者选项已经不一样了。我这里附上26.1.0版本的docker-compose.yaml内容：x-restart-policy: [手动删除，省略了] sentry-kafka-log: sentry-smtp-log: sentry-clickhouse-log:
你的機器是 8核16GB，而 Sentry self-hosted（尤其是 26.x 版本）在低流量或中低流量情況下，16GB 其實已經勉強達標（官方 minimum 是 16GB RAM + swap），但在啟動、事件入庫、查詢、Snuba/ClickHouse 運作時很容易因為並發 + Python 記憶體開銷導致 OOM 或嚴重 swap，進而出現各種 timeout（web 超時、consumer 卡住、healthcheck 失敗等）。
26.1.0 版本已經把很多地方改成 Rust consumer，記憶體效率比以前好一些，但 web、taskworker、ClickHouse、Kafka 這些仍然是吃資源大戶。
以下是你目前最值得優先調整的幾個方向（由影響程度從大→小排序）：
Sentry 的 web 預設使用 uWSGI，worker 數偏多會在 16GB 機器上直接吃爆記憶體。
推薦做法（在 ./sentry/sentry.conf.py 裡面加或改）：
# 強制覆蓋 uWSGI 參數（26.x 仍然支援這種寫法）
SENTRY_UWSGI_OPTIONS = {
"workers": 2, # 從原本的 4~8 降到 2（甚至可以試 1）
"threads": 2, # 每個 worker 2 條 thread
"http": "0.0.0.0:9000",
"master": True,
"enable-threads": True,
"lazy-apps": True,
"max-requests": 80000, # 避免記憶體長期洩漏
"max-requests-delta": 500,
"thunder-lock": True,
"http-keepalive": 15,
}
極低流量可以再降到 workers:1, threads:3~4
26.x 版本把 Celery 換成 taskworker + taskbroker，預設 concurrency 可能偏高。
方法一（推薦）：直接用環境變數控制（26.1.0 已支援）
在 .env 檔裡加：
SENTRY_TASKWORKER_CONCURRENCY=3 # 預設可能是 4~8，降到 3 或 2
然後
docker compose restart taskworker
方法二：直接改 docker-compose.yaml 裡的 taskworker 這段
taskworker:
<<: *sentry_defaults
command: run taskworker --concurrency=3 --rpc-host=taskbroker:50051 --health-check-file-path=/tmp/health.txt
你目前的設定是 MAX_MEMORY_USAGE_RATIO: 0.3（30%），在 16GB 機器上大約只給 ClickHouse ~4.5–5GB，已經很保守了。
但如果還是 OOM 或查詢超時，可以再降：
environment:
MAX_MEMORY_USAGE_RATIO: 0.20 # 降到 20% ≈ 3.2GB
# 或直接硬限制
# CLICKHOUSE_MAX_MEMORY_USAGE: 3500000000 # 3.5GB
| 項目 | 建議值 | 位置 | 說明 |
|---|---|---|---|
| Snuba uWSGI workers | UWSGI_MAX_REQUESTS=5000 | snuba-api 環境變數 | 避免長期記憶體成長 |
| Redis maxmemory | 建議設 1.5~2GB | ./redis.conf | 預防 Redis 吃太多（用 maxmemory-policy allkeys-lru） |
| Kafka heap | 環境變數 KAFKA_HEAP_OPTS="-Xmx1G -Xms1G" | kafka 服務 environment 新增 | Kafka JVM 預設吃很多 |
| memcached | 保持 -I 64m 或更低 | memcached command | 通常不需要調 |
| worker concurrency | 降到 2~3 | events-consumer 等 consumer | 可手動加 --concurrency=2 |
# .env 新增或修改
SENTRY_TASKWORKER_CONCURRENCY=3
# sentry/sentry.conf.py 最後面加入
SENTRY_UWSGI_OPTIONS = {
"workers": 2,
"threads": 2,
"max-requests": 80000,
"max-requests-delta": 500,
}
# docker-compose.yaml 改 clickhouse
MAX_MEMORY_USAGE_RATIO: 0.20
改完後：
docker compose down
docker compose up -d
等所有 healthy 後，用瀏覽器大量操作幾個頁面（issue list、discover、project dashboard），觀察是否還有明顯 timeout。
如果還是卡，再提供具體的 timeout 錯誤訊息（是 504、upstream prematurely closed、healthcheck timeout 還是其他），我可以再幫你針對性調整。 祝部署順利～
拉起服务中，有如下超时内容：process-spans-1 | ~~~~~~~~~~~~~~~~~~~~~~~~~~^ process-spans-1 | processor, quantized_rebalance_delay_secs, dump_stacktrace_on_shutdown process-spans-1 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ process-spans-1 | ) process-spans-1 | ^ process-spans-1 | File "/usr/src/sentry/src/sentry/utils/kafka.py", line 67, in run_processor_with_signals process-spans-1 | processor.run() process-spans-1 | ~~~~~~~~~~~~~^^ process-spans-1 | File "/.venv/lib/python3.13/site-packages/arroyo/processing/processor.py", line 369, in run process-spans-1 | self._run_once() process-spans-1 | ~~~~~~~~~~~~~~^^ process-spans-1 | File "/.venv/lib/python3.13/site-packages/arroyo/processing/processor.py", line 469, in _run_once process-spans-1 | self.__message = self.__consumer.poll(timeout=1.0) process-spans-1 | ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^ process-spans-1 | File "/.venv/lib/python3.13/site-packages/arroyo/backends/kafka/consumer.py", line 489, in poll process-spans-1 | raise ConsumerError(str(error)) process-spans-1 | arroyo.errors.ConsumerError: KafkaError{code=_MAX_POLL_EXCEEDED,val=-147,str="Application maximum poll interval (30000ms) exceeded by 265 ms"}
這個錯誤是典型的 Kafka consumer 問題，具體出現在 process-spans 這個 consumer 上（處理 spans/profiling 資料的容器）：
arroyo.errors.ConsumerError: KafkaError{code=_MAX_POLL_EXCEEDED,val=-147,str="Application maximum poll interval (30000ms) exceeded by 265ms"}
注意：你的 Kafka broker 端 log 可能也有類似 "leaving group" 的訊息，但重點在 consumer 這邊。
按順序嘗試，第一個通常就能解決 80% 的情況。
大幅增加 max.poll.interval.ms（最推薦，先試這個） Arroyo (Sentry 用的 streaming 框架) 支援透過環境變數或 config 傳遞 Kafka consumer 參數。
在你的 docker-compose.yaml 中，找到 process-spans 服務，改成這樣：
process-spans:
<<: *sentry_defaults
command: run consumer --no-strict-offset-reset process-spans --consumer-group process-spans --health-check-file-path /tmp/health.txt
environment:
<<: *你的其他環境變數如果有
KAFKA_MAX_POLL_INTERVAL_MS: "120000" # 改成 120 秒（2分鐘），或更高如 300000 (5分鐘)
降低 batch 處理量，讓每批次更快處理完 Arroyo consumer 預設 batch.size 可能偏大。試著加參數限制：
在 command 後面加（如果支援）：
command: run consumer --no-strict-offset-reset process-spans --consumer-group process-spans --max-batch-size 100 --health-check-file-path /tmp/health.txt
或透過環境變數（如果 Arroyo 認）：
environment:
KAFKA_MAX_POLL_RECORDS: "50" # 每 poll 最多拉 50 筆
KAFKA_FETCH_MAX_BYTES: "5242880" # 每 fetch 最多 5MB
這樣每批次資料少，處理時間就短，不容易超 30 秒。
如果 profiling/spans 流量很低，可以乾脆關閉這個 consumer（feature-complete 專用） 你的 docker-compose 有 profiles: - feature-complete，如果你沒啟用 profiling，就不要啟動 process-spans：
docker compose --profile default up -d # 或直接不加 --profile feature-complete
或在 docker-compose.yaml 把 process-spans 的 profiles 註解掉。
其他輔助調整（搭配使用）
確保機器沒有大量 swap：free -h 看 swap 使用率，如果 swap > 1GB 就加 swapfile 或殺掉其他吃資源的東西。
降低 taskworker concurrency（如之前建議設 2~3）。
檢查 Kafka 本身健康：docker compose logs kafka 看是否有 OOM 或 disk full。
如果超時還是頻繁發生，考慮把 Kafka heap 限制小一點（但你機器小，不建議）：
kafka:
environment:
KAFKA_HEAP_OPTS: "-Xmx512m -Xms512m"
這個錯誤本身不會丟事件（只是 consumer 短暫離開 group，之後會 rejoin），但如果頻繁發生會導致 spans 處理延遲或積壓。調高 interval 後通常就穩了。
加油，應該很快就好了！
是不是 process-spans: <<: *sentry_defaults command: run consumer --no-strict-offset-reset process-spans --consumer-group process-spans --healthcheck-file-path /tmp/health.txt environment:
# # 新增下面这行，单位 ms，建议从 300000（5分钟）开始，内网低配可以直接上 600000（10分钟）甚至 900000（15分钟）
KAFKA_MAX_POLL_INTERVAL_MS: "120000"
# # 可选：同时减小单次拉取记录数，降低单 poll 处理时间
# KAFKA_MAX_POLL_RECORDS: "50" # 默认可能是 500，调小能让处理更快返回 poll
这里也能增加这个KAFKA_MAX_POLL_RECORDS环境变量
是的，process-spans 这个服务完全可以（而且非常推荐）同时加上这两个环境变量：
process-spans:
<<: *sentry_defaults
command: run consumer --no-strict-offset-reset process-spans --consumer-group process-spans --health-check-file-path /tmp/health.txt
environment:
KAFKA_MAX_POLL_INTERVAL_MS: "300000" # 强烈建议从 300000（5分钟）开始，甚至可以设 600000（10分钟）
KAFKA_MAX_POLL_RECORDS: "50" # 同时限制每次 poll 最多拉 50 条记录，降低单次处理负担
# 如果还想更保守，可以再加：
# KAFKA_FETCH_MAX_BYTES: "5242880" # 5MB，防止一次拉太多大 spans
# KAFKA_FETCH_MIN_BYTES: "1" # 尽量快速返回（默认1字节即可）
低配机器（8c16g）上，spans 处理（尤其是 profiling 相关的）计算量不小，同时限制数量 + 放宽超时 是最稳的组合。
| 场景 | KAFKA_MAX_POLL_INTERVAL_MS | KAFKA_MAX_POLL_RECORDS | 其他建议 | 预期效果 |
|---|---|---|---|---|
| 先试（最常用） | 300000（5分钟） | 50 | — | 大多数情况解决 |
| 还是偶发超时 | 600000（10分钟） | 30～50 | 加 KAFKA_FETCH_MAX_BYTES: "10485760" | 更稳，但 rebalance 稍慢 |
| 流量极低、机器很卡 | 900000（15分钟） | 20 | 考虑降低其他 consumer concurrency | 几乎不可能再超时 |
| 想更激进（不推荐先用） | 1200000（20分钟） | 10 | — | 处理极慢但不丢 partition |
编辑 docker-compose.yaml，加入上面 environment 部分。
重启该服务（不需要全 down）：
docker compose up -d --force-recreate process-spans
观察日志：
docker compose logs -f process-spans
这样改完，process-spans 超时问题基本能根治。 如果改完还是有新错误，把最新的日志贴出来，我继续帮你看～
Explain Arroyo Kafka configSentry profiling optimization
Powered by Grok Exporter
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。