Ứng dụng Asp.net chậm nhưng CPU ở mức tối đa 40%

Question

Tôi có tình huống lạ trên máy chủ sản xuất. Kết nối cho asp.net được xếp hàng đợi nhưng CPU chỉ ở mức 40%. Cơ sở dữ liệu cũng chạy tốt với CPU 30%.

Một số lịch sử hơn theo yêu cầu trong các ý kiến:

• Trong giờ cao điểm các trang web được khoảng 20.000 khách một giờ.
• Trang web này là một ứng dụng webforms asp.net với rất nhiều AJAX/POSTS
• Trang web này sử dụng rất nhiều tài khoản tạo ra nội dung
• Chúng tôi đo hiệu suất của trang web với một testpage mà nhấn cơ sở dữ liệu và các dịch vụ web được trang web sử dụng. Trang này được phân phối trong vòng một giây khi tải bình thường. Whe xác định ứng dụng là chậm khi yêu cầu mất hơn 4 giây.
• Từ các phép đo, chúng ta có thể thấy rằng connectiontime là nhanh, nhưng thời gian xử lý lớn.
• Chúng tôi không thể xác định phản hồi chậm theo yêu cầu duy nhất, trang web chạy tốt trong giờ bình thường nhưng bị chậm trong giờ cao điểm
• Chúng tôi gặp sự cố rằng trang web bị ràng buộc CPU (còn gọi là 100%), chúng tôi cố định rằng
• Chúng tôi cũng gặp sự cố với ngoại lệ đã bắt đầu khởi động lại appdomain, chúng tôi đã khắc phục điều đó
• Trong giờ cao điểm, tôi xem qua các bộ đếm hiệu suất asp.net. Chúng ta có thể thấy hành vi mà chúng ta có 600 kết nối hiện tại với 500 kết nối được xếp hàng đợi.
• Tại thời gian cao điểm CPU là khoảng 40% (mà làm cho tôi nghĩ rằng nó không phải là CPU bị ràng buộc)
• bộ nhớ vật lý là khoảng 60% sử dụng
• Tại thời gian cao điểm CPU DatabaseServer là khoảng 30% (trong đó khiến tôi nghĩ rằng đó không phải là cơ sở dữ liệu bị ràng buộc)

Kết luận của tôi là việc ngăn máy chủ xử lý yêu cầu nhanh hơn. nghi phạm có thể

• Deadlocks (syncblk chỉ cung cấp cho một khóa!)
• Disk I/O (kiểm tra qua Sysinternals procesexplorer: 3,5 MB/s)
• Thu gom rác (10 ~ 15% trong đỉnh)
• I/O mạng (thời gian kết nối vẫn còn thấp)

Để tìm hiểu xem các proces đang làm gì tôi tạo ra cho minidumps.

Tôi đã quản lý để tạo hai MemoryDumps cách nhau 20 giây. Đây là sản phẩm đầu tiên:

!threadpool 
CPU utilization 6% 
Worker Thread: Total: 95 Running: 72 Idle: 23 MaxLimit: 200 MinLimit: 100 
Work Request in Queue: 1 
-------------------------------------- 
Number of Timers: 64 

và đầu ra của thứ hai:

!threadpool 
CPU utilization 9% 
Worker Thread: Total: 111 Running: 111 Idle: 0 MaxLimit: 200 MinLimit: 100 
Work Request in Queue: 1589 

Như bạn có thể thấy có rất nhiều yêu cầu trong Queue.

Câu hỏi 1: có nghĩa là có 1589 yêu cầu trong hàng đợi. Nó có nghĩa là một cái gì đó đang chặn?!

Danh sách threadpool chứa chủ yếu là những mục: Chức năng Unknown: 6a2aa293 Bối cảnh: 01cd1558 AsyncTimerCallbackCompletion TimerInfo @ 023a2cb0

Nếu tôi bạn vào chiều sâu với AsyncTimerCallbackCompletion

!dumpheap -type TimerCallback 

Sau đó, tôi nhìn vào các đối tượng trong TimerCallback và hầu hết trong số chúng là các loại:

System.Web.SessionState.SessionStateModule 
System.Web.Caching.CacheCommon 

Câu hỏi 2: Có phải bất kỳ ý nghĩa nào đối với những đối tượng đó là một bộ hẹn giờ và quá nhiều? Tôi có nên ngăn chặn điều này không. Và làm thế nào?

Câu hỏi chính tôi có bỏ lỡ bất kỳ vấn đề rõ ràng nào tại sao tôi xếp hàng kết nối và không tối đa CPU?

---

Tôi đã thành công trong việc tạo một sự cố trong thời gian cao điểm. Phân tích nó với debugdiag đã cho tôi cảnh báo này:

Detected possible blocking or leaked critical section at webengine!g_AppDomainLock owned by thread 65 in Hang Dump.dmp 
Impact of this lock 
25.00% of threads blocked 
(Threads 11 20 29 30 31 32 33 39 40 41 42 74 75 76 77 78 79 80 81 82 83) 

The following functions are trying to enter this critical section 
webengine!GetAppDomain+c9 

The following module(s) are involved with this critical section 
\\?\C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\webengine.dll from Microsoft Corporation 

Tìm kiếm nhanh trên google không cho tôi bất kỳ kết quả nào. Có ai đó có một đầu mối?

Answer 1

Quy trình công nhân xử lý hàng đợi là giao dịch thực sự. Có thể kết nối với trang web gọi dịch vụ web trên cùng một máy chủ. Do đó tạo ra một loại bế tắc.

Tôi đã thay đổi Machine.config để đến sau:

<processModel 
     autoConfig="false" 
     maxWorkerThreads="100" 
     maxIoThreads="100" 
     minWorkerThreads="50" 
     minIoThreads="50" /> 

Chuẩn processModel này được thiết lập để AutoConfig = "true"

Với cấu hình mới máy chủ web là xử lý các yêu cầu đủ nhanh để không được xếp hàng đợi.

Answer 2

Quá nhiều yêu cầu xếp hàng đợi ASP.NET sẽ phá hủy hiệu suất. Có một số lượng yêu cầu rất hạn chế.

Cố gắng giải phóng các chủ đề đó bằng cách xử lý các phần chậm của trang của bạn một cách không đồng bộ hoặc làm bất kỳ điều gì khác bạn có thể để giảm thời gian thực thi trang.

Answer 3

Tôi đang sử dụng bộ giải mã realworldcoder: IIS hoạt động bằng cách xử lý các Processer của Worker. Nếu các yêu cầu được xếp chồng lên nhau, vì nó xuất hiện đang diễn ra, sau đó hiệu suất sẽ lặn.

Có một số điều có thể thực hiện/kiểm tra.

1. Bật giám sát hoạt động trên máy chủ SQL. Bạn muốn xem những truy vấn nào mất nhiều thời gian nhất và, tùy thuộc vào kết quả, thực hiện các thay đổi để giảm thời gian thực hiện của chúng. Các truy vấn dài có thể làm cho luồng mà trang đang thực thi theo khối, giảm số lượng kết nối bạn có thể hỗ trợ.

2. Xem số lượng truy vấn và thời gian chúng thực hiện, đối với các lệnh gọi trang/ajax này. Tôi đã nhìn thấy các trang với hàng tá truy vấn không cần thiết được thực hiện cho một cuộc gọi Ajax đơn giản chỉ vì .Net thực thi toàn bộ chu trình trang ngay cả khi chỉ có một phương thức cụ thể cần chạy. Bạn có thể chia các cuộc gọi đó thành các trang xử lý web thông thường (.ashx) theo cách bạn có thể kiểm soát chính xác hơn những gì xảy ra.

3. Cân nhắc tăng số lượng quy trình công nhân IIS phải xử lý các yêu cầu gửi đến. Giá trị mặc định cho nhóm ứng dụng mới là 1 quy trình với 20 threads. Điều này thường đủ để xử lý tấn yêu cầu; tuy nhiên, nếu các yêu cầu đang chặn do chờ đợi trên máy chủ DB hoặc một số tài nguyên khác, nó có thể khiến cho đường dẫn xếp chồng lên nhau. Hãy nhớ rằng điều này có thể có tác động tích cực hoặc tiêu cực đến cả hiệu suất và hoạt động thường xuyên của ứng dụng của bạn. Vì vậy, làm một số nghiên cứu sau đó thử nghiệm, kiểm tra, thử nghiệm.

4. Cân nhắc việc giảm hoặc loại bỏ việc sử dụng phiên của bạn.Dù bằng cách nào, hãy nhìn vào việc sử dụng bộ nhớ của nó, có khả năng thêm ram hơn vào máy chủ web của bạn. Dữ liệu phiên được tuần tự hóa và deserialized cho mỗi tải trang (bao gồm cả các cuộc gọi ajax) bất kể dữ liệu được sử dụng hay không. tùy thuộc vào những gì bạn đang lưu trữ trong phiên nó có thể có tác động tiêu cực nghiêm trọng trên trang web của bạn. Nếu bạn không sử dụng nó, sau đó hãy chắc chắn rằng nó hoàn toàn bị tắt trong web.config của bạn. Lưu ý rằng những vấn đề này chỉ trở nên tồi tệ hơn nếu bạn lưu trữ phiên tắt của máy chủ web khi bạn bị ràng buộc với tốc độ của mạng khi trang truy xuất và lưu trữ nó.

5. Xem các quầy hiệu suất của trang web xung quanh biên dịch JIT (Just-In-Time). Điều này sẽ gần như không tồn tại. Tôi đã nhìn thấy các trang web được đưa đến đầu gối của họ bằng một lượng lớn JIT. Một khi các trang đó được mã hóa để loại bỏ nó, các trang web bắt đầu bay trở lại.

6. Xem xét các chiến lược lưu trong bộ nhớ cache khác nhau (Tôi không coi phiên là giải pháp lưu vào bộ nhớ cache thực). Có lẽ có những thứ mà bạn liên tục yêu cầu rằng bạn không thực sự cần phải liên tục kéo ra khỏi máy chủ DB. Một người bạn của tôi có một trang web nơi họ lưu toàn bộ trang web dưới dạng tệp vật lý cho nội dung động, bao gồm các nhóm thảo luận của họ. Điều này đã làm tăng hiệu suất của họ một cách triệt để; nhưng nó là một thay đổi kiến ​​trúc lớn.

Ở trên chỉ là một vài điều cần xem xét. Về cơ bản, bạn cần phải tìm hiểu sâu hơn về các chi tiết để tìm hiểu chính xác những gì đang diễn ra và hầu hết các bộ đếm hiệu suất thông thường sẽ không cung cấp cho bạn sự rõ ràng đó.

Answer 4

Có ai có thể xác nhận điều này phù hợp với họ không? Tôi đã tìm thấy câu trả lời trên web và không có xác nhận rằng câu trả lời đã đăng đã khắc phục sự cố này cho họ. Với điều đó đang được nói, tôi không thực sự cung cấp cho nó độ tin cậy như câu trả lời được cung cấp bởi các poster câu hỏi.

Tôi có cùng một vấn đề thời gian gần đây:

phát hiện ngăn chặn khả năng bị rò rỉ hoặc phần quan trọng tại webengine g_AppDomainLock thuộc sở hữu của chủ đề 16 trong w3wp.exe__DefaultAppPool__PID__3920__Date__04_26_2011__Time_10_40_42AM__109__IIS_COM + Hằng Dump.dmp Tác động của khóa này

4.17% chủ đề bị chặn (Chủ đề 17) Các chức năng sau đây đang cố gắng nhập phần webengine quan trọng này! GetAppDoma trong + c9 (Các) mô-đun sau đây có liên quan đến phần quan trọng này \? \ c: \ WINDOWS \ microsoft.net \ framework \ v2.0.50727 \ webengine.dll từ Tập đoàn Microsoft

Đây là đề nghị đăng bởi Microsoft để gỡ rối thêm:

Các công ty sau đã được xác định để theo dõi dựa trên gốc nguyên nhân phân tích Tập đoàn Microsoft Hãy theo dõi với các nhà cung cấp được xác định ở trên. Hãy xem xét các phương pháp sau đây để xác định nguyên nhân gốc rễ cho phần vấn đề quan trọng này:

1. Kích hoạt 'khóa kiểm tra' trong Application Verifier A. Tải ứng dụng Verifier từ URL sau: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=c4a25ab9-649d-4a1b-b4a7-c9d8b095df18&displaylang=en B. Enable 'khóa kiểm tra' cho quá trình này bằng cách chạy lệnh sau:

   Appverif.exe -enable locks -for w3wp.exe C. Xem các tài liệu sau để biết thêm thông tin về ứng dụng Verifier: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnappcom/html/appverifier.asp?frame=true

2. Sử dụng một quy tắc tai nạn DebugDiag để giám sát việc áp dụng cho trường hợp ngoại lệ

Answer 5

Tôi biết đây là một chủ đề cũ nhưng nó là một trong những người đầu tiên Google lượt truy cập cho những người có hiệu suất ASP.NET website nghèo nàn. Vì vậy, tôi sẽ đưa ra một vài đề xuất:

1) Lập trình không đồng bộ sẽ giải quyết nguyên nhân gốc rễ. Trong khi bạn đang kêu gọi một webservice để làm logic kinh doanh thực tế của bạn, những yêu cầu đề chỉ là ngồi đó chờ đợi trên phản ứng. Chúng có thể được sử dụng để phục vụ một yêu cầu đến khác. Điều này sẽ giảm đáng kể Độ dài Hàng đợi của bạn nếu không loại bỏ hoàn toàn. Lập trình không đồng bộ là về khả năng mở rộng, không phải hiệu suất yêu cầu riêng lẻ. Điều này đạt được khá dễ dàng trong .NET 4.5 với mẫu Async/Await. ASP.NET injects thread với tốc độ 2 mỗi phút, vì vậy trừ khi bạn đang tái sử dụng những chủ đề hiện có, bạn sẽ nhanh chóng chạy ra ngoài với tải trang web mà bạn đang nhận. Ngoài ra, quay lên nhiều chủ đề là một hit hiệu suất nhỏ; nó chiếm nhiều RAM và thời gian để phân bổ RAM đó. Chỉ cần tăng kích thước hồ bơi thread trong machine.config sẽ không khắc phục được vấn đề cơ bản. Trừ khi bạn thêm nhiều CPU hơn, việc thêm nhiều luồng hơn sẽ không thực sự hữu ích vì nó vẫn là một sự sắp xếp sai tài nguyên và bạn cũng có thể chuyển ngữ cảnh thành cái chết bằng cách có quá nhiều luồng và quá ít CPU.

2) From a popular article on threading in IIS 7.5: Nếu ứng dụng ASP.NET của bạn đang sử dụng dịch vụ web (WFC hoặc ASMX) hoặc System.Net để liên lạc với chương trình phụ trợ qua HTTP, bạn có thể cần phải tăng connectionManagement/maxconnection. Đối với các ứng dụng ASP.NET, điều này được giới hạn ở 12 * #CPUs bởi tính năng autoConfig. Điều này có nghĩa là trên quad-proc, bạn có thể có tối đa 12 * 4 = 48 kết nối đồng thời tới điểm kết thúc IP. Bởi vì điều này được gắn với autoConfig, cách dễ nhất để tăng maxconnection trong một ứng dụng ASP.NET là thiết lập System.Net.ServicePointManager.DefaultConnectionLimit lập trình, từ Application_Start, ví dụ. Đặt giá trị cho số lượng kết nối System.Net đồng thời mà bạn mong đợi ứng dụng của mình sử dụng. Tôi đã thiết lập này để Int32.MaxValue và không có bất kỳ tác dụng phụ, vì vậy bạn có thể thử điều đó - đây thực sự là mặc định được sử dụng trong ngăn xếp HTTP gốc, WinHTTP. Nếu bạn không thể đặt System.Net.ServicePointManager.DefaultConnectionLimit theo chương trình, bạn sẽ cần phải tắt autoConfig, nhưng điều đó có nghĩa là bạn cũng cần phải đặt maxWorkerThreads và maxIoThreads. Bạn sẽ không cần đặt minFreeThreads hoặc minLocalRequestFreeThreads nếu bạn không sử dụng chế độ cổ điển/ISAPI.

3) Bạn thực sự nên xem xét cân bằng tải nếu bạn nhận được 20 nghìn khách truy cập mỗi giờ. Nếu mỗi người dùng đã yêu cầu 10-20 AJAX mỗi giờ, bạn có thể dễ dàng nói về 1 triệu cuộc gọi dịch vụ web trở lên với chương trình phụ trợ của mình. Việc ném lên một máy chủ khác sẽ giảm tải trên máy chủ chính. Kết hợp điều này với async/await, và bạn đã đặt mình vào một tình huống tốt, nơi bạn có thể dễ dàng ném phần cứng vào vấn đề (mở rộng quy mô). Có nhiều lợi ích ở đây như dự phòng phần cứng, định vị địa lý và hiệu suất. Nếu bạn đang sử dụng một nhà cung cấp đám mây như AWS hoặc RackSpace, hãy quay lên một máy ảo khác với ứng dụng của bạn trên nó đủ dễ dàng để nó có thể được thực hiện từ điện thoại di động của bạn. Điện toán đám mây quá rẻ hiện nay thậm chí còn có chiều dài hàng đợi. Bạn có thể làm điều này để cung cấp các lợi ích hiệu suất ngay cả trước khi bạn chuyển sang mô hình lập trình không đồng bộ.

4) Mở rộng quy mô: thêm phần cứng khác vào (các) máy chủ của bạn giúp đỡ vì nó cung cấp sự ổn định tốt hơn khi bạn có chủ đề bổ sung. Thêm chủ đề có nghĩa là bạn cần nhiều CPU và RAM hơn. Và ngay cả sau khi bạn đã nhận được async/await dưới vành đai của bạn, bạn vẫn sẽ muốn tinh chỉnh những yêu cầu dịch vụ web nếu bạn có thể. Điều này có thể có nghĩa là thêm vào một lớp đệm hoặc tăng cường hệ thống cơ sở dữ liệu của bạn. Bạn KHÔNG muốn tối đa hóa CPU trên máy chủ đơn đó. Khi CPU đạt 80%, ASP.NET sẽ ngừng tiêm thêm các luồng vào hệ thống. Nó không quan trọng nếu quá trình công nhân đang ngồi ở mức 0%, nếu việc sử dụng CPU hệ thống tổng thể theo báo cáo của Task Manager đạt đến 80%, thì dừng luồng và yêu cầu bắt đầu xếp hàng. Những điều kỳ lạ với bộ sưu tập rác cũng xảy ra khi nó phát hiện tải CPU cao trên máy chủ.