Dlaczego apt-get NIE używa 100% (procesor LUB dysk LUB sieć)?


21

Dlaczego apt-get nie używa 100% procesora, dysku lub sieci - a nawet blisko niego? Nawet w wolnym systemie (Raspberry Pi 2+) mam maksymalnie 30% obciążenia procesora. Po prostu myślę, że albo jest sztucznie dławione, albo powinno maksymalnie zwiększyć wydajność podczas pracy ... albo powinno być w stanie robić to szybciej niż robi.

Edycja: Właśnie mierzę z grubsza za pomocą monitorów cpu / disk / net w moim panelu oraz aplikacji System Monitor systemu Ubuntu MATE.

Wyjaśnij, dlaczego się mylę. :-)

Aktualizacja: Rozumiem, że apt-getnależy pobrać aktualizacje (i mogą być ograniczone przepustowością łącza nadawczego / dostawcy). Ale kiedy „rozpakowanie” i tak dalej, użycie procesora powinno przynajmniej wzrosnąć (jeśli nie maksymalnie). Na mojej dość przyzwoitej domowej stacji roboczej, która używa dysku SSD jako napędu głównego i ramdysku dla / tmp, tak nie jest.

A może muszę przyjrzeć się bliżej.


Jak mierzysz obciążenie dysku i sieci?
JigglyNaga,

1
Dysk IO jest jednak podobny do sieciowego IO. Nadal będzie blokować aplikację, uniemożliwiając jej użycie procesora. Niestety, apt-getnie jest szczególnie dobry w optymalizacji tego. Wyobrażam sobie, że można go zainstalować podczas pobierania, aby do czasu zakończenia pobierania większość ładunku mogła już zostać zainstalowana, ale niestety tak się nie dzieje. W każdym razie samodzielne instalacje przeważnie po prostu wyodrębniają dane na dysk. Te operacje są z natury związane z IO i po prostu nie ma wiele więcej do roboty niż czekać na dysku, aby zakończyć odczyt lub zapis.
PSkocik

Jak uzyskałeś 30% obciążenia procesora ?
AL

1
@PSkocik „Wyobrażam sobie, że można zainstalować podczas pobierania” apt-get tylko pobiera, instaluje dpkg. A dpkg jest mądrzejszy niż apt-get w takiej kolejności, w jakiej należy zainstalować kilka pakietów, co może nie być tym samym, co apt-get je pobiera.
Braiam

Zauważ, że aplikacja, która jest w 100% związana z procesorem dla połowy tiku, a następnie w 100% związana z IO dla drugiej połowy nie pojawi się ani związana z procesorem, ani związana z IO.
MSalters

Odpowiedzi:


28

Aplikacje będą maksymalnie obciążały procesor tylko, jeśli aplikacja jest związana z procesorem . Aplikacja jest powiązana z procesorem, jeśli może szybko uzyskać wszystkie swoje dane, a procesor przetwarza dane.

apt-getz drugiej strony jest związany z IO . Oznacza to, że może przetwarzać swoje dane dość szybko, ale ładowanie danych (z dysku lub z sieci) zajmuje dużo czasu, podczas którego procesor może wykonywać inne czynności lub pozostawać bezczynny, jeśli inne procesy go nie potrzebują.

Zazwyczaj wszystkie żądania We / Wy (dysk, sieć) są wolne i za każdym razem, gdy wątek aplikacji je tworzy, jądro usuwa je z procesora, dopóki dane nie zostaną załadowane do jądra (= te żądania We / Wy nazywane są żądaniami blokującymi ).


6
W przypadku aptpoleceń pogarsza to fakt, że wiele plików jest otwartych w trybie synchronizacji lub częste jawne opróżnianie dysku w celu zagwarantowania, że ​​dane na dysku pozostaną w spójnym stanie, ponieważ awaria systemu może mieć poważne konsekwencje. Uruchamianie aptpoleceń za eatmydatapomocą często może znacznie poprawić wydajność kosztem zmniejszonej niezawodności (nie wspominając, że usługi uruchomione w ramach instalacji pakietów odziedziczą ustawienia
eatmydata

Lol w tym ostatnim punkcie :). Czy ktoś ma numery dla eatmydata od czasu zatwierdzenia w 2010 roku w bugs.debian.org/cgi-bin/bugreport.cgi?bug=578635 ? Nie wiem, czy „dramatycznie” jest nadal właściwym słowem.
sourcejedi

Ach, może to jest (przynajmniej u niektórych dostawców chmury) bugs.launchpad.net/cloud-init/+bug/1236531/comments/6
sourcejedi

1
@sourcejedi Na Raspberry Pi2 ze stosunkowo wysokiej klasy kartą SD (ale nadal kartą SD, a nie wysokiej klasy dyskami SSD) uważam, że „dramatycznie” to trochę za mało powiedziane. Wydajność dpkg na Flash Media naprawdę jest do kitu.
Gilles „SO- przestań być zły”

1
Jeśli jest związany z dyskiem IO, to dlaczego nie wykorzystuje 100% przepustowości dysku?
user253751

15

Nawet w wolnym systemie (Raspberry Pi 2+) mam maksymalnie 30% obciążenia procesora.

Raspberry Pi 2+ ma 4 rdzenie. W przypadku niektórych narzędzi do monitorowania użycie 100% odpowiada wszystkim rdzeniom użytym w 100%. Jeśli używany jest tylko jeden rdzeń procesora czterokodowego, obciążenie procesora wynosi 25%. Wspomniane 30% obciążenie procesora to w przybliżeniu jeden rdzeń używany na 100%, podczas gdy niektóre procesy działają na innych rdzeniach:

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

Ponieważ apt-getnie jest wielowątkowy, nigdy nie użyje więcej niż jednego procesora, co stanowi 25% wszystkich zasobów procesora.


Oto przykład na moich 8 rdzeniach (4 rdzenie z Hyper-Threading ) na maszynie z Ubuntu, uruchomiłem jeden wątek z cat /dev/zero > /dev/nullpoleceniem, aby stworzyć nieskończony proces, który całkowicie wykorzystuje jeden rdzeń.

Teraz, jeśli spojrzymy na wykres htop, zobaczymy, że średnie obciążenie ( Avgbar) wynosi 12.7%, co odpowiada jednemu rdzeniu użytemu na 100%, co stanowi również 1/8 wszystkich zasobów procesora:

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

htop

Można również zauważyć, że polecenie ma wartość 100%w CPU%kolumnie, ponieważ jest to związane z jednym rdzeniem, a nie ze wszystkimi rdzeniami.


+1, użycie% zbliżone do wielokrotności (100 / nCores) zawsze powinno uruchamiać dalszą kontrolę. Można to sprawdzić - i rzeczywiście jest to wykluczone - za pomocą monitora pokazującego użycie dla rdzenia, gdzie 0 <=% <= 100 * nCores
underscore_d

Czy nie /dev/zero > /dev/nulljest lepszym przykładem, skoro urandom wyczerpuje pulę entropii?
Filip Haglund

@FilipHaglund cat /dev/zero > /dev/nulldaje ten sam wynik, nie znałem tego urządzenia, dzięki. urandom wyczerpuje pulę entropii Nie znam puli entropii, jak może to stanowić problem?
AL

1
Gdy programy używają szyfrowania, potrzebują prawdziwie losowych danych, aby wygenerować bezpieczne klucze szyfrowania. Komputer generuje entropię, obserwując między innymi ruch myszy. Istnieją sprzętowe generatory liczb losowych, ale większość komputerów ich nie ma. Jeśli entropia zostanie całkowicie zużyta, kod, który wymaga bezpiecznej entropii, musi poczekać na wygenerowanie kolejnych. Urandom użyje naprawdę losowych bitów, jeśli są dostępne, lub w inny sposób zwróci mniej bezpieczne losowe bity.
Filip Haglund

Kiedy programy używają szyfrowania Nawet jeśli uważam, że nikt nie przeprowadzi testu porównawczego procesora podczas generowania losowego klucza, zaktualizowałem moją odpowiedź jako środek ostrożności.
AL

2

Myślę, że tak naprawdę nie mierzysz% IO. Nie widziałem widżetu Linux IO%. (Jestem bardzo zazdrosny o menedżera zadań Windows 10 :). Sprawdź za pomocą iotoppolecenia, a zobaczysz 100% IO.

toppowinien pokazywać 100% w całym user+ system+ iowait, dla wartości 100% podzielonych przez liczbę rdzeni, jak opisano przez AL Nie twierdzę, że topjest w 100% pomocny, ale może być naprawdę przydatnym wszechstronnym narzędziem do nauki.

Przepustowość będzie niższa niż maksymalna, ponieważ rozpakowujesz wiele małych plików, czyli „losowe we / wy”. Jest też kilka opróżnień synchronizacji dysku / pamięci podręcznej, chociaż od 2010 roku w Linuksie jest tylko kilka z nich dla każdego zainstalowanego pakietu. ( Kiedyś jeden na plik ).


Użyj iotop --only, --onlyopcja pokazuje tylko procesy lub wątki, które faktycznie wykonują operacje we / wy .
AL

4
iostat, dstat, atop ... pokaże wykorzystanie dysku na dysku bez potrzeby posiadania uprawnień. Do korzystania z zadania potrzebujesz uprawnień
Stéphane Chazelas

@ StéphaneChazelas absolutnie poprawne. Chodziło o to, że próbowałem (edycja ninja), że OP wspomina o kilku narzędziach GUI. I konkretne narzędzia GUI, które widziałem, takie jak Gnome System Monitor, pokazują przepustowość, ale nie% IO.
sourcejedi

2

W rzeczywistości żądania We / Wy są bardzo wolne w porównaniu do operacji procesora. Oznacza to, że podczas gdy twoja karta sieciowa pobiera dane lub dysk zapisuje te dane, twój procesor absolutnie nic nie robi (w tym przypadku i tak).

Jeśli twój dysk twardy jest szybszy niż połączenie sieciowe (co prawdopodobnie jest prawdą), nie zapisze więcej niż otrzymał.

Wreszcie procent sieci odpowiada maksymalnemu możliwemu użyciu karty sieciowej , a nie połączeniu. Więc możesz mieć kartę sieciową 1 Gb / s, naprawdę mało prawdopodobne jest, aby połączenie internetowe osiągało tę przepustowość.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.