Cơ sở dữ liệu điểm chuẩn 101 - phần 1

Điểm chuẩn là một trong những hoạt động mà người quản trị cơ sở dữ liệu thực hiện. Bạn chạy chúng để xem phần cứng của bạn hoạt động như thế nào, bạn chạy chúng để xem ứng dụng và cơ sở dữ liệu của bạn hoạt động cùng nhau như thế nào dưới áp lực. Bạn chạy chúng trong nhiều tình huống khác nhau. Hãy nói một chút về chúng, những thách thức bạn sẽ phải đối mặt là gì, những vấn đề bạn nên tránh là gì.

Các loại điểm chuẩn

Mỗi điểm chuẩn đều khác nhau. Chúng phục vụ các mục đích khác nhau và nó phải được tính đến khi bạn định chạy một. Nói chung, bạn có thể xác định hai loại điểm chuẩn chính:điểm chuẩn tổng hợp và, hãy gọi nó là điểm chuẩn "thế giới thực".

Điểm chuẩn tổng hợp thường là các công cụ mô phỏng một số loại khối lượng công việc. Nó có thể là một khối lượng công việc OLTP như trong trường hợp của Sysbench, nó có thể là một số điểm chuẩn "tiêu chuẩn" như trong TPC-C hoặc TPC-H. Thông thường, ý tưởng là một điểm chuẩn như vậy mô phỏng một số loại khối lượng công việc và nó có thể hữu ích nếu khối lượng công việc trong thế giới thực của bạn cũng diễn ra theo cùng một mô hình. Nó cũng có thể được sử dụng để xác định cách kết hợp giữa cấu hình phần cứng và cơ sở dữ liệu của bạn hoạt động cùng nhau trong một loại khối lượng công việc nhất định. Ưu điểm của điểm chuẩn tổng hợp là khá rõ ràng. Bạn có thể chạy chúng ở mọi nơi, chúng không phụ thuộc vào một số thiết lập hoặc thiết kế lược đồ cụ thể. Vâng, họ làm nhưng họ nghĩ ra các công cụ để thiết lập mọi thứ từ máy chủ cơ sở dữ liệu trống. Nhược điểm chính là đây không phải là khối lượng công việc của bạn. Nếu bạn định chạy các bài kiểm tra OLTP bằng Sysbench thì bạn phải nhớ rằng ứng dụng của bạn sẽ không bao giờ là Sysbench. Nó cũng có thể chạy khối lượng công việc OLTP nhưng kết hợp truy vấn sẽ khác. Không bao giờ, trong bất kỳ trường hợp nào, điểm chuẩn tổng hợp sẽ cho bạn biết chính xác ứng dụng của bạn sẽ hoạt động như thế nào trên một kết hợp phần cứng / cấu hình nhất định.

Ở đầu bên kia của quang phổ, chúng tôi có cái mà chúng tôi gọi là điểm chuẩn "thế giới thực". Ý chúng tôi muốn nói ở đây là điểm chuẩn sử dụng tập dữ liệu và các truy vấn liên quan đến ứng dụng của bạn. Nó không phải lúc nào cũng có tập dữ liệu đầy đủ và kết hợp truy vấn đầy đủ. Bạn có thể muốn tập trung vào một số phần trong ứng dụng của mình, nhưng ý tưởng chính đằng sau nó là bạn muốn hiểu chính xác các tương tác giữa ứng dụng, phần cứng và cấu hình cơ sở dữ liệu, nói chung hoặc theo một số khía cạnh cụ thể.

Như chúng tôi đã đề cập ở trên, chúng tôi có hai loại điểm chuẩn chính, khác nhau, tuy nhiên, chúng có một số điểm chung mà bạn phải xem xét khi cố gắng chạy điểm chuẩn.

1. Quyết định nội dung bạn muốn kiểm tra

Trước hết, điểm chuẩn vì lợi ích của việc chạy điểm chuẩn là vô nghĩa. Nó phải được thiết kế để thực sự hoàn thành một cái gì đó. Bạn muốn gì để thoát khỏi quá trình chạy điểm chuẩn? Bạn có muốn điều chỉnh các truy vấn? Bạn có muốn điều chỉnh cấu hình không? Bạn có muốn đánh giá khả năng mở rộng của ngăn xếp của mình không? Bạn có muốn chuẩn bị ngăn xếp của mình để chịu tải cao hơn không? Bạn có muốn thực hiện một tweeking cấu hình chung cho một dự án mới không? Bạn có muốn xác định cài đặt tốt nhất cho phần cứng của mình không? Đó là những ví dụ về các mục tiêu bạn có thể muốn đạt được. Mỗi điều này sẽ yêu cầu một cách tiếp cận khác nhau và thiết lập điểm chuẩn khác nhau.

2. Thực hiện từng thay đổi

Dù bạn đang thử nghiệm và điều chỉnh, điều quan trọng nhất là bạn chỉ thực hiện một thay đổi cấu hình tại một thời điểm. Điều này thực sự rất quan trọng. Điểm chuẩn nhằm cung cấp cho bạn một số ý tưởng về hiệu suất. Các truy vấn trên giây, độ trễ, 99 phần trăm, tất cả điều này cho bạn biết bạn có thể thực thi các truy vấn nhanh như thế nào và khối lượng công việc ổn định và có thể dự đoán được như thế nào. Thật dễ dàng để biết liệu thay đổi bạn đã thực hiện trong cấu hình, phần cứng hoặc kết hợp truy vấn có thay đổi bất cứ điều gì hay không:các chỉ số từ điểm chuẩn sẽ trông khác. Vấn đề là, nếu bạn thực hiện một vài thay đổi cùng một lúc, không có cách nào để biết cái nào chịu trách nhiệm cho kết quả chung. Nó có thể đi xa hơn thế. Giả sử bạn đã thay đổi hai giá trị trong cấu hình cơ sở dữ liệu. Giá trị A và B. Mức cải thiện tổng thể là 20%, khá tốt nếu chỉ thay đổi cấu hình. Mặc dù vậy, thay đổi đối với giá trị A đã mang lại sự cải thiện 30% trong khi thay đổi bổ sung đối với giá trị B đặt nó trở lại 20%. Với nhiều thay đổi cùng một lúc, bạn chỉ có thể quan sát tác động chung của chúng, đây không phải là cách để xác định đúng kết quả của mọi thay đổi bạn đã thực hiện. Chắc chắn, điều này làm tăng đáng kể thời gian bạn sẽ dành để chạy điểm chuẩn nhưng đó là cách.

3. Thực hiện nhiều lần chạy điểm chuẩn

Máy tính tự thân là hệ thống phức tạp. Chúng có nhiều thành phần tương tác với nhau:bộ nhớ, CPU, đĩa, mạng. Sau đó, hãy thêm vào ảo hóa, chứa đựng này. Sau đó là phần mềm - hệ điều hành, ứng dụng, cơ sở dữ liệu. Layer over layer over layer over layer of element tương tác bằng cách nào đó. Không dễ để dự đoán hành vi của nó. Chà, bạn có thể nói rằng hầu như không thể dự đoán chính xác hoạt động của những hệ thống phức tạp như vậy. Đây là lý do tại sao chạy một lần chạy điểm chuẩn là không đủ để đưa ra kết luận. Điều gì sẽ xảy ra nếu bạn vô tình biết được, một số yếu tố, hoàn toàn không liên quan đến những gì bạn muốn kiểm tra, ảnh hưởng đến hiệu suất tổng thể? Tải cao trên một máy ảo khác nằm trên cùng một máy chủ. Một số máy chủ khác đang phát trực tuyến sao lưu qua mạng. Điều này có thể tạm thời ảnh hưởng đến hiệu suất và làm sai lệch kết quả điểm chuẩn. Nếu bạn thực hiện chỉ một lần chạy điểm chuẩn, bạn sẽ nhận được kết quả không chính xác. Đây là lý do tại sao phương pháp hay nhất là thực hiện một số lần vượt qua điểm chuẩn, sau đó loại bỏ điểm chậm nhất và nhanh nhất, lấy trung bình các điểm khác.

4. Một bức tranh có giá trị hàng ngàn lời nói

Chà, đây là một mô tả khá chính xác về điểm chuẩn. Nếu chỉ có thể, hãy luôn tạo đồ thị. Tốt nhất, hãy theo dõi các chỉ số trong quá trình chuẩn thường xuyên nhất có thể. Một giây chi tiết là đủ cho hầu hết các trường hợp. Để tránh viết hàng nghìn từ, chúng tôi sẽ đưa vào ví dụ này. Bạn nghĩ điều gì hữu ích hơn? Tập hợp các đầu ra điểm chuẩn này đại diện cho QPS trung bình cho mỗi 10 lần vượt qua, mỗi lần vượt qua mất 600 giây

11650,52

11237,97

11550,16

11247,08

11177,78

11163,76

11131,47

11235,06

11235,59

11277,25

Hoặc âm mưu này:

QPS trung bình là 11k nhưng thực tế là hiệu suất trên đặt, bao gồm giảm xuống 0 truy vấn được thực hiện trong vòng một giây và đó chắc chắn là thứ bạn muốn làm việc và cải thiện trên hệ thống sản xuất.

5. Truy vấn mỗi giây không phải là chỉ số quan trọng nhất

Bạn có thể nghĩ rằng truy vấn trên giây là chén thánh của hiệu suất vì nó đại diện cho số lượng truy vấn mà cơ sở dữ liệu có thể thực hiện trong vòng một giây. Sự thật là, nó không phải là số liệu quan trọng nhất, đặc biệt nếu chúng ta đang nói về sản lượng trung bình từ điểm chuẩn. QPS đại diện cho thông lượng nhưng nó bỏ qua độ trễ. Bạn có thể cố gắng đẩy một khối lượng lớn truy vấn nhưng cuối cùng bạn lại phải đợi chúng trả về kết quả. Đây không phải là những gì người dùng mong đợi từ ứng dụng. Người dùng mong đợi hiệu suất ổn định. Nó không nhất thiết phải quá nhanh nhưng khi một số hành động mất một giây để hoàn thành, chúng tôi có xu hướng hy vọng rằng việc thực hiện hành động đó sẽ luôn mất 1 giây đó. Nếu vì lý do nào đó, thời gian bắt đầu lâu hơn, con người có xu hướng lo lắng. Đây là lý do chính tại sao chúng ta có xu hướng thích độ trễ, đặc biệt là P99 (phân vị thứ 99) như một số liệu đáng tin cậy hơn. Độ trễ cho chúng ta biết ứng dụng đã phải đợi kết quả từ cơ sở dữ liệu trong bao lâu. P99 cho chúng tôi biết độ trễ rằng 99% các truy vấn có độ trễ thấp hơn. Giả sử chúng ta có P99 là 100 mili giây, điều đó có nghĩa là 99% truy vấn trả lại kết quả không chậm hơn 100 mili giây. Nếu chúng tôi thấy độ trễ P99 thấp, điều đó có nghĩa là hầu hết tất cả các truy vấn đang trở lại nhanh chóng và hoạt động ổn định, có thể dự đoán được. Đây là điều mà người dùng của chúng tôi muốn thấy.

6. Hiểu điều gì đang xảy ra trước khi đưa ra kết luận

Điểm cuối cùng mà chúng tôi có trong blog ngắn này nhưng chúng tôi muốn nói rằng đó là điểm quan trọng nhất. Bạn sẽ thấy các kết quả và hành vi kỳ lạ và bất ngờ khác nhau trong quá trình đánh giá điểm chuẩn. Thậm chí tệ hơn, bạn có thể thấy kết quả khá chuẩn, lặp đi lặp lại nhưng vẫn còn thiếu sót. Hầu hết chúng có thể được theo dõi hành vi của cơ sở dữ liệu hoặc phần cứng. Điều này thực sự rất quan trọng - trước khi bạn coi kết quả là điều hiển nhiên, bạn phải có thể giải thích hành vi và mô tả những gì đã xảy ra. Chúng tôi biết nó không dễ dàng và chúng tôi biết nó thực sự đòi hỏi kiến ​​thức về cơ sở dữ liệu cụ thể, đặc biệt là kiến ​​thức liên quan đến nội bộ cơ sở dữ liệu. Chúng tôi biết rằng trong thế giới thực, mọi người thường không bận tâm đến điều này, họ chỉ muốn nhận được một số kết quả. Vấn đề là, đặc biệt là đối với những trường hợp bạn đang cố gắng cải thiện hiệu suất thông qua các chỉnh sửa về cấu hình hoặc phần cứng, việc hiểu rõ điều gì đã xảy ra cho phép bạn chọn cách điều chỉnh phù hợp. Nó cũng giúp bạn có thể biết liệu điểm chuẩn đã được thực thi có thể có ý nghĩa gì không. Chúng tôi thực sự đang kiểm tra phần tử chính xác? Một ví dụ sẽ là một bài kiểm tra được thực hiện qua mạng (vì bạn sẽ không muốn sử dụng các lõi CPU cục bộ của nút cơ sở dữ liệu cho công cụ điểm chuẩn). Rất có thể chính mạng và tải CPU của softirq sẽ là yếu tố hạn chế, sớm hơn bạn sẽ gặp phải những tắc nghẽn “dự kiến” như bão hòa CPU. Nếu bạn không nhận thức được môi trường của mình và hành vi của nó, bạn sẽ đo hiệu suất mạng của mình để truyền khối lượng lớn dữ liệu chứ không phải hiệu suất CPU.

Như bạn thấy, đo điểm chuẩn không phải là điều dễ thực hiện nhất, bạn phải có mức độ nhận thức về những gì đang diễn ra, bạn nên có kế hoạch phù hợp cho những gì bạn sẽ làm và bạn muốn kiểm tra cái gì? Trong phần tiếp theo của blog này, chúng ta sẽ đi qua một số trường hợp thử nghiệm trong thế giới thực. Điều gì có thể xảy ra sai sót, những vấn đề chúng ta sẽ gặp phải và cách giải quyết chúng.