Tại sao phải khởi động lại định kỳ để giữ cho cá thể của tôi hoạt động tốt?


22

Chúng tôi đã có một máy chủ DB sản xuất trên SQL 2005. Mọi thứ hoạt động bình thường trong một thời gian, nhưng sau một vài tuần, chúng tôi thấy hiệu suất giảm đáng chú ý. Chỉ khởi động lại SQL Server đưa hiệu suất trở lại bình thường.

Một số nền tảng:

  • Chạy hơn 1200 cơ sở dữ liệu (chủ yếu là người thuê đơn, một số người thuê nhiều). Trước khi bất cứ ai giảng về việc chuyển sang chỉ nhiều người thuê, có những lý do hợp lệ để giữ cấu trúc này ......
  • RAM là 16 GB. Sau khi khởi động lại, SQL Server không mất quá nhiều thời gian để quay lại sử dụng 15 GB.
  • Các kết nối DB hoạt động là khoảng 80 kết nối - mà chúng tôi cảm thấy khá lành mạnh khi có một nhóm kết nối cho mỗi máy chủ web trên mỗi quy trình - vì vậy chúng tôi không gặp sự cố rò rỉ kết nối.

Chúng tôi đã thử một số thứ trong thời gian không cao điểm: - Chạy DBCC DROPCLEANBUFFERS (với CHECKPOINT) để xóa bộ đệm dữ liệu. Nó không có tác dụng, cũng không xóa bất kỳ việc sử dụng RAM nào). - Chạy FREEPROCCACHE và FREESYSTEMCACHE để xóa các gói truy vấn và bộ nhớ cache được lưu trữ. Không có tác dụng.

Rõ ràng việc khởi động lại SQL Server không lý tưởng trong môi trường sản xuất hoạt động. Chúng tôi đang thiếu một cái gì đó. Bất cứ ai khác đi qua điều này?

CẬP NHẬT: Tháng Tư-28-2012 Vẫn chiến đấu với vấn đề này. Tôi đã giảm bộ nhớ cho SQL Server xuống còn 10 GB, để loại trừ bất kỳ sự tranh chấp nào với HĐH. Tôi đang tiến gần hơn đến việc thu hẹp nó xuống, nhưng cần sự giúp đỡ từ bước tiếp theo.

Đây là những gì tôi tìm thấy, sau khi khởi động lại SQL Server, tệp trang dao động trong khoảng từ 12,3 GB đến 12,5 GB. Nó sẽ giữ cách đó trong nhiều ngày. Tổng số luồng máy chủ sẽ đi ra trong khoảng từ 850 đến 930 - cũng ổn định và nhất quán trong nhiều ngày liên tục (máy chủ sqls ổn định trong khoảng từ 55 đến 85 trong số đó tùy thuộc vào lưu lượng truy cập).

Sau đó, có "một sự kiện". Tôi không biết sự kiện này là gì, tôi không thể nhìn thấy nó trong nhật ký và tôi không thể thấy bất cứ điều gì nhất quán vào ngày trong tuần hoặc thời gian nó xảy ra, nhưng tất cả những điều tuyệt vời mà anh ấy đã nhảy vào 14.1 hoặc 14.2 GB và các chủ đề nhảy đến giữa 1750 và 1785.

Kiểm tra perfom khi điều này xảy ra, hơn 900 trong số các chủ đề đó là sqlserver. Vì vậy, tôi đi đến sp_who2 để xem các luồng này đến từ đâu ... và chỉ có 80 kết nối db được sử dụng.

Vì vậy, .... có ai có bất kỳ ý tưởng nào làm thế nào tôi có thể xác định vị trí phần còn lại của 900 luồng này trên máy chủ SQL không, và họ đang làm gì?

CẬP NHẬT: Tháng Sáu-01-2012 Vẫn chiến đấu với vấn đề. Đối với bất cứ ai đọc điều này vẫn còn, vấn đề với các chủ đề nhảy lên đã được giải quyết. Điều này được gây ra bởi phần mềm sao lưu tự động ComVault. Nó đang tạo ra một luồng cố gắng sao lưu cơ sở dữ liệu không còn ở đó (nó đang duy trì một danh sách các cơ sở dữ liệu trước đó) thay vì chỉ sao lưu cơ sở dữ liệu hiện tại.

Nhưng - vấn đề vẫn còn, và chúng tôi phải khởi động lại mỗi tuần, cho hoặc mất một vài ngày. Làm việc với nhóm Rackspace để xem liệu họ có thể làm sáng tỏ được không.


1
Điểm cho một câu hỏi kỹ lưỡng, nhưng bạn đã nghĩ rằng 16 GB RAM có thể không đủ cho 1200 cơ sở dữ liệu?
Nick Vaccaro

Không thể thực sự giúp ích trong sơ đồ lớn nhưng tôi biết rằng MSSQL đã được thiết kế để tiêu thụ nhiều RAM nhất có sẵn. Điều này thực sự có ý nghĩa vì nếu không có RAM sẽ lãng phí. Việc tôi tăng lên 15GB ngay sau khi khởi động lại thực sự không phải là vấn đề. Tuy nhiên @Norla có thể đúng rằng số 16 không đủ cho những gì bạn muốn làm.

Có bao nhiêu SPID đang hoạt động trong thời gian chậm? Chạy sp_who2 và vui lòng đếm số hàng.
Nick Vaccaro

Chỉ cần kiểm tra - Bạn có bất kỳ công việc máy chủ Sql nào đang chạy không? Bạn có thể ngăn chặn từng người một để xem Nếu có ai trong số họ gây ra vấn đề này không?

Đầu ra của: chọn SUM (single_pages_kb + multi_pages_kb) /1024.0 từ sys.dm_os_memory_clerks trong đó [name] = 'TokenAndPermUserStore'
Đánh dấu Storey-Smith

Câu trả lời:


7

Bạn nói rằng mọi thứ đều ổn, sau một vài tuần, hiệu suất giảm xuống. . lập chỉ mục hoặc số liệu thống kê xấu gây ra các truy vấn chuyên sâu về cpu hoặc đọc đĩa. Hoặc các nội dung khác.) Tuần là không bình thường.

Giả thuyết của tôi là một ứng dụng khác trên máy chủ của bạn bị rò rỉ bộ nhớ. Tôi đã thấy điều này với phần mềm vi rút (nhân vật phản diện phần mềm máy chủ yêu thích của DBA) và phần mềm giám sát của bên thứ 3. Tôi sẽ kiểm tra lại việc sử dụng bộ nhớ của SQL Server theo thời gian và tôi cũng sẽ nắm bắt tất cả việc sử dụng bộ nhớ của tất cả các ứng dụng khác trên hộp. Nếu bạn có các giới hạn cứng được đặt cho việc sử dụng bộ nhớ của SQL Server và được đặt thành không cho phép phân trang, thì đó có thể là các ứng dụng khác được phân trang và ăn hết dung lượng I / O.

Không khó để tìm kiếm. Nếu bạn chưa giữ số liệu trên máy chủ, tôi sẽ khởi động Perfmon và lấy mẫu sau mỗi 30 hoặc 60 phút. Sau một vài ngày, bạn có thể thấy việc sử dụng bộ nhớ ứng dụng khác leo lên.

Có thông báo lỗi trong nhật ký SQL Server nói rằng "các phần quan trọng của máy chủ sql đã được phân trang" không? Đó cũng sẽ là một đầu mối lớn.


Tôi đồng ý, hành vi này làm cho nó nghe như rò rỉ bộ nhớ.
Nick Kavadias

+1 Đối với rò rỉ bộ nhớ. Tôi nghi ngờ tuổi thọ trang rất dài trên máy chủ này, nhưng nó không làm cho trang web phát triển nhanh chóng. FYI, gần như cùng một vấn đề ở đây (đó là AV là vấn đề): social.msdn.microsoft.com/Forums/en/sqlsetupandupTHER/thread/ Lỗi
brian

5

Tôi xin chúc mừng bạn vì bạn có thể chạy 1200 DB trên một phiên bản duy nhất của máy chủ SQL chỉ với 16 GB RAM và chỉ có các loại sự cố này sau vài tuần chạy trơn tru. Câu chuyện hay để kể tại chương PASS địa phương.

Bây giờ để khắc phục sự cố: RAM của bạn là 16 GB cho cả SQL và HĐH. Tôi giả sử cài đặt bộ nhớ tối đa của bạn là 15 GB hoặc tối đa. Điều này có thể khiến nhóm bộ đệm sử dụng hết bộ nhớ và làm nghẹt hệ điều hành. Bạn đang nói rằng việc dọn sạch vùng đệm và bộ đệm không cho thấy bất kỳ sự khác biệt nào, cộng với PLE của bạn trên 300. Điều này chứng tỏ chống lại cổ chai bộ nhớ. CPU và IO trên máy chủ (thông số / thống kê) như thế nào?

Chạy select * from sys.dm_exec_request where session_id>50 and session_id<>@@spidvà những tranh chấp tài nguyên mà bạn thấy (Wait_type, Wait_time, last_wait_type, Wait_resource) là gì.


1200 không tệ lắm! Trở ngại lớn nhất là khắc phục các sự cố nhóm kết nối, được giải quyết bằng cách đặt chuỗi kết nối thành chủ, và sau đó là SỬ DỤNG [DBName] sau khi kết nối. Về mặt truy vấn, tôi đã chạy select * từ sys.dm_exec numquests trong đó session_id> 50 và session_id <> @@ spid và đó là một danh sách ngắn gồm 4 đến 5 yêu cầu, tối đa và chúng thường rời khỏi danh sách trong vòng 500 ms. Nhưng tôi sẽ thử điều này một khi chúng ta chậm lại, nó đã được khởi động lại vào Chủ nhật, vì vậy bây giờ nó ồn ào như bình thường.
PaulJ

@PaulJ cảm ơn vì lời khuyên về kết nối tổng hợp. Tôi đang đọc một số về nó bây giờ.
StanleyJohns

5

1200 cơ sở dữ liệu, một hệ điều hành, và có thể các công cụ khác? Vâng, tôi nghĩ rằng bản thân máy chủ sẽ cần nhiều hơn 1gb ram để hoạt động, đặc biệt là nếu bạn đặt 15gb làm cài đặt bộ nhớ tối đa của SQL Server, thì nó vẫn cần thêm bộ nhớ ngoài 15gb cho các luồng.

Tôi sẽ nâng SQL Server xuống còn 14gb để cung cấp cho máy chủ một phòng thở hơn một chút.

Ngoài ra, một ví dụ được đưa ra trong "Chuyên gia và khắc phục sự cố SQL Server 2008 chuyên nghiệp" cho các khoản phụ cấp bộ nhớ trên hệ thống SQL Server 2008 x64 với tiện ích sao lưu phần ba với RAM 16GB:

  • 2 GB cho Windows
  • 1GB cho chủ đề công nhân
  • 1GB cho MPA, v.v.
  • 1GB cho chương trình sao lưu
  • 11GB cho máy chủ SQL

Trong cuốn sách này cho thấy cách xác định số lượng chủ đề tối đa bạn có thể có và cách tính dung lượng bộ nhớ mà chúng sẽ chiếm. Chạy cái này (thay đổi loại máy chủ để phù hợp với máy chủ của bạn) để tìm ra số lượng bộ nhớ mà chủ đề của bạn sẽ cần.

declare @servertype int

set @servertype=1
/*
1: x86 (32-bit)
2: x64 (64-bit)
3: IA64

*/

select max_workers_count *
    (
        case @servertype when 1 then .5
            when 2 then 2
            when 3 then 4
            else .5
        end
    )
from sys.dm_os_sys_info

công cụ tuyệt vời, cảm ơn. Tôi đã chuyển nó xuống còn 14 GB. Đã học được một cái gì đó mới ở đây, vì tôi đã luôn để SQL Server lấy những gì nó muốn. Một bài viết hay khác để tham khảo ủng hộ điều này: sqlservercentral.com/bloss/glennberry/2009/10/29/iêu
PaulJ

4

Nếu bộ nhớ cơ sở dữ liệu được phân phối đồng đều trên tất cả các cơ sở dữ liệu, bạn chỉ có 12,8 Megs cho mỗi cơ sở dữ liệu (15 * 1024) /1200=12.8. Bạn cần thêm bộ nhớ.

Bạn cần xem xét lý do tại sao hiệu suất chậm lại. Bạn đang thấy khóa, chặn, vv? Các chỉ số chờ đợi trông như thế nào?


3

Các lệnh DBCC sẽ chỉ xóa bộ đệm bộ nhớ mà chúng sẽ không giải phóng bộ nhớ trở lại HĐH.

Bạn có biết rằng SQL Server đang thực sự tiêu thụ bộ nhớ? Tôi sẽ đề nghị xem xét việc thiết lập phiên Perfmon hoặc bắt đầu thu thập thông tin DMV sau khi khởi động lại để tìm hiểu SQL Server đang làm gì và làm gì. Ngoài ra, hãy lưu ý nếu người dùng đang làm việc nhiều hơn bình thường trong thời gian thu thập của bạn (chẳng hạn như xử lý Cuối tháng, v.v.). Bạn có đang chạy SSRS, SSIS hoặc SSAS trên cùng một máy chủ không?

Bạn có 1200 cơ sở dữ liệu trên hệ thống, DB có kích thước lớn nhất bạn có là bao nhiêu?


db lớn nhất là 5GB. Chỉ ~ 25 trong số đó là 1GB trở lên. Phần lớn là 50 đến 200 MB.
PaulJ

"Bạn có đang chạy SSRS, SSIS hoặc SSAS trên cùng một máy chủ không?" - Không chạy các dịch vụ đó. Đó là một hộp sql tinh khiết.
PaulJ
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.