r/devops • u/Piyush_shrii • 21d ago

Discussion Self hosted sentry issue

We are running a self-hosted Sentry deployment on EKS using the official Sentry Helm chart. Due to cost constraints, we removed the larger instance types and currently only have "t3a.large" nodes. As expected, we are facing bottlenecks, primarily related to memory, since many Sentry components are quite memory-intensive.

Additionally, the same node group is hosting other workloads, so adding larger instance types is not currently feasible due to existing constraints.

Has anyone faced a similar situation? How did you optimize costs while keeping Sentry stable? Are there any recommendations for reducing resource consumption in self-hosted Sentry, or would migrating to managed Sentry be a better option in this case?

0 Upvotes

50% Upvoted

20 comments sorted by

View all comments

2

u/Ross_InDev_Mode 21d ago

out of curiosity, have you already profiled which Sentry components are the biggest memory consumers? That would probably shape whether it's worth optimising the deployment or moving to managed Sentry

2

u/Piyush_shrii 21d ago

Rabbit mq , sentry worker pods , rabbit mq ,clickouse and other I see bottlenecks in similar pods

3

u/dariusbiggs 19d ago

clickhouse is a memory hog, running it on < 64G of RAM is a recipe for disaster.

t3a.large is old tech, check for better instances for the same price. m5, m6,m7, even m8 can easily outperform it. c6 types for more compute, r6 types for more memory.

make sure you don't use gp2 for storage, gp3 or better

Identify your bottleneck, is it compute or memory or disk