InglésFrancésEspañol

Ad


icono de página de OnWorks

perf-script-python: en línea en la nube

Ejecute perf-script-python en el proveedor de alojamiento gratuito de OnWorks a través de Ubuntu Online, Fedora Online, emulador en línea de Windows o emulador en línea de MAC OS

Este es el comando perf-script-python que se puede ejecutar en el proveedor de alojamiento gratuito de OnWorks utilizando una de nuestras múltiples estaciones de trabajo en línea gratuitas, como Ubuntu Online, Fedora Online, emulador en línea de Windows o emulador en línea de MAC OS.

PROGRAMA:

NOMBRE


perf-script-python: procesa datos de seguimiento con un script de Python

SINOPSIS


Perf guión [-s [Python]: secuencia de comandos [.py]]

DESCRIPCIÓN


Esta opción de secuencia de comandos perf se utiliza para procesar datos de secuencias de comandos perf utilizando Python incorporado de perf
Interprete. Lee y procesa el archivo de entrada y muestra los resultados del seguimiento.
análisis implementado en el script de Python dado, si lo hubiera.

A RÁPIDO EJEMPLO


Esta sección muestra el proceso, de principio a fin, de crear una secuencia de comandos Python funcional que
agrega y extrae información útil de un flujo de secuencias de comandos perf sin procesar. Puedes evitar
leer el resto de este documento si un ejemplo es suficiente para usted; el resto de
El documento proporciona más detalles sobre cada paso y enumera las funciones de la biblioteca disponibles para
escritores de guiones.

Este ejemplo realmente detalla los pasos que se utilizaron para crear el recuentos de llamadas al sistema guión
que ve cuando enumera los scripts de secuencias de comandos de rendimiento disponibles a través de Perf guión -l. Como tal, este
La secuencia de comandos también muestra cómo integrar su secuencia de comandos en la lista de aplicaciones de uso general. Perf
guión scripts enumerados por ese comando.

El script syscall-count es un script simple, pero demuestra todas las ideas básicas
necesario para crear un guión útil. Aquí hay un ejemplo de su salida (los nombres de syscall son
aún no admitidos, aparecerán como números):

.pies C
eventos syscall:

recuento de eventos
---------------------------------------- ---------- -
sys_write 455067
sys_getdents 4072
sys_cerrar 3037
sys_swapoff1769
sys_read 923
sys_sched_setparam 826
sistema_abierto 331
sys_newfstat326
mapa del sistema 217
sys_munmap216
sistema_futex 141
selección_sys 102
encuesta_sys 84
sys_setitimer 12
sys_writev 8
15 8
sys_lseek 7
sys_rt_sigprocmask 6
sys_wait4 3
sistema_ioctl 3
sys_set_robust_list 1
salida_sistema 1
56 1
sys_acceso 1
.pie

Básicamente, nuestra tarea es mantener un recuento por llamada al sistema que se actualiza cada vez que un sistema
la llamada ocurre en el sistema. Nuestro script hará eso, pero primero necesitamos registrar los datos
que será procesado por ese script. Teóricamente, hay un par de formas en las que podríamos
Haz eso:

· Podríamos habilitar cada evento en el directorio tracing / events / syscalls, pero esto es
más de 600 llamadas al sistema, mucho más allá del número permitido por perf. Estos syscall individuales
Sin embargo, los eventos serán útiles si queremos utilizar más adelante la orientación que obtenemos de la
scripts de propósito general para profundizar y obtener más detalles sobre llamadas al sistema individuales de
interés.

· Podemos habilitar las llamadas al sistema sys_enter y / o sys_exit que se encuentran en
seguimiento / eventos / raw_syscalls. Estos se llaman para todas las llamadas al sistema; los id el campo puede ser
se utiliza para distinguir entre números de llamadas al sistema individuales.

Para este script, solo necesitamos saber que se ingresó una llamada al sistema; no nos importa como sea
salido, así que usaremos Perf grabar para registrar solo los eventos sys_enter:

.pies C
# perf record -a -e raw_syscalls: sys_enter

^ C [registro de rendimiento: despertado 1 vez para escribir datos]
[registro de rendimiento: capturado y escrito 56.545 MB de datos de rendimiento (~ 2470503 muestras)]
.pie

Las opciones básicamente dicen que se recopilen datos para cada evento de llamada al sistema en todo el sistema y
multiplexar la salida por cpu en un solo flujo. Esa única secuencia se grabará en
un archivo en el directorio actual llamado perf.data.

Una vez que tenemos un archivo perf.data que contiene nuestros datos, podemos usar la opción -g Perf guión opción de
generar una secuencia de comandos de Python que contendrá un controlador de devolución de llamada para cada tipo de evento que se encuentra en
el flujo de seguimiento de datos de perf. (para obtener más detalles, consulte la sección ARRANQUE DE GUÍAS)

.pies C
# secuencia de comandos de rendimiento -g python
secuencia de comandos de Python generada: perf-script.py

El archivo de salida creado también en el directorio actual se llama
perf-script.py. Aquí está el archivo en su totalidad:

# controladores de eventos del script perf, generados por el script perf -g python
# Con licencia según los términos de la licencia GNU GPL versión 2

# Los campos del controlador de eventos common_ * son los campos más útiles comunes a
# todos los eventos. No se corresponden necesariamente con los campos 'common_ *'
# en los archivos de formato. Los campos que no están disponibles como parámetros de controlador pueden
# ser recuperado usando funciones de Python de la forma común _ * (contexto).
# Consulte la documentación de perf-script-python para ver la lista de funciones disponibles.

importar os
importación de sistemas

sys.path.append (os.environ ['PERF_EXEC_PATH'] + \
'/ scripts / python / Perf-Trace-Util / lib / Perf / Trace')

desde la importación de perf_trace_context *
desde Core import *

def trace_begin ():
imprimir "en trace_begin"

def trace_end ():
imprimir "en trace_end"

def raw_syscalls__sys_enter (nombre_evento, contexto, CPU_común,
common_secs, common_nsecs, common_pid, common_comm,
id, argumentos):
print_header (nombre_evento, common_cpu, common_secs, common_nsecs,
común_pid, común_comm)

print "id =% d, args =% s \ n"% \
(id, argumentos),

def trace_unhandled (nombre_de_evento, contexto, CPU_común ,sec_común ,nsec_común,
común_pid, común_comm):
print_header (nombre_evento, common_cpu, common_secs, common_nsecs,
común_pid, común_comm)

def print_header (event_name, cpu, secs, nsecs, pid, comm):
imprimir "% -20s% 5u% 05u.% 09u% 8u% -20s"% \
(nombre_de_evento, cpu, segundos, nsecs, pid, comm),
.pie

En la parte superior hay un bloque de comentarios seguido de algunas declaraciones de importación y un anexo de ruta que
cada secuencia de comandos perf debe incluir.

A continuación hay un par de funciones generadas, trace_begin () y trace_end (), que son
llamado al principio y al final de la secuencia de comandos respectivamente (para obtener más detalles, consulte la
Sección SCRIPT_LAYOUT a continuación).

Siguiendo esos son los evento entrenador de animales funciones generadas una para cada evento en el Perf
grabar producción. Las funciones del controlador toman la forma de subsistemanombre del evento, y que no contengo llamado
parámetros, una para cada una campo in las evento; in así caso, existe , solamente una evento,
raw_sysllamadassys_enter (). (Consulte la sección de CONTROLADORES DE EVENTOS a continuación para obtener más información sobre el evento.
manipuladores).

El último par de funciones son, como las funciones de inicio y fin, generadas para cada
texto. El primero, trace_unhandled (), se llama cada vez que el script encuentra un evento en
el archivo perf.data que no corresponde a ningún controlador de eventos en el script. Esto podría
significa que el paso de grabación registró tipos de eventos en los que no estaba realmente interesado,
o la secuencia de comandos se ejecutó en un archivo de seguimiento que no corresponde a la secuencia de comandos.

La secuencia de comandos generada por la opción -g simplemente imprime una línea para cada evento encontrado en la traza
stream, es decir, básicamente, simplemente descarga el evento y los valores de sus parámetros en stdout. los
La función print_header () es simplemente una función de utilidad utilizada para ese propósito. Cambiemos el nombre
el script y ejecútelo para ver el resultado predeterminado:

.pies C
# mv perf-script.py syscall-counts.py
# secuencia de comandos de rendimiento -s syscall-counts.py

raw_syscalls__sys_enter 1 00840.847582083 7506 id perf = 1, args =
raw_syscalls__sys_enter 1 00840.847595764 7506 id perf = 1, args =
raw_syscalls__sys_enter 1 00840.847620860 7506 id perf = 1, args =
raw_syscalls__sys_enter 1 00840.847710478 6533 npviewer.bin id = 78, args =
raw_syscalls__sys_enter 1 00840.847719204 6533 npviewer.bin id = 142, args =
raw_syscalls__sys_enter 1 00840.847755445 6533 npviewer.bin id = 3, args =
raw_syscalls__sys_enter 1 00840.847775601 6533 npviewer.bin id = 3, args =
raw_syscalls__sys_enter 1 00840.847781820 6533 npviewer.bin id = 3, args =
.
.
.
.pie

Por supuesto, para este script, no estamos interesados ​​en imprimir todos los eventos de seguimiento, sino más bien
agregándolo de una manera útil. Así que también nos desharemos de todo lo que tenga que ver con la impresión.
como las funciones trace_begin () y trace_unhandled (), que no usaremos. Eso deja
nosotros con este esqueleto minimalista:

.pies C
importar os
importación de sistemas

sys.path.append (os.environ ['PERF_EXEC_PATH'] + \
'/ scripts / python / Perf-Trace-Util / lib / Perf / Trace')

desde la importación de perf_trace_context *
desde Core import *

def trace_end ():
imprimir "en trace_end"

def raw_syscalls__sys_enter (nombre_evento, contexto, CPU_común,
common_secs, common_nsecs, common_pid, common_comm,
id, argumentos):
.pie

En trace_end (), simplemente imprimiremos los resultados, pero primero necesitamos generar algunos resultados
imprimir. Para hacer eso, necesitamos que nuestro controlador sys_enter () haga el recuento necesario
hasta que se hayan contado todos los eventos. Una tabla hash indexada por syscall id es una buena forma de
almacenar esa información; cada vez que se llama al controlador sys_enter (), simplemente incrementamos
un recuento asociado con esa entrada hash indexada por ese ID de llamada al sistema:

.pies C
syscalls = autodict ()

tratar:
syscalls [id] + = 1
excepto TypeError:
syscalls [id] = 1
.pie

Las llamadas al sistema autodicto El objeto es un tipo especial de diccionario de Python (implementado en
Core.py) que implementa Perl's autovivir hashes en Python, es decir, con autovivificación
hash, puede asignar valores hash anidados sin tener que tomarse la molestia de crear
niveles intermedios si no existen, por ejemplo, syscalls [comm] [pid] [id] = 1 creará el
niveles de hash intermedios y finalmente asigne el valor 1 a la entrada de hash para id (porque
el valor que se asigna no es un objeto hash en sí mismo, el valor inicial se asigna en el
Excepción TypeError. Bueno, puede haber una mejor manera de hacer esto en Python, pero eso es lo que
funciona por ahora).

Poniendo ese código en el controlador raw_syscalls__sys_enter (), efectivamente terminamos con un
diccionario de un solo nivel con clave en el ID de llamada del sistema y con los recuentos que hemos contabilizado como valores.

La función print_syscall_totals () itera sobre las entradas en el diccionario y
muestra una línea para cada entrada que contiene el nombre de la llamada al sistema (las claves del diccionario contienen
los identificadores de syscall, que se pasan a la función Util syscall_name (), que traduce
los números de syscall sin procesar a las cadenas de nombre de syscall correspondientes). La salida es
se muestra después de que se hayan procesado todos los eventos en la traza, llamando al
Función print_syscall_totals () del controlador trace_end () llamada al final del script
procesar.

El script final que produce el resultado que se muestra arriba se muestra en su totalidad a continuación
(el ayudante syscall_name () aún no está disponible, solo puede tratar con las identificaciones por ahora):

.pies C
importar os
importación de sistemas

sys.path.append (os.environ ['PERF_EXEC_PATH'] + \
'/ scripts / python / Perf-Trace-Util / lib / Perf / Trace')

desde la importación de perf_trace_context *
desde Core import *
desde Util import *

syscalls = autodict ()

def trace_end ():
print_syscall_totals ()

def raw_syscalls__sys_enter (nombre_evento, contexto, CPU_común,
common_secs, common_nsecs, common_pid, common_comm,
id, argumentos):
tratar:
syscalls [id] + = 1
excepto TypeError:
syscalls [id] = 1

def print_syscall_totals ():
si for_comm no es None:
imprimir "\ nsyscall eventos para% s: \ n \ n"% (for_comm),
más:
imprimir "\ nsyscall eventos: \ n \ n",

imprimir "% -40s% 10s \ n"% ("evento", "recuento"),
imprimir "% -40s% 10s \ n"% ("------------------------------------- --- ", \
"-----------"),

para id, val en sorted (syscalls.iteritems (), key = lambda (k, v): (v, k), \
reverso = Verdadero):
imprimir "% -40s% 10d \ n"% (syscall_name (id), val),
.pie

El script se puede ejecutar como antes:

# secuencia de comandos de rendimiento -s syscall-counts.py

Entonces, esos son los pasos esenciales para escribir y ejecutar un guión. El proceso puede ser
generalizado a cualquier punto de rastreo o conjunto de puntos de rastreo que le interesen, básicamente busque
los puntos de seguimiento que le interesan consultando la lista de eventos disponibles mostrada por
Perf lista y / o busque en / sys / kernel / debug / tracing eventos para eventos y campos detallados
info, registre los datos de seguimiento correspondientes utilizando Perf grabar, pasándole la lista de
eventos interesantes, genere un script esqueleto usando Perf guión -g pitón y modificar el
código para agregarlo y mostrarlo para sus necesidades particulares.

Una vez que haya hecho eso, puede terminar con un script de propósito general que desea conservar
alrededor y tener disponible para uso futuro. Escribiendo un par de scripts de shell muy simples
y colocándolos en el lugar correcto, puede tener su secuencia de comandos en la lista junto con el otro
guiones enumerados por el Perf guión -l comando por ejemplo:

.pies C
root @ tropicana: ~ # perf script -l
Lista de scripts de seguimiento disponibles:
latencia de activación en todo el sistema latencia mínima / máxima / promedio de activación
rw-por-archivo actividad de r / w para un programa, por archivo
Actividad de r / w en todo el sistema rw-by-pid
.pie

Un buen efecto secundario de hacer esto es que también captura el probablemente largo Perf
grabar comando necesario para registrar los eventos para el script.

Para que el guión aparezca como incorporado script, escribe dos scripts simples, uno para
grabación y uno para la presentación de informes.

El grabar script es un script de shell con el mismo nombre base que su script, pero con
-Registro adjunto. El script de shell debe colocarse en perf / scripts / python / bin
directorio en el árbol de fuentes del kernel. En ese guión, escribe el Perf grabar
línea de comandos necesaria para su secuencia de comandos:

.pies C
# cat kernel-source / tools / perf / scripts / python / bin / syscall-count-record

#!/ bin / bash
registro de perf -a -e raw_syscalls: sys_enter
.pie

El reporte script también es un script de shell con el mismo nombre base que su script, pero con
-informe adjunto. También debe estar ubicado en el directorio perf / scripts / python / bin. En
ese guión, escribe el Perf guión -s línea de comandos necesaria para ejecutar su script:

.pies C
# cat kernel-source / tools / perf / scripts / python / bin / syscall-count-report

#!/ bin / bash
# descripción: recuentos de llamadas al sistema en todo el sistema
secuencia de comandos de rendimiento -s ~ / libexec / perf-core / scripts / python / syscall-counts.py
.pie

Tenga en cuenta que la ubicación de la secuencia de comandos de Python proporcionada en la secuencia de comandos de shell está en el
directorio libexec / perf-core / scripts / python - aquí es donde el script será copiado por
para lograr instalar cuando instalas perf. Para que la instalación instale su script allí,
su secuencia de comandos debe estar ubicada en el directorio perf / scripts / python en la fuente del kernel
árbol:

.pies C
# ls -al kernel-source / tools / perf / scripts / python

root @ tropicana: / home / trz / src / tip # ls -al tools / perf / scripts / python
32 totales
drwxr-xr-x 4 trz trz 4096 2010-01-26 22:30.
drwxr-xr-x 4 trz trz 4096 2010-01-26 22:29 ..
drwxr-xr-x 2 trz trz 4096 2010-01-26 22:29 papelera
-rw-r - r-- 1 trz trz 2548 2010-01-26 22:29 check-perf-script.py
drwxr-xr-x 3 trz trz 4096 2010-01-26 22:49 Perf-Trace-Util
-rw-r - r-- 1 trz trz 1462 2010-01-26 22:30 syscall-counts.py
.pie

Una vez que haya hecho eso (no olvide hacer un nuevo para lograr instalar, de lo contrario tu script no
aparecer en tiempo de ejecución), Perf guión -l debería mostrar una nueva entrada para su script:

.pies C
root @ tropicana: ~ # perf script -l
Lista de scripts de seguimiento disponibles:
latencia de activación en todo el sistema latencia mínima / máxima / promedio de activación
rw-por-archivo actividad de r / w para un programa, por archivo
Actividad de r / w en todo el sistema rw-by-pid
recuentos de syscall-count recuentos de syscall en todo el sistema
.pie

Ahora puede realizar el paso de grabación a través de Perf guión grabar:

# perf script record syscall-count

y mostrar la salida usando Perf guión reporte:

# perf script report syscall-count

ARRANCADOR GUIONES


Puede comenzar rápidamente a escribir un script para un conjunto particular de datos de seguimiento al
generando un script esqueleto usando Perf guión -g pitón en el mismo directorio que un
archivo de seguimiento perf.data existente. Eso generará un script de inicio que contiene un controlador
para cada uno de los tipos de eventos en el archivo de seguimiento; simplemente imprime todos los campos disponibles para
cada evento en el archivo de seguimiento.

También puede ver los scripts existentes en ~ / libexec / perf-core / scripts / python para
ejemplos típicos que muestran cómo hacer cosas básicas como datos de eventos agregados, resultados de impresión,
etc. Además, el script check-perf-script.py, aunque no es interesante por sus resultados,
intenta ejercitar todas las funciones principales de secuencias de comandos.

EVENT MANIPULADORES


Cuando se invoca el script perf mediante un script de seguimiento, un entrenador de animales función is
llamado para cada evento en la traza. Si no hay una función de controlador definida para un determinado
tipo de evento, el evento se ignora (o se pasa a un rastro_manejado función, ver más abajo) y
se procesa el siguiente evento.

La mayoría de los valores de campo del evento se pasan como argumentos a la función del controlador; algunos de
los menos comunes no lo son: están disponibles como llamadas al ejecutable perf
(vea abajo).

Como ejemplo, el siguiente comando perf record se puede utilizar para registrar todos los sched_wakeup
eventos en el sistema:

# perf record -a -e sched: sched_wakeup

Los rastros destinados a ser procesados ​​mediante un script deben registrarse con la opción anterior: -a
para habilitar la recopilación en todo el sistema.

El archivo de formato para el evento sched_wakep define los siguientes campos (consulte
/ sys / kernel / debug / tracing / events / sched / sched_wakeup / format):

.pies C
formato:
campo: tipo_común corto sin firmar;
campo: char common_flags sin firmar;
campo: char sin firmar common_preempt_count;
campo: int common_pid;

campo: char comm [TASK_COMM_LEN];
campo: pid_t pid;
campo: int prio;
campo: int éxito;
campo: int target_cpu;
.pie

La función de controlador para este evento se definiría como:

.pies C
def sched__sched_wakeup (nombre_de_evento, contexto, CPU_común, seg_común,
common_nsecs, common_pid, common_comm,
comm, pid, prio, éxito, target_cpu):
pass
.pie

La función del controlador toma la forma subsystem__event_name.

Los argumentos common_ * en la lista de argumentos del manejador son el conjunto de argumentos pasados ​​a
todos los controladores de eventos; algunos de los campos corresponden a los campos common_ * en el formato
archivo, pero algunos están sintetizados, y algunos de los campos common_ * no son lo suficientemente comunes como para
pasar a cada evento como argumentos, pero están disponibles como funciones de biblioteca.

Aquí hay una breve descripción de cada uno de los argumentos de eventos invariantes:

event_name el nombre del evento como texto
contexto una 'cookie' opaca utilizada en las llamadas de vuelta a perf
common_cpu la CPU en la que ocurrió el evento
common_secs la parte de segundos de la marca de tiempo del evento
common_nsecs la parte nsecs de la marca de tiempo del evento
common_pid el pid de la tarea actual
common_comm el nombre del proceso actual

Todos los campos restantes en el archivo de formato del evento tienen contrapartes como controlador
argumentos de función del mismo nombre, como se puede ver en el ejemplo anterior.

Lo anterior proporciona los conceptos básicos necesarios para acceder directamente a todos los campos de cada evento en un
trace, que cubre el 90% de lo que necesita saber para escribir un script de seguimiento útil. los
las secciones siguientes cubren el resto.

GUIÓN DISPOSICIÓN


Cada secuencia de comandos de perf script de Python debe comenzar configurando una ruta de búsqueda de módulo de Python y
'importar' algunos módulos de soporte (consulte las descripciones de los módulos a continuación):

.pies C
importar os
importación de sistemas

sys.path.append (os.environ ['PERF_EXEC_PATH'] + \
'/ scripts / python / Perf-Trace-Util / lib / Perf / Trace')

desde la importación de perf_trace_context *
desde Core import *
.pie

El resto del script puede contener funciones de controlador y funciones de soporte en cualquier orden.

Aparte de las funciones del controlador de eventos discutidas anteriormente, cada script puede implementar un conjunto
de funciones opcionales:

traza_comienzo, si está definido, se llama antes de que se procese cualquier evento y le da a los scripts un
oportunidad de realizar tareas de configuración:

.pies C
def trace_begin:
pass
.pie

fin_rastreo, si se define, se llama después de que se hayan procesado todos los eventos y le da a los scripts un
oportunidad de realizar tareas de final de secuencia de comandos, como mostrar resultados:

.pies C
def fin_rastreo:
pass
.pie

trace_unhandled, si está definido, se llama después para cualquier evento que no tenga un controlador
definido explícitamente para ello. Se le pasa el conjunto estándar de argumentos comunes:

.pies C
def trace_unhandled (nombre_de_evento, contexto, CPU_común, seg_común,
common_nsecs, common_pid, common_comm):
pass
.pie

Las secciones restantes proporcionan descripciones de cada uno de los scripts perf integrados disponibles.
Módulos de Python y sus funciones asociadas.

DISPONIBLE MÓDULOS Y Las funciones


Las siguientes secciones describen las funciones y variables disponibles a través de los distintos perfiles
módulos de script de Python. Para usar las funciones y variables del módulo dado, agregue el
correspondiente en XXXX importar línea a su secuencia de comandos perf.

núcleo.py Módulo
Estas funciones proporcionan algunas funciones esenciales para los scripts de usuario.

El cadena_bandera y símbolo_str Las funciones proporcionan cadenas legibles por humanos para banderas y símbolos.
los campos. Estos corresponden a las cadenas y valores analizados de la Imprimir fmt campos de la
archivos de formato de evento:

flag_str (event_name, field_name, field_value) - devuelve la representación de cadena correspondiente a field_value para el campo de bandera field_name del evento event_name
symbol_str (event_name, field_name, field_value) - devuelve la representación de cadena correspondiente a field_value para el campo simbólico field_name del evento event_name

El autodicto La función devuelve un tipo especial de diccionario de Python que implementa las
autovivir hashes en Python, es decir, con hashes de autovivificación, puedes asignar hash anidados
valores sin tener que tomarse la molestia de crear niveles intermedios si no
existe.

autodict () - devuelve una instancia de diccionario autovivificante

perf_trace_context Módulo
Algunos de los común Los campos en el archivo de formato de evento no son tan comunes, pero deben ser
no obstante, accesible a los scripts de usuario.

perf_trace_context define un conjunto de funciones que se pueden utilizar para acceder a estos datos en el
contexto del evento actual. Cada una de estas funciones espera una variable de contexto, que es
lo mismo que la variable de contexto pasada a cada controlador de eventos como segundo argumento.

common_pc (contexto) - devuelve common_preempt count para el evento actual
common_flags (contexto): devuelve common_flags para el evento actual
common_lock_depth (contexto) - devuelve common_lock_depth para el evento actual

Util.py Módulo
Varias funciones de utilidad para usar con el script perf:

nsecs (segundos, nsecs): devuelve el total de nsecs dado el par de segundos / nsecs
nsecs_secs (nsecs): devuelve la porción de segundos enteros dados los nsecs
nsecs_nsecs (nsecs) - devuelve nsecs resto dado nsecs
nsecs_str (nsecs): devuelve una cadena imprimible con el formato secs.nsecs
avg (total, n): devuelve el promedio dado una suma y un número total de valores

Use perf-script-python en línea usando los servicios de onworks.net


Servidores y estaciones de trabajo gratuitos

Descargar aplicaciones de Windows y Linux

  • 1
    VBA-M (Archivado - Ahora en Github)
    VBA-M (Archivado - Ahora en Github)
    El proyecto se ha trasladado a
    https://github.com/visualboyadvance-m/visualboyadvance-m
    caracteristicas:Creación de trucosguardar estadosmulti
    sistema, compatible con gba, gbc, gb, sgb,
    sgb2tu...
    Descargar VBA-M (Archivado - Ahora en Github)
  • 2
    Stacer
    Stacer
    Optimizador y monitorización del sistema Linux
    Repositorio de Github:
    https://github.com/oguzhaninan/Stacer.
    Público: Usuarios finales / Escritorio. Usuario
    interfaz: Qt. Programando La...
    Descargar Stacer
  • 3
    NaranjaZorro
    NaranjaZorro
    Bifurcación de TeamWinRecoveryProject (TWRP)
    con muchas funciones adicionales, rediseño
    y más funciones: admite agudos y
    ROM no Treble Kernel Oreo actualizado,
    construido...
    Descargar Orange Fox
  • 4
    itop - ITSM CMDB de código abierto
    itop - ITSM CMDB de código abierto
    Portal de operaciones de TI: un espacio abierto completo
    fuente, ITIL, servicio basado en web
    herramienta de gestión que incluye un completo
    CMDB personalizable, un sistema de asistencia técnica y
    un hombre de documentos...
    Descargar itop - ITSM CMDB OpenSource
  • 5
    Clementine
    Clementine
    Clementine es una música multiplataforma
    reproductor y organizador de bibliotecas inspirado en
    Amarok 1.4. Tiene un rápido y
    interfaz fácil de usar y le permite
    busca y...
    Descargar Clementina
  • 6
    XISMUS
    XISMUS
    ATENCIÓN: la actualización acumulativa 2.4.3 ha
    sido lanzado !! La actualización funciona para cualquier
    versión 2.xx anterior. Si actualiza
    desde la versión v1.xx, descargue y
    i ...
    Descargar XISMuS
  • Más "

Comandos de Linux

Ad