-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable auto-scaling for sidekiq #20
Comments
There is a way to do auto scaling for most of the sidekiq queues. Except for the scheduler. You can only have one of those. This article helped me work on some of my experiments with scaling Sidekiq (https://nora.codes/post/scaling-mastodon-in-the-face-of-an-exodus/). At a minimum you need at least 1 gigabyte of memory for each instance. I'm not sure how many threads though. The default is 5 but it might make sense to reduce it to maybe 2 based on the amount of cpu units on each container instance you have (I'm using 0.5 for each). |
Were you able to integrate these changes into the CloudFormation configuration @compuguy? After increasing the Cpu and Memory flags I'm still seeing full load. |
I honestly went down a different road @vesteinn. I moved the mail and scheduler queues to their own separate instance, with 0.25 vCPU and .5 GB of memory. You can only have one scheduler queue per Mastodon instance, so I left it with the mail queue which wasn't using much CPU or RAM. Then I made the SidekiqService container run the rest of the needed queues |
I wanted to share an incident report I created after a member of my instance reported problems uploading videos: https://hub.montereybay.social/blog/degraded-service-video-transcoding-failures.html tl;dr: iPhone video transcoding with ffmpeg was causing the CPU and memory usage to spike on the Sidekiq service. Changing vCPUs from 0.25 -> 0.5 and memory from 0.5 Gb -> 1 Gb in the Task Definition and redeploying that service resolved the issue, at least temporarily. My instance is still pretty small at 19 users. If anyone would like me to report additional statistics, let me know what you want to see -- I'm happy to share operational metrics. |
At your service! https://hub.montereybay.social/Operations.html now has a public CloudWatch dashboard with all of those metrics. |
@pegli That's cool :) Do you mind sharing the JSON definition (open the dashboard in the CloudWatch UI, click Actions -> View/edit source) of the dashboard? We could add it to the template. |
see
Originally posted by @scrappydog in #1 (comment)
Originally posted by @michaelwittig in #1 (comment)
My inner system admin really "wants" to add another task... but I agree as long as jobs are completing in a reasonable time it's not an immediate issue.
BUT we are running tiny instances for testing... we NEED a way to scale up... :-)
Originally posted by @scrappydog in #1 (comment)
This feels happier for now... but it doesn't address the real scalability question...
Originally posted by @scrappydog in #1 (comment)
Upgraded about half way through this graph... definably a lot better!
Originally posted by @scrappydog in #1 (comment)
The text was updated successfully, but these errors were encountered: