Stable counterparts for Scalability Group and Application Performance Group
The Scalability group and Application performance group do work which affects a lot of self managed environments.
Scalability groupscalability does a lot of work around Sidekiq
- Collaborating with QE to understand why Sidekiq workers can only use on CPU (and so to use more CPUs, more workers are needed)
- Setting default thread count to 20 in %15.7
-
Reconfiguring Sidekiq to use mainly the default queue.
- This is an example of where closer working with support would have been really useful, since the change had to be reverted and backported.
Application performance ~"group::application performance"
- Issue about sidekiq troubleshooting in their queue (Scalability could also have been a good home) yielded some great troubleshooting for performance issues
-
Memory use by Puma and issues around performance caused by excessive puma worker killer (PWK) was resolved by ~"group::application performance"
- This has resulted in a lot of analysis and work to introduce a replacement for PWK and analysis into why GitLab Puma workers leak memory
- Team has specifically identified that it would benefit from a Support Stable Counterpart to improve their insight into Self managed environments. Currently their focus has been biased towards GitLab.com
Edited by Ben Prescott_