Application Server Migration (Unicorn to Puma)

7/8/2020

This post details the technical journey of migrating GitLab's application servers from Unicorn to Puma. It explains the architectural differences between the two servers (single-threaded vs. multi-threaded), the motivations for the migration (memory growth and scalability), and the implementation steps. Key technical challenges and solutions discussed include: identifying and fixing a thread-safety issue with the ChronicDuration library by forking it into `gitlab-chronic-duration`, tuning Puma's worker and thread configurations to address latency issues, and contributing an upstream patch to Puma to improve request scheduling and capacity distribution by injecting minimal latency between requests when a worker is busy. The post also quantifies the results, showing a 37% reduction in memory usage.

9/13/2019

This post details the creation of the GitLab Memory team to address the application's high memory footprint. It outlines the team's priorities: migrating from Unicorn to Puma, optimizing endpoints, and improving development practices. The post specifically highlights the migration from Unicorn to Puma as a key initiative to reduce memory usage, with preliminary research showing Puma's threaded nature requires less memory than Unicorn's single-request-per-process model. The team has configured Puma on dev.gitlab.com and plans to enable it on GitLab.com. Additionally, the team is addressing memory issues in Sidekiq, project import, and exports, and is working on improving internal development practices related to memory usage and code complexity.