Các chuyên gia của Oracle tại Dell Technologies thường xuyên được khách hàng thuê để trợ giúp về việc định cỡ máy chủ cơ sở dữ liệu (DB). Tức là định cỡ các máy chủ DB độc lập hoặc là một phần của hệ thống VxRail hoặc PowerFlex. 

Kích thước máy chủ rất quan trọng vì nó giúp đảm bảo số lượng lõi CPU phù hợp với nhu cầu khối lượng công việc của bạn, mang lại hiệu suất tối ưu và giúp quản lý chi phí cấp phép phần mềm Oracle DB. 

Hiểu tần số CPU

Khi định cỡ máy chủ cho Oracle DB, tần số CPU rất quan trọng. Theo tần số CPU, chúng ta đang đề cập đến thời gian chu kỳ CPU, về cơ bản có thể được coi là thời gian để CPU thực hiện một lệnh đơn giản, ví dụ: lệnh Bổ sung . 

Trong bài đăng trên blog này, chúng tôi sẽ sử dụng số liệu tần số CPU cơ bản, là tần số mà CPU sẽ chạy nếu các tùy chọn tăng tốc turbo và quản lý nguồn bị tắt trong BIOS hệ thống. 

Do đó, trọng tâm trong quá trình định cỡ là: 

• Giao dịch đơn luồng
• Hiệu suất dựa trên máy chủ tốt nhất trên mỗi phiên DB

Việc đóng gói càng nhiều lõi CPU càng tốt vào một máy chủ sẽ tăng khả năng xử lý khối lượng công việc tổng hợp của máy chủ nhiều hơn là cải thiện hiệu suất phiên trên mỗi DB. Hơn nữa, trong hầu hết các trường hợp, máy chủ chạy Oracle không yêu cầu hơn 40 lõi CPU. Việc sử dụng CPU có tần số cơ bản cao nhất sẽ mang lại hiệu suất tốt nhất cho mỗi phiên DB. 

Tại sao nên sử dụng CPU tần số 3.x GHz?  

Thời gian chu kỳ CPU về cơ bản là thời gian cần thiết để thực hiện một lệnh đơn giản, ví dụ: lệnh Cộng . Thời gian chu kỳ CPU 3.x GHz thấp hơn trên CPU có tần số cao hơn: 

• Thời gian chu kỳ CPU 2,3 GHz là 0,43 ns
• Thời gian chu kỳ CPU 3,4 GHz là 0,29 ns

CPU 3.x GHz đạt được mức giảm thời gian chu kỳ khoảng 33% với CPU tần số cơ bản cao hơn. 

Mặc dù một nano giây có vẻ như là một khoảng thời gian cực kỳ ngắn, nhưng trong môi trường làm việc DB điển hình, những nano giây đó sẽ cộng lại. Ví dụ: nếu một DB đang thực hiện hơn 3.000.000 lượt đọc logic mỗi giây trong khi vẫn thực hiện tất cả các công việc khác trên máy chủ thì tốc độ có thể bị ảnh hưởng.

Oracle DB thực hiện một khối lượng xử lý cực lớn dựa trên máy chủ, ngốn hết chu kỳ CPU. Ví dụ:

1. Duyệt qua chuỗi bộ đệm bộ đệm (CBC)
   1. CBC là tập hợp các nhóm băm và danh sách liên kết nằm trong bộ nhớ máy chủ.
   2. Chúng được sử dụng để định vị khối DB trong bộ đệm đệm của máy chủ, sau đó tìm hàng và cột cần thiết mà truy vấn cần.
2. Thứ tự SQL bằng cách xử lý
   1. Việc sắp xếp và/hoặc nhóm tập hợp kết quả SQL giúp bộ nhớ máy chủ tạo tập hợp kết quả theo thứ tự mà người dùng muốn xem.
3. Phân tích cú pháp SQL
   1. Trước khi bắt đầu một câu lệnh SQL, nó phải được phân tích cú pháp. 
   2. CPU được sử dụng để phân tích cú pháp mềm và cứng.
4. PLSQL 
   1. PLSQL là logic thủ tục mà ứng dụng sử dụng để chạy logic IF-THEN-ELSE và DO-WHILE. Đó là logic ứng dụng trên máy chủ DB.
5. Xâu chuỗi một khối DB vừa đọc từ bộ lưu trữ
   1. Khi một khối DB mới được đọc từ bộ lưu trữ, nó phải được đặt trên CBC và bộ nhớ đệm được “cấp phát” cho nội dung của nó.
6. Đăng nhập và đăng xuất phiên DB
   1. Phiên đăng nhập và đăng xuất sẽ phân bổ và hủy phân bổ các vùng bộ nhớ để phiên DB chạy.
7. ACO – Tùy chọn nén nâng cao 
   1. ACO đang loại bỏ dữ liệu cột giống hệt nhau trong khối DB – một lần nữa, nhiều CPU và RAM hơn sẽ hoạt động để đi qua bộ nhớ máy chủ nhằm loại bỏ dữ liệu dư thừa.
8. TDE – Mã hóa dữ liệu minh bạch 
   1. TDE mã hóa và giải mã dữ liệu trong bộ nhớ máy chủ khi người dùng truy cập – trên dữ liệu lớn Cần thêm/Cập nhật CPU để mã hóa dữ liệu trong quá trình giao dịch.

Tất cả bộ xử lý dựa trên máy chủ này điều khiển việc thực thi lệnh CPU và truy cập bộ nhớ (DIMM từ xa/cục bộ và bộ nhớ đệm L1, L2 và L3). Khi có hàng triệu thao tác này xảy ra mỗi giây, nó hỗ trợ nhu cầu CPU nhanh nhất để hoàn thành việc thực thi lệnh CPU trong khoảng thời gian ngắn nhất. Thời gian thực hiện nano giây tăng lên.

Hãy nhớ rằng, hệ điều hành máy chủ và bản thân CPU là:

1. Chạy nhiều tiến trình bộ nhớ nền hỗ trợ truy cập SGA và PGA
2. Sử dụng chu trình CPU để duyệt qua các địa chỉ bộ nhớ nhằm tìm và di chuyển dữ liệu mà phiên DB cần
3. Hoạt động ngầm để chuyển các dòng bộ đệm từ nút NUMA sang nút NUMA, DIMM sang lõi CPU và giao thức Snoopy/MESI hoạt động để giữ cho các dòng bộ đệm không đồng bộ hóa

Cuối cùng, các quy trình này tiêu tốn một số chu kỳ CPU bổ sung ngoài những gì DB đang tiêu thụ, làm tăng thêm nhu cầu về CPU nhanh nhất cho khối lượng công việc DB của chúng tôi.

Kiểm tra đọc logic SLOB:

Khuyến nghị 3.x GHz dựa trên nhiều bài kiểm tra đọc logic khác nhau của Oracle được thực hiện với một khách hàng sử dụng nhiều mẫu CPU Intel khác nhau trong cùng một dòng. Mục tiêu của khách hàng là tìm ra CPU thực hiện số lần kiểm tra đọc logic mỗi giây cao nhất để hỗ trợ một ứng dụng quan trọng chủ yếu chạy các truy vấn đơn luồng (chẳng hạn như không có PQ – Truy vấn song song). 

Mỗi thử nghiệm đều cho thấy CPU có tần số cơ bản cao hơn hoạt động tốt hơn CPU có tần số cơ bản thấp hơn trên cơ sở lõi mỗi CPU chạy các thử nghiệm đọc logic SLOB (nghĩa là không thực hiện I/O vật lý, tất cả xử lý dựa trên máy chủ – chỉ sử dụng CPU , Bộ nhớ đệm, DIMM và truy cập NUMA từ xa).

Trong các thử nghiệm được thực hiện, điểm so sánh giữa các CPU khác nhau và các thử nghiệm của chúng là số lần đọc logic mỗi giây trên mỗi lõi CPU. Hơn nữa, máy chủ đã dành riêng 100% cho quá trình thử nghiệm của chúng tôi và không thực hiện I/O vật lý nào cho các giao dịch để tránh đưa ra thời gian phản hồi I/O vật lý trong kết quả.

Hình ảnh sau đây mô tả một số ví dụ từ nhiều lần chạy thử nghiệm bằng cách sử dụng một luồng SLOB duy nhất (phiên DB) và số lần đọc logic mỗi giây được ghi lại cho mỗi thử nghiệm. 

Đường cơ sở của CPU là E5-4627 v2, có tần số cơ bản 3,3 GHz, nhưng có kênh QPI 7,2GT và 4 x DDR3-1866 DIMM, so với CPU Skylake có UPI 10,2GT và 6 x DDR4-2666 DIMM.

Tại sao có sự khác biệt về số lần đọc logic mỗi giây giữa lần chạy thử nghiệm của cùng một mẫu CPU trên cùng một máy chủ? Vì SLOB chạy cấu hình khối DB đọc ngẫu nhiên dẫn đến ít nhiều khối DB được tìm thấy trên nút NUMA cục bộ nên phiên DB đang chạy trong các thử nghiệm khác nhau. Do đó, ở những nơi có ít khối DB hơn, nút NUMA từ xa phải chuyển các khối DB qua UPI sang nút NUMA cục bộ, việc này cần có thời gian để hoàn thành.

Nếu bạn vẫn đang thắc mắc liệu Dell Technologies có thể giúp bạn tìm được CPU và máy chủ PowerEdge phù hợp cho khối lượng công việc Oracle của mình hay không, hãy xem xét những điều sau:

• Dell có nhiều mẫu máy chủ PowerEdge để lựa chọn, tất cả đều cung cấp khả năng hỗ trợ các nhu cầu khối lượng công việc cụ thể.
• Máy chủ Dell PowerEdge cho phép bạn chọn từ một số kiểu CPU và kích cỡ RAM của Intel và AMD.
• Các chuyên gia Oracle tại Dell Technologies có thể thực hiện đánh giá khối lượng công việc AWR để đảm bảo bạn có được máy chủ PowerEdge, mẫu CPU và cấu hình RAM phù hợp để đạt được hiệu suất Oracle tối ưu. 

Bản tóm tắt

Nếu phiên trên mỗi DB, hiệu suất dựa trên máy chủ là quan trọng đối với bạn và doanh nghiệp của bạn thì CPU cũng quan trọng. Luôn sử dụng CPU có tần số cơ bản cao nhất có thể để đáp ứng nhu cầu về điện năng của CPU và duy trì thời gian chu kỳ nhanh hơn cho hiệu suất của Oracle DB.  

Nếu bạn cần thêm thông tin hoặc muốn thảo luận thêm về chủ đề này, chuyên gia Dell Oracle sẵn sàng giúp phân tích ứng dụng và môi trường cơ sở dữ liệu của bạn, đồng thời đề xuất các mẫu máy chủ CPU và PowerEdge phù hợp để đáp ứng nhu cầu của bạn. Liên hệ với đại diện Dell của bạn để biết thêm thông tin hoặc gửi email cho chúng tôi theo địa chỉ askaworkloadspecialist@dell.com