Khi khắc phục sự cố hiệu suất CPU trên Máy chủ SQL được ảo hóa chạy trên VMware, một trong những điều đầu tiên tôi làm là xác minh rằng cấu hình máy ảo không phải là yếu tố góp phần gây ra sự cố hiệu suất. Trong đó máy chủ vật lý có 100% tài nguyên khả dụng dành riêng cho hệ điều hành, máy ảo thì không, vì vậy việc xem xét một số mục cơ bản trước giúp loại bỏ việc khắc phục sự cố sai và lãng phí thời gian. Trước đây, tôi đã viết blog về tầm quan trọng của việc DBA có quyền truy cập chỉ đọc vào Trung tâm ảo cho VMware để khắc phục sự cố cơ bản về các sự cố hiệu suất. Tuy nhiên, ngay cả khi không có quyền truy cập vào Trung tâm ảo, bạn vẫn có thể tìm ra một số thông tin cơ bản bên trong Windows có thể dẫn đến các sự cố cấp máy chủ tiềm ẩn đang ảnh hưởng đến hiệu suất.
Mỗi máy ảo VMware đều có hai nhóm bộ đếm hiệu suất trong Windows được thêm vào khi các công cụ VMware được cài đặt trong máy khách; Bộ xử lý VM và Bộ nhớ VM. Các bộ đếm hiệu suất này là một trong những thứ đầu tiên tôi xem xét bất cứ khi nào tôi làm việc với một máy ảo trên VMware, vì chúng cung cấp cho bạn cái nhìn về những tài nguyên mà máy ảo đang nhận từ hypervisor. Nhóm Bộ xử lý VM có các bộ đếm sau:
- % Thời gian của Bộ xử lý
- Tốc độ VM hiệu quả tính bằng MHz
- Tốc độ bộ xử lý máy chủ tính bằng MHz
- Giới hạn tính bằng MHz
- Đặt trước tính bằng MHz
- Chia sẻ
Trên máy khách VM đang hiển thị Bộ xử lý \% Thời gian xử lý cao trong Trình quản lý tác vụ hoặc perfmon, việc kiểm tra bộ đếm Bộ xử lý máy ảo sẽ cung cấp tài khoản chính xác về phân bổ tài nguyên thực tế mà khách máy ảo đang nhận. Nếu tốc độ bộ xử lý Máy chủ tính bằng MHz là 3000 và khách có 8 CPU ảo được phân bổ cho nó, thì tốc độ hiệu dụng tối đa cho máy ảo là 24000 MHz và Tốc độ máy ảo hiệu dụng tính bằng MHz sẽ phản ánh liệu máy ảo có thực sự lấy tài nguyên từ đó hay không máy chủ. Thông thường khi rơi vào trường hợp này, bạn sẽ cần phải bắt đầu xem xét thông tin cấp máy chủ để chẩn đoán thêm nguyên nhân gốc rễ của vấn đề. Nhưng trong một lần tương tác với khách hàng gần đây, điều này đã không xảy ra.
Máy khách trong trường hợp này phù hợp với cấu hình được mô tả ở trên và có tốc độ hiệu dụng tối đa là 24000 MHz nhưng Tốc độ máy ảo hiệu dụng trong bộ đếm MHz chỉ đạt mức trung bình khoảng 6900 MHz với thời gian Bộ xử lý phần trăm VM Windows được chốt ở mức gần 100%. Nhìn ngay bên dưới bộ đếm Tốc độ máy ảo hiệu quả tính bằng MHz đã tiết lộ nguyên nhân của sự cố:Giới hạn tính bằng MHz là 7000, có nghĩa là máy ảo có giới hạn sử dụng CPU được định cấu hình ở 7000MHz trong ESX, vì vậy nó liên tục được điều chỉnh bởi trình giám sát dưới trọng tải.
Giải thích cho điều này là máy ảo cụ thể này đã được sử dụng cho mục đích thử nghiệm trong một bằng chứng về khái niệm và ban đầu được đặt chung trên một máy chủ VM bận; quản trị viên VM không muốn khối lượng công việc không xác định gây ra các vấn đề về hiệu suất trên máy chủ đó. Vì vậy, để đảm bảo rằng nó sẽ không tác động tiêu cực đến khối lượng công việc sản xuất thực trên máy chủ trong thời gian POC, nó bị giới hạn chỉ cho phép CPU 7000 MHz hoặc tương đương với 2 1/3 lõi vật lý trên máy chủ. Cuối cùng, việc loại bỏ Giới hạn CPU VM trong ESX đã loại bỏ các vấn đề CPU cao trong Windows và các vấn đề về hiệu suất mà máy khách đang gặp phải đã biến mất.
Nhóm bộ đếm Bộ nhớ máy ảo cũng quan trọng như nhóm Bộ xử lý máy ảo để xác định các vấn đề hiệu suất tiềm ẩn cho SQL Server. Nhóm bộ đếm bộ nhớ VM chứa các bộ đếm sau:
- Bộ nhớ hoạt động tính bằng MB
- Bộ nhớ được tích hợp tính bằng MB
- Giới hạn bộ nhớ tính bằng MB
- Bộ nhớ được ánh xạ trong MB
- Chi phí Bộ nhớ tính bằng MB
- Bảo lưu bộ nhớ tính bằng MB
- Bộ nhớ được chia sẻ bằng MB
- Bộ nhớ được chia sẻ được lưu trong MB
- Chia sẻ bộ nhớ
- Bộ nhớ được hoán đổi bằng MB
- Bộ nhớ được sử dụng tính bằng MB
Trong số những bộ đếm này, những bộ đếm mà tôi đặc biệt xem xét là Bộ nhớ Ballooned tính bằng MB và Bộ nhớ được hoán đổi bằng MB, cả hai bộ đếm này phải bằng 0 đối với khối lượng công việc của SQL Server. Bộ đếm Memory Ballooned in MB cho biết có bao nhiêu bộ nhớ đã được trình điều khiển bong bóng lấy lại từ máy ảo khách do bộ nhớ vượt cấp trên máy chủ, điều này sẽ khiến SQL Server giảm mức sử dụng bộ nhớ để đáp ứng với áp suất bộ nhớ trong Windows do trình điều khiển bong bóng gây ra thổi phồng để lấy bộ nhớ khỏi máy ảo. Bộ đếm Bộ nhớ được hoán đổi trong MB đang theo dõi lượng bộ nhớ đã được phân trang vào đĩa bởi trình siêu giám sát máy chủ lưu trữ do quá tải bộ nhớ trên máy chủ lưu trữ mà không thể giải quyết bằng cách đánh bóng khách VM bằng trình điều khiển bong bóng. Hướng dẫn thực hành tốt nhất của VMware dành cho SQL Server khuyên bạn nên sử dụng đặt chỗ để đảm bảo rằng SQL Server không bị đánh dấu hoặc phân trang vì lý do hiệu suất nhưng nhiều quản trị viên VM do dự khi đặt đặt chỗ tĩnh vì nó làm giảm tính linh hoạt của môi trường.
Các công cụ giám sát, như SentryOne V Sentry, cũng có thể giúp ích. Hãy xem xét trường hợp bạn có thể không có quyền truy cập trực tiếp vào vCenter, nhưng ai đó có thể thiết lập giám sát chống lại vCenter thay mặt bạn. Giờ đây, bạn có thể có được trực quan tuyệt vời và cái nhìn sâu sắc về các vấn đề về CPU, bộ nhớ và thậm chí là ổ đĩa - ở cả cấp độ khách và máy chủ - cũng như tất cả lịch sử đi kèm với điều đó. Trên trang tổng quan bên dưới, bạn có thể thấy số liệu máy chủ ở bên trái (bao gồm sự cố CPU cho thời gian đồng dừng và sẵn sàng) và số liệu khách ở bên phải:
Để dùng thử chức năng này và các chức năng khác từ SentryOne, bạn có thể tải xuống bản dùng thử miễn phí.
Kết luận
Khi khắc phục sự cố hiệu suất trên Máy chủ SQL được ảo hóa trên VMware, điều quan trọng là phải xem xét vấn đề từ quan điểm tổng thể thay vì thực hiện khắc phục sự cố "đầu gối" chỉ sử dụng thông tin hạn chế. Bộ đếm dành riêng cho VMware trong Màn hình hiệu suất có thể là một cách tuyệt vời để nhanh chóng xác minh rằng máy ảo đang nhận được phân bổ tài nguyên cơ bản từ máy chủ, trước khi thực hiện các bước tiếp theo để khắc phục sự cố.
