Archive

Archive for May, 2009

Gráficas de rendimiento – Consumo de %CPU y Memoria

May 30th, 2009 6 comments

Sí, este post también habla sobre desarrollo en GNU/Linux… Cuando desarrollamos una aplicación, puede que nos guste/necesitemos ver el rendimiento de esta, así que buscando sobre cómo podría monitorizar el tiempo de CPU y el uso de memoria de una aplicación, me encuentro sin querer con aplicaciones como Cacti, MRTG, a demás de los administradores de taréas de cada uno de los entornos de escritorio de GNU/Linux y todos y cada uno de sus plugins, versiones, modificaciones, changelogs, etc. Pero lo que realmente andaba buscando era algo mucho más simple, alguna utilidad que me permitiese generar una gráfica simple del consumo de CPU y memoria de X programa, así que al no encontrarlo, decidí utilizar un script en python que encontré en un foro, para medir el uso total de la memoria usada por cada uno de los procesos, y escribir algunos scripts para crearme la herramienta que necesitaba, ayudado por gnuplot, para crear gráficas como esta:

1

Aquí os dejo los scripts:

ps_mem.py

#!/usr/bin/env python

# Try to determine how much RAM is currently being used per program.
# Note the per program, not per process. So for example this script
# will report mem used by all httpd process together. In detail it reports:
# sum(all RSS for process instances) + max(shared mem for any process instance)
#
# The shared calculation below will factor out shared text and
# libs etc. within a program, but not between programs. So there
# will always be some overestimation. This will be the same for
# all processes that just use libc for e.g. but more for others
# that use larger shared libs like gnome, kde etc.

# Author: [email protected]

# V1.0      06 Jul 2005    Initial release
# V1.1      11 Aug 2006    root permission required for accuracy
# V1.2      08 Nov 2006    Add total to output
#                          Use KiB,MiB,… for units rather than K,M,…
# V1.3      22 Nov 2006    Ignore shared col from /proc/$pid/statm for
#                          2.6 kernels up to and including 2.6.9.
#                          There it represented the total file backed extent
# V1.4      23 Nov 2006    Remove total from output as it’s meaningless
#                          (the shared values overlap with other programs).
#                          Display the shared column. This extra info is
#                          useful, especially as it overlaps between programs.
# V1.5      26 Mar 2007    Remove redundant recursion from human()
# V1.6      05 Jun 2007    Also report number of processes with a given name.
#                          Patch from [email protected]

# Notes:
#
# All interpreted programs where the interpreter is started
# by the shell or with env, will be merged to the interpreter
# (as that’s what’s given to exec). For e.g. all python programs
# starting with “#!/usr/bin/env python” will be grouped under python.
# You can change this by changing comm= to args= below but that will
# have the undesirable affect of splitting up programs started with
# differing parameters (for e.g. mingetty tty[1-6]).
#
# For 2.6 kernels up to and including 2.6.13 and later 2.4 redhat kernels
# (rmap vm without smaps) it can not be accurately determined how many pages
# are shared between processes in general or within a program in our case:
# http://lkml.org/lkml/2005/7/6/250
# A warning is printed if overestimation is possible.
# In addition for 2.6 kernels up to 2.6.9 inclusive, the shared
# value in /proc/$pid/statm is the total file-backed extent of a process.
# We ignore that, introducing more overestimation, again printing a warning.
#
# I don’t take account of memory allocated for a program
# by other programs. For e.g. memory used in the X server for
# a program could be determined, but is not.
#
# This script assumes threads are already merged by ps

# TODO:
#
# use ps just to enumerate the pids and names
# so as to remove the race between reading rss and shared values

import sys, os, string

if os.geteuid() != 0:
sys.stderr.write(“Sorry, root permission required.\n”);
sys.exit(1)

PAGESIZE=os.sysconf(“SC_PAGE_SIZE”)/1024 #KiB
our_pid=os.getpid()

#(major,minor,release)
def kernel_ver():
kv=open(“/proc/sys/kernel/osrelease”).readline().split(“.”)[:3]
for char in “-_”:
kv[2]=kv[2].split(char)[0]
return (int(kv[0]), int(kv[1]), int(kv[2]))

kv=kernel_ver()

def getShared(pid):
if os.path.exists(“/proc/”+str(pid)+”/smaps”):
shared_lines=[line
for line in open("/proc/"+str(pid)+"/smaps").readlines()
if line.find("Shared")!=-1]
return sum([int(line.split()[1]) for line in shared_lines])
elif (2,6,1) <= kv <= (2,6,9):
return 0 #lots of overestimation, but what can we do?
else:
return int(open(“/proc/”+str(pid)+”/statm”).readline().split()[2])*PAGESIZE

cmds={}
shareds={}
count={}
for line in os.popen(“ps -e -o rss=,pid=,comm=”).readlines():
size, pid, cmd = map(string.strip,line.strip().split(None,2))
if int(pid) == our_pid:
continue #no point counting this process
try:
shared=getShared(pid)
except:
continue #ps gone away
if shareds.get(cmd):
if shareds[cmd] < shared:
shareds[cmd]=shared
else:
shareds[cmd]=shared
#Note shared is always a subset of rss (trs is not always)
cmds[cmd]=cmds.setdefault(cmd,0)+int(size)-shared
if count.has_key(cmd):
count[cmd] += 1
else:
count[cmd] = 1

#Add max shared mem for each program
for cmd in cmds.keys():
cmds[cmd]=cmds[cmd]+shareds[cmd]

sort_list = cmds.items()
sort_list.sort(lambda x,y:cmp(x[1],y[1]))
sort_list=filter(lambda x:x[1],sort_list) #get rid of zero sized processes (kernel threads)

#The following matches “du -h” output
#see also human.py
def human(num, power=”Ki”):
powers=["Ki","Mi","Gi","Ti"]
while num >= 1000: #4 digits
num /= 1024.0
power=powers[powers.index(power)+1]
return “%.1f %s” % (num,power)

def cmd_with_count(cmd, count):
if count>1:
return “%s (%u)” % (cmd, count)
else:
return cmd
print ” Private  +  Shared  =  RAM used\tProgram \n”
for cmd in sort_list:
print “%8sB + %8sB = %8sB\t%s” % (human(cmd[1]-shareds[cmd[0]]), human(shareds[cmd[0]]), human(cmd[1]),
cmd_with_count(cmd[0], count[cmd[0]]))
print “\n Private  +  Shared  =  RAM used\tProgram \n”

#Warn of possible inaccuracies
#1 = accurate
#0 = some shared mem not reported
#-1= all shared mem not reported
def shared_val_accurate():
“”"http://wiki.apache.org/spamassassin/TopSharedMemoryBug”"”
if kv[:2] == (2,4):
if open(“/proc/meminfo”).read().find(“Inact_”) == -1:
return 1
return 0
elif kv[:2] == (2,6):
if os.path.exists(“/proc/”+str(os.getpid())+”/smaps”):
return 1
if (2,6,1) <= kv <= (2,6,9):
return -1
return 0
else:
return 1

vm_accuracy = shared_val_accurate()
if vm_accuracy == -1:
sys.stderr.write(“Warning: Shared memory is not reported by this system.\n”)
sys.stderr.write(“Values reported will be too large.\n”)
elif vm_accuracy == 0:
sys.stderr.write(“Warning: Shared memory is not reported accurately by this system.\n”)
sys.stderr.write(“Values reported could be too large.\n”)

datos.sh

#!/bin/bash

if [ ! $# -eq 2 ]
then
echo “Uso: $0 <proceso> <iteraciones>”
exit 1
fi

PID=`ps -e | grep $1 | awk ‘{print $1}’`

if [ -z "$PID" ]
then
echo “Proceso $1 no encontrado”
unset PID
exit 2
fi

PS_MEM=”./ps_mem.py”
ARCHIVOM=”/tmp/memoria.dat”
ARCHIVOC=”/tmp/cpu.dat”

rm -f “$ARCHIVOC” “$ARCHIVOM”

cont=0
while [ $cont -lt $2 ]
do
#uso de memoria
dMEM=`”$PS_MEM” | grep “$1″ | awk ‘{print \$7}’`
if [ -z "$dMEM" ]
then
dMEM=0
fi
echo $dMEM >> “$ARCHIVOM”

#quantum de CPU
dCPU=`top -n1 -p $PID | grep “$1″ | tr -s ” *” ‘;’ | awk -F\; ‘{print \$10}’`
if [ -z "$dCPU" ]
then
dCPU=0
fi
echo $dCPU >> “$ARCHIVOC”

echo “$cont) Memoria (MB): $dMEM | %CPU: $dCPU”
let cont=cont+1
done

unset dCPU cont dMEM ARCHIVOC ARCHIVOM PS_MEM PID
exit 0

grafica.sh

#!/bin/sh

if [ ! $# -eq 1 ]
then
echo “Uso: $0 ”
exit 1
fi

ARCHIVOM=”/tmp/memoria.dat”
ARCHIVOC=”/tmp/cpu.dat”

if [ ! -f "$ARCHIVOM" ] || [ ! -f "$ARCHIVOC" ]
then
echo “No se encuentran $ARCHIVOM , $ARCHIVOC”
unset ARCHIVOM ARCHIVOC
exit 2
fi

TMPM=”/tmp/mtmp.dat”
TMPC=”/tmp/ctmp.dat”

cont=0;
while read line; do
echo $cont ${line#*\ };
cont=$(( $cont + 1 ));
done < $ARCHIVOM > $TMPM

cont=0;
while read line; do
echo $cont ${line#*\ };
cont=$(( $cont + 1 ));
done < $ARCHIVOC > $TMPC

PLOT=”/tmp/gp1.dat”

rm -f “$PLOT” “$1″

echo “set terminal png” > $PLOT
echo “set title \”RENDIMIENTO\”" >> $PLOT
echo “set grid” >> $PLOT
echo “set ylabel \”Consumo\”" >> $PLOT
echo “set xlabel \”Tiempo\”" >> $PLOT
echo “set output \”$1\”" >> $PLOT
echo “plot \”$TMPM\” w lines title \”Memoria (MB)\”,\”$TMPC\” w lines title \”Uso %CPU\”" >> $PLOT

gnuplot $PLOT

rm -f “$PLOT” “$TMPM” “$TMPC”
unset ARCHIVO TMPM TMPC cont PLOT
exit 0

rendimiento.sh

#!/bin/bash

VISOR=”gpicview ”
if [ ! $# -eq 3 ]
then
echo “Uso: $0

unset VISOR
exit 1
fi

DATOS=”./datos.sh”
GRAFICA=”./grafica.sh”

if [ ! -f "$DATOS" ] || [ ! -f "$GRAFICA" ]
then
echo “No se encuentran \”$DATOS\” , \”$GRAFICA\”"
unset DATOS GRAFICA VISOR
exit 1
fi

$DATOS $1 $3

echo -e “\nGenerando grafica…”
$GRAFICA $2
unset DATOS GRAFICA

echo ‘Visualizando…’
$VISOR $2 &

unset VISOR
exit 0

El script principal es rendimiento.sh al que deben pasársele como argumentos el nombre del proceso, la ruta de la imagen de destino, y el número de iteraciones para recabar información sobre el consumo de CPU y memoria. Después de esto usará gnuplot para crear la gráfica y el visor especificado en “rendimiento.sh” para visualizar la imagen.

Un ejemplo sería este: ./rendimiento.sh Xorg ./grf_xorg.png 30

Categories: Bash Script, GNU/Linux, Programacion Tags:

Algoritmo del Banquero – Implementacion (C)

May 25th, 2009 1 comment

Hace poco tiempo tuve que hacer una implementación del Algoritmo del Banquero usado en SSOO, aquí os dejo un extracto de la Wikipedia y el enlace al código:

http://es.wikipedia.org/wiki/Algoritmo_del_banquero

El Algoritmo del banquero, en sistemas operativos es una forma de evitar el interbloqueo, propuesta por primera vez por Edsger Dijkstra. Es un acercamiento teórico para evitar los interbloqueos en la planificación de recursos. Requiere conocer con anticipación los recursos que serán utilizados por todos los procesos. Esto último generalmente no puede ser satisfecho en la práctica.

Este algoritmo usualmente es explicado usando la analogía con el funcionamiento de un banco. Los clientes representan a los procesos, que tienen un crédito límite, y el dinero representa a los recursos. El banquero es el sistema operativo.

El banco confía en que no tendrá que permitir a todos sus clientes la utilización de todo su crédito a la vez. El banco también asume que si un cliente maximiza su crédito será capaz de terminar sus negocios y retornar el dinero de vuelta a la entidad, permitiendo servir a otros clientes.

El algoritmo mantiene al sistema en un estado seguro. Un sistema se encuentra en un estado seguro si existe un orden en que pueden concederse las peticiones de recursos a todos los procesos, previniendo el interbloqueo. El algoritmo del banquero funciona encontrando estados de este tipo.

Los procesos piden recursos, y son complacidos siempre y cuando el sistema se mantenga en un estado seguro después de la concesión. De lo contrario, el proceso es suspendido hasta que otro proceso libere recursos suficientes.

En términos más formales, un sistema se encuentra en un estado seguro si existe una secuencia segura. Una secuencia segura es una sucesión de procesos, < P1,…, Pn > , donde para un proceso Pi, el pedido de recursos puede ser satisfecho con los recursos disponibles sumados los recursos que están siendo utilizados por Pj, donde j < i. Si no hay suficientes recursos para el proceso Pi, debe esperar hasta que algún proceso Pj termine su ejecución y libere sus recursos. Recién entonces podrá Pi tomar los recursos necesarios, utilizarlos y terminar su ejecución. Al suceder esto, el proceso Pi+1 puede tomar los recursos que necesite, y así sucesivamente. Si una secuencia de este tipo no existe, el sistema se dice que está en un estado inseguro, aunque esto no implica que esté bloqueado.

Así, el uso de este tipo de algoritmo permite impedir el interbloqueo, pero supone una serie de restricciones:

  • Se debe conocer la máxima demanda de recursos por anticipado.
  • Los procesos deben ser independientes, es decir que puedan ser ejecutados en cualquier orden. Por lo tanto su ejecución no debe estar forzada por condiciones de sincronización.
  • Debe haber un número fijo de recursos a utilizar y un número fijo de procesos.
  • Los procesos no pueden finalizar mientras retengan recursos.

Descarga

Categories: C/C++, Programacion, SSOO Tags:

Solucionario Reto Panda Security #1-#3

May 6th, 2009 No comments

Para tenerlo más accesible y organizado, aquí tenéis los enlaces a los posts con las soluciones:

Solucion Reto 1AbsshA
Solucion Reto 2 – Guan & AbsshA
Solucion Reto 3RoMaNSoFt

Categories: Ing. Inversa, MS Windows, Programacion, Retos Tags:

Reto Panda Security #3 (Solucion – Actualizado)

May 5th, 2009 No comments

Esta vez ha sido RoMaNSoFt el autor de la documentación a la solución del reto 3.

Descarga

Actualizado:

Solucion Reto 1
Solucion Reto 2

Categories: Ing. Inversa, MS Windows, Programacion, Retos Tags:

Reto Panda Security #2 (Solucion – Actualizado)

May 5th, 2009 No comments

Esta vez han sido Guan y AbsshA, de CracksLatinos quienes han redactado la documentación del reto, resuelto por los miembros de CracksLatinos.

Mirror 1
Mirror 2

Atualizado:

Solucion Reto 1
Solucion Reto 3

Categories: Ing. Inversa, MS Windows, Programacion, Retos Tags: