Alexey Kovyazin, 14-Tháng 7-2014

Như bạn nhớ từ các bài viết trước của chúng tôi, chúng tôi đã điều tra những lầm tưởng về sự suy giảm hiệu suất của Firebird ( /vi/articles/firebird-performance-degradation-tests-myths-and-truth/), nơi chúng tôi đã tạo ra một số cơ sở dữ liệu từ 9Gb đến 30Gb, và cũng đã thử nghiệm cơ sở dữ liệu Firebird rất lớn (1.7 terabyte) (/vi/articles/more-details-about-1-7-terabyte-firebird-sql-database/).

Tất cả các thử nghiệm đều được thực hiện trên cùng một phần cứng, một cấu hình khá tiết kiệm: CPU AMD-FX8350, RAM 16GB, SATA software RAID1 2x4Tb ổ cứng HDD Seagate, Hệ điều hành Windows Server 2008R2 (2008R2 là 64 bit), và với cùng cấu hình Firebird: đó là Firebird 2.5.2 64-bit, SuperServer, với page buffers và TempCacheSize tăng lên. Bạn có thể tải xuống miễn phí tệp cấu hình SuperServer này từ vị trí: /vi/optimized-firebird-configuration/

Kết quả là, chúng tôi có bức tranh sau về hiệu suất cơ sở dữ liệu:

![Firebird performance 1813Gb (1.7Tb)](/images/performance/perf7_performance_with 1800Gb_Firebird_database.png)

Hình 1. Sự suy giảm hiệu suất từ 9Gb đến 30Gb, và 1,7Tb

Điểm #11 là chỉ số hiệu suất cho cơ sở dữ liệu 30Gb và #12 cho cơ sở dữ liệu 1.7 Terabyte - kích thước cơ sở dữ liệu đã tăng gấp 60 lần (từ 30Gb lên 1813Gb), tổn thất hiệu suất là 2.4 lần (từ 407 xuống 169 điểm).

Vì vậy, câu hỏi đặt ra là: chúng ta có thể cải thiện hiệu suất Firebird trên cùng phần cứng bằng cách tinh chỉnh cấu hình không?

Và câu trả lời là: có!

Tăng cường hiệu suất FirebirdSQL

Như bạn nhớ, trong thử nghiệm này chúng tôi chạy 20 kết nối đồng thời thực hiện các thao tác INSERT mạnh mẽ và các thao tác UPDATE ít mạnh mẽ hơn.

Tất cả các SELECT đều ngắn và được xác định rõ ràng, với các kế hoạch thực thi SQL hiệu quả, vì vậy đây là một ứng dụng OLTP (xử lý giao dịch trực tuyến) điển hình. Đối với các ứng dụng như vậy, điều quan trọng nhất đối với hiệu suất là xử lý song song. Firebird SuperServer 2.5.2 không phù hợp tốt cho xử lý đa luồng - nó chỉ sử dụng hiệu quả 1 lõi cho mỗi cơ sở dữ liệu, và thực tế này khiến SuperServer không phải là lựa chọn tốt cho ứng dụng OLTP.

Vì vậy, chúng ta cần thay đổi kiến trúc Firebird sang Classic hoặc SuperClassic, hỗ trợ xử lý đa luồng và sử dụng nhiều lõi CPU (có 8 lõi trong CPU AMD-FX8350).

Sau đó, cần một số tinh chỉnh, vì cấu hình mặc định cho Firebird không tối ưu cho hệ thống thử nghiệm của chúng tôi.

Các tham số tinh chỉnh trong firebird.conf

Page cache

Vì vậy, để cải thiện hiệu suất OLTP, chúng tôi quyết định thử các kiến trúc Classic và SuperClassic. Một trong những tham số quan trọng nhất đối với Classic và SuperClassic là số lượng page buffers trong bộ nhớ cache. Không giống như SuperServer, Classic và SuperClassic phân bổ page cache cho mỗi kết nối.

Để biết thêm chi tiết về các kiến trúc Firebird trong 2.5, bạn có thể xem bảng này tại http://www.firebirdsql.org/file/fb25.architecture_comparison.pdf

Có một công thức đơn giản để tính toán mức sử dụng bộ nhớ page cache cho các kiến trúc Firebird khác nhau:

1. SuperServer - một page cache duy nhất cho mỗi cơ sở dữ liệu. Kích thước page cache mặc định là 2048 trang, khuyến nghị chung là 10000 buffers. Trong trường hợp của chúng tôi, cache là 16k (kích thước trang) x 10000 ~= 160Mb. Điều này áp dụng cho tất cả các kết nối.
1. Classic và SuperClassic - engine phân bổ page cache cho mỗi kết nối. Kích thước mặc định là 75 trang, vì vậy 16Kb (kích thước trang) x 75 = ~= 1.17 Mb, cho mỗi kết nối.

Rõ ràng, kích thước page cache nên được tăng lên, vì 75 trang cho mỗi kết nối là quá thấp. Chúng tôi sẽ trình bày dưới đây kết quả của một số giá trị khác nhau cho kích thước page cache.

LockHashSlots

Bên trong, engine Firebird sử dụng bảng khóa (lock table) để yêu cầu và giành khóa cho các đối tượng nội bộ trong cơ sở dữ liệu, và đối với Classic và SuperClassic có tham số LockHashSlots (giá trị mặc định là 1009). Nó nên được tăng lên khi tải cao, để giảm các chuỗi băm trong bảng khóa. Chà, “tải cao” dường như là bất kỳ ứng dụng đa người dùng thực tế nào, vì vậy chúng tôi đã đặt nó thành 30011 (cho tất cả các thử nghiệm).

LockMemSize

Tham số LockMemSize được sử dụng để thiết lập kích thước bảng khóa ban đầu (giá trị mặc định là 1048576). Engine có thể tăng kích thước bảng theo nhu cầu. Tuy nhiên, việc tăng bảng khóa là tốn kém về CPU và các tài nguyên khác, vì nó được thực hiện thông qua việc ánh xạ lại bộ nhớ. Vì vậy, chúng tôi đã đặt nó thành 7Mb, để tiết kiệm một chút thời gian và tài nguyên CPU.

Các lần chạy thử nghiệm

Chúng tôi đã thực hiện một số lần chạy thử nghiệm với các giá trị khác nhau của page cache, với kết quả sau:

Page buffers	Classic, điểm thử nghiệm	SuperClassic, điểm thử nghiệm
256	299	372
512	371	359
768	362	386
1024	312	387
1500	390	392
2048	285	284

Bảng 1. Các lần chạy thử nghiệm cho Classic và SuperClassic

Như bạn có thể thấy, Classic và SuperClassic hiệu quả hơn nhiều so với Firebird SuperServer cho nhiệm vụ này: kết quả thử nghiệm được cải thiện từ 169 điểm lên 300-400, gần với kết quả chúng tôi có cho cơ sở dữ liệu 30Gb!

Tốt hơn là xem kết quả trên biểu đồ sau:

Firebird performance 1813Gb (1.7Tb)

Hình 2. Kết quả thử nghiệm cho cơ sở dữ liệu 1.7 Terabyte

Bạn có thể thấy rằng hiệu suất tốt nhất (cả ở Classic và SuperClassic) là ở 1500 trang cho mỗi kết nối, vì vậy kích thước page cache cho mỗi kết nối là:

1500x16k ~= 23,4Mb

Với 2000 trang cho mỗi kết nối, hiệu suất giảm đáng kể. Có vẻ như ở đâu đó khoảng 1500-2000 trang, lợi ích của việc lưu vào bộ nhớ cache trở nên thấp hơn so với chi phí do tương tác bảng khóa giữa các tiến trình để đồng bộ hóa các trang trong bộ nhớ cache của mỗi tiến trình máy chủ. Rõ ràng, với số lượng kết nối cao hơn, điều này sẽ xảy ra sớm hơn, đó là lý do tại sao các máy chủ Classic/SuperClassic thường được cấu hình với các con số như 256-512 trang.

Cũng có sự sụt giảm hiệu suất của Classic ở khoảng 768-1000 page caches - không chắc chắn tại sao điều đó xảy ra.

Tóm tắt

Các thử nghiệm của chúng tôi xác nhận rằng hiệu suất Firebird có thể được tăng lên với việc lựa chọn đúng kiến trúc Firebird (SuperServer, Classic hoặc SuperClassic) và với việc tinh chỉnh phù hợp một số tham số quan trọng cho kiến trúc cụ thể.

Kết quả là, một cơ sở dữ liệu Firebird SQL khổng lồ 1.7 Tb có thể hoạt động trên phần cứng cấp thấp với hiệu suất đủ tốt. Là một kết quả thực tế từ các thử nghiệm này, chúng tôi đã tạo ra một số tệp cấu hình cho tất cả các phiên bản Firebird cho tất cả các kiến trúc. Tất nhiên, chúng không được tinh chỉnh cho ứng dụng và/hoặc phần cứng cụ thể, nhưng chúng tốt hơn các tệp cấu hình mặc định, vốn được tạo cho tải rất khiêm tốn.

Bộ đầy đủ các tệp cấu hình Firebird được tối ưu hóa: /vi/optimized-firebird-configuration/

Vui lòng đặt bất kỳ câu hỏi nào: [email protected]

Tiếp theo là gì?

Chúng tôi đang thực hiện một thử nghiệm toàn diện sẽ so sánh hiệu suất của Firebird 2.5 và Firebird 3.0, với mô phỏng tải thực tế và số lượng kết nối lớn. Hãy theo dõi!