2010-01-12 26 views
50

Ứng dụng web ASP.NET chạy trên IIS6 định kỳ bắn CPU lên đến 100%. Đó là W3WP chịu trách nhiệm cho gần như tất cả việc sử dụng CPU trong các tập phim này. CPU vẫn được ghim ở 100% ở bất cứ nơi nào từ vài phút đến hơn một giờ.W3WP.EXE sử dụng CPU 100% - bắt đầu từ đâu?

Đây là trên máy chủ dàn dựng và trang web chỉ nhận được lưu lượng truy cập rất nhẹ từ những người thử nghiệm tại thời điểm này.

Chúng tôi đã chạy trình thu thập kiến ​​thức ANTS trên máy chủ nhưng chưa rõ ràng.

Chúng ta có thể bắt đầu tìm hiểu điều gì gây ra những tập này và mã nào giữ CPU bận rộn trong suốt thời gian đó?

+0

Bạn đang bằng cách nào đó đăng nhập ngoại lệ bên trong của bạn mã? Gọi một cái gì đó như "Logger.Log (ngoại lệ)"? – wtaniguchi

Trả lời

34
  1. Bộ đếm hiệu suất Windows chuẩn (tìm các hoạt động tương quan khác, chẳng hạn như nhiều yêu cầu GET, mạng quá mức hoặc đĩa I/O, v.v ...); bạn có thể đọc chúng từ mã cũng như từ perfmon (để kích hoạt thu thập dữ liệu nếu sử dụng CPU vượt quá ngưỡng, ví dụ)
  2. Bộ đếm hiệu suất tùy chỉnh (đặc biệt là thời gian yêu cầu không thực hiện)
  3. Tải thử nghiệm, sử dụng các công cụ như Visual Studio Team Test hoặc WCAT
  4. Nếu bạn có thể thử nghiệm hoặc nâng cấp lên IIS 7, bạn có thể định cấu hình truy vấn không thành công để tạo dấu vết nếu yêu cầu mất nhiều thời gian nhất định
  5. Sử dụng logparser để xem yêu cầu nào đến thời điểm tăng đột biến CPU
  6. Đánh giá mã/lượt đi bộ (cụ thể là l ook cho các vòng lặp có thể không kết thúc đúng cách, chẳng hạn như nếu xảy ra lỗi, cũng như các khóa và các vấn đề về luồng tiềm năng, chẳng hạn như sử dụng các số liệu thống kê)
  7. Cấu hình CPU và bộ nhớ (có thể khó trên hệ thống sản xuất)
  8. Process Explorer
  9. Windows Resource Monitor
  10. lỗi đăng nhập chi tiết
  11. Tuỳ dấu vết khai thác gỗ, bao gồm chi tiết thời gian thực hiện (có lẽ có điều kiện, dựa trên CPU sử dụng perf truy cập)
  12. Are các lỗi xảy ra khi AppPool tái chế ? Nếu vậy, nó có thể là một đầu mối.
+6

Tôi sẽ chỉ thêm vào bản ghi những gì đã kết thúc đưa chúng tôi đến nguồn gốc của vấn đề: ** SQL Profiler **. Chúng tôi đã có một truy vấn LINQ to SQL phức tạp bao gồm một tham chiếu đến một đối tượng trong bộ nhớ, do đó nó không thể dịch toàn bộ truy vấn vào bộ nhớ và thay vào đó là tắt hàng nghìn truy vấn SQL nhỏ để thực hiện một phép nối. –

0

Chúng tôi đã có điều này trên một truy vấn đệ quy đã bán phá giá tấn dữ liệu cho đầu ra - bạn có kiểm tra lại mọi thứ không xuất hiện và không tồn tại vòng lặp vô hạn?

Có thể cố gắng thu hẹp nó xuống bằng một trang duy nhất - chúng tôi thấy ANTS không giúp được gì nhiều trong cùng trường hợp đó - những gì chúng tôi đã làm là chạy trang web truy cập trang xem CPU - nhấn vào trang tiếp theo CPU - rất có phương pháp và tốn thời gian nhưng nếu bạn không thể tìm thấy nó với một số truy tìm mã, bạn có thể không may mắn -

Chúng tôi có thể sử dụng tệp nhật ký IIS để theo dõi nó thành một nhóm trang nghi ngờ -

Hy vọng điều đó sẽ hữu ích!

4

Nếu CPU của bạn đang tăng lên 100% và ở đó, rất có khả năng bạn có tình huống bế tắc hoặc vòng lặp vô hạn. Một profiler có vẻ như là một lựa chọn tốt cho việc tìm kiếm một vòng lặp vô hạn. Tuy nhiên, rất nhiều khó khăn để theo dõi.

+1

Sử dụng dotTrace profiler và chọn "Call Tree" theo "All Threads" để hiển thị các phương thức được hầu hết CPU được dùng để nhóm thành 1 ngăn xếp cuộc gọi.Theo dõi xuống để xem chính xác vị trí. –

11

Nó không có nhiều câu trả lời, nhưng bạn có thể cần phải đi học cũ và chụp ảnh chụp nhanh của quá trình IIS và gỡ lỗi nó. Bạn cũng có thể muốn kiểm tra blog của Tess Ferrandez - cô ấy là một kỹ sư leo thang ** microsoft và blog của cô ấy tập trung vào việc gỡ lỗi các cửa sổ ASP.NET, nhưng blog có liên quan đến gỡ lỗi cửa sổ nói chung. Nếu bạn chọn thẻ ASP.NET (đó là những gì tôi đã liên kết đến) thì bạn sẽ thấy một số mục tương tự.

1

Ngoài ra, hãy xem bộ đếm nước hoa của bạn. Họ có thể cho bạn biết rất nhiều thời gian cpu đang được chi tiêu. Dưới đây là một liên kết đến các quầy phổ biến nhất để sử dụng:

4

Process Explorer là một công cụ tuyệt vời để gỡ rối. Bạn có thể thử nó để tìm kiếm vấn đề sử dụng cao CPU. Nó cung cấp cho bạn một cái nhìn sâu sắc vào cách ứng dụng của bạn hoạt động.

Bạn cũng có thể thử Procdump để kết thúc quá trình và phân tích những gì thực sự đã xảy ra trên CPU.

-2

Nếu bạn xác định một trang cần thời gian để tải, hãy sử dụng Developer Dashboard của SharePoint để xem thành phần nào cần thời gian.

+4

Tôi không nghĩ rằng tôi thấy Sharepoint được đề cập ở đây. –

0

Đây là phỏng đoán tốt nhất, nhưng có lẽ nhóm phát triển của bạn đang xây dựng và triển khai ứng dụng ở chế độ gỡ lỗi, thay cho chế độ phát hành. Điều này sẽ gây ra sự xuất hiện của các tập tin .pdb. Ý nghĩa của điều này là ứng dụng của bạn sẽ mất thêm tài nguyên để thu thập thông tin trạng thái hệ thống và gỡ lỗi trong quá trình thực thi hệ thống của bạn, khiến cho việc sử dụng bộ vi xử lý tăng lên.

Vì vậy, nó sẽ đủ đơn giản để đảm bảo rằng chúng đang xây dựng và triển khai trong chế độ phát hành.

0

Đây là một bài đăng rất cũ, tôi biết, nhưng đây cũng là một vấn đề phổ biến. Tất cả các phương pháp được đề xuất đều rất hay nhưng chúng sẽ luôn chỉ ra quy trình và có nhiều cơ hội mà chúng tôi biết rằng trang web của chúng tôi đang gây ra sự cố, nhưng chúng tôi chỉ muốn biết trang cụ thể dành quá nhiều thời gian để xử lý. Công cụ chính xác và đơn giản nhất trong quan điểm của tôi là bản thân IIS.

  1. Chỉ cần nhấp vào máy chủ của bạn trong ngăn bên trái của IIS.
  2. Nhấp vào 'Quy trình công nhân' trong ngăn chính. bạn đã thấy hồ bơi ứng dụng nào đang dùng quá nhiều CPU.
  3. Kích đúp vào dòng này (thậm chí làm mới bằng cách nhấp vào 'Show All') để xem những gì các trang tiêu thụ quá nhiều thời gian CPU ('Thời gian trôi qua' cột) trong hồ bơi này