Làm thế nào để tìm ra nguyên nhân tăng tải máy chủ


12

Tôi đang gặp vấn đề về tải với máy chủ của mình và mặc dù hiện tại tôi là một quản trị viên Linux có kinh nghiệm.

Vấn đề là tải chậm nhưng tăng đều đặn trên máy chủ mà không có bất kỳ nguyên nhân rõ ràng nào.

Máy chủ là Bộ xử lý lõi kép AMD Athlon (tm) 64 X2 6000+ với RAM 6GB. Nó đang chạy Debian Ổn định với Linux gir 2.6.26-2-amd64 # 1 SMP Thứ tư, ngày 19 tháng 8, 22:33:18 UTC 2009 x86_64 GNU / Linux.

Về cơ bản, máy chủ chạy Lighttpd, một số quy trình PHP FastCGI và cơ sở dữ liệu MySQL. Nhiệm vụ máy chủ web điển hình.

CPU không bao giờ thực sự được sử dụng hết và bộ nhớ chủ yếu được sử dụng cho bộ đệm và bộ đệm. Tôi đã thử khởi động lại các dịch vụ khác nhau để xem liệu một trong số chúng có giảm tải nữa không, nhưng không gặp may.

Dưới đây là đồ họa hiển thị tải, CPU và IOStat:

Vì vậy, câu hỏi là: Điều gì có thể gây ra tải chậm nhưng không ngừng tăng? Và làm thế nào để tôi tìm ra những gì chịu trách nhiệm?

Cập nhật: Tôi quên đề cập, khi tôi khởi động lại máy chủ, tải sẽ giảm xuống khoảng 0,3 đến 0,6 và sẽ bắt đầu tăng trở lại từ từ trong tuần tới.


1
Những hình ảnh bạn đăng không còn tồn tại. Xin vui lòng tải lại chúng nếu bạn vẫn còn bản sao.
Michael Hampton

Câu trả lời:


6

Mỗi quá trình zombie thêm 1.0 vào tải. Bạn có thể thấy sự tích lũy của thây ma.


Đúng. Kiểm tra biểu đồ " Số lượng quá trình ".
Teddy

Nếu đó là chính xác, sau đó gõ for N in {1..100} ; do sleep 60 & done ; exec sleep 500nên đủ để gây ra tải cao. Nhưng nó không. Lệnh đó tạo ra 100 zombie, nhưng tải trên máy tính của tôi vẫn ở dưới 1.
kasperd 7/12/14

5

Tôi tìm thấy một gợi ý tuyệt vời trong câu trả lời cho một câu hỏi khác .

Tìm kiếm các quy trình ở trạng thái 'D' cho thấy bốn quy trình PHP dường như bị treo khá lâu tương ứng với các "bước" trong đường cong tải:

#> ps aux | awk '$8 ~ /D/  { print $0 }'
wiki      6651  0.0  0.0      0     0 ?        D    Oct04   0:41 [php-cgi]
bugs      6731  0.0  0.0      0     0 ?        D    Oct27   0:14 [php-cgi]
manpages  7536  0.0  0.0      0     0 ?        D    Oct30   0:21 [php5-cgi]
wiki     23847  0.0  0.0      0     0 ?        D    Oct06   1:32 [php-cgi]

Vì vậy, những điều này dường như là vấn đề. Bây giờ tôi cần tìm hiểu trong khi các quy trình đó bị treo và cách khắc phục. Cảm ơn mọi người.


Câu trả lời này đã giải quyết vấn đề của tôi. Tải tăng từ 0,5 đến 350 và tiếp tục tăng. Đó là do quá trình zombie cố gắng đọc một thư mục từ xa đã bị xóa.
Philippe Delteil

2

Tôi đoán là máy chủ bị bỏ đói IO, có lẽ bạn nên thêm số liệu thống kê iotop vào biểu đồ

Tôi tự hỏi nếu bạn có thể có một hoạt động io cho mỗi ứng dụng cũng là một yếu tố cho tải máy chủ

http://rt.wiki.kernel.org/index.php/I/Otop_utility

công cụ khác là dstat


Tôi đã thêm đồ họa cho IOStat. IO đĩa không tăng khi tải. Đó có phải là những gì bạn đã nhắm đến?
Andreas Gohr

Oh và dstat có vẻ hữu ích. Tôi phải đọc thêm một chút về nó.
Andreas Gohr

2

Nếu là I / O, thì anh ta sẽ thấy iowait (màu hồng) trên biểu đồ cpu.


0

Loại sự cố này thường xuất phát từ ổ cứng không đủ nhanh để phục vụ dữ liệu theo yêu cầu của cơ sở dữ liệu MySQL và máy chủ HTTP. Bạn nên nhìn vào lệnh iostat


IO có vẻ bình thường với tôi. Và nó sẽ không giải thích tại sao tải đang tăng chậm.
Andreas Gohr

-1

Nói chung, thực sự không phải là một điều xấu khi có tải máy chủ cao; điều đó có nghĩa là bạn không ngồi yên và làm ít hơn bạn có thể. Tải 80% -90% tổng công suất của bạn (với một số phòng "nổ") là những gì thường được tìm kiếm. Tôi khuyên bạn nên kiểm tra đầu ra của mpstat và vmstat. Đặc biệt, 2 số đầu tiên từ vmstat có thể cung cấp cho bạn thông tin có ý nghĩa hơn về cách bạn "sao lưu" về mặt quy trình trong hàng đợi chạy. Cột cuối cùng ("wa") của đầu ra vmstat có thể cho bạn biết nếu và trong bao lâu, bạn đang chờ hoàn thành I / O. Kích thước hàng đợi chạy và thời gian chờ I / O thường tương quan với nhau. Ngoài ra hãy kiểm tra sar (từ gói sysstat): cung cấp cho bạn cái nhìn chi tiết về những gì đang diễn ra trong một khoảng thời gian; các số liệu mà nó ghi lại là rất kỹ lưỡng.

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.