Mi opinión sobre este tema es desde el lado del desarrollador. Escribo el código que se coloca en una máquina virtual RHEL que se ejecuta como una de muchas en un sistema empresarial. El sistema de archivos que se utiliza es un dispositivo de almacenamiento remoto conectado a la red.
Tuvimos una gran variabilidad en comandos simples durante el lote. Así que organizamos una prueba para obtener más información, pero ahora no sé qué hemos encontrado.
Ejecutamos el siguiente comando cada 30 minutos y registramos el resultado. Es una copia de un archivo de 6 gb. Lo que veo es un salto en el tiempo transcurrido de 11 segundos a 190 segundos cuando el sistema está ocupado ejecutando muchos trabajos y este comando de prueba tiene poco tiempo de CPU.
Lo que puedo ver es que la columna "I" (entradas del sistema de archivos) se completa cuando la CPU está baja, pero no cuando está alta. La columna "w" (canjes involuntarios) también es mucho más alta.
Mi pregunta es, ¿qué le sucede a este trabajo/comando que lo obliga a ejecutarse MUCHO MÁS TIEMPO cuando el tiempo de la CPU disminuye? ¿El intercambio de entrada/salida almacena todos esos datos en algún otro dispositivo que sea mucho más lento? En general, ¿qué sucede durante un intercambio de entrada/salida?
Comando en ejecución:
/usr/bin/time -a -o filename.txt cp file.txt fileCopy.txt
| Fecha | Tiempo | mi | S | Ud. | PAG | C | w | I | oh |
|---|---|---|---|---|---|---|---|---|---|
| 14/03/2022 | 5:19:02 | 64,9 | 16.23 | 1.03 | 26% | 3005 | 29210 | 12000016 | 12000000 |
| 14/03/2022 | 5:49:02 | 12.7 | 11.63 | 0,79 | 97% | 2069 | 76 | 0 | 12000000 |
| 14/03/2022 | 6:19:02 | 100.39 | 14.74 | 0,78 | 15% | 1034 | 29925 | 12000136 | 12000000 |
| 14/03/2022 | 6:49:24 | 191,32 | 18,86 | 0,94 | 10% | 3374 | 36164 | 12001024 | 12000000 |
| 14/03/2022 | 7:19:02 | 71,61 | 15.61 | 0,88 | 23% | 1610 | 30316 | 12000296 | 12000000 |
| 14/03/2022 | 7:49:02 | 70,73 | 17,5 | 0,91 | 26% | 1408 | 29540 | 12000072 | 12000000 |
| 14/03/2022 | 8:19:02 | 10,95 | 9,89 | 0,7 | 96% | 1709 | 75 | 0 | 12000000 |
| 14/03/2022 | 8:49:02 | 11.01 | 10.22 | 0,73 | 99% | 239 | 85 | 0 | 12000000 |
Las descripciones de las columnas de la 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.
Respuesta1
P en este contexto significa la relación entre el tiempo de CPU que obtuvo este trabajo y el tiempo total transcurrido. Cerca del 100% significa que casi todo el tiempo estuvo en la CPU, por lo que la CPU estaba limitada para esas ejecuciones. A diferencia de otras carreras en las que el factor limitante era otro. Más tiempo del sistema (también conocido como kernel) que tiempo del sistema, como es típico de las tareas pesadas de E/S.
Dado que la carga de trabajo fue copiar un archivo de 6 GB, podemos inferir que las ejecuciones de 11 segundos promediaron más de 0,5 GB de escritura por segundo. La columna O confirma el mismo número de escrituras cada vez, lo que es consistente con un proceso simple de copiar un archivo.
Sin embargo, la columna de entrada tiene cambios importantes. Las ejecuciones lentas tienen aproximadamente la misma lectura que las escrituras. ¡Pero las carreras rápidas no hacen ninguna lectura! Supongo que el archivo todavía está almacenado en caché en la RAM desde la última vez que se leyó. La DRAM es mucho más rápida que incluso el almacenamiento de estado sólido. Lo cual es un gran aumento de velocidad, hasta que, bajo presión de la memoria, el sistema operativo elimina los datos almacenados en caché y tiene que volver a leer desde el almacenamiento lento.
Entonces esta es una tarea de 200 segundos, que ocasionalmente puede tomar 12 segundos. Probablemente debido al caché de la página de Linux.
Encontrar la causa raíz de un problema de rendimiento a menudo requiere una comprensión más profunda del sistema en general, más allá de cualquier conjunto particular de métricas.
El sistema de archivos que se utiliza es un dispositivo de almacenamiento remoto conectado a la red.
Tenga en cuenta que su copia se realiza a través del almacenamiento en red, por lo que también podría ser cualquier cosa en el sistema remoto o en la red intermedia. Rendimiento del almacenamiento remoto. Velocidades y utilización de la red (probablemente IP). O podría ser local para esta máquina virtual, donde el invitado compite por los recursos con todo lo demás que se ejecuta en su infraestructura.
Siempre es posible profundizar en cómo funcionan las cosas. ¿Importa el almacenamiento de red (NFS?) o también ve esto para el disco local? En realidad, 0,7 segundos de tiempo de CPU del usuario es bastante trabajo, ¿cuánto se contabiliza para administrar muchas llamadas al sistema? ¿Qué significa realmente CPU ocupada cuando la mayor parte está esperando una memoria lenta y un almacenamiento muy lento? No son preguntas fáciles de responder, pero tal vez no sea necesario profundizar demasiado una vez que la cosa esté funcionando adecuadamente.