hiệu suất đồng thời máy chủ sql

Chúng tôi đã gặp một số vấn đề hiệu suất trên môi trường sản xuất của chúng tôi.

chúng tôi thấy rằng khi các phiên hoạt động tăng lên trên 25, việc sử dụng CPU đạt tới 100% và mất nhiều thời gian để đi xuống.

Môi trường chúng ta có:

Sản phẩm Microsoft SQL Server Enterprise Phiên bản 9.3 (sp2)

CPU 2 (Xeon 2.13)

Bộ nhớ 7G

ảnh chụp chi tiết phiên1

Phiên hoạt động 25

Giao dịch tích cực 496

Phiên nhàn rỗi 289

Giao dịch bị chặn 29

ảnh chụp chi tiết phiên2

Phiên hoạt động 59

Giao dịch tích cực 885

Phiên nhàn rỗi 267

Giao dịch bị chặn 49

Tôi muốn biết:

1. liệu 2CPU có thể xử lý tốt 25 phiên hoạt động (500 giao dịch hoạt động) hay không.PS: chúng tôi đã kiểm tra rằng không có yêu cầu đồng thời, một giao dịch, đọc / ghi 5 bảng, mất khoảng 1 giây ở cấp ứng dụng.

2. liệu các giao dịch bị chặn có sử dụng CPU nhiều hơn không .PS: các giao dịch bị chặn chủ yếu là do khóa trên 2 bảng.

Giải pháp gì: Thêm CPU? hoặc điều chỉnh ứng dụng (java / hibernate) để rút ngắn giao dịch này và giảm các khối trên bảng?

Các tùy chọn của bạn để có một bức tranh tốt về tình huống khi mọi thứ đang bò:

• sử dụng dấu vết phía máy chủ để xem các phiên dài nhất và nặng nhất
• sử dụng quy trình Ai được kích hoạt lưu trữ bởi Adam Machanic - để lưu thông tin về những khoảnh khắc khi máy chủ được tải - tập lệnh miễn phí tuyệt vời
• sử dụng Trình giám sát hoạt động từ Management Studio chỉ để xem qua trực quan (Cpu và IO là những công cụ tôi thấy hữu ích nhất) - công cụ khá tốt có trong Management Studio
• sử dụng công cụ miễn phí của bên thứ 3 - Confio Ignite Free - rất tốt cho những khoảnh khắc khi mọi thứ chậm và cần xem chi tiết về các chỉ số chờ đợi, chặn..v.v. - công cụ miễn phí tuyệt vời
• kiểm tra số liệu thống kê để được cập nhật
• kiểm tra xem các chỉ mục có bị phân mảnh không và nếu có, hãy phân mảnh chúng
• Thực hiện theo các lời khuyên khác của việc kiểm tra các chỉ mục bị thiếu, thiết kế
• kiểm tra khả năng sử dụng mức cô lập ảnh chụp nhanh trong cơ sở dữ liệu của bạn (bạn có mức chặn cao để xem bạn có thực sự cần mức cô lập hiện tại hay không)

Và chúc may mắn điều tra các vấn đề :-).

Vấn đề của bạn rất có thể là hiệu năng truy vấn kém gây ra bởi

• thiết kế kém
• lập chỉ mục kém

Khóa / chặn xuất phát từ việc lập chỉ mục kém vì tất cả thời gian dành cho các bảng quét kết thúc. CPU không liên quan ở đây.

Để khắc phục nhanh, hãy kiểm tra các chỉ mục bị thiếu bằng cách sử dụng thông tin trong bài viết này: http://blogs.msdn.com/b/bartd/archive/2007/07/19/are-you-USE-sql-s-missing- chỉ mục-dmvs.aspx

Tôi đồng ý với GBN và Marian.

Để trả lời câu hỏi của bạn về 2 CPU xử lý 25 yêu cầu: Tôi có hệ thống 2 CPU hỗ trợ khoảng 750 kết nối người dùng và trung bình 4K Batch Yêu cầu chạy một giây. Một số mục rất quan trọng đối với tôi: Thiết kế, Quản lý và Điều chỉnh. Nếu bạn bắt đầu với một thiết kế kém của ứng dụng và cơ sở dữ liệu của bạn thì bạn sẽ thất bại khi tải (nghĩ tỷ lệ).

CPU cao có thể chỉ ra áp suất bộ nhớ. Bạn đề cập chỉ có 7GB bộ nhớ khả dụng cho SQL Server. Nếu bạn có các chỉ mục hoạt động kém (Quá nhiều chỉ mục, chỉ mục không chính xác hoặc không có chỉ mục) thì điều này sẽ khiến hệ thống chuyển nhiều cơ sở dữ liệu vào bộ nhớ cho các yêu cầu khác nhau sau đó nếu có các chỉ mục phù hợp. Tôi sẽ thận trọng với các chỉ mục tạo hog-wild vì các chỉ mục sai cũng sẽ làm tổn thương bạn vì mỗi chỉ mục có khả năng yêu cầu cập nhật trong quá trình cập nhật hàng (Tạo-Cập nhật-Xóa).

Ngoài ra, sử dụng DMV Index thiếu chỉ số yêu cầu sử dụng những gì bạn biết về ứng dụng và cơ sở dữ liệu của bạn và không chỉ thực hiện từng chỉ mục được đề xuất. Tôi sẽ kiểm tra các mục blog của Kimberly Tripp về các chỉ mục ở đây . Sau phần Index, xem xét các danh mục khác có thể hữu ích cho tình huống của bạn.

Nếu bản cập nhật Java / Hibernate của 5 bảng trong một giao dịch đang thực hiện các bản cập nhật thông qua nhiều chuyến đi khứ hồi tới cơ sở dữ liệu, thì bạn đang để mình mở cho tranh chấp (Yêu cầu CRUD bị chặn). Vấn đề trở nên tồi tệ hơn nếu ứng dụng không thể quay lại cơ sở dữ liệu kịp thời. Trong khi trong ứng dụng, giao dịch hoạt động được liên kết có thể chặn các yêu cầu khác xử lý và khiến hết thời gian yêu cầu.

Thêm hai vấn đề trên với nhau và bạn bắt đầu có một trường hợp đau đầu về hiệu suất.

Giảm số lượng các chuyến đi khứ hồi cơ sở dữ liệu trong bối cảnh của một giao dịch sẽ là một điều rất tốt để theo đuổi. Có lẽ một thủ tục lưu trữ sẽ giúp.

Phần còn lại sẽ yêu cầu công việc để mở rộng ứng dụng của bạn. Bạn cũng có thể xem xét bộ nhớ, nhưng điều đó sẽ xuất hiện sau khi đánh giá thiết kế và hiệu suất được thực hiện và những thay đổi cần thiết được thực hiện khi thêm bộ nhớ ngay lập tức sẽ che giấu các vấn đề của bạn.

Hoàn toàn làm theo những gợi ý mà Marian đã vạch ra.

Tôi muốn nói rằng bạn đã tìm cho mình một thử thách tuyệt vời và chúc bạn thành công rực rỡ!

1. Theo kinh nghiệm của tôi, chúng tôi có MS SQL Server 2000 với 2 cpu và hơn 30 phiên hoạt động và hơn 1000 giao dịch. Thật khó để phục vụ, nhưng nó đã hoạt động.
2. Tôi không chắc rằng khóa sử dụng nhiều CPU hơn. Khóa và sử dụng CPU, theo tôi, là hai vấn đề hiệu suất khác nhau.

Về giải pháp, trước tiên bạn nên chắc chắn rằng vấn đề chính của bạn là CPU. Cố gắng đọc vấn đề này để tìm nguồn gốc của vấn đề của bạn và để có được giải pháp thích hợp. Finnaly, nếu bạn có thể thực hiện giao dịch của mình nhỏ nhất có thể - hãy thực hiện.

Suy nghĩ đầu tiên của tôi là giảm số lượng giao dịch và giảm số lượng chặn. Bạn có thể tách một số giao dịch thành nhiều bit không? Bạn có thể rút một số truy vấn ra khỏi giao dịch không? Như Alex_l đã đề cập - giao dịch nhỏ nhất có thể là lý tưởng ở đây.

Tôi đồng ý với gbn, thêm chỉ mục cũng có thể giúp đỡ.

Một suy nghĩ khác là tôi cũng sẽ xem xét ổ khóa của bạn. Bạn có đang sử dụng khóa cấp bảng khi bạn chỉ cập nhật một hàng không? Bạn có thể xem xét đề xuất khóa cấp hàng cho SQL Server. Điều đó sẽ giải quyết rất nhiều vấn đề. (Cấp, nếu bạn có 5 bảng, đó có thể không phải là trường hợp, nhưng chỉ là một suy nghĩ.)

Cuối cùng, tôi sẽ xem xét các bảng của bạn mà bạn đang sử dụng. Nếu mọi người đang chặn trên một bảng cụ thể, bạn có thể di chuyển logic cho bảng đó đến cuối giao dịch của mình không? Nếu bạn có thể giảm thời gian bạn giữ một khóa trên bảng yêu cầu cao đó, nó có thể giúp ích.