Cẩm nang Phần cứng Firebird

_by Alexey Kovyazin, cập nhật lần cuối: 30 tháng 11, 2015

Bạn thường có thể thấy câu hỏi sau trong các nhóm hỗ trợ kỹ thuật Firebird: “Phần cứng nào nên chọn cho hệ quản trị cơ sở dữ liệu Firebird?”. Chủ đề này luôn được quan tâm vì yêu cầu phần cứng khác nhau tùy theo tác vụ và bản thân phần cứng cũng thay đổi theo thời gian.

Chúng tôi quyết định viết hướng dẫn này để cung cấp kiến thức cần thiết cho bất kỳ ai muốn chọn phần cứng thực sự hiệu quả cho cơ sở dữ liệu Firebird của mình. Để làm được điều đó, bạn sẽ phải tìm hiểu một số chi tiết cơ bản về cách Firebird, hệ điều hành và tất nhiên là phần cứng hoạt động.

Một Chút Lý Thuyết

Để tìm ra phần cứng nào phù hợp nhất với cơ sở dữ liệu Firebird của bạn, chúng ta phải hiểu cách Firebird sử dụng các thành phần của nó: CPU, RAM, HDD/SSD và cách các thành phần này tương tác với hệ điều hành (ví dụ: với bộ nhớ đệm tệp).

Các Mô-đun Chức Năng của Máy Chủ Firebird

Trước tiên, chúng ta sẽ xem xét các mô-đun chức năng của Firebird với sự trợ giúp của Hình 1:

Hình 1. Các mô-đun Firebird

Firebird bao gồm các mô-đun chức năng chính sau:

Các đối tượng siêu dữ liệu: view, bảng, chỉ mục, trigger, thủ tục lưu trữ và các đối tượng cơ sở dữ liệu khác. Các đối tượng siêu dữ liệu nằm trong không gian địa chỉ của tiến trình Firebird (có thể là fbserver, fb_inet_server hoặc firebird.exe).
Bộ nhớ đệm của các bộ đệm trang chứa các trang cơ sở dữ liệu được đọc từ đĩa và nằm trong không gian địa chỉ của tiến trình máy chủ. Cơ chế lưu trữ trang trong bộ nhớ đệm khá phức tạp nên chúng tôi chỉ nêu rằng Firebird lưu trữ các trang cơ sở dữ liệu được sử dụng thường xuyên nhất.
Firebird sắp xếp các bản ghi trong bộ nhớ (trong không gian địa chỉ của tiến trình máy chủ) cho đến khi lượng bộ nhớ được sử dụng cho tất cả các thao tác sắp xếp đồng thời đạt đến giới hạn được đặt bởi tham số TempCacheLimit (firebird.conf). Khi vượt quá giới hạn này, một tệp tạm thời (với cờ hệ điều hành tương ứng) sẽ được tạo trong thư mục chứa tệp tạm thời và được sử dụng để sắp xếp. Nếu hệ thống có RAM trống, tệp sắp xếp sẽ được hệ điều hành lưu trữ trong bộ nhớ đệm và việc sắp xếp sẽ được thực hiện trong bộ nhớ.
Bảng tạm thời toàn cục (GTT) được tạo dưới dạng tệp tạm thời trong hệ điều hành. Nếu hệ điều hành có bộ nhớ trống, các thao tác với GTT sẽ được thực hiện trong RAM.

Các Thao Tác Cơ Bản với Phần Cứng

Chúng ta hãy xem các mô-đun chức năng của Firebird tương tác với các thành phần phần cứng như thế nào trong các thao tác được thực hiện trong quá trình làm việc với cơ sở dữ liệu.

Khi Firebird được khởi động, tiến trình máy chủ chiếm lượng RAM tối thiểu (vài megabyte) và không thực hiện bất kỳ thao tác chuyên sâu nào với CPU hoặc RAM.

Khi một kết nối được thiết lập đến cơ sở dữ liệu, máy chủ bắt đầu đọc siêu dữ liệu của nó và tạo các đối tượng tương ứng trong bộ nhớ, dẫn đến tiến trình sử dụng nhiều tài nguyên hơn khi có nhiều bảng, chỉ mục, trigger và siêu dữ liệu khác được sử dụng. Việc sử dụng bộ nhớ tăng lên, nhưng CPU hầu như không được sử dụng ở giai đoạn này.

Khi máy khách bắt đầu thực thi các truy vấn SQL (bao gồm cả thủ tục lưu trữ), máy chủ thực hiện các thao tác tương ứng bằng phần cứng. Có thể nêu ra các thao tác cơ bản sau liên quan đến tương tác với phần cứng:

đọc các trang cơ sở dữ liệu từ ổ cứng,
ghi các trang cơ sở dữ liệu vào ổ cứng,
đọc các trang cơ sở dữ liệu từ bộ nhớ đệm,
ghi các trang cơ sở dữ liệu vào bộ nhớ đệm,
đọc dữ liệu từ và ghi dữ liệu vào các bảng tạm thời toàn cục,
xử lý các truy vấn SQL (ví dụ: JOIN),
sắp xếp các bản ghi trong tập kết quả.

Mỗi thao tác này yêu cầu một lượng tài nguyên hệ thống nhất định. Bảng dưới đây cho thấy mức tiêu thụ tài nguyên theo đơn vị cường độ (1 là ít nhất, 10 là nhiều nhất):


	Đọc một trang từ đĩa	Ghi một trang vào đĩa	Đọc một trang từ bộ nhớ đệm trang	Ghi một trang vào bộ nhớ đệm trang	Đọc từ GTT	Ghi vào GTT	Sắp xếp bản ghi	Xử lý truy vấn SQL
CPU	1	1	1	1	1	1	5	10
RAM	5	5	5	5	5	5	5	2
I/O đĩa	10	10	1	1	1	1	1	1

Như bạn có thể thấy, các thao tác tốn nhiều tài nguyên nhất là những thao tác liên quan đến truy cập đĩa vì đĩa vẫn là thành phần phần cứng chậm nhất mặc dù có những tiến bộ trong những năm gần đây liên quan đến SSD.

Điều này dẫn đến một trong những cách tối ưu hóa hiệu suất hoàn toàn liên quan đến phần cứng - đưa tất cả các thao tác đọc-ghi vào RAM. Nhưng lưu ý rằng cách tiếp cận tăng bộ nhớ đệm trang không hiệu quả. Chúng tôi sẽ đề cập chi tiết vấn đề này trong phần RAM.

Các Thao Tác Được Thực Hiện Đồng Thời

Thông thường, cần phải chọn phần cứng cho một máy chủ sẽ phục vụ nhiều khách hàng, vì vậy việc hiểu cách triển khai tính song song của các thao tác là thực sự quan trọng.

Từ quan điểm của các thành phần phần cứng, chúng ta có thể nói về việc sử dụng song song CPU, đĩa và RAM. CPU hiện đại có nhiều lõi có thể thực thi các tập lệnh song song, do đó máy chủ DBMS phân phối các thao tác giữa các lõi, điều này có nghĩa là kết luận rằng CPU càng nhiều lõi thì càng có nhiều khách hàng có thể làm việc trên máy chủ này.

Từ quan điểm của đĩa, điều đó không đơn giản như vậy. Khi ổ đĩa cứng truyền thống (HDD) đọc thông tin, chúng di chuyển đầu đọc một cách vật lý trên vật liệu từ tính ở một vận tốc hữu hạn nào đó. Cơ sở dữ liệu có thể khá lớn, tức là 3 terabyte, và nếu các truy vấn SQL từ khách hàng truy cập dữ liệu của nó nằm ở các khu vực khác nhau trên đĩa song song, đầu đọc của đĩa sẽ nhảy giữa các khu vực khác nhau trên đĩa, do đó làm chậm nghiêm trọng các thao tác đọc và ghi. Điều này sẽ làm tăng đáng kể hàng đợi đĩa trong khi các tài nguyên còn lại (CPU, RAM) ở trạng thái rảnh. Tất nhiên, bộ nhớ đệm của đĩa (bộ nhớ đệm của HDD hoặc của bộ điều khiển RAID) bù đắp phần nào cho sự chậm lại này, nhưng điều đó là không đủ.

Không giống như HDD truyền thống, ổ đĩa thể rắn (SSD) ít bị suy giảm hiệu suất hơn nhiều trong trường hợp truy cập dữ liệu song song. Ưu điểm của SSD đặc biệt rõ ràng khi bạn ghi dữ liệu song song - các thử nghiệm của chúng tôi cho thấy SSD nhanh hơn 7 lần so với đĩa SATA (liên kết!). Tuy nhiên, SSD có một số vấn đề phải được tính đến trong quá trình sử dụng (xem Chọn Đĩa) để tránh chậm lại, hỏng hóc sớm và mất dữ liệu.

Các thao tác với RAM được thực hiện rất nhanh trên các máy tính hiện đại, chúng thực tế chỉ bị giới hạn bởi băng thông bus dữ liệu, vì vậy các thao tác này không đóng vai trò là nút thắt cổ chai ngay cả khi có nhiều truy vấn SQL song song.

Luồng Dữ Liệu

Trong khi thực thi các truy vấn SQL, Firebird đọc và ghi rất nhiều dữ liệu, chuyển dữ liệu giữa các mô-đun chức năng và các thành phần phần cứng tương ứng. Để xác định các nút thắt cổ chai tiềm năng, chúng ta cần hiểu cách trao đổi dữ liệu được thực hiện. Hình 2 dưới đây sẽ giúp chúng ta điều đó:

Hình 2. Luồng dữ liệu giữa RAM và bộ lưu trữ liên tục

Rõ ràng, việc chuyển dữ liệu từ bộ lưu trữ liên tục sang RAM và ngược lại là thao tác tốn thời gian nhất. Nó tạo ra hai luồng dữ liệu: đọc/ghi các trang dữ liệu từ các tệp cơ sở dữ liệu và đọc/ghi các tệp sắp xếp. Vì có thể có nhiều tệp sắp xếp và chúng có thể khá lớn, chúng có thể tạo ra tải khá nặng lên đĩa, vì vậy nên hướng các luồng đầu vào/đầu ra này đến các đĩa khác nhau.

Sao Lưu

Firebird cung cấp cho bạn hai phương pháp sao lưu: sao lưu đã xác minh với sự trợ giúp của tiện ích gbak và sao lưu gia tăng chưa xác minh với sự trợ giúp của tiện ích nbackup.

Chúng tôi khuyên bạn nên kết hợp các phương pháp sao lưu này: chạy nbackup thường xuyên (ví dụ: mỗi giờ, mỗi ngày và mỗi tuần) và tạo bản sao lưu đã xác minh mỗi đêm với sự trợ giúp của gbak.

Dù bạn sử dụng phương pháp sao lưu nào, tệp cơ sở dữ liệu được đọc (toàn bộ hoặc một phần) và bản sao lưu (đầy đủ hoặc gia tăng) được ghi. Các thao tác ghi được thực hiện tuần tự trong quá trình sao lưu, điều đó có nghĩa là các ổ cứng thông thường giá rẻ với giao diện SATA (HDD SATA) sẽ phù hợp cho việc sao lưu vì chúng ghi tuần tự khá nhanh.

Chọn Phần Cứng Phù Hợp

Bây giờ chúng ta đã có ý tưởng về cách Firebird tương tác với phần cứng, chúng ta nên đề cập đến các yếu tố ảnh hưởng đến việc lựa chọn từng thành phần cụ thể và thông số kỹ thuật của nó.

Đôi khi số liệu thống kê thực tế của một cơ sở dữ liệu cụ thể ảnh hưởng mạnh mẽ đến việc lựa chọn các thành phần phần cứng, vì vậy chúng tôi sẽ sử dụng các công cụ từ HQbird (gói phân phối chuyên nghiệp của Firebird từ IBSurgeon) để lấy các số liệu thống kê này. Bạn có thể tải phiên bản dùng thử của HQbird tại http://hqbird.com/en/hqbird/.

CPU

Khi chọn CPU, bạn nên tính đến ba điều sau:

Loại truy vấn nào chiếm ưu thế trong ứng dụng,
Số lượng kết nối hoạt động đến cơ sở dữ liệu trung bình và dưới tải cao điểm,
Phiên bản và kiến trúc Firebird.

Loại Truy Vấn Nào Chiếm Ưu Thế trong Ứng Dụng?

Firebird luôn thực thi một truy vấn trên một lõi, vì vậy các truy vấn phức tạp và được tối ưu hóa kém có thể sử dụng một lõi lên đến 100%, buộc các truy vấn khác phải chuyển sang các lõi ít tải hơn và càng nhiều lõi thì khả năng toàn bộ CPU bị sử dụng hết và người dùng nhận thấy bất kỳ sự suy giảm hiệu suất nào trong ứng dụng càng thấp.

Nếu ứng dụng chủ yếu chạy các truy vấn SQL ngắn đơn giản, tất cả các truy vấn được tối ưu hóa tốt và không có truy vấn đặc biệt nào được tạo (ví dụ: cho các báo cáo), CPU sẽ không tạo ra nút thắt cổ chai cho hiệu suất và bạn có thể chọn CPU cấp thấp với ít lõi hơn.

Nếu ứng dụng chứa trình tạo báo cáo hoặc nhiều truy vấn chậm trả về lượng dữ liệu lớn, bạn cần CPU có nhiều lõi hơn.

Số Lượng Kết Nối Hoạt Động đến Cơ Sở Dữ Liệu Trung Bình và Dưới Tải Cao Điểm

Số lượng kết nối (người dùng hoạt động) cũng ảnh hưởng đến việc lựa chọn CPU. Thật không may, ngay cả các nhà phát triển ứng dụng cũng không biết chính xác có bao nhiêu kết nối, truy vấn và giao dịch đang hoạt động tại một thời điểm cụ thể. Để có được thông tin chính xác hơn về điều này, chúng tôi khuyên bạn nên sử dụng công cụ MON$ Logger từ HQbird và chụp một vài ảnh chụp nhanh trong khi nó đang chạy, nơi bạn sẽ thấy có bao nhiêu kết nối thực sự được thiết lập.

Hình 3. MON$ Logger: số lượng kết nối

Ví dụ: ở đây bạn có thể thấy số lượng kết nối là 296. Rõ ràng, việc sử dụng CPU lõi tứ trong trường hợp này là quá lạc quan, trong khi giải pháp 24 lõi sẽ khá ổn. Bạn cũng nên đếm số lượng truy vấn chạy đồng thời vì các kết nối có thể ở trạng thái rảnh mà không có bất kỳ truy vấn SQL nào đang chạy.

Bạn có thể sử dụng tỷ lệ 10 đến 30 kết nối trên 1 lõi để ước tính sơ bộ số lõi cần thiết trong CPU của mình. 10 kết nối trên mỗi lõi cho một ứng dụng có chủ yếu là các truy vấn phức tạp và chậm, 30 kết nối trên mỗi lõi cho một ứng dụng có chủ yếu là các truy vấn đơn giản được tối ưu hóa tốt.

Phiên Bản và Kiến Trúc Firebird

Nếu bạn sử dụng Firebird phiên bản 2.5, lưu ý rằng bạn nên sử dụng kiến trúc Classic hoặc SuperClassic để có thể phân phối xử lý giữa nhiều lõi. Trong phiên bản 2.5, kiến trúc SuperServer chỉ có thể sử dụng một lõi cho một cơ sở dữ liệu, vì vậy nó không nên được sử dụng trong các hệ thống tiêu thụ nhiều tài nguyên.

Trong Firebird phiên bản 3.0, SuperServer, Classic và SuperClassic sử dụng các tính năng của CPU đa lõi. Firebird 3.0 SuperServer cho thấy hiệu suất tốt nhất.

RAM

Khi bạn chọn RAM, bạn nên chú ý đến hai điều:

mô-đun bộ nhớ phải có mã sửa lỗi (ECC RAM)
dung lượng RAM phải được tính toán chính xác

ECC RAM

ECC RAM làm giảm đáng kể số lượng lỗi xảy ra trong quá trình làm việc với bộ nhớ và nó được khuyến nghị mạnh mẽ để sử dụng trong các hệ thống công nghiệp.

Tính Toán Lượng RAM Cần Thiết

Để tính toán lượng bộ nhớ, chúng ta sẽ phải xem xét các đặc điểm riêng của các kiến trúc Firebird khác nhau. Firebird 2.5 Classic và Firebird 3.0 Classic chạy một tiến trình riêng biệt để phục vụ mỗi kết nối, SuperClassic chạy một luồng riêng cho mỗi kết nối, nhưng thực tế có cùng cấu trúc tiêu thụ bộ nhớ - mỗi kết nối có bộ nhớ đệm trang độc lập riêng.

Firebird SuperServer chạy một tiến trình với một bộ nhớ đệm trang cho tất cả các kết nối.

Do đó, các tham số sau ảnh hưởng đến tổng lượng bộ nhớ tiêu thụ:

Số lượng kết nối
Kích thước trang cơ sở dữ liệu
Kích thước siêu dữ liệu (tỷ lệ thuận với số lượng bảng, trigger, thủ tục lưu trữ, v.v.; không thể điều chỉnh; được xác định bởi việc sử dụng thực tế)
Đối với Classic và SuperClassic - trên mỗi kết nối
Đối với SuperServer - trên mỗi phiên bản của cơ sở dữ liệu đang mở
Kích thước bộ nhớ đệm trang (được xác định bởi các tham số trong tiêu đề cơ sở dữ liệu hoặc trong firebird.conf hoặc trong thuộc tính của một kết nối cụ thể)
Đối với Classic và SuperClassic - trên mỗi kết nối
Đối với SuperServer - trên mỗi phiên bản của cơ sở dữ liệu đang mở
Kích thước bộ nhớ đệm sắp xếp (được xác định bởi tham số trong firebird.conf). Lưu ý rằng bộ nhớ cho việc sắp xếp không được cấp phát ngay lập tức mà chỉ khi cần thiết.
Đối với Classic - trên mỗi kết nối
Đối với SuperServer và SuperClassic - trên mỗi tiến trình (tức là một bộ nhớ đệm sắp xếp)
Đối với Classic/SuperClassic - kích thước bảng khóa (thường nhỏ nên chúng ta sẽ bỏ qua trong tính toán).

Công ty IBSurgeon đã thực hiện một số thử nghiệm và thu được một tập hợp các giá trị tối ưu cho số lượng trang trong bộ nhớ đệm trang Firebird:

Classic/SuperClassic - từ 256 đến 2000 trang
SuperServer 2.5 - 10000 trang
SuperServer 3.0 - 100000 trang

Dựa trên các thử nghiệm này, chúng tôi đã tạo ra các tệp cấu hình Firebird được tối ưu hóa cho các máy chủ có 4-6 GB bộ nhớ. Bạn có thể tải xuống tại đây: /vi/optimized-firebird-configuration/

Công Thức Tính Lượng RAM Cần Thiết

Dưới đây bạn có thể thấy các công thức được sử dụng để ước tính lượng bộ nhớ gần đúng mà Firebird sẽ yêu cầu. Mức tiêu thụ bộ nhớ thực tế có thể khác vì ước tính này không tính đến lượng bộ nhớ cần thiết cho siêu dữ liệu, cho mặt nạ bit của các chỉ mục, v.v., có thể làm tăng mức tiêu thụ bộ nhớ. Tuy nhiên, cũng giả định rằng bộ nhớ sắp xếp sẽ được sử dụng tối đa trong tất cả các kết nối, điều này thường không xảy ra.

Khi cơ sở dữ liệu của bạn đã được sử dụng, bạn có thể xem lượng bộ nhớ trung bình được sử dụng bởi tiến trình Firebird (với sự trợ giúp của TaskManager hoặc ProcessExplorer).

Ước tính cho Classic:

Số lượng kết nối * ( (Số trang trong bộ nhớ đệm * Kích thước trang) + Kích thước bộ nhớ đệm sắp xếp )

Ví dụ cho Classic: giả sử chúng ta mong đợi 100 người dùng hoạt động, kích thước trang cơ sở dữ liệu được đặt là 8 KB và số trang trong bộ nhớ đệm trang được đặt là 256, kích thước bộ nhớ đệm sắp xếp được tăng từ 8 MB (giá trị mặc định cho Classic và SuperClassic) lên 64 MB:

((256.8 KB)+64) = 6600 MB

Ước tính cho SuperClassic:

Số lượng kết nối * (Số trang trong bộ nhớ đệm * Kích thước trang) + Kích thước bộ nhớ đệm sắp xếp

Ví dụ cho SuperClassic: 100 người dùng, kích thước trang cơ sở dữ liệu là 8 KB, số trang trong bộ nhớ đệm trang là 256, kích thước bộ nhớ đệm sắp xếp là 1024 MB

100.(256.8 KB) + 1024 MB = 2024 MB

Ước tính cho SuperServer:

(Số trang trong bộ nhớ đệm * Kích thước trang) + Kích thước bộ nhớ đệm sắp xếp

Ví dụ cho SuperServer (Firebird 2.5): 1 cơ sở dữ liệu, 100 người dùng, kích thước trang cơ sở dữ liệu là 8 KB, số trang trong bộ nhớ đệm trang là 10000, kích thước bộ nhớ đệm sắp xếp là 1024 MB:

(10000.8 KB) + 1024 = 1102 MB

Ví dụ cho SuperServer (Firebird 3.0): 1 cơ sở dữ liệu, 100 người dùng, kích thước trang cơ sở dữ liệu là 8 KB, số trang trong bộ nhớ đệm trang là 100000, kích thước bộ nhớ đệm sắp xếp là 1024 MB:

(100000.8 KB) + 1024 = 1805 MB

“Bộ Nhớ Dư Thừa”

Firebird thường bị đổ lỗi cho việc sử dụng bộ nhớ không hiệu quả - khi tiến trình đang chạy của máy chủ tiêu thụ một lượng RAM nhỏ và phần bộ nhớ còn lại được cho là không được sử dụng.

Thực tế, điều này không đúng. Kết luận này về cơ bản nằm ở sự hiểu lầm về cách hoạt động của cơ chế bộ nhớ đệm Firebird và sự không hoàn hảo của các công cụ giám sát hệ điều hành.

Trước hết, bạn phải hiểu rõ rằng Firebird sử dụng rộng rãi bộ nhớ đệm tệp của hệ điều hành. Khi một trang được tải vào bộ nhớ đệm trang Firebird, nó đi qua bộ nhớ đệm tệp của hệ điều hành. Khi Firebird dỡ một trang khỏi bộ nhớ đệm của nó, hệ điều hành vẫn giữ phần này của cơ sở dữ liệu trong RAM của nó miễn là nó có đủ bộ nhớ trống.

Hình 4. Các cấp độ bộ nhớ đệm: Firebird, hệ điều hành và lưu trữ

Tuy nhiên, nếu bạn chỉ nhìn vào, hệ điều hành không hiển thị bộ nhớ được cấp phát cho bộ nhớ đệm tệp như đang được sử dụng. Ví dụ, đây là tình huống điển hình về phân bổ bộ nhớ khi máy chủ Firebird đang chạy, như được hiển thị bởi TaskManager:

Hình 5. TaskManager không hiển thị việc sử dụng bộ nhớ đệm tệp

Có vẻ như chỉ có 6,3 GB trong số 16 GB được sử dụng.

Tuy nhiên, nếu bạn sử dụng công cụ RAMMap (từ SysInternals của Microsoft), mọi thứ trông hợp lý hơn nhiều:

Hình 6. RAMMap hiển thị chi tiết về việc sử dụng bộ nhớ: các tệp được ánh xạ là các cơ sở dữ liệu được lưu trong bộ nhớ đệm

Các tệp cơ sở dữ liệu (dbw350.fb252x64.fdb và dbw250.fb252x64.fdb) được hệ điều hành lưu trong bộ nhớ đệm và chiếm toàn bộ bộ nhớ mà TaskManager khai báo là trống:

Hình 7. RAMMap: chi tiết về việc sử dụng bộ nhớ đệm tệp

Do đó, chúng tôi kết luận rằng hệ điều hành sử dụng hiệu quả toàn bộ bộ nhớ khả dụng để lưu trữ cơ sở dữ liệu trong bộ nhớ đệm cho đến khi tải hoàn toàn cơ sở dữ liệu vào bộ nhớ.

Hệ Thống Đĩa

Cấu hình chính xác của hệ thống đĩa đóng vai trò quan trọng trong việc lựa chọn và cấu hình phần cứng cho Firebird vì bất kỳ sai sót nào trong bước này sẽ dẫn đến các sự cố lớn khó khắc phục.

Các Đĩa Riêng Biệt Cho Mọi Thứ

Để giảm sự cạnh tranh cho đầu vào/đầu ra đĩa giữa các thao tác với tệp cơ sở dữ liệu và giảm khả năng mất đồng thời cơ sở dữ liệu và bản sao lưu, nên có ba đĩa khác nhau (hoặc mảng raid): một cho cơ sở dữ liệu, một cho các tệp tạm thời và một để tạo và lưu trữ các bản sao lưu.

Khi chúng ta nói “các đĩa riêng biệt”, điều đó có nghĩa là các luồng dữ liệu phải đi qua các kênh đầu vào/đầu ra khác nhau. Nếu bạn tạo ba đĩa logic trên một đĩa vật lý, sẽ không có sự gia tăng hiệu suất. Tuy nhiên, nếu bạn bố trí ba đĩa logic trên một thiết bị lưu trữ dữ liệu được trang bị bộ điều khiển đa kênh, hiệu suất rất có thể sẽ được tăng lên vì thiết bị có thể phân phối các luồng dữ liệu giữa các bộ điều khiển. Đôi khi việc dành riêng một đĩa riêng để lưu trữ các tệp hệ điều hành và tệp hoán đổi của hệ điều hành được cho là làm tăng hiệu suất.

SSD Cho Cơ Sở Dữ Liệu

SSD là lựa chọn tốt nhất để làm việc với cơ sở dữ liệu vì chúng đảm bảo khả năng mở rộng tuyệt vời trong quá trình đầu vào/đầu ra song song. Bạn bắt buộc phải sử dụng đĩa doanh nghiệp với số chu kỳ đọc/ghi tăng lên, nếu không rất có thể bạn sẽ mất dữ liệu do sự cố của SSD.

Một thời gian trước, SSD dễ bị mài mòn tăng lên trong trường hợp có ít không gian trống còn lại trên đĩa (dưới 30%). Nói một cách đơn giản, mỗi lần sửa đổi trên SSD được ghi vào một ô trống mới nên việc thiếu không gian trống dẫn đến sự mài mòn tăng lên của các ô còn trống và tuổi thọ của đĩa bị rút ngắn.

Các nhà sản xuất bộ điều khiển SSD hiện đại tuyên bố rằng vấn đề này đã được giải quyết bằng cách di chuyển dữ liệu tĩnh một cách phòng ngừa và hiện nay sự mài mòn của các ô ít nhiều đã được cân bằng. Tuy nhiên, các thông số kỹ thuật và thuật toán hoạt động chính xác của SSD được các nhà sản xuất giữ bí mật nên chúng tôi vẫn khuyên bạn nên để trống 30% dung lượng trên SSD cũng như giảm tuổi thọ dự kiến của chúng và lên kế hoạch thay thế không ít hơn một lần trong ba năm.

Giả sử kích thước cơ sở dữ liệu của bạn hiện là 100 GB, nó tăng 1 GB mỗi tháng. Trong trường hợp này, bạn không nên mua SSD có kích thước tối thiểu (120 GB), mà tốt hơn là chọn thiết bị tiếp theo trong dòng sản phẩm - 250 GB. Đồng thời, việc mua SSD 512 gigabyte sẽ là lãng phí tiền vì nên thay đĩa sau ba năm.

Thực hành tốt nhất là dành riêng một SSD chỉ để làm việc với cơ sở dữ liệu vì bất kỳ thao tác đầu vào/đầu ra nào cũng làm giảm tuổi thọ của đĩa.

Đĩa Cho Các Tệp Tạm Thời

Vì các tệp tạm thời chỉ xuất hiện trên đĩa khi không có đủ lượng RAM, cách tốt nhất là tránh tình huống này hoàn toàn, tất nhiên. Có thể đánh giá số lượng và kích thước của các tệp tạm thời trong hệ thống sản xuất chỉ bằng cách giám sát thư mục chứa các tệp tạm thời. FBDataGuard từ gói phân phối HQbird thực hiện loại giám sát đó. Khi bạn biết có bao nhiêu tệp sắp xếp tạm thời được tạo trên đĩa và khi nào chúng được tạo, bạn sẽ có thể tăng lượng RAM và thay đổi cấu hình trong firebird.conf.

Trong mọi trường hợp, Firebird yêu cầu bạn chỉ định thư mục nơi các tệp tạm thời sẽ được lưu trữ. Thông thường, giá trị mặc định được giữ nguyên, tức là thư mục tệp tạm thời của hệ điều hành được sử dụng. Nếu RAM trống đủ, đây là một lựa chọn tốt.

Tuy nhiên, có một vấn đề quan trọng khác liên quan đến vị trí của các tệp tạm thời trên đĩa - đó là việc tạo chỉ mục khi bạn khôi phục một bản sao lưu đã được xác minh (được tạo bằng tiện ích gbak). Khi một chỉ mục được tạo, một tệp tạm thời chứa tất cả các khóa từ chỉ mục này cũng được tạo. Nếu cơ sở dữ liệu khá lớn, kích thước của chỉ mục cho một số bảng lớn cũng có thể khá lớn. Ví dụ, chỉ mục của bảng lớn nhất chứa 3,2 tỷ bản ghi trong cơ sở dữ liệu 1 terabyte là 29 GB, nhưng cần 180 GB không gian trống để tạo chỉ mục này:

Để ngăn chặn việc thiếu không gian trống trên đĩa hệ thống, có thể chỉ định thêm một đĩa nữa làm không gian dự phòng bổ sung trong firebird.conf:

TempDirectories =C:\temp; H:\Temp

Nếu không có không gian trên đĩa đầu tiên, Firebird sẽ tiếp tục sử dụng đĩa thứ hai cho các tệp tạm thời và cứ tiếp tục như vậy.

HDD Cho Các Bản Sao Lưu

Các HDD thông thường với giao diện SATA hoặc nSAS sẽ phù hợp để tạo và lưu trữ các bản sao lưu. Chúng đảm bảo các thao tác ghi và đọc tuần tự nhanh cho các tệp sao lưu và đủ rẻ để không phải tiết kiệm kích thước và giữ nhiều bản sao lưu.

Các đĩa cho bản sao lưu phải luôn có thêm không gian trống trên chúng: kích thước của bản sao lưu mới nhất + 10%. Trong trường hợp này, có thể tạo một bản sao lưu mới, đảm bảo quá trình sao lưu hoàn tất thành công (quá trình này có thể mất vài giờ đối với cơ sở dữ liệu có kích thước vài terabyte) và chỉ sau đó mới xóa bản sao lưu trước đó.

Nếu bạn xóa bản sao lưu trước đó trước khi bản sao lưu mới được tạo, có thể sẽ không có bản sao lưu mới nào được tạo trong khi bản cũ đã bị xóa và cơ sở dữ liệu sẽ bị hỏng, ví dụ, do sự cố đĩa.

Nếu bạn sử dụng phương pháp sao lưu được khuyến nghị ở trên (sự kết hợp giữa sao lưu tăng dần ba cấp và sao lưu đã được xác minh mỗi ngày một lần chỉ lưu trữ một bản mới nhất), hãy sử dụng công thức sau để tính không gian tối thiểu cho sao lưu:

Kích_thước_cơ_sở_dữ_liệu*3+0.2.Kích_thước_cơ_sở_dữ_liệu

Hãy xem xét ví dụ tính toán không gian cần thiết cho sao lưu sau đây:

Giả sử chúng ta có một cơ sở dữ liệu 100 GB mà chúng ta lưu trữ sao lưu tăng dần ba cấp (tuần-ngày-giờ - một bản mỗi cấp) và một bản sao lưu đã được xác minh hàng ngày. Trong trường hợp này, các bản sao lưu sẽ chiếm không gian sau:

Nbackup_level_0.weekly - 100 GB
Nbackup_level_1.daily - 5 GB (xấp xỉ)
Nbackup_level_2.hourly - 200 MB (xấp xỉ)
Bản sao lưu đã được xác minh hàng ngày - 100 GB (xấp xỉ)
Cộng thêm bạn cần dự trữ 110 GB để có thể tạo bản sao lưu tiếp theo.

Tổng - 316 GB.

! Kích thước của tệp gia tăng cấp đầu tiên hoặc cao hơn phụ thuộc vào số trang được sửa đổi kể từ lần chạy nbackup cuối cùng. Kích thước của các tệp này chỉ có thể được xác định bằng thực nghiệm vì lượng thay đổi trong cơ sở dữ liệu phụ thuộc vào các ứng dụng.

Tất nhiên, việc ước tính không gian cho bản sao lưu cần tính đến khả năng tăng bất thường về kích thước của cơ sở dữ liệu và tương ứng tăng lượng không gian trống, nếu không quá trình sao lưu có thể bị gián đoạn bất ngờ do thiếu không gian.

Tự nhiên, các công cụ sao lưu thông minh (FBDataGuard từ HQbird) sẽ nhận thấy tình trạng thiếu không gian cho các bản sao lưu và gửi thông báo tương ứng đến quản trị viên.

Ổ cứng cho Cơ sở dữ liệu

SSD có thể trở thành giải pháp quá đắt đỏ hoặc cơ sở dữ liệu có thể quá lớn và bạn sẽ phải sử dụng các phương pháp ít tốn kém hơn. Trong trường hợp này, bạn nên sử dụng ổ cứng HDD với giao diện SAS. Nếu không thể, hãy sử dụng ổ SATA với giao diện nSAS hoặc lựa chọn rẻ nhất - ổ SATA thông thường.

Để tăng tốc độ (và cả độ tin cậy - xem bên dưới) của các ổ cứng, bạn nên kết hợp chúng thành RAID10. RAID10 là sự kết hợp của các khối nhân bản (RAID1) và khối phân chia (RAID0). Một bộ điều khiển RAID tốt và được cấu hình đúng với bộ nhớ đệm lớn là một giải pháp thay thế tốt cho SSD.

Độ tin cậy và RAID

Tất nhiên, cần phải tăng độ tin cậy của hệ thống đĩa bằng cách kết hợp các đĩa thành RAID trong tất cả các phương án đã đề cập ở trên (ngoại trừ đĩa dành riêng cho tệp tạm thời).

• Đối với SSD, hãy đảm bảo bạn sử dụng RAID1 - tức là hai đĩa nhân bản có các thay đổi được ghi đồng thời, giúp giảm đáng kể khả năng mất toàn bộ dữ liệu. RAID 10 bao gồm các SSD rất có thể sẽ dư thừa vì bus RAID sẽ giới hạn thông lượng. Ví dụ, giao diện 6 Gbit/s có thông lượng 600 megabyte mỗi giây trong khi các SSD đơn hiện đại đã đạt đến tốc độ này. Do đó, chúng ta sẽ nhận được giới hạn tương tự là 600 MB/s cho RAID 10.

Ngoại trừ việc bạn có thể sử dụng PCI Express 3.0 để kết hợp các SSD thành RAID 10 vì thông lượng của bus này đã là 16 gigabit mỗi giây trở lên.

• Nếu bạn sử dụng HDD cho mục đích sao lưu, chỉ cần sử dụng RAID1 để đảm bảo an toàn cho các bản sao lưu và tốc độ đọc/ghi chấp nhận được.

• Các HDD dùng cho cơ sở dữ liệu nên được kết hợp thành RAID10 (ít nhất 4 đĩa) để cung cấp sự kết hợp tối ưu giữa chi phí, độ tin cậy và hiệu suất. Một số người dùng cũng sử dụng RAID5, hy sinh hiệu suất để có thêm dung lượng.

Cấu hình RAID cho Firebird

Trước hết, bạn nên đảm bảo có bộ pin dự phòng (BBU) được sạc đầy trong RAID. Nếu không có bộ pin này, hầu hết RAID chuyển sang chế độ ghi an toàn (bộ nhớ đệm đĩa bị vô hiệu hóa hoàn toàn) cung cấp tốc độ đầu vào/đầu ra thấp hơn cả ổ SATA thông thường!

Thực tế này là nguyên nhân gây ra hầu hết các thông điệp thất vọng gửi đến bộ phận hỗ trợ kỹ thuật từ những người dùng đã mua một máy chủ đắt tiền và phát hiện ra rằng nó hoạt động chậm hơn cả máy tính để bàn. Thật không may, một số nhà cung cấp không bao gồm bộ pin theo mặc định, vì vậy đây là điều đầu tiên bạn nên kiểm tra và khắc phục nếu cần.

Sau đó, bạn nên cấu hình bộ nhớ đệm đọc và ghi. Thông thường, bộ nhớ đệm bị vô hiệu hóa theo mặc định và nếu bạn muốn làm cho RAID nhanh hơn, bạn cần bật bộ nhớ đệm.

Bên cạnh việc bật bộ nhớ đệm, bạn nên kiểm tra cách nó hoạt động - có thể là ghi xuyên (write through) và ghi lại (write back). Cách nhanh để làm việc với bộ nhớ đệm là ghi lại - trong trường hợp này, mọi thay đổi được ghi vào bộ điều khiển bộ nhớ đệm và sau một lúc, trực tiếp vào đĩa.

Bạn có thể sử dụng các công cụ từ nhà sản xuất đi kèm với RAID để kiểm tra bộ pin, bộ nhớ đệm và chế độ.

Các bộ điều khiển RAID hiện đại cũng có thể tinh chỉnh bộ nhớ đệm - nó có thể được điều chỉnh để hỗ trợ đọc hoặc ghi. Thông thường, nó được chia 50%/50% cho đọc và ghi.

Để tìm hiểu chính xác cách cấu hình bộ nhớ đệm, bạn cũng có thể sử dụng công cụ MON$ Logger từ gói phân phối nâng cao HQbird. Nó hiển thị tỷ lệ các thao tác đọc và ghi so với nhau (tổng hợp từ thời điểm kết nối đầu tiên đến máy chủ):

Hình 8. HQbird MON$Logger: tỷ lệ đọc/ghi

Như bạn có thể thấy, trong ví dụ này có nhiều thao tác đọc hơn nhiều so với thao tác ghi, vì vậy cấu hình bộ điều khiển RAID cho 80% thao tác đọc và 20% thao tác ghi là hợp lý.

SAN và cơ sở dữ liệu

Các bộ lưu trữ tích hợp đã trở nên phổ biến gần đây. Chúng bao gồm một mảng đĩa có thể tùy chỉnh linh hoạt (tất cả các loại RAID) với các tính năng bộ nhớ đệm tiên tiến. Thông thường, SAN có nhiều bộ điều khiển đầu vào/đầu ra, giúp có thể phục vụ nhiều máy chủ đồng thời và hoạt động khá nhanh.

Nhiều tổ chức mua SAN và sử dụng chúng trong công việc với cơ sở dữ liệu Firebird. Nếu SAN được cấu hình đúng, có thể đạt được hiệu suất tốt. Bạn nên tính đến các vấn đề sau nếu sử dụng SAN:

Phải có nhiều bộ điều khiển đĩa hiệu suất cao cung cấp trao đổi dữ liệu đa kênh.
Phải có bộ pin dự phòng (BBU) nếu được thiết kế cung cấp.
Các đĩa cơ sở dữ liệu phải được kết hợp thành RAID10.
Bộ nhớ đệm phải được bật, chế độ ghi phải được chuyển sang ghi lại (write back).
Nếu nhiều máy tính được kết nối với SAN, mỗi máy phải có bộ điều khiển riêng.
Các trình điều khiển SAN mới nhất được cài đặt. Chúng tôi đã gặp các trường hợp trình điều khiển mới hơn cung cấp tăng 30% hiệu suất.
Nếu có nhiều đĩa logic trên SAN (cho cơ sở dữ liệu, bản sao lưu, hệ điều hành), chúng có các kênh đầu vào/đầu ra khác nhau. Cố gắng sử dụng một kênh cho tất cả các đĩa cùng nhau sẽ dẫn đến hiệu suất thấp hơn.
Tương tự, nếu nhiều máy chủ và cơ sở dữ liệu sử dụng SAN cùng một lúc, hiệu suất có thể thấp hơn do băng thông của các bộ điều khiển đầu vào/đầu ra tăng lên.
Các cách kết hợp thường được sử dụng - khi hệ điều hành và tệp tạm thời được lưu trữ trên đĩa cục bộ trong khi cơ sở dữ liệu và tệp sao lưu được lưu trữ trên SAN.

Thông thường, SAN được sử dụng như “hai máy chủ - một SAN” để tạo một cụm chống lỗi. Cần lưu ý rằng cụm như vậy chỉ có thể giải quyết các vấn đề liên quan đến lỗi phần cứng trên một trong các máy chủ bằng cách chuyển sang máy chủ thứ hai ngay lập tức. Nếu vấn đề liên quan đến SAN hoặc chính cơ sở dữ liệu, giải pháp này sẽ không giúp ích.

Để xây dựng một giải pháp thực sự chống lỗi, bạn nên sử dụng các giải pháp nhân bản dữ liệu giữa hai phiên bản cơ sở dữ liệu. Bạn có thể liên hệ [email protected] để tìm hiểu thêm các giải pháp có sẵn cho Firebird.

Kết luận và Khuyến nghị Tóm tắt

Hãy tóm tắt các kết luận và khuyến nghị cho Firebird liên quan đến phần cứng.

Phải sử dụng CPU đa lõi để phục vụ một số lượng lớn người dùng.
Lượng RAM tối thiểu được tính dựa trên số lượng người dùng và cấu hình cơ sở dữ liệu, lượng RAM vượt quá sẽ được hệ điều hành sử dụng hiệu quả để lưu trữ tệp cơ sở dữ liệu.
Sử dụng các đĩa riêng biệt cho cơ sở dữ liệu, tệp tạm thời và tệp sao lưu.
Nên sử dụng SSD cho cơ sở dữ liệu.
Dự trữ ít nhất 30% không gian trống trên SSD.
Nên dành riêng một đĩa cho cơ sở dữ liệu.
Sử dụng SSD cấp doanh nghiệp (với nhiều chu kỳ ghi/đọc).
Đảm bảo bạn sử dụng RAID.
Đối với SSD - RAID 1, đối với HDD - RAID10, đối với HDD sao lưu - RAID1. i. SAS, SATA, nSAS
Đảm bảo pin RAID có và được sạc đầy.
Đảm bảo nó được chuyển sang chế độ ghi lại (write back).
Một số bộ điều khiển RAID đã có kích thước bộ nhớ đệm được cấu hình sẵn, ví dụ: 75% cho đọc, 25% cho ghi, hoặc 50/50, v.v. Vì vậy, cần cài đặt MON$Logger - phần mềm sẽ kiểm soát các tham số RAID, tìm tỷ lệ đọc/ghi và thay đổi cài đặt RAID.
Có cả ưu và nhược điểm khi sử dụng SAN. Để tận dụng tối đa, bạn nên cấu hình SAN đúng cách.
Để xây dựng một giải pháp chống lỗi, bạn cần sử dụng các giải pháp có bản sao chạy trên các máy chủ khác nhau.

Liên hệ

Công ty IBSurgeon/IBase.ru đã phát triển gói phân phối nâng cao HQbird cho doanh nghiệp, cung cấp hỗ trợ kỹ thuật phức tạp cho Firebird và phát triển các gói phân phối tùy chỉnh cũng như giải quyết các vấn đề phức tạp khác.

IBSurgeon cũng cung cấp dịch vụ Tối ưu hóa Firebird để cải thiện hiệu suất cơ sở dữ liệu Firebird.

Liên hệ với chúng tôi: [email protected]