Tại sao apt-get KHÔNG sử dụng 100% (cpu HOẶC đĩa HOẶC net)?


21

Tại sao apt-get không sử dụng 100% cả cpu, đĩa hoặc mạng - hoặc thậm chí gần với nó? Ngay cả trên một hệ thống chậm (Raspberry Pi 2+) tôi đang tải tối đa 30% CPU. Tôi chỉ nghĩ rằng nó sẽ được điều chỉnh một cách giả tạo, hoặc nó sẽ tối đa hóa một cái gì đó trong khi nó đang hoạt động ... hoặc nó có thể làm điều đó nhanh hơn nó.

Chỉnh sửa: Tôi chỉ đo đại khái thông qua màn hình cpu / đĩa / mạng trong bảng điều khiển của mình và ứng dụng Giám sát hệ thống của Ubuntu MATE.

Hãy giải thích tại sao tôi sai. :-)

Cập nhật: Tôi hiểu rằng apt-getcần phải tìm nạp các bản cập nhật của nó (và có thể bị giới hạn bởi băng thông ngược dòng / nhà cung cấp). Nhưng một khi nó "giải nén" và cứ thế, việc sử dụng CPU ít nhất sẽ tăng lên (nếu không phải là tối đa). Trên máy trạm gia đình khá tốt của tôi, sử dụng ổ SSD cho ổ đĩa chính và ramdisk cho / tmp, đây không phải là trường hợp.

Hoặc có lẽ tôi cần xem xét kỹ hơn.


Làm thế nào để bạn đo đĩa và tải mạng?
JigglyNaga

1
Mặc dù vậy, đĩa IO cũng giống như IO mạng. Nó vẫn sẽ chặn ứng dụng, ngăn không cho nó sử dụng CPU. Than ôi, apt-getkhông đặc biệt tốt trong việc tối ưu hóa điều này. Tôi tưởng tượng nó có thể cài đặt khi tải xuống để đến khi tải xuống xong, hầu hết tải trọng của bạn đã được cài đặt, nhưng thật không may, nó không hoạt động. Trong mọi trường hợp, cài đặt độc lập chủ yếu chỉ trích xuất dữ liệu vào đĩa. Các hoạt động đó vốn đã bị ràng buộc IO, và đơn giản là không có nhiều việc phải làm ngoài việc chờ vào ổ đĩa để đọc xong hoặc ghi.
PSkocik

Làm thế nào bạn có được số lượng tải CPU 30% ?
AL

1
@PSkocik "Tôi tưởng tượng nó có thể cài đặt khi tải xuống" apt-get chỉ cần tải xuống, cài đặt dpkg. Và dpkg thông minh hơn apt-get theo thứ tự một gói các gói nên được cài đặt, có thể không giống với apt-get tải chúng xuống.
Braiam

Lưu ý rằng một ứng dụng bị ràng buộc 100% CPU trong một nửa tích tắc và sau đó ràng buộc 100% IO cho nửa kia sẽ xuất hiện không bị ràng buộc CPU cũng như ràng buộc IO ,.
MSalters

Câu trả lời:


28

Ứng dụng sẽ chỉ tối đa CPU nếu ứng dụng bị ràng buộc CPU . Một ứng dụng bị ràng buộc bởi CPU nếu nó có thể nhanh chóng lấy được tất cả dữ liệu của nó và điều nó chờ đợi là bộ xử lý để xử lý dữ liệu.

apt-get, mặt khác, bị ràng buộc IO . Điều đó có nghĩa là nó có thể xử lý dữ liệu của mình khá nhanh, nhưng việc tải dữ liệu (từ đĩa hoặc từ mạng) cần có thời gian, trong đó bộ xử lý có thể thực hiện các công việc khác hoặc không hoạt động nếu không có quy trình nào khác cần.

Thông thường, tất cả các yêu cầu IO (đĩa, mạng) đều chậm và bất cứ khi nào một luồng ứng dụng tạo một, kernel sẽ xóa nó khỏi bộ xử lý cho đến khi dữ liệu được tải vào kernel (= các yêu cầu IO này được gọi là yêu cầu chặn ).


6
Với aptcác lệnh, nó trở nên trầm trọng hơn bởi thực tế là nhiều tệp được mở ở chế độ đồng bộ hóa hoặc với các lần xả rõ ràng thường xuyên vào đĩa được yêu cầu để đảm bảo dữ liệu trên đĩa luôn ở trạng thái nhất quán vì sự cố hệ thống có thể gây hậu quả nghiêm trọng. Chạy aptcác lệnh với eatmydatathường có thể cải thiện đáng kể hiệu năng với chi phí giảm độ tin cậy (chưa kể các dịch vụ được bắt đầu như một phần của cài đặt gói sẽ kế thừa cài đặt eatmydata)
Stéphane Chazelas

Lol ở điểm cuối cùng đó :). Có ai có số cho eatmydata kể từ khi cam kết năm 2010 trong bug.debian.org/cgi-bin/ormsreport.cgi?orms=578635 không? Tôi không biết liệu "đáng kể" có phải là từ đúng hay không.
nguồn

Ah, có lẽ nó là (ít nhất là trên một số các nhà cung cấp điện toán đám mây) bugs.launchpad.net/cloud-init/+bug/1236531/comments/6
sourcejedi

1
@sourcejedi Trên Raspberry Pi2 với thẻ SD tương đối cao cấp (nhưng vẫn là thẻ SD, không phải SSD cao cấp), tôi cho rằng, một cách đáng kinh ngạc là một chút thiếu chính xác. Hiệu suất của dpkg trên phương tiện flash thực sự tệ.
Gilles 'SO- ngừng trở nên xấu xa'

1
Nếu nó bị ràng buộc bởi IO thì tại sao nó không sử dụng băng thông đĩa 100%?
dùng253751

15

Ngay cả trên một hệ thống chậm (Raspberry Pi 2+) tôi đang tải tối đa 30% CPU.

Raspberry Pi 2+ có 4 lõi. Đối với một số công cụ giám sát, mức sử dụng 100% tương ứng với tất cả các lõi đã được sử dụng ở mức 100%. Nếu chỉ có một lõi trong bộ xử lý mã tứ được sử dụng, tải CPU là 25%. Tải CPU 30% mà bạn đề cập là khoảng một lõi được sử dụng ở mức 100% trong khi một số quy trình đang chạy trên các lõi khác:

(100% on one core out of 4 = 100 / 4 = 25%) + some processes ≃ 30%

apt-getkhông phải là đa luồng, nó sẽ không bao giờ sử dụng nhiều hơn một bộ xử lý, chiếm 25% tổng tài nguyên CPU.


Dưới đây là một ví dụ trên máy 8 lõi của tôi (4 lõi với Hyper-Threading ) chạy Ubuntu, tôi đã khởi chạy một luồng với cat /dev/zero > /dev/nulllệnh để tạo một quy trình vô hạn sử dụng hoàn toàn một lõi.

Bây giờ nếu chúng ta nhìn vào biểu đồ từ htop, chúng ta có thể thấy rằng tải trung bình ( Avgthanh) là 12.7%, tương ứng với một lõi được sử dụng ở mức 100%, cũng là 1/8 của tất cả các tài nguyên CPU:

(100% = 100 / 8 = 12.5%) + some background processes ≃ 12.7%.

đỉnh

Cũng có thể lưu ý rằng lệnh có giá trị 100%trong CPU%cột, điều này là do nó liên quan đến một lõi và không phải tất cả các lõi.


+1,% sử dụng gần với bội số (100 / nCores) sẽ luôn luôn kích hoạt sự xem xét kỹ lưỡng hơn nữa. Điều này có thể được kiểm tra - và thực sự bị loại trừ - bằng cách sử dụng màn hình có thể hiển thị mức sử dụng trên mỗi lõi, trong đó 0 <=% <= 100 * nCores
underscore_d

Không phải là /dev/zero > /dev/nullmột ví dụ tốt hơn, vì urandom sẽ làm cạn kiệt entropy?
Filip Haglund

@FilipHaglund cat /dev/zero > /dev/nullcho kết quả tương tự, tôi không biết thiết bị đó, cảm ơn. urandom sẽ làm cạn kiệt entropy pool Tôi không biết pool entropy, làm thế nào nó có thể là một vấn đề?
AL

1
Khi các chương trình sử dụng tiền điện tử, họ cần dữ liệu thực sự ngẫu nhiên để tạo các khóa mã hóa an toàn. Máy tính tạo entropy bằng cách xem chuột di chuyển giữa những thứ khác. Có các bộ tạo số ngẫu nhiên phần cứng, nhưng hầu hết các máy tính không có chúng. Nếu entropy được sử dụng hết, mã cần entropy an toàn phải chờ thêm để được tạo. Urandom sẽ sử dụng các bit thực sự ngẫu nhiên nếu có, hoặc trả lại các bit ngẫu nhiên kém an toàn hơn.
Filip Haglund

Khi các chương trình sử dụng tiền điện tử Ngay cả khi tôi nghĩ rằng không ai sẽ thực hiện điểm chuẩn CPU trong khi tạo khóa ngẫu nhiên, tôi đã cập nhật câu trả lời của mình để đề phòng.
AL

2

Tôi nghĩ rằng bạn thực sự không đo IO%. Tôi chưa thấy tiện ích Linux IO%. (Tôi rất ghen tị với trình quản lý tác vụ Windows 10 :). Kiểm tra bằng iotoplệnh và bạn sẽ thấy 100% IO.

topsẽ hiển thị 100% trên user+ system+ iowait, với các giá trị được chia 100% cho số lượng cốt lõi của bạn như được mô tả bởi AL Tôi không nói toplà hữu ích 100%, nhưng nó có thể là một công cụ thực sự hữu ích để tìm hiểu.

Thông lượng sẽ thấp hơn mức tối đa, bởi vì bạn đang giải nén rất nhiều tệp nhỏ, còn gọi là "IO ngẫu nhiên". Ngoài ra còn có một số lỗi đồng bộ hóa / bộ đệm đĩa, mặc dù từ năm 2010 trên Linux chỉ có một vài trong số chúng cho mỗi gói được cài đặt. ( Được sử dụng là một cho mỗi tệp ).


Sử dụng iotop --only, các --onlytùy chọn chỉ hiển thị các tiến trình hoặc đề thực sự làm I / O .
AL

4
i bổ sung, dstat, trên đỉnh ... sẽ hiển thị trên mỗi lần sử dụng đĩa mà không cần đặc quyền. Đó là để sử dụng cho mỗi nhiệm vụ mà bạn cần đặc quyền
Stéphane Chazelas

@ StéphaneChazelas hoàn toàn chính xác. Điểm tôi đang cố gắng thực hiện (chỉnh sửa ninja) là OP đề cập đến một vài công cụ GUI. Và các công cụ GUI cụ thể mà tôi đã thấy, như Gnome System Monitor, hiển thị thông lượng nhưng không có IO%.
nguồn

2

Trên thực tế, các yêu cầu IO / Network rất chậm so với CPU ops. Điều này có nghĩa là trong khi card mạng của bạn đang tìm nạp dữ liệu hoặc đĩa của bạn đang ghi dữ liệu này, CPU của bạn hoàn toàn không làm gì cả (dù sao cho quá trình này).

Nếu ổ cứng của bạn nhanh hơn kết nối mạng của bạn (điều này có thể đúng), nó sẽ không ghi nhiều hơn số tiền nhận được.

Cuối cùng, tỷ lệ phần trăm mạng tương ứng với mức sử dụng card mạng tối đa có thể , không phải kết nối. Vì vậy, bạn có thể có bộ điều hợp mạng 1Gb / s, bạn thực sự không có kết nối internet đạt được băng thông này.

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.