Điểm:4

Máy chủ này có bị quá tải không (ảnh chụp màn hình htop)

lá cờ bd

Tôi không phải là người phục vụ, tôi nghĩ nó có vẻ quá tải nhưng tôi không chắc. Bạn có nói rằng máy chủ này đang quá tải? nhập mô tả hình ảnh ở đây

lá cờ jp
Vâng, nó bị quá tải, tải trung bình quá cao cho hai CPU
Jack0220 avatar
lá cờ bd
Cảm ơn. Bạn nên đưa ra câu trả lời đó để có thể nhận được tín dụng. @AlexD
Criggie avatar
lá cờ in
@Jack0220 Đây là máy vật lý hay máy ảo? Tôi hỏi vì máy vật lý 2 lõi hiện tại có thể đã hơi cũ (do đó việc thay thế trở nên quan trọng hơn), trong khi máy ảo thường có thể được tăng kích thước mà không cần khởi động lại (và có thể cao hơn hàng tháng nếu bạn đang ở AWS hoặc tương tự)
Craig Estey avatar
lá cờ kr
Bạn có rất nhiều chủ đề/quy trình. _Nếu_ bạn có thể cấu trúc lại ứng dụng/máy chủ và mỗi yêu cầu là "nhẹ", bạn có thể triển khai "nhóm luồng". Nghĩa là, chi phí tạo/tham gia một luồng cao hơn so với quá trình xử lý. Máy chủ xác định một nhóm gồm N luồng (ví dụ: trong đó N là số lõi * 2). Máy chủ bắt đầu các chủ đề. Nó có thể xếp các yêu cầu vào một hàng đợi chung. Mỗi luồng lấy một yêu cầu từ hàng đợi, xử lý nó và sau đó lặp/ngủ trên hàng đợi, chờ thêm công việc. Nếu không, chỉ cần "tiêu tiền" ;-)
James avatar
lá cờ in
"*máy chủ* này có bị quá tải không"? Không thể nói từ dữ liệu được cung cấp. Phần mềm nào đang chạy và phần mềm đó có phụ thuộc nhiều vào CPU không, v.v. Mọi thứ chạy chậm hay bạn thực sự ổn ở mức cao nhất? Vì vậy, các tài nguyên cần thiết đã được đáp ứng, mặc dù với các tài nguyên có sẵn ở mức tối đa. Cái sau là "nói chung" không tốt vì bạn nên có một số chi phí hoạt động khi thứ gì đó cần nhiều hơn kế hoạch hoặc thường cần, v.v. "*CPU* này có bị quá tải không" không, đó là mức sử dụng tối đa.
Điểm:12
lá cờ jp

Máy chủ của bạn chỉ có hai CPU và LA (tải trung bình) trong khoảng 10-15. Điều đó có nghĩa là các tiến trình đang chạy cần nhiều thời gian hơn CPU có thể xử lý. Bạn có thể đọc nhiều hơn về LA trong bài viết này của Brendan Gregg.

Xin lưu ý rằng LA chỉ là một số liệu duy nhất và mặc dù hệ thống của bạn không nhận được tất cả thời gian CPU mong muốn nhưng vẫn có thể có đủ thời gian CPU để phục vụ các yêu cầu của người dùng cuối một cách hợp lý. Bạn cần kiểm tra các chỉ số khác của mình trước khi đưa ra bất kỳ quyết định nào về máy chủ này nhưng nếu người dùng của bạn đã phàn nàn thì giải pháp đã rõ ràng - hãy lấy một phiên bản có nhiều CPU hơn.

Jack0220 avatar
lá cờ bd
Tôi trân trọng điều đó. Hệ thống tiếp tục đạt đỉnh. Nhìn chung, nó có thể xử lý tải nhưng không kịp thời. Máy chủ thường không phản hồi hoặc phản hồi quá muộn. Bạn đã xác nhận sự nghi ngờ của tôi.
marcelm avatar
lá cờ ng
_"Máy chủ của bạn chỉ có hai CPU và LA (tải trung bình) trong khoảng 10-15."_ - Chưa hết, 2 trên 3 ảnh chụp màn hình cho thấy mức sử dụng CPU ở mức khoảng 60%. Tôi sẽ không nhanh chóng đánh giá rằng máy chủ bị ràng buộc bởi CPU. Nó có thể là giới hạn I/O. Tôi cũng thấy áp lực bộ nhớ tương đối cao, điều này có thể không giúp ích gì cho tình huống I/O. Và dù bằng cách nào, tải cao không có nghĩa là hệ thống bị quá tải. Một máy chủ không nhạy cảm với độ trễ được sử dụng tốt (ví dụ: thư) có thể hoàn toàn ổn với tải cao. Nó phụ thuộc vào tình hình.
Guntram Blohm avatar
lá cờ in
Tuy nhiên, không có một quy trình nào trong chế độ D và (một phần) redis dường như tiêu thụ 100% CPU (có nghĩa là nó là một luồng đơn hoặc nó sẽ vượt quá 100%). Điều đó có thể có nghĩa là mọi thứ khác đang chờ bản làm lại (khá làm việc quá sức) và việc thêm lõi sẽ không giúp được gì nhiều ở đây. Tôi sẽ kiểm tra các tệp nhật ký và cấu hình redis trước khi ném thêm lõi vào sự cố.
lá cờ jp
@marcelm Tôi đồng ý rằng có thể có tải I/O đáng kể do `redis-rdb-bgsave` đang chạy nhưng thật khó để nói vì không có sẵn chỉ số iowait và không có quy trình nào có trạng thái 'D'. Cũng xin lưu ý rằng trên mỗi ảnh chụp màn hình, 1 phút LA thấp hơn 15 phút LA, do đó, hơi dài đối với ảnh chụp nhanh 2 GB.Ngoài ra, phần lớn thời gian của CPU được dành cho quy trình `chirpstack-network-server`.
lá cờ jp
Vì hệ thống đang chạy trên AWS, tôi khuyên bạn nên chuyển `redis` sang phiên bản ElastiCache Redis được quản lý nhưng điều này sẽ gây ra độ trễ mạng bổ sung có thể ảnh hưởng đến hiệu suất hệ thống.
Jack0220 avatar
lá cờ bd
Cảm ơn tất cả các bạn cho đầu vào bổ sung. Đây là máy chủ mạng LoRa và nhạy cảm với độ trễ. Có các đường xuống để đáp ứng các đường lên cần được phân phối rất nhanh và những gì tôi thấy là chúng thường đến quá muộn và đôi khi chúng không đến chút nào. Các đường lên không thường xuyên nên có thể một loạt chúng xảy ra cùng một lúc, vượt quá hệ thống. @marcelm Guntram Blohm
Điểm:10
lá cờ mx

Xác định âoverloadedâ.

Nếu bạn chỉ chạy theo mức tải trung bình, thì vâng, nó bị quá tải (theo hệ số khoảng 5-7,5). Tuy nhiên, tải trung bình chỉ là một số liệu hợp lý để sử dụng nếu khối lượng công việc của bạn song song với số lượng lớn và chủ yếu dành cho CPU. Tải trung bình về cơ bản theo dõi số lượng trung bình của các quy trình có thể chạy trong 1/5/15 phút qua.

Tuy nhiên, dựa trên hai ảnh chụp màn hình của bạn, mức sử dụng CPU tức thời của bạn không phải lúc nào cũng đạt 100% khả năng của hệ thống. Điều này, kết hợp với mức trung bình tải cao, có nghĩa là nhiều quy trình cần chạy, nhưng chúng chạy nhanh và sau đó được thực hiện. Điều đó khá bình thường đối với một hệ thống cung cấp dịch vụ mạng, vì hầu hết các dịch vụ mạng đều không phải Giới hạn CPU, nhưng thay vào đó là giới hạn IO. Điều này có nghĩa là tải trung bình không phải là thước đo tốt để xác định việc sử dụng tài nguyên trên hệ thống.

Điều bạn thực sự nên xem xét ở đây (và thực ra, điều bạn thực sự nên tìm kiếm đầu tiên không tí nào dịch vụ mạng) là thước đo hiệu suất của chính dịch vụ đó.Trong hầu hết các trường hợp, các phép đo có liên quan là phép đo độ trễ cho các loại yêu cầu khác nhau mà dịch vụ phục vụ (và cụ thể hơn, bạn thường muốn quan tâm đến độ trễ trung bình và một trong các phân vị thứ 95 hoặc 99 hoặc độ trễ cao nhất). htop khá đơn giản là không thể theo dõi điều này cho bạn, bạn cần xem xét một công cụ khác, chẳng hạn như dữ liệu mạng (từ chối trách nhiệm, tôi làm việc cho Netdata) hoặc Prometheus.

Thậm chí còn tốt hơn thế: Người dùng có báo cáo sự cố không? Nếu câu trả lời là không, không có sự cố nào được báo cáo, thì có lẽ máy chủ có bị “quá tải” hay không cũng không liên quan, bởi vì mọi thứ đang hoạt động đủ tốt.

lá cờ jp
các quy trình liên kết mạng không ảnh hưởng đến `LA`, vì vậy bạn sẽ không nhận được `LA` > `số lượng CPU` trên các hệ thống liên kết IO mạng. Khi `LA` > `n CPUs` có nghĩa là có rất nhiều tiến trình đang chờ CPU nhưng không chạy được, chứ không phải là "chạy nhanh là xong" (trong trường hợp đó bạn sẽ nhận được LA số lượng CPU gần bằng nhau) . LA cao có nghĩa là hệ thống **là** liên kết với CPU hoặc liên kết với IO của đĩa. "CPU tức thời không liên tục 100%" có nghĩa là hệ thống đã vượt quá mức tải tối đa, bạn có thể thấy nó từ 1m LA là ít hơn 5 và 10 phút LA.
Jack0220 avatar
lá cờ bd
Có, có vấn đề với dịch vụ cuối, máy chủ không phải lúc nào cũng phản hồi đủ nhanh. Có các liên kết lên và một số trong số chúng yêu cầu các liên kết xuống để đáp ứng. Độ trễ đường xuống đôi khi vượt quá 5 giây, quá muộn (đây là hệ thống LoRa). Tôi sẽ xem netdata, nó trông rất đẹp. Vấn đề là những người chịu trách nhiệm về máy chủ này đặt mọi máy chủ vào cùng một phiên bản thay vì trải rộng ra. Nó có thể hoạt động lúc đầu nhưng khi hệ thống phát triển thì điều này không bền vững. Rất cám ơn tất cả mọi người cho những ý tưởng tốt!

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.