Cách GitLab rút ngắn thời gian sao lưu kho lưu trữ từ 48 giờ xuống 41 phút

 (about.gitlab.com)
5 điểm bởi GN⁺ 2025-06-07 | 1 bình luận | Chia sẻ qua WhatsApp
  • GitLab đã phát hiện vấn đề sao lưu kho lưu trữ dung lượng lớn mất quá nhiều thời gian và tiến hành cải thiện
  • Nguyên nhân cốt lõi là độ phức tạp O(N²) của một hàm Git đã tồn tại 15 năm, và hiệu năng đã được cải thiện mạnh nhờ tối ưu thuật toán
  • Kết quả tối ưu hóa giúp thời gian sao lưu của kho lưu trữ lớn nhất giảm từ 48 giờ xuống 41 phút
  • Cách làm được cải thiện vừa mang lại hiệu quả tài nguyên và độ tin cậy, vừa tạo ảnh hưởng tích cực tới các công cụ dựa trên Git và cộng đồng
  • Từ phiên bản GitLab 18.0, mọi người dùng đều có thể hưởng lợi ích này mà không cần cấu hình bổ sung

Tầm quan trọng và thách thức của sao lưu kho lưu trữ

  • Sao lưu kho lưu trữ là yếu tố cốt lõi của chiến lược khôi phục khẩn cấp
  • Khi quy mô kho lưu trữ tăng lên, độ phức tạp của quy trình sao lưu đáng tin cậy cũng tăng theo
  • Kho lưu trữ Rails nội bộ của GitLab mất 48 giờ để sao lưu, khiến họ phải cân nhắc khó khăn giữa tần suất sao lưu và hiệu năng hệ thống
  • Ở các kho lưu trữ quy mô lớn, tồn tại nhiều vấn đề như thời gian, tài nguyên, rủi ro thất bại và race condition
    • Điều này dẫn tới các chiến lược thiếu nhất quán giữa các tổ chức, như khó lên lịch sao lưu, phụ thuộc vào công cụ bên ngoài hoặc giảm số lần sao lưu

Phân tích nút thắt hiệu năng và xác định nguyên nhân

  • Tính năng sao lưu của GitLab sử dụng lệnh git bundle create để tạo snapshot kho lưu trữ
  • Trong quá trình triển khai lệnh này, nút thắt hiệu năng xuất hiện khi số lượng reference tăng lên
  • Đã có trường hợp việc sao lưu các kho lưu trữ lớn với hàng triệu reference mất hơn 48 giờ

Phân tích nguyên nhân

  • Trong quá trình chạy lệnh, GitLab dùng Flame Graph để xác định đoạn gây nghẽn
  • Khi có 10.000 reference, khoảng 80% thời gian thực thi bị tiêu tốn trong hàm object_array_remove_duplicates()
  • Hàm này được đưa vào từ năm 2009 trong commit này nhằm xử lý reference trùng lặp
    • Khi dùng git bundle create, nó ngăn vấn đề phát sinh nếu có reference trùng lặp được đưa vào
    • Tuy nhiên, việc phát hiện trùng lặp được triển khai bằng vòng lặp for lồng nhau, tạo ra độ phức tạp O(N²)
    • Số lượng reference càng nhiều thì nút thắt này càng nghiêm trọng

Chuyển từ O(N²) sang ánh xạ hiệu quả

  • GitLab đã đóng góp một bản vá cho Git, thay vòng lặp lồng nhau bằng cách dùng cấu trúc dữ liệu map
    • Mỗi reference được thêm vào map để tự động loại bỏ trùng lặp và xử lý hiệu quả hơn
  • Thay đổi này giúp hiệu năng của git bundle create được cải thiện mạnh, đồng thời có thể mở rộng tốt trong môi trường có số lượng reference lớn
  • Kết quả benchmark cho thấy hiệu năng cải thiện hơn 6 lần với mốc 100.000 reference

Thời gian sao lưu giảm mạnh và hiệu quả đạt được

  • Thời gian sao lưu tối đa của kho lưu trữ đã giảm từ 48 giờ xuống 41 phút (còn khoảng 1,4%)
  • Có thể cung cấp hiệu năng nhất quán bất kể quy mô kho lưu trữ
  • Có thêm các lợi ích như giảm tải máy chủ và cải thiện hiệu năng của nhiều lệnh Git dựa trên sao lưu
  • Bản vá này đã được áp dụng vào upstream Git, đồng thời GitLab cũng triển khai ngay để khách hàng có thể trải nghiệm sớm hơn

Thay đổi thực tế đối với khách hàng GitLab

  • Các khách hàng doanh nghiệp lớn giờ có thể chạy sao lưu xuyên đêm liên tục mà không xung đột với quy trình làm việc phát triển
  • Nhờ RPO (mục tiêu điểm khôi phục) được rút ngắn, rủi ro mất dữ liệu trong tình huống thảm họa cũng giảm đáng kể
  • Chi phí vận hành như mức tiêu thụ tài nguyên, thời gian bảo trì và chi phí đám mây cũng được cắt giảm
  • Ngay cả khi quy mô kho lưu trữ tăng lên, người dùng không còn phải băn khoăn giữa tần suất sao lưu và hiệu năng hệ thống
  • Giờ đây mọi người dùng GitLab đều có thể hưởng lợi ích này mà không cần thay đổi cấu hình

Bước tiếp theo và ý nghĩa

  • Cải tiến lần này là một phần trong nỗ lực liên tục của GitLab nhằm xây dựng hạ tầng Git cấp doanh nghiệp có khả năng mở rộng cao
  • Thay đổi do GitLab đóng góp cũng đã được phản ánh vào dự án Git upstream, tạo hiệu ứng lan tỏa tích cực tới toàn ngành và cộng đồng mã nguồn mở
  • Những nỗ lực cải thiện hạ tầng như vậy đang trở thành hình mẫu cho các công việc tối ưu hiệu năng cốt lõi khác

Có thể tìm hiểu sâu hơn về cách tiếp cận hiệu năng của GitLab tại sự kiện ra mắt ảo GitLab 18

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-06-07
Ý kiến Hacker News

  • Chia sẻ thông tin rằng mã cải thiện hiệu năng mà GitLab đóng góp cho Git dự kiến sẽ được phát hành trong v2.50.0 liên kết commit liên quan

  • Từ kinh nghiệm thực tế, nhấn mạnh rằng việc loại bỏ phép toán n^2 trong mã mình viết luôn là lựa chọn đúng đắn. Cũng bày tỏ sự ngạc nhiên khi vấn đề có thể dễ dàng lộ ra ngay cả với giá trị n rất nhỏ mà không cần phải viết thuật toán đặc biệt nào

    • Trích dẫn định luật điện toán thứ nhất của Bruce Dawson: O(n^2) là điểm gây ra vấn đề mở rộng tệ nhất. Trong môi trường production thì có vẻ đủ nhanh, nhưng khi triển khai thực tế lại xảy ra suy giảm hiệu năng nghiêm trọng liên kết bài viết liên quan

    • Chia sẻ kinh nghiệm cá nhân rằng đã nhiều lần chứng kiến độ phức tạp thời gian O(N^2) trông có vẻ nhanh trong kiểm thử nhưng lại gây sự cố nghiêm trọng trong production

    • Theo kinh nghiệm của bản thân, trong đa số vấn đề (80~90%), nếu cần đến thuật toán phức tạp thì đó là dấu hiệu cho thấy chính mô hình dữ liệu đang không đúng. Chỉ trong một số trường hợp đặc biệt như compiler, nội bộ DB, lập kế hoạch đường đi... thì thuật toán phức tạp mới thực sự là bản chất của vấn đề

    • Nêu ngoại lệ duy nhất là các trường hợp phần cứng nhỏ với n dưới 10 (như giao diện CAN), còn nếu n có thể tăng mà không thay đổi phần cứng thì nhất định phải tránh phép toán n^2; nên giới hạn ngay từ thiết kế hoặc phát hiện sớm để nhận ra nhu cầu tái thiết kế

    • Bày tỏ sự bối rối vì bản thân đang gặp nút thắt cổ chai do phép toán n^3 chỉ với 10.000 phần tử mà vẫn chưa tìm ra cách giải quyết

  • Đánh giá đây là một phát hiện thú vị, đồng thời tiếc rằng bài gốc dù chỉ dài bằng 1/10 vẫn có thể truyền đạt hiệu quả. Dù vậy, mặt tích cực là đây không phải nội dung video nên khá dễ skim

    • Gợi ý cho những ai chưa đọc bài: chỉ cần đọc đến đoạn sau flame graph và trước khi nhắc tới backport rồi dừng lại là hiệu quả nhất để nắm ý chính

    • Cảm nhận rằng phong cách toàn bộ bài viết dài tới mức tạo cảm giác như do LLM (mô hình ngôn ngữ lớn) tạo ra, và đó là điều đọng lại trong trí nhớ

    • Nghĩ rằng bài còn dài hơn nữa cũng không sao, và vẫn thắc mắc vì sao lại tạo hai backup bundle theo ref

  • Cảm thấy thời gian 48 tiếng để nén một thư mục git cỡ vài GB, và ngay cả 41 phút, đều là quá lâu. Thắc mắc liệu có lý do đặc biệt nào để nhất quyết dùng git bundle thay vì chỉ snapshot/archive toàn bộ repo git. Cũng tò mò git bundle có ưu điểm gì so với việc backup ZFS diễn ra thường xuyên

    • Theo FAQ chính thức của git, cách làm như vậy có rủi ro vì bỏ qua quy trình kiểm tra tính toàn vẹn thông thường của Git. Trong trường hợp này nên dùng git fsck để xác minh tính toàn vẹn của bộ sưu tập. Ở quy mô cá nhân, chỉ cần Syncthing và snapshot Btrfs cũng đã đủ nhanh và ổn định tài liệu liên quan

    • Đề cập rằng việc đưa snapshot ZFS đi backup offsite lên nền tảng không dựa trên ZFS như S3 có những hạn chế. Một tính năng ít được biết tới của git bundle là có thể chỉ định vị trí bằng git clone --bundle-uri; nếu server báo cho client vị trí bundle thì client có thể tải bundle, bung nhanh ra rồi chỉ nhận các cập nhật delta từ server, giúp giảm đáng kể gánh nặng khi clone repo lớn

    • Đánh giá rằng rốt cuộc đây giống như việc thêm caching vào chỗ cần caching. Thông thường repo git vốn mang tính hệ phân tán, nên chỉ cần mirror sang kho khác rồi quản lý bằng công cụ snapshot/backup filesystem là được hay sao. Nhấn mạnh rằng điểm cốt lõi là chính thông tin quản lý phiên bản quan trọng phải được phân tán

  • Không có nhiều kinh nghiệm backup git, nhưng bày tỏ thắc mắc vì sao lại phát sinh race condition khi tạo backup trực tiếp từ repo local

  • Nếu chỉ vì giao thức dữ liệu ở tầng trên mà mọi chuyện rắc rối tới mức này, thì đặt câu hỏi vì sao không dùng snapshot ở mức block. Điểm vướng là Git không có WAL (Write Ahead Logging) như vậy, nhưng với SQLite thì chỉ cần thêm chế độ WAL là có thể áp dụng chiến lược snapshot block rất dễ dàng trong môi trường dịch vụ thực tế. Cho rằng nếu Git có kiến trúc tương tự thì sẽ có chiến lược backup ổn định hơn nhiều

    • Đồng cảm với vấn đề phát sinh từ việc Git không có cơ chế tương tự WAL, và chia sẻ từng gặp lỗi nghiêm trọng là chỉ tin vào snapshot để backup thì khi khôi phục repo có thể bị hỏng. Có thể sửa được nhưng rất phiền phức

    • Chia sẻ thêm mẹo rằng gần đây SQLite có giải pháp tốt hơn là sqlite3_rsync

    • Giải thích từ góc nhìn của GitLab rằng đây không chỉ là một dịch vụ managed đơn thuần, mà là sản phẩm có thể tự cài đặt và dùng trong nhiều môi trường khác nhau, nên filesystem, khả năng hỗ trợ snapshot và điều kiện hệ điều hành của mỗi người dùng đều khác nhau. Nói cách khác, GitLab muốn một hệ thống backup độc lập có thể hoạt động phổ quát trong mọi môi trường

  • Khi thấy cách diễn đạt "rút ngắn thời gian backup theo cấp số nhân (Exponentially) nhờ thay đổi thuật toán", đặt câu hỏi liệu có nghĩa là giảm từ O(n^2) xuống O(n^2/2^n) hay không. Đoán rằng thực tế không phải vậy

    • Giải thích rằng độ phức tạp thuật toán của hàm được sửa thực tế chỉ nhanh hơn 6 lần, còn trong ngữ cảnh vận hành khác thì tổng thời gian chạy giảm xuống còn 1%, nên trong trường hợp này cách nói "cải thiện theo cấp số nhân" là hợp lý về mặt marketing. Việc quy định chính xác độ phức tạp không quá quan trọng

    • Làm rõ rằng trong hội thoại thường ngày, "exponential" không được dùng theo nghĩa toán học chính xác mà chỉ như một cách nói ví von cho "cải thiện cực lớn"

    • Theo cách hiểu của bản thân, có thể là n đã giảm xuống log(n). Tương tự bối cảnh mà biến đổi Fourier lượng tử thường được mô tả là nhanh hơn theo cấp số nhân so với DFT truyền thống, ở đây cũng nhắc tới trường hợp độ phức tạp đổi từ n^2 sang nlogn

    • Nếu thay thuật toán n^2 bằng cách tra cứu log(n) thì đúng là tốc độ được cải thiện theo cấp số nhân, nhưng trên thực tế thường còn nhanh hơn nữa vì nhiều trường hợp đi tới O(1) như tra cứu hashmap

    • Cho rằng bản thân cuộc tranh luận này là một kiểu bắt bẻ không mang lại hiệu quả gì

  • Cho rằng đây là ví dụ tốt cho thấy viết bằng C không đồng nghĩa hiệu năng sẽ tự động vượt trội; cấu trúc dữ liệu và thuật toán mới là yếu tố quan trọng hơn

    • Vì trong C việc hiện thực container phù hợp vốn rất khó, nên những vấn đề hiệu năng kiểu này xảy ra thường xuyên hơn. Trong C++ hay Rust, nhờ có cấu trúc dữ liệu tích hợp như unordered_set/HashSet, lập trình viên có xu hướng tối ưu tự nhiên thay vì tiện tay dùng một vòng lặp for. Phân tích rằng trong trường hợp này Git cũng có string set, nhưng vì nó không mang tính tiêu chuẩn nên có thể tác giả ban đầu không biết tới

  • Nhắc tới bài học cần cân bằng giữa tối ưu hóa quá sớm và tối ưu hóa mang tính dự đoán trước. Thông thường người ta cảnh giác với việc tối ưu hóa vội vàng, nhưng đề xuất một quy tắc rằng với những hàm được gọi cực kỳ thường xuyên thì nên áp dụng trước các tối ưu rõ ràng và dễ thực hiện

    • Suy đoán rằng nếu tại thời điểm triển khai, ngôn ngữ nguồn có sẵn kiểu set-of-strings tích hợp, thì lập trình viên ban đầu cũng đã dễ dàng áp dụng tối ưu này. Cuối cùng cho rằng vấn đề này bắt nguồn từ giới hạn cấu trúc của những ngôn ngữ thiếu container như C

  • Trực tiếp chia sẻ liên kết tới commit liên quan (nội dung cải thiện thuật toán) liên kết commit liên quan