El proveedor profile proporciona sondeos asociados a la activación de una interrupción temporal cada intervalo de tiempo fijo especificado. Estos sondeos no anclados no están asociados a ningún punto de ejecución en concreto, sino más bien con el evento de interrupción asíncrono. Estos sondeos pueden utilizarse para proporcionar ejemplos de determinados aspectos del estado del sistema por cada unidad de tiempo, ejemplos que pueden utilizarse posteriormente para deducir la conducta del sistema. Si la tasa de muestreo es alta, o si el tiempo de muestreo es amplio, es posible realizar una deducción incorrecta. Mediante las acciones DTrace, el proveedor profile puede utilizarse para realizar un muestreo de prácticamente cualquier aspecto del sistema. Por ejemplo, podría obtener ejemplos del estado del subproceso actual, el estado de la CPU o la instrucción de la máquina actual.
Las variables de supbroceso local no son accesibles a los sondeos desde el proveedor profile. El uso del identificador especial self para hacer referencia a una variable local con un sondeo de este tipo no generará ningún resultado.
Los sondeos profile-n se activan después de un intervalo de tiempo fijo, en todas las CPU a un alto nivel de interrupción. El intervalo de activación del sondeo está indicado por el valor de n: la fuente de interrupción se activará n veces por segundo. n podría tener también un sufijo de tiempo opcional, en cuyo caso se interpreta que n se encuentra en las unidades que vienen indicadas con el sufijo. Puede consultar la lista de sufijos válidos y las unidades que denotan en la Tabla 19–1.
Tabla 19–1 Sufijos de tiempo válidos
Sufijo |
Unidades de tiempo |
---|---|
nsec o ns |
nanosegundos |
usec o us |
microsegundos |
msec o ms |
milisegundos |
sec o s |
segundos |
min o m |
minutos |
hour o h |
horas |
day o d |
días |
hz |
hercios (frecuencia por segundo) |
El siguiente ejemplo crea un sondeo que se activa a los 97 hercios para obtener muestras del proceso que se encuentra en ejecución:
#pragma D option quiet profile-97 /pid != 0/ { @proc[pid, execname] = count(); } END { printf("%-8s %-40s %s\n", "PID", "CMD", "COUNT"); printa("%-8d %-40s %@d\n", @proc); }
La ejecución del ejemplo anterior durante un breve periodo de tiempo devuelve una salida similar a la del siguiente ejemplo:
# dtrace -s ./prof.d ^C PID CMD COUNT 223887 sh 1 100360 httpd 1 100409 mibiisa 1 223887 uname 1 218848 sh 2 218984 adeptedit 2 100224 nscd 3 3 fsflush 4 2 pageout 6 100372 java 7 115279 xterm 7 100460 Xsun 7 100475 perfbar 9 223888 prstat 15 |
Es posible también utilizar el proveedor profile-n para obtener información de ejemplo acerca de los procesos en ejecución. La siguiente secuencia de comandos de ejemplo D utiliza un sondeo de perfil de 1.001 hercios para obtener ejemplos de la prioridad actual de un proceso especificado:
profile-1001 /pid == $1/ { @proc[execname] = lquantize(curlwpsinfo->pr_pri, 0, 100, 10); }
Para ver esta secuencia de comandos de ejemplo en acción, escriba los siguientes comandos en una ventana:
$ echo $$ 12345 $ while true ; do let i=0 ; done |
En otra ventana, ejecute la secuencia de comandos D durante un breve periodo de tiempo, y sustituya 12345 con el PID que haya devuelto el comando echo:
# dtrace -s ./profpri.d 12345 dtrace: script './profpri.d' matched 1 probe ^C ksh value ------------- Distribution ------------- count < 0 | 0 0 |@@@@@@@@@@@@@@@@@@@@@ 7443 10 |@@@@@@ 2235 20 |@@@@ 1679 30 |@@@ 1119 40 |@ 560 50 |@ 554 60 | 0 |
Esta salida muestra el margen de error de la clase de planificación de utilización compartida de tiempo. Debido a que el proceso shell está girando en la CPU, el sistema reduce constantemente su prioridad. Si el proceso shell se ejecutara con menor frecuencia, su prioridad sería más alta. Para ver este resultado, pulse Control-C en la shell que se encuentra en ciclo y vuelva a ejecutar la secuencia de comandos:
# dtrace -s ./profpri.d 494621 dtrace: script './profpri.d' matched 1 probe |
Escriba algunos caracteres en la shell. Cuando finalice la secuencia de comandos DTrace, aparecerá una salida similar a la del siguiente ejemplo:
ksh value ------------- Distribution ------------- count 40 | 0 50 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 14 60 | 0 |
Dado que el proceso shell se encontraba inactivo esperando una acción por parte del usuario en lugar de estar girando en la CPU, cuando se ejecutó, lo hizo a una prioridad mucho más alta.
Al igual que los sondeos profile- n, los sondeos tick- n se activarán cada intervalo fijo a un alto nivel de interrupción. Sin embargo, a diferencia de los sondeos profile-n que se activan en todas las CPU, los sondeos tick- n se activan sólo en una CPU por intervalo. La CPU efectiva podría cambiar a lo largo del tiempo. Al igual que los sondeos profile- n, n tiene un valor predeterminado de tasa por segundo, pero, opcionalmente, puede también contar con un sufijo de tiempo. Los sondeos tick-n tienen varios usos, como por ejemplo proporcionar salidas periódicas o realizar una acción de forma periódica.
Los argumentos de los sondeos profile son los siguientes:
arg0 |
El contador de programa (PC) del núcleo en el momento en el que se activó el sondeo, o 0 si el proceso actual no estaba en ejecución en el núcleo en el momento de activación del sondeo |
arg1 |
El PC en el proceso a nivel de usuario en el momento de activación del sondeo, o 0 si el proceso actual estaba en ejecución en el núcleo en el momento en el que se activó el sondeo |
Tal y como implican las descripciones, si arg0 no es cero, arg1 es cero; si arg0 es cero, arg1 no es cero. Por lo tanto, puede utilizar arg0 y arg1 para diferenciar nivel de usuario de nivel de núcleo, al igual que en este sencillo ejemplo:
profile-1ms { @ticks[arg0 ? "kernel" : "user"] = count(); }
El proveedor profile utiliza temporizadores de intervalo de resolución arbitraria en el sistema operativo. En arquitecturas que no admitan auténticas interrupciones basadas en el tiempo de resolución arbitraria, la frecuencia está limitada por la frecuencia de reloj del sistema, especificada por la variable del núcleo hz. Los sondeos de frecuencia superior a hz se activarán en este tipo de arquitecturas un cierto número de veces cada 1/hz segundos. Por ejemplo, un sondeo profile de 1.000 hercios en dicha arquitectura, con hz definido en 100, se activará diez veces en una rápida sucesión cada diez milisegundos. En plataformas que admitan resolución arbitraria, un sondeo profile de 1.000 hercios se activará exactamente cada un milisegundo.
El siguiente ejemplo prueba la resolución de una arquitectura determinada:
profile-5000 { /* * We divide by 1,000,000 to convert nanoseconds to milliseconds, and * then we take the value mod 10 to get the current millisecond within * a 10 millisecond window. On platforms that do not support truly * arbitrary resolution profile probes, all of the profile-5000 probes * will fire on roughly the same millisecond. On platforms that * support a truly arbitrary resolution, the probe firings will be * evenly distributed across the milliseconds. */ @ms = lquantize((timestamp / 1000000) % 10, 0, 10, 1); } tick-1sec /i++ >= 10/ { exit(0); }
En una arquitectura que admita sondeos profile con resolución arbitraria, la ejecución de la secuencia de comandos de ejemplo ofrecerá una distribución equilibrada:
# dtrace -s ./restest.d dtrace: script './restest.d' matched 2 probes CPU ID FUNCTION:NAME 0 33631 :tick-1sec value ------------- Distribution ------------- count < 0 | 0 0 |@@@ 10760 1 |@@@@ 10842 2 |@@@@ 10861 3 |@@@ 10820 4 |@@@ 10819 5 |@@@ 10817 6 |@@@@ 10826 7 |@@@@ 10847 8 |@@@@ 10830 9 |@@@@ 10830 |
En una arquitectura que no admita sondeos profile con resolución arbitraria, la ejecución de la secuencia de comandos de ejemplo ofrecerá una distribución desigual:
# dtrace -s ./restest.d dtrace: script './restest.d' matched 2 probes CPU ID FUNCTION:NAME 0 28321 :tick-1sec value ------------- Distribution ------------- count 4 | 0 5 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 107864 6 | 424 7 | 255 8 | 496 9 | 0 |
En estas arquitecturas, hz podría ajustarse manualmente en /etc/system para mejorar la resolución profile efectiva.
Actualmente, todas las variantes de UltraSPARC (sun4u) admiten sondeos profile con resolución arbitraria. Diversas variantes de la arquitectura x86 (i86pc) admiten también sondeos profile con resolución arbitraria, aunque algunas variantes más antiguas no lo hacen.
A diferencia de otros proveedores, el proveedor profile crea sondeos dinámicamente según sean necesarios. Por lo tanto, puede que el sondeo profile que desee no aparezca en una lista de todos los sondeos (una lista conseguida al utilizar dtrace -l -P profile, por ejemplo), pero el sondeo se creará cuando se habilite de forma explícita.
En arquitecturas que admitan sondeos profile con resolución arbitraria, un intervalo demasiado breve provocaría que la máquina devolviera interrupciones basadas en el tiempo, denegando por lo tanto el servicio en el sistema. Para evitar esta situación, el proveedor profile rechazará en segundo plano la creación de todo sondeo que tuviera como resultado un intervalo inferior a doscientos microsegundos.
El proveedor profile utiliza el mecanismo de estabilidad de DTrace para describir sus estabilidades, tal y como se muestra en la tabla siguiente. Para obtener más información sobre el mecanismo de estabilidad, consulte el Capítulo 39Estabilidad.
Elemento |
Estabilidad del nombre |
Estabilidad de los datos |
Clase de dependencia |
---|---|---|---|
Proveedor |
Evolutivo |
Evolutivo |
Común |
Módulo |
Inestable |
Inestable |
Desconocido |
Función |
Privado |
Privado |
Desconocido |
Nombre |
Evolutivo |
Evolutivo |
Común |
Argumentos |
Evolutivo |
Evolutivo |
Común |