Giúp khắc phục sự cố SqlException:Hết thời gian chờ khi kết nối, trong tình huống không tải

Không đủ bộ nhớ

Đây rất có thể là một vấn đề về Trí nhớ, có thể trầm trọng hơn hoặc do những thứ khác kích hoạt, nhưng vốn dĩ vẫn là một vấn đề về trí nhớ. có hai khả năng khác (ít xảy ra hơn) mà bạn nên kiểm tra và loại bỏ trước (vì rất dễ làm như vậy):

Khả năng Kiểm tra Dễ dàng:

1. Bạn có thể đã bật "Tự động đóng":Tự động đóng có thể có chính xác hành vi này, tuy nhiên hiếm khi nó được bật. Để kiểm tra điều này, trong SSMS bấm chuột phải vào cơ sở dữ liệu ứng dụng của bạn, chọn "Thuộc tính", rồi chọn ngăn "Tùy chọn". Nhìn vào mục nhập "Tự động đóng" và đảm bảo rằng mục nhập này được đặt thành Sai. Cũng kiểm tra tempdb.

2. SQL Agent Jobs có thể gây ra nó:Kiểm tra Nhật ký Lịch sử của Agent để xem liệu có bất kỳ công việc nào chạy liên tục trong các sự kiện hay không. Hãy nhớ kiểm tra các công việc bảo trì, vì những thứ như Chỉ mục xây dựng lại thường được trích dẫn là các vấn đề về hiệu suất trong khi chúng đang chạy. Hiện tại đây không phải là những ứng cử viên hiếm có, chỉ vì thông thường họ sẽ không bị ảnh hưởng bởi Hồ sơ.

Tại sao Nó trông giống như Sự cố Bộ nhớ:

Nếu những điều đó không hiển thị bất cứ điều gì, thì bạn nên kiểm tra các vấn đề về bộ nhớ. Tôi nghi ngờ Bộ nhớ là nguyên nhân trong trường hợp của bạn vì:

• Bạn có 1 GB bộ nhớ:Mặc dù về mặt kỹ thuật, con số này cao hơn mức Tối thiểu cho SQL Server, nhưng nó thấp hơn mức khuyến nghị cho SQL Server và thấp hơn mức theo kinh nghiệm của tôi là có thể chấp nhận được cho sản xuất, ngay cả đối với một máy chủ được tải nhẹ.

• Bạn đang chạy IIS và SQL Server trên cùng một hộp:Điều này không được khuyến nghị bởi chính nó, phần lớn là do tranh giành bộ nhớ dẫn đến kết quả, nhưng chỉ với 1 GB bộ nhớ, nó dẫn đến IIS, ứng dụng, SQL Server, Hệ điều hành và bất kỳ tác vụ và / hoặc bảo trì nào khác đều tranh giành rất ít bộ nhớ. Cách Windows quản lý điều này là cấp bộ nhớ cho các tiến trình đang hoạt động bằng cách tích cực lấy bộ nhớ khỏi các tiến trình không hoạt động. Có thể mất nhiều giây, hoặc thậm chí vài phút để một quy trình lớn như SQL Server lấy lại đủ bộ nhớ để có thể hoàn toàn phục vụ một yêu cầu trong tình huống này.

• Hồ sơ đã giải quyết 90% sự cố:Đây là một manh mối lớn cho thấy bộ nhớ có thể là vấn đề, bởi vì thông thường, những thứ như Hồ sơ có ảnh hưởng chính xác đến vấn đề cụ thể này:tác vụ Hồ sơ giữ cho SQL Server chỉ một chút bit hoạt động mọi lúc. Thông thường, đây là hoạt động vừa đủ để giữ nó khỏi danh sách "người nhặt rác" của hệ điều hành hoặc ít nhất là giảm bớt phần nào tác động của nó.

Cách kiểm tra bộ nhớ là thủ phạm:

1. Tắt hồ sơ:Nó có tác động Heisenberg đối với vấn đề, vì vậy bạn phải tắt nó đi nếu không bạn sẽ không thể nhìn thấy vấn đề một cách đáng tin cậy.

2. Chạy Trình giám sát hệ thống (perfmon.exe) từ một hộp khác, kết nối từ xa với dịch vụ thu thập dung lượng trên hộp mà SQL Server và IIS của bạn đang chạy. bạn có thể dễ dàng thực hiện việc này nhất bằng cách xóa ba số liệu thống kê mặc định (chúng chỉ dành cho cục bộ), sau đó thêm các số liệu thống kê cần thiết (bên dưới), nhưng hãy đảm bảo thay đổi tên Máy tính trong menu thả xuống đầu tiên để kết nối với SQL của bạn hộp.

3. Gửi dữ liệu đã thu thập đến một tệp bằng cách tạo "Nhật ký Bộ đếm" trên perfmon. Nếu bạn không quen với điều này, thì điều dễ dàng nhất có thể làm là thu thập dữ liệu vào một tab hoặc tệp được phân tách bằng dấu phẩy mà bạn có thể mở bằng Excel để phân tích.

4. Thiết lập perfmon của bạn để thu thập vào một tệp và thêm các bộ đếm sau vào tệp đó:

   - Bộ xử lý \% Thời gian xử lý [Tổng số]

   - PhysicalDisk \% Idle Time [ cho mỗi đĩa ]

   - PhysicalDisk \ Avg. Độ dài hàng đợi đĩa [ cho mỗi đĩa ]

   - Bộ nhớ \ Pages / giây

   - Bộ nhớ \ Số lần đọc trang / giây

   - Bộ nhớ \ MByte có sẵn

   - Giao diện mạng \ Tổng số byte / giây [ cho mỗi giao diện được sử dụng ]

   - Xử lý \% Thời gian xử lý [ xem bên dưới ]

   - Xử lý \ Trang Lỗi / giây [ xem bên dưới ]

   - Quy trình \ Bộ làm việc [ xem bên dưới ]

5. Đối với bộ đếm Quy trình (ở trên), bạn muốn bao gồm quy trình sqlserver.exe, bất kỳ quy trình IIS nào và bất kỳ quy trình ứng dụng ổn định nào. Lưu ý rằng điều này sẽ CHỈ hoạt động đối với các quy trình "ổn định". Không thể ghi lại các quy trình liên tục được tạo lại khi cần thiết theo cách này vì không có cách nào để chỉ định chúng trước khi chúng tồn tại.

6. Chạy bộ sưu tập này vào một tệp trong thời gian mà sự cố thường xuyên xảy ra nhất. Đặt khoảng thời gian thu thập gần 10-15 giây. (điều này thu thập rất nhiều dữ liệu, nhưng bạn sẽ cần giải pháp này để chọn ra các sự kiện riêng biệt).

7. Sau khi bạn gặp một hoặc nhiều sự cố, hãy dừng thu thập và sau đó mở tệp dữ liệu đã thu thập của bạn bằng Excel. Bạn có thể sẽ phải định dạng lại cột dấu thời gian để có thể nhìn thấy hữu ích và hiển thị giờ phút và giây. Sử dụng nhật ký IIS của bạn để tìm thời gian chính xác của các sự cố, sau đó xem dữ liệu perfmon để xem những gì đang diễn ra trước và sau khi sự cố xảy ra. Đặc biệt, bạn muốn xem liệu tập hợp làm việc của nó trước đây nhỏ và lớn sau đó, với rất nhiều trang bị lỗi ở giữa. Đó là dấu hiệu rõ ràng nhất của vấn đề này.

GIẢI PHÁP:

Tách IIS và SQL Server vào hai hộp khác nhau (ưu tiên) hoặc nếu không sẽ thêm bộ nhớ vào hộp. Tôi nghĩ rằng tối thiểu phải là 3-4 GB.

Còn về Nội dung EF Kỳ lạ đó thì sao?

Vấn đề ở đây là rất có thể nó là thiết bị ngoại vi hoặc chỉ góp phần vào vấn đề chính của bạn. Hãy nhớ rằng Hồ sơ đã làm cho 90% sự cố của bạn biến mất, vì vậy những gì còn lại, có thể là một vấn đề khác, hoặc nó có thể chỉ là người làm nặng nhất của vấn đề. Do hành vi của nó, tôi có thể đoán rằng nó đang chạy bộ nhớ cache của nó hoặc có một số bảo trì nền khác của các quy trình máy chủ ứng dụng.