Por que o apt-get NÃO usa 100% (cpu OU disco OU rede)?

21

Por que apt-get não usa 100% da CPU, disco ou rede - ou mesmo perto dela? Mesmo em um sistema lento (Raspberry Pi 2+), estou recebendo no máximo 30% de carga da CPU. Eu só estou pensando que ou está sendo artificialmente acelerado, ou deve maximizar algo enquanto está trabalhando ... ou deve ser capaz de fazer suas coisas mais rapidamente do que faz.

Edit: Estou apenas medindo aproximadamente via monitores cpu / disk / net no meu painel e o aplicativo System Monitor do Ubuntu MATE.

Por favor, explique por que estou errado. :-)

Atualização: Entendo que é apt-getnecessário buscar suas atualizações (e pode ser limitado pela largura de banda upstream / provedor). Mas uma vez que está "descompactando" e assim por diante, o uso da CPU deve pelo menos aumentar (se não o máximo). Na minha estação de trabalho doméstica bastante decente, que usa um SSD para sua unidade principal e um ramdisk para / tmp, esse não é o caso.

Ou talvez eu precise dar uma olhada.

apt cpu-usage

— KlaymenDK
fonte

Como você está medindo a carga do disco e da rede?

— JigglyNaga

1

O IO do disco é como o IO da rede. Ele ainda bloqueará o aplicativo, impedindo-o de usar a CPU. Infelizmente, apt-getnão é particularmente bom em otimizar isso. Eu imagino que ele possa ser instalado durante o download para que, quando o download for concluído, a maior parte da carga já esteja instalada, mas, infelizmente, não. De qualquer forma, a instalação autônoma geralmente extrai apenas dados para o disco. Essas operações são inerentemente vinculadas à E / S e simplesmente não há muito o que fazer, exceto aguardar na unidade de disco para concluir a leitura ou gravação.

— PSkocik 25/05

Como você conseguiu o número de carga da CPU de 30% ?

— AL

1

@PSkocik "Eu imagino que ele possa ser instalado durante o download" apt-get apenas downloads, instalações do dpkg. E o dpkg é mais inteligente que o apt-get na ordem em que vários pacotes devem ser instalados, o que pode não ser o mesmo que o apt-get os baixa.

— Braiam 25/05

Observe que um aplicativo que é 100% vinculado à CPU por meio intervalo e depois 100% vinculado à IO para a outra metade não aparecerá nem vinculado à CPU nem vinculado à IO.

— MSalters

28

Os aplicativos só maximizarão a CPU se o aplicativo estiver associado à CPU . Um aplicativo é vinculado à CPU se puder obter rapidamente todos os seus dados e o que ele espera é o processador para processar os dados.

apt-get, por outro lado, é vinculado a IO . Isso significa que ele pode processar seus dados rapidamente, mas carregar os dados (do disco ou da rede) leva tempo, durante o qual o processador pode fazer outras coisas ou ficar ocioso se nenhum outro processo precisar.

Normalmente, todas as solicitações de E / S (disco, rede) são lentas e, sempre que um encadeamento de aplicativo faz uma, o kernel o remove do processador até que os dados sejam carregados no kernel (= essas solicitações de E / S são chamadas de solicitações de bloqueio ).

— PSkocik
fonte

6

Com os aptcomandos, é agravado pelo fato de muitos arquivos serem abertos no modo de sincronização ou com solicitações frequentes e explícitas no disco para garantir que os dados permaneçam em um estado consistente, pois uma falha no sistema pode ter sérias conseqüências. Executando aptcomandos com eatmydatapode melhorar muitas vezes dramaticamente o desempenho em detrimento da confiabilidade reduzida (para não mencionar que os serviços começaram como parte de instalações de pacotes herdará as configurações eatmydata)

— Stéphane Chazelas

Lol nesse último ponto :). Alguém tem números para eatmydata desde o commit de 2010 em bugs.debian.org/cgi-bin/bugreport.cgi?bug=578635 ? Não sei se "dramaticamente" ainda é a palavra certa.

— sourcejedi

Ah, talvez seja (pelo menos em alguns provedores de nuvem) bugs.launchpad.net/cloud-init/+bug/1236531/comments/6

— sourcejedi

1

@sourcejedi Em um Raspberry Pi2 com um cartão SD relativamente high-end (mas ainda um cartão SD, não um SSD high-end), considero “dramaticamente” um exagero. O desempenho do dpkg na mídia flash é realmente péssimo.

— Gilles 'SO- stop be evil'

1

Se é ligado a disco IO, por que não está usando 100% de largura de banda do disco?

— User253751 26/05

15

Mesmo em um sistema lento (Raspberry Pi 2+), estou recebendo no máximo 30% de carga da CPU.

O Raspberry Pi 2+ possui 4 núcleos. Para algumas ferramentas de monitoramento, um uso de 100% corresponde a todos os núcleos usados em 100%. Se apenas um núcleo em um processador de código quádruplo for usado, a carga da CPU será de 25%. A carga de 30% da CPU mencionada é aproximadamente um núcleo usado a 100%, enquanto alguns processos estão em execução nos outros núcleos:

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

Como apt-getnão é multiencadeado, nunca utilizará mais de um processador, o que representa 25% de todos os recursos da CPU.

Aqui está um exemplo na minha máquina de 8 núcleos (4 núcleos com Hyper-Threading ) executando o Ubuntu, lancei um thread com o cat /dev/zero > /dev/nullcomando para criar um processo infinito que utiliza um núcleo inteiramente.

Agora, se dermos uma olhada no gráfico htop, podemos ver que a carga média ( Avgbar) é 12.7%, que corresponde a um núcleo usado a 100%, que também é 1/8 de todos os recursos da CPU:

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

Também é possível observar que o comando tem um valor de 100%na CPU%coluna, porque é relativo a um núcleo e não a todos os núcleos.

— AL
fonte

+1, um% de uso próximo a um múltiplo de (100 / nCores) sempre deve desencadear um exame mais aprofundado. Isso pode ser verificado - e, de fato, é impedido - usando um monitor capaz de mostrar o uso por núcleo, em que 0 <=% <= 100 * nCores

— underscore_d

Não é /dev/zero > /dev/nullum exemplo melhor, já que o urandom esgotará o pool de entropia?

— Filip Haglund

@FilipHaglund cat /dev/zero > /dev/nulldá o mesmo resultado, eu não conhecia esse dispositivo, obrigado. urandom esgotará o conjunto de entropia Eu não conheço o conjunto de entropia, como isso pode ser um problema?

— AL

1

Quando os programas usam criptografia, eles precisam de dados verdadeiramente aleatórios para gerar chaves de criptografia seguras. O computador gera entropia observando o mouse se mover entre outras coisas. Existem geradores de números aleatórios de hardware, mas a maioria dos computadores não os possui. Se a entropia estiver esgotada, o código que precisa de entropia segura terá que esperar que mais seja gerado. O Urandom usará bits verdadeiramente aleatórios, se disponíveis, ou retornará bits aleatórios menos seguros.

— Filip Haglund

Quando os programas usam criptografia Mesmo que eu ache que ninguém fará um benchmark de CPU enquanto gera uma chave aleatória, atualizei minha resposta como precaução.

— AL

2

Eu acho que você realmente não está medindo% de IO. Não vi um widget% de IO do Linux. (Estou com muita inveja do gerenciador de tarefas do Windows 10 :). Verifique usando o iotopcomando e você verá 100% IO.

topdeve mostrar 100% em user+ system+ iowait, para valores de 100% divididos por sua contagem principal, conforme descrito por AL. Não estou dizendo que topseja 100% útil, mas pode ser uma ferramenta geral realmente útil para aprender.

O rendimento será menor que o máximo, porque você está descompactando muitos arquivos pequenos, também conhecido como "E / S aleatório". Há também algumas liberações de sincronização / cache de disco, embora desde 2010 no Linux existam apenas algumas delas para cada pacote instalado. ( Costumava ser um por arquivo ).

— sourcejedi
fonte

Use iotop --onlya --onlyopção de mostrar apenas processos ou threads realmente fazendo I / O .

— AL

4

iostat, dstat, atop ... mostrará a utilização por disco, sem a necessidade de privilégios. É para a utilização per-tarefa que você precisa de privilégios

— Stéphane Chazelas

@ StéphaneChazelas absolutamente correto. O ponto que eu estava tentando enfatizar (edição ninja) é que o OP menciona algumas ferramentas da GUI. E as ferramentas GUI específicas que eu já vi, como o Gnome System Monitor, mostram a taxa de transferência, mas nenhuma% de IO.

— sourcejedi

2

Na verdade, as solicitações de IO / Rede são realmente lentas em comparação com as operações da CPU. Isso significa que, enquanto sua placa de rede está buscando dados ou seu disco está gravando esses dados, sua CPU não faz absolutamente nada (para esse processo de qualquer maneira).

Se o seu disco rígido for mais rápido que a sua conexão de rede (o que provavelmente é verdade), ele não gravará mais do que recebeu.

Finalmente, a porcentagem da rede corresponde ao máximo possível de uso da placa de rede , não à conexão. Como você pode ter um adaptador de rede de 1 Gb / s, é improvável que você tenha uma conexão à Internet que atinja essa largura de banda.

— Aymeric R.
fonte