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
Snuba 22.6.0 in a sentry k8s environment and also snuba 22.7.0 in the onpremise docker compose environment.
Steps to Reproduce
Use sentry for a long time with activity that generates sessions.
Expected Result
Session data would be purged somewhere around after it reaches retention_days old.
Actual Result
Session data is never purged by any process and as a result it takes up large amounts of disk space. On my prod k8s installation, the last ~90 days is ~400 gb, so obviously additional retention quickly adds up on the disk space front. I need to periodically. manually drop partitions to keep disk space in check The docker-compose installation is more lightly used so the disk space is not notable but shows that it has sessions_raw data that is ~16 months old, even though retention_days is set to 90.
It's possible there's some cleanup task in snuba that I don't have configured, but i can't find any evidence of such a thing in snuba's codebase.
The text was updated successfully, but these errors were encountered:
We have identified the problem to be a bug in the table definition. There is no TTL defined on the table due to which it does not get deleted. We will work on fixing the bug on our end. Thanks for reporting the problem.
Environment
Snuba 22.6.0 in a sentry k8s environment and also snuba 22.7.0 in the onpremise docker compose environment.
Steps to Reproduce
Expected Result
Session data would be purged somewhere around after it reaches retention_days old.
Actual Result
Session data is never purged by any process and as a result it takes up large amounts of disk space. On my prod k8s installation, the last ~90 days is ~400 gb, so obviously additional retention quickly adds up on the disk space front. I need to periodically. manually drop partitions to keep disk space in check The docker-compose installation is more lightly used so the disk space is not notable but shows that it has sessions_raw data that is ~16 months old, even though retention_days is set to 90.
It's possible there's some cleanup task in snuba that I don't have configured, but i can't find any evidence of such a thing in snuba's codebase.
The text was updated successfully, but these errors were encountered: