Tema 3-Monitorización (1) PDF

Document Details

TranquilOklahomaCity3120

Uploaded by TranquilOklahomaCity3120

null

false

null

Tags

system performance monitoring system analysis computer performance computer science

Summary

This document provides an overview of system monitoring, including the concept of activity monitoring, different uses, and implementation. It details the role of monitors in evaluating server performance under real-world loads. The document also includes a bibliography of relevant resources and explores different types of monitors.

Full Transcript

¿Cómo medir el rendimiento de mi servidor? Analistas, administradores ydiseñadores Objetivos del tema  Entender el concepto de monitor de actividad de un servidor y sus diferentes utilidades e implementaciones.  Conocer las características fundamen...

¿Cómo medir el rendimiento de mi servidor? Analistas, administradores ydiseñadores Objetivos del tema  Entender el concepto de monitor de actividad de un servidor y sus diferentes utilidades e implementaciones.  Conocer las características fundamentales de un monitor a nivel de sistema operativo y a nivel de aplicación concreta (profilers).  Comprender el papel que desempeñan los monitores para evaluar el rendimiento de un servidor ante una carga real.  Saber interpretar adecuadamente la información que aporta un monitor. 2 Bibliografía  Evaluación y modelado del rendimiento de los sistemas informáticos. Xavier Molero, C. Juiz, M. Rodeño. Pearson Educación, 2004.  Capítulo 2  Measuring computer performance: a practitioner’s guide. D. J. Lilja, Cambridge University Press, 2000.  Capítulos 4 y 6  The art of computer system performance analysis. R. Jain. John Wiley & Sons, 1991.  Capítulos 7 y 8  System performance tuning. G.D. Musumeci, M. Loukides. O’Reilly, 2002.  Capítulo 2  Linux performance and tuning guidelines. E.Ciliendo, T.Kunimasa. IBM Redpaper, 2007.  Capítulos 1 y 2  Linux performance tools. B. Gregg. 2015. https://conferences.oreilly.com/velocity/devops-web-performance- 2015/public/schedule/detail/42513.  Linux man pages. http://www.linuxmanpages.com/. 3 Contenido  Concepto de monitor de actividad.  Monitorización a nivel de sistema.  Monitorización a nivel de aplicación. 4 La carga y la actividad de un sistema  Carga (workload): conjunto de tareas que ha de realizar un sistema. (= Todo aquello que demande recursos delsistema.)  Actividad de un sistema: conjunto de operaciones que se realizan en el sistema como consecuencia de la carga que soporta.  Un sistema informático no es “bueno” ni “malo” per se, sino que se adapta mejor o peor a un tipo determinado decarga.  Algunas variables que reflejan la actividad de un sistema:  Procesadores: Utilización, temp., fCLK, nº de procesos, nº de interrupciones, cambios de contexto,etc.  Memoria: nº de accesos, memoria utilizada, fallos de caché, fallos de página, uso de memoria de intercambio, latencias, anchos de banda, voltajes, etc.  Discos: lecturas/escrituras por unidad de tiempo, longitud de las colas de espera, tiempo de espera medio por acceso, etc.  Red: paquetes recibidos/enviados, colisiones por segundo, sockets abiertos, paquetes perdidos,etc.  Sistema global: nº de usuarios, nº de peticiones, etc. 6 Definición de monitor de actividad  Herramienta diseñada para medir la actividad de un sistema informático y facilitar su análisis. Monitor Carga  Acciones típicas de unmonitor:  Medir alguna/s variables que reflejen la actividad.  Procesar y almacenar la información recopilada.  Mostrar los resultados. 7 Utilidad de los monitores de actividad  Administrador/Ingeniero  Conocer la utilización de los recursos (detección de cuellos de botella) parasaber:  Qué hardware hay que reconfigurar / sustituir/ añadir.  Cómo ajustar los parámetrosdel sistema (sintonización).  Predecir cargas futuras (capacityplanning).  Tarificar a losclientes.  Obtener un modelo un componente o de todo el sistema para poder deducir qué pasaría si...  Programador  Conocer las partes críticas de una aplicación de cara a su optimización.  Sistema Operativo  Adaptarse dinámicamente a lacarga. 8 Tipos de monitores: ¿cuándo se mide? Cada vez que ocurre un evento (monitor por eventos)  Evento: Cambio en el estadodel  Ejemplos deeventos: sistema.  Inicio/fin de la ejecución deun  Volumen de información recogida: programa. Depende de la frecuencia de los  Fallo en memoriacache. eventos.  Interrupción de undispositivo  Información exacta. periférico.  Abrir/cerrar un fichero, etc. Cada cierto tiempo (monitor por muestreo) T T T  Volumen de información recogida: Depende del periodo de muestreo(T). T puede ser, a su vez, variable. Medidas  Información estadística. 9 Tipos de monitores: ¿cómo se mide?  Software Sistema  Programas instalados en elsistema informático Monitor  Hardware Monitor  Dispositivos físicos de medida (menor sobrecarga) Sistema informático  Híbridos Sistema informático  Utiliza los dos tiposanteriores Monitor Sistema informático Monitor Monitor hardware software 10 Tipos de monitores: ¿existe interacción con el analista/administrador?  No existe. La consulta sobre los resultados se realiza aparte mediante otra herramienta independiente al proceso de monitorización: monitores tipo batch, por lotes o en segundo plano (batch monitors).  Sí existe. Durante el propio proceso de monitorización se pueden consultar los valores monitorizados y/o interactuar con ellos realizando representaciones gráficas diversas, modificando parámetros del propio monitor, etc.: monitores en primer plano o interactivos (on-linemonitors). 11 Atributos que caracterizan a un sensor/monitor  Exactitud de la medida (Accuracy, offset): ¿Cómo se aleja el valor medido del valor real que se quiere medir?  Precisión (Precision): ¿Cuál es la dispersión delas medidas?  Resolución del sensor: ¿Cuánto tiene que cambiar el valor a medir para detectar un cambio?  Tasa Máxima de Entrada (Max Input Rate): ¿Cuál es la frecuencia máxima de ocurrencia de los eventos que el monitor puede observar? (monitores por eventos)  Periodo de Muestreo (Sampling Time): ¿Cada cuánto tiempo tomamos la medida? (monitores por muestreo)  Anchura de Entrada (Input Width): ¿Cuánta información (nº de bytes de datos) se almacena por cada medida que toma el monitor? 12 Más atributos: sobrecarga (overhead)  Sobrecarga (Overhead): ¿Qué recursos le “roba” el monitoral sistema? El instrumento de medida puede perturbar el funcionamiento del sistema. 𝑈𝑈𝑈𝑈𝑆𝑆𝑑𝑑𝑆𝑆𝑑𝑑𝑆𝑆𝑆𝑆𝑆𝑆𝑟𝑟𝑆𝑆𝑈𝑈𝑆𝑆𝑝𝑝𝑆𝑆𝑆𝑆𝑝𝑝𝑆𝑆𝑆𝑆𝑝𝑝𝑆𝑆𝑑𝑑𝑆𝑆𝑑𝑑𝑚𝑚𝑆𝑆𝑚𝑚𝑚𝑚𝑝𝑝𝑆𝑆𝑆𝑆 𝑆𝑆𝑆𝑆𝑆 𝑅𝑅𝑅𝑅𝑅𝑅 𝑅 𝑅 % = × 100 𝐶𝐶𝑆𝑆𝑝𝑝𝑆𝑆𝑆𝑆𝑚𝑚𝑑𝑑𝑆𝑆𝑑𝑑𝑝𝑝𝑆𝑆𝑝𝑝𝑆𝑆𝑑𝑑𝑑𝑑𝑆𝑆𝑑𝑑𝑆𝑆𝑆𝑆𝑆𝑆𝑟𝑟𝑆𝑆𝑈𝑈𝑆𝑆  Ejemplo: Sobrecarga de CPU de un monitor software por muestreo. La ejecución de las instrucciones del monitor se lleva a cabo utilizando recursos del sistema monitorizado. Supongamos que el monitor se activa cada 5 s y cada activación del mismo usa el procesador durante 6 ms. 6 × 10−3𝑈𝑈 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝐶𝐶𝐶𝐶𝐶𝐶 % = × 100 = 0,12% 5𝑈𝑈 13 El directorio /proc (Unix)  Es una carpeta en RAM utilizada por el núcleo de Unix para facilitar el acceso del usuario a las estructuras de datos del S.O.  A través de /procpodemos:  Acceder a información global sobre el S.O.: loadavg, uptime, cpuinfo, meminfo, mounts, net, kmsg, cmdline, slabinfo, filesystems, diskstats, devices, interrupts, stat, swap, version, vmstat,...  Acceder a la información de cada uno de los procesos del sistema (/proc/[pid]): stat, status, statm, mem, smaps, cmdline, cwd, environ, exe, fd, task...  Acceder y, a veces, modificar algunos parámetros del kernel del S.O. (/proc/sys): dentry_state, dir-notify-enable, dquot-max, dquot-nr, file-max, file-nr, inode-max, inode- nr, lease-break- time, mqueue, super-max, super-nr, acct, domainname, hostname, panic, pid_max, version, net, vm...  La mayoría de los monitores de Unix usan como fuente de información este directorio. 15 uptime  Tiempo que lleva el sistema en marcha y la “carga media” que soporta % uptime 1:21pm up 1 day, 4:09, 18 users, load average: 1.04, 0.30, 0.09 Hora actual Tiempo en marcha “Carga media” último minuto Últimos 5 min Últimos 15 min man uptime (http://man7.org/linux/man-pages/man1/uptime.1.html) NAME uptime - Tell how long the system has been running. DESCRIPTION uptime gives a one line display of the following information. The current time, how long the system has been running, how many users are currently logged on, and the system load averages for the past 1, 5, and 15 minutes. This is the same information contained in the header line displayed by w. 16 “Carga” del sistema Unix  Estados básicos de unproceso:  En ejecución (running) o en la cola de ejecución (runnable).  Bloqueado esperando a que se complete una operación de E/S para continuar (uninterruptible sleep = I/O blocked).  Durmiendo esperando a un evento del usuario o similar (p.ej. una pulsación de tecla) (interruptible sleep).  La cola de procesos del núcleo (run queue) está formada por aquellos que pueden ejecutarse (runnable + running).  “Carga del sistema” (system load): número de procesos en modo running, runnable o I/O blocked. Interrupt. I/O runnable/ sleep blocked running 17 ¿Cómo mide la carga media el S.O.?  Experimento: Ejecutamos 1 único proceso (bucle infinito). Llamamos a uptime cada cierto tiempo y representamos los resultados. Según timer.c (kernel de Linux): LA(t) = c· load(t) + (1-c)·LA(t-5)  LA (t) = Load Average en el instante t.  Se actualiza cada 5 segundos su valor.  load(t) es la “carga del sistema” en el instante t.  c es una constante. A mayor valor, más influencia tiene la carga actual en el valor medio (c1>c5>c15). Si c = c1 calculamos LA_1(t), etc. 18 ps (process status)  Información sobre el estado actual de los procesos del sistema. $ ps aur USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND miguel 29951 55.9 0.1 1448 384 pts/0 R 09:16 0:11 tetris carlos 29968 50.6 0.1 1448 384 pts/0 R 09:32 0:05 tetris javier 30023 0.0 0.5 2464 1492 pts/0 R 09:27 0:00 ps aur  USER: Usuario que lanzó elproceso. Procesos a mostrar:  %CPU, %MEM: Porcentaje de procesadory memoria -A, -e: show all processes; T: all processes on this física usada. terminal; U: processes for specified users…  RSS (resident set size): Memoria (KiB) física Campos que mostrar: process ID, cumulative user time, ocupada por el proceso. number of minor/major page faults, parent process ID, RSS, time process was started, user ID number, user  STAT. Estado en el que se encuentra el proceso: name, total VM size in bytes, kernel scheduling  R (running or runnable), D (I/O blocked), priority, etc.  S (interruptible sleep), T (stopped),  Z (zombie: terminated but not died).  N (lower priority = running niced),  < (higher priority = not nice).  s (session leader),  + (in the foreground process group),  W (swapped/paging). 19 top  Muestra cada T segundos: carga media, procesos, consumo de memoria...  Normalmente se ejecuta en modo interactivo (se puede cambiar T, lascolumnas seleccionadas, la forma de ordenar las filas, etc.) 8:48am up 70 days, 21:36, 1 user, load average: 0.28, 0.06, 0.02 Tareas: 47 total, 2 running, 45 sleeping, 0 stopped, 0 zombie %Cpu(s): 99.6 us, 0.3 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 256464 total, 234008 used, 22456 free, 13784 buffers KiB Swap: 136512 total, 4356 used, 132156 free, 5240 cached Mem PID USER PR NI VIRT RES SHR STAT %CPU %MEM TIME COMMAND 9826 carlos 0 0 388 388 308 R 99.6 0.1 0:22 simulador 9831 miguel 19 0 976 976 776 R 0.3 0.3 0:00 top 1 root 20 0 76 64 44 S 0.0 0.0 0:03 init 2 root 20 0 0 0 0 S 0.0 0.0 0:00 keventd 4 root 20 19 0 0 0 SN 0.0 0.0 0:00 ksoftiq 5 root 20 0 0 0 0 S 0.0 0.0 0:13 kswapd 6 root 2 0 0 0 0 S 0.0 0.0 0:00 bdflush 7 root 20 0 0 0 0 S 0.0 0.0 0:10 kdated 8 root 20 0 0 0 0 S 0.0 0.0 0:01 kinoded 11 root 0 -20 0 0 0 S< 0.0 0.0 0:00 recoved  wa: %tiempo ocioso esperando E/S. st: %tiempo robado por el hipervisor. 20 vmstat (virtual memory statistics)  Paging (paginación), swapping, interrupciones, cpu  La primera línea no sirve para nada (info desde el inicio del sistema) % vmstat 1 6 procs memory swap io system cpu r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 868 8964 60140 342748 0 0 23 7 222 199 1 4 80 15 0 0 0 868 8964 60140 342748 0 0 0 14 283 278 0 7 80 23 0 0 0 868 8964 60140 342748 0 0 0 0 218 212 6 2 93 0 0 0 0 868 8964 60140 342748 0 0 0 0 175 166 3 3 94 0 0 0 0 868 8964 60140 342752 0 0 0 2 182 196 0 7 88 5 0 0 0 868 8968 60140 342748 0 0 0 18 168 175 3 8 69 20 0  Procesos: r (runnable), b (I/O blocked)  Bloques por segundo transmitidos: bi (blocks in), (blocks out)  KB/s entre memoria y disco: si (swapped in), so (swapped out)  in (interrupts per second), cs (context switches per second)  Con otros argumentos, puede dar información sobre acceso a discos (en concreto la partición de swap) y otras estadísticas de memoria. 21 El paquete de monitorización: Sysstat http://sebastien.godard.pagesperso-orange.fr/ 22 El monitor sar(system activity reporter)  Información general sobre todo el sistema a partir de la información obtenida del directorio /proc.  Actual: qué está pasando el día de hoy, o ahora mismo, en el sistema.  Histórica: qué ha pasado en el sistema en otros días pasados.  Ficheros históricos en /var/log/sa/saDD, donde los dígitos DD indican el día del mes.  Esquema de funcionamiento:  sadc (system-accounting data collector): Recoge los datos estadísticos (lectura de contadores) y construye un registro en formato binario (back-end).  sar: Lee los datos binarios que recoge sadc y las traduce a texto plano (front-end). fichero histórico binario sar Informe /proc sadc texto pipe 23 Parámetros de sar  Gran cantidad de parámetros (puede funcionar en modo batch o en modo interactivo) Modo interactivo: [tiempo_muestreo, [nº muestras]] Modo no interactivo: -f Fichero de donde extraer la información, por defecto: hoy -s Hora de comienzo de la monitorización -e Hora de fin de la monitorización -u Utilización del procesador (opción por defecto) -P Mostrar estadísticas por cada procesador (-P ALL: todos) -I Estadísticas sobre interrupciones -w Cambios de contexto -q Tamaño de la cola y carga media del sistema -b Estadísticas de transferencias de E/S -d Transferencias para cada disco -n Conexión de red -r Utilización de memoria -R Estadísticas sobre la memoria -A Toda la información disponible... 24 Ejemplo de salidas del monitor sar  Utilización del procesador (que puede ser multi-núcleo): $ sar (=sar –u) 00:00:00 CPU %user %nice %system %iowait %steal %idle 00:05:00 all 0.09 0.00 0.08 0.00 0.00 99.83 00:10:00 all 0.01 0.00 0.01 0.00 0.00 99.98... 11:15:00 all 0.02 0.00 0.02 0.00 0.00 99.96 11:20:00 all 0.44 0.00 0.20 0.00 0.00 99.36 11:25:00 all 0.05 0.00 0.02 0.00 0.00 99.92  Actividad del sistema de entrada/salida (sin incluir la red): $ sar -b 00:00:00 tps rtps wtps bread/s bwrtn/s 00:05:00 0.74 0.39 0.35 7.96 3.27 00:10:01 0.09 0.00 0.09 0.00 0.91 00:15:00 0.15 0.00 0.14 0.03 1.36 00:20:00 65.12 59.96 5.16 631.62 162.64 25 Otros ejemplos de ejecución de sar  Ejecución interactiva (tiempo de muestro, nºmuestras) $ sar 1 3 19:20:39 CPU %user %nice %system %iowait %steal %idle 19:20:40 all 11.88 0.00 2.97 0.00 0.00 85.15 19:20:41 all 21.00 0.00 2.00 0.00 0.00 77.00 19:20:42 all 20.41 0.00 1.02 0.00 0.00 78.57  Información recogida sobre el día de hoy  sar (= sar –u)  sar -d -s 10:00:00 -e 12:00:00  sar -A  sar -b  Información recogida en otro día anterior  sar -f /var/log/sa/sa02  sar –P ALL -f /var/log/sa/sa06  sar -d -s 10:00:00 -e 12:00:00 -f /var/log/sa/sa04 26 Los datos sobre la actividad  Se utiliza un fichero histórico de datos por cada día.  Se programa la ejecución de sadc un número de veces al día con la utilidad “cron” del sistema Unix.  Por ejemplo, una vez cada 5 minutos comenzando a las 0:00 de cada día.  Cada ejecución de sadc añade un registro binario con los datos recogidos al fichero histórico del día. %ls /var/log/sa -rw-r--r-- 1 root root 3049952 Sep 30 23:55 sa30 -rw-r--r-- 1 root root 3049952 Oct 1 23:55 sa01 -rw-r--r-- 1 root root 3049952 Oct 2 23:55 sa02 -rw-r--r-- 1 root root 3049952 Oct 3 23:55 sa03 -rw-r--r-- 1 root root 3049952 Oct 4 23:55 sa04 -rw-r--r-- 1 root root 3049952 Oct 5 23:55 sa05 Día actual -rw-r--r-- 1 root root 3049952 Oct 6 23:55 sa06 -rw-r--r-- 1 root root 3049952 Oct 7 23:55 sa07 -rw-r--r-- 1 root root 2372320 Oct 8 18:45 sa08 27 Análisis de un fichero histórico  Ejemplo  El fichero histórico de un día ocupa 3.049.952 bytes (unos 3 MB)  La orden sadc se ejecuta cada 5 minutos Cada hora se recogen 12 muestras   Al día se recogen 24 x 12 = 288 muestras  Anchura de entrada delmonitor: Cada registro ocupa de media10,3 KiB -rw-r--r-- 1 root root 3049952 Oct 2 23:55 sa02 Fichero sa02 (día 2 de octubre) 28 Otras herramientas de Sysstat  mpstat (processors related statistics). Nos muestra estadísticas concretas por cada núcleo (core). Podemos ver si la carga está bien distribuida entre los diferentes núcleos. 29 Otras herramientas de Sysstat (cont.)  iostat (input/output statistics). Muestra estadísticas de los dispositivos de E/S y particiones de disco existentes en el sistema. 30 Otras herramientas para monitorización 31 http://www.brendangregg.com/linuxperf.html Procedimiento sistemático de monitorización: método USE (Utilization, Saturation, Errors)  Para cada recurso (CPU, memoria, E/S, red,…)comprobamos:  Utilización: Tanto por ciento de utilización del recurso (tiempo de CPU, tamaño de memoria, ancho de banda,etc.)  Saturación: Tamaño de las colas de aquellas tareas que quieren hacer uso de ese recurso (en el caso de la memoria, cantidad de swapping a disco).  Errores: Mensajes de errordel kernel sobre el uso de dichos recursos.  Ejemplo: CPU  Utilización: vmstat 1, "us" + "sy" + "st"; sar -u, sumando todos los campos excepto "%idle" e "%iowait"; …  Saturación: vmstat 1, "r" > nº de CPU; sar -q, "runq-sz" > nº de CPU;…  Errores: usando perf si la opción de “eventos de errores específicos de CPU” está habilitada; …  Más ejemplos: http://www.brendangregg.com/USEmethod/use-linux.html 32 Otras herramientas para monitorización (II)  CollectL  http://collectl.sourceforge.net/. Parecido a sar. Es capaz de ejecutarse de forma interactiva o como un servicio/demonio para recopilar datos históricos.  Nagios  https://www.nagios.org/. Permite la monitorización y la generación de alarmas de equipos distribuidos en red (tanto recursos HW como servicios de red). Se puede personalizar mediante la programación de plugins propios.  Otras herramientas que permiten la monitorización de equipos distribuidos en red: Ganglia, Munin, Zabbix, Pandora FMS… 33 Programa SarCheck (www.sarcheck.com)  Herramienta para:  Análisis de prestaciones. UNIX Performance Tuning Simplified...  Sintonización, planificación de la and Linux Performance Tuning too! capacidad.  Genera informes en formato HTML:  Estadísticas sobre el uso de recursos.  Análisis de recursos, detectandoposibles cuellos de botella.  Sección de recomendaciones.  Sistemas Sun Solaris, HP-UX, AIX y Linux x86.  Basado en el monitorsar. 34 Ejemplo informe generado por SarCheck Average CPU utilization was only 15.7 percent. This indicates that spare capacity exists within the CPU. If any performance problems were seen during the monitoring period, they were not caused by a lack of CPU power. CPU utilization peaked at 34.00 percent from 08:10:01 to 08:15:01. A CPU upgrade is not recommended because the current CPU had significant unused capacity. Change the virtual memory parameter 'swappiness' from 60 to 70. This controls the systems likelihood of swapping out memory pages which have not been recently used. Larger values will swap out unused pages of memory, speeding the time required to load new pages into memory. Try to balance the disk I/O load across time or among other disk devices. The load on at least one disk was clearly excessive at peak times. By distributing the load over a greater time period or across other disk devices, the load will not be as likely to cause performance degradation. Change the bdflush parameter 'nfract' from 50 to 55. This is the percentage of dirty buffers allowed in the buffer cache before the kernel flushes some of them. Change the bdflush parameter 'nfract_sync' from 80 to 85. This is the percentage of dirty buffers in the buffer cache before the kernel aggressively flushes them synchronously. To change the value of the bdflush parameters immediately as described in the above recommendations, use the following command: echo "55 500 8 0 500 3000 85 45 0" > /proc/sys/vm/bdflush 35 Monitorización a nivel de aplicación (profiling)  Objetivo de un profiler:  Monitorizar la actividad generada por una aplicación concreta con el fin de obtener información para poderoptimizar su código.  Información que suele proporcionar un profiler:  ¿Cuánto tiempo tarda en ejecutarse el programa? ¿Qué parte de ese tiempo es de usuario y cuál de sistema? ¿Cuánto tiempo se pierde por las operaciones de E/S?  ¿En qué parte del código pasa la mayor parte de su tiempo de ejecución (=hot spots)?  ¿Cuántas veces se ejecuta cada línea de programa?  ¿Cuántas veces se llama a un procedimiento y desde dónde?  ¿Cuánto tiempo tarda en ejecutarse (el código propio de) un procedimiento?  ¿Cuántos fallos de caché/página genera cada línea del programa? ... 37 Una primera aproximación: time El programa /usr/bin/time mide el tiempo de ejecución de un programa y muestra algunas estadísticas sobre suejecución.  real: tiempo total usado por elsistema % /usr/bin/time -v./matr_mult2 (wall-clock CPU time). User time (seconds): 4.86 System time (seconds): 0.01  user: tiempo de CPU ejecutando enmodo Percent of CPU this job got: 99% usuario. Elapsed (wall clock) time 0:04.90  sys: tiempo de CPU ejecutando códigodel Maximum RSS (kbytes): 48784 Major page faults: 0 núcleo. Minor page faults: 3076  Cambios de contexto voluntarios: al tener que Voluntary context switches: 1 esperar a una operación de E/S cede la CPU a Involuntary context switches: 195 otro proceso....  Cambios involuntarios: Expira su “timeslice”. No confundir con:  Major page faults: requieren accederal disco. % time./matr_mult2 real 0m4.862s user 0m4.841s sys 0m0.010s 38 Monitor gprof  Da información sobre el tiempo de CPU y número de veces que se ejecuta cada función de un proceso/hilo en un sistema Unix.  Utilización de gprof para programas escritos en C, C++:  Instrumentación en lacompilación:  gcc prog.c –o prog –pg -g Programa Añadir Programa  Ejecución del programa y recogida de instrumentación original instrumentado información: ./prog  La información recogida se deja en el fichero gmon.out Datos sobre el comportamiento Ejecutar  Visualización de la información referida a la del programa programa ejecución del programa:  gprof prog 39 gprof (ejemplo) float a=0.3; float b=0.8; float c=0.1; void main(void) { unsigned long i; for (i=0;i

Use Quizgecko on...
Browser
Browser