Minha opinião sobre esse assunto vem do lado do desenvolvedor. Eu escrevo o código que é colocado em uma máquina virtual RHEL executada como uma entre muitas em um sistema corporativo. O sistema de arquivos usado é um dispositivo de armazenamento remoto conectado à rede.
Tivemos uma grande variabilidade em comandos simples durante o lote. Então montamos um teste para obter mais informações, mas agora não sei o que encontramos.
Executamos o seguinte comando a cada 30 minutos e registramos a saída. É uma cópia de um arquivo de 6 GB. O que vejo é um salto no tempo decorrido de 11 segundos para 190 segundos quando o sistema está ocupado executando muitos trabalhos e este comando de teste obtém baixo tempo de CPU.
O que posso ver é que a coluna "I" (entradas do sistema de arquivos) é preenchida quando a CPU está baixa, mas não quando está alta. A coluna “w” (swaps involuntárias) também é muito mais alta.
Minha pergunta é: o que está acontecendo com esse trabalho/comando que o força a rodar MUITO MAIS quando o tempo da CPU diminui? A entrada/saída de troca armazena todos esses dados em algum outro dispositivo muito mais lento? Geralmente, o que acontece durante uma entrada/saída de troca?
Comando sendo executado:
/usr/bin/time -a -o filename.txt cp file.txt fileCopy.txt
| Data | Tempo | e | S | você | P | c | c | EU | Ó |
|---|---|---|---|---|---|---|---|---|---|
| 14/03/2022 | 5:19:02 | 64,9 | 16.23 | 1.03 | 26% | 3005 | 29210 | 12000016 | 12.000.000 |
| 14/03/2022 | 5:49:02 | 12,7 | 11.63 | 0,79 | 97% | 2069 | 76 | 0 | 12.000.000 |
| 14/03/2022 | 6:19:02 | 100,39 | 14,74 | 0,78 | 15% | 1034 | 29925 | 12000136 | 12.000.000 |
| 14/03/2022 | 6:49:24 | 191,32 | 18,86 | 0,94 | 10% | 3374 | 36164 | 12001024 | 12.000.000 |
| 14/03/2022 | 7:19:02 | 71,61 | 15,61 | 0,88 | 23% | 1610 | 30316 | 12000296 | 12.000.000 |
| 14/03/2022 | 7:49:02 | 70,73 | 17,5 | 0,91 | 26% | 1408 | 29540 | 12000072 | 12.000.000 |
| 14/03/2022 | 8:19:02 | 10,95 | 9,89 | 0,7 | 96% | 1709 | 75 | 0 | 12.000.000 |
| 14/03/2022 | 8:49:02 | 11.01 | 10.22 | 0,73 | 99% | 239 | 85 | 0 | 12.000.000 |
As descrições das colunas da página man para /usr/bin/time
e Elapsed real time (in seconds).
S Total number of CPU-seconds that the process spent in kernel mode.
U Total number of CPU-seconds that the process spent in user mode.
P Percentage of the CPU that this job got, computed as (%U + %S) / %E.
c Number of times the process was context-switched involuntarily (because the time slice expired).
w Number of waits: times that the program was context-switched voluntarily, for instance while waiting for an I/O operation to complete.
I Number of filesystem inputs by the process.
O Number of filesystem outputs by the process.
Responder1
P neste contexto significa a proporção do tempo de CPU que este trabalho obteve em relação ao tempo total decorrido. Perto de 100% significa que quase todo o tempo esteve na CPU e, portanto, a CPU ficou restrita para essas execuções. Em contraste com as outras corridas onde algo mais era o fator limitante. Mais tempo do sistema (também conhecido como kernel) do que tempo do sistema, como é típico de tarefas pesadas de E/S.
Dado que a carga de trabalho era copiar um arquivo de 6 GB, podemos inferir que as execuções de 11 segundos tiveram em média mais de 0,5 GB de gravações por segundo. A coluna O confirma o mesmo número de gravações a cada vez, consistente com um processo simples de copiar um arquivo.
A coluna de entrada apresenta grandes oscilações, entretanto. Execuções lentas têm leituras e gravações quase iguais. Mas as corridas rápidas não fazem nenhuma leitura! Presumo que o arquivo ainda esteja armazenado em cache na RAM desde a última leitura. A DRAM é muito mais rápida do que o armazenamento em estado sólido. O que é um grande aumento de velocidade, até que, sob pressão de memória, o sistema operacional descarte os dados em cache e precise ler novamente o armazenamento lento.
Portanto, esta é uma tarefa de 200 segundos, que ocasionalmente pode levar 12 segundos. Provavelmente devido ao cache da página do Linux.
Encontrar a causa raiz de um problema de desempenho geralmente requer uma compreensão mais profunda do sistema geral, além de qualquer conjunto específico de métricas.
O sistema de arquivos usado é um dispositivo de armazenamento remoto conectado à rede.
Observe que sua cópia está no armazenamento em rede; portanto, também pode ser qualquer coisa no sistema remoto ou na rede intermediária. Desempenho de armazenamento remoto. Velocidades e utilização da rede (provavelmente IP). Ou pode ser local para esta VM, onde o convidado está competindo por recursos com todo o resto em execução na sua infraestrutura.
Sempre é possível se aprofundar em como as coisas funcionam. O armazenamento em rede (NFS?) É importante ou você também vê isso no disco local? 0,7 segundos de tempo de CPU do usuário é bastante trabalhoso, na verdade, quanto é contabilizado para gerenciar muitas chamadas do sistema? O que realmente significa CPU ocupada quando a maior parte disso está aguardando memória lenta e armazenamento muito lento? Não são perguntas fáceis de responder, mas talvez não seja necessário cavar muito fundo quando a coisa estiver funcionando adequadamente.