feedburner

Lorem ipsum dolor sit amet,
consectetur adipisicing elit,
sed do eiusmod tempor incididunt ut labore
et dolore magna aliqua.

The power of time

Etiquetas:

La instrucción time, usada tal cual, devuelve estadísticas de tiempo invertido en la ejecución del comando que se pase por parámetro. Según man time :

"(...)
La orden time ejecuta el programa orden con los argumentos suministra
dos. Cuando orden finaliza, time escribe un mensaje en la salida
estándar devolviendo estadísticas temporales sobre la ejecución de
este programa. Estas estadísticas están compuestas por (i) el tiempo
real transcurrido entre la llamada y la finalización de orden , (ii)
el tiempo de usuario del procesador (la suma de los valores tms_utime y
tms_cutime en un struct tms tal y como devuelve times(2)), y (iii) el
tiempo de sistema del procesador (la suma de los valores tms_stime y
tms_cstime en un struct tms tal y como devuelve times(2)).
(...)"


Veámos un ejemplo:

dballester@nebuchadnezzar:~$ time scp sqldeveloper-1.1.2.2579-no-jre.zip dballester@localhost:/tmp/prueba2.zip
dballester@localhost's password:
sqldeveloper-1.1.2.2579-no-jre.zip 100% 39MB 38.8MB/s 00:01

real 0m4.963s
user 0m0.688s
sys 0m0.104s
dballester@nebuchadnezzar:~$

Ok, pero si seguimos leyendo el man de time, éste es capaz de darnos muchísima más información. Lo que vemos de real, user y sys es tan solo la salida por defecto y la punta del iceberg.

time nos puede dar estadísticas de ( entre otras ) : el número de veces que el proceso ha sido sacado de la memoria principal, el número de veces que el sistema ha sacado al proceso de ejecución en CPU por haber consumido todo el tiempo asignado para él, número de mensajes ( sockets ) enviados y recibidos...

Todas estas estadísticas ( ver man time ) se pueden obtener indicando un formato de salida determinado a time. Como yo soy, entre muchas otras cosas, vago y con falta de memoria, he montado un script que visualiza todas las estadísticas. No hay magia, solo las muestro pero agrupadas por área. Os dejo el código junto con un ejemplo de ejecución. Para los que nos dedicamos a la consultoría creo que nos irá muy bien tener este script a mano. Está bajo licencia GPL2 así que ya sabéis podéis usarlo, transformarlo y distribuirlo bajo los límites de dicha licencia.

Script time_command.sh disponible en in.solit.us http://in.solit.us/archives/download/23169



Una vez bajado nuestra máquina, hay que darle derechos de ejecucción

chmod 755 time_command.sh


Ejemplo de lanzamiento

Acepta 2 parámetros, el primero debe ser el comando a ejecutar, limitado entre comillas dobles. El segundo es el fichero de log donde se guarda la salida de las estadísticas. Este segundo parámetro es opcional y si no se informa el script generará uno que creará con los datos de la fecha ( fecha/hora hasta los segundos ) del momento de la ejecución, y lo dejará en el mismo directorio donde se ha lanzado el script ( por lo tanto debemos tener derechos de escritura en dicho directorio). Yo recomiendo que dejéis este script en vuestro home y lo lancéis desde ahí


$ ./time_command.sh "scp sqldeveloper-1.1.2.2579-no-jre.zip dballester@localhost:/tmp/prueba2.zip" cp2.log
The authenticity of host 'localhost (127.0.0.1)' can't be established.
RSA key fingerprint is 43:53:7e:71:3a:95:ff:b4:d1:2d:21:dc:c4:1b:ad:1d.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'localhost' (RSA) to the list of known hosts.
dballester@localhost's password:
sqldeveloper-1.1.2.2579-no-jre.zip


Log resultante

$ cat cp2.log
Comand executed scp sqldeveloper-1.1.2.2579-no-jre.zip dballester@localhost:/tmp/prueba2.zip
TIME COMMAND

Elapsed real (wall clock) time used by the process, in [hours:]minutes:seconds 0:06.91
Elapsed real (wall clock) time used by the process in seconds 6.91


CPU STASTISTICS

Percentage of the CPU that this job got(1) 13%
Total number of CPU-seconds used by the system on behalf of the process (in kernel mode), in seconds 0.11
Total number of CPU-seconds that the process used directly (in user mode), in seconds 0.82
Number of times that the program was context-switched voluntarily(2) 5437
Number of times the process was context-switched involuntarily (because the time slice expired) 6024
Number of signals delivered to the process 0


MEMORY STATISTICS

Average amount of shared text in the process, in Kilobytes 0
Average size of the process’s unshared data area, in Kilobytes 0
Average unshared stack size of the process in Kilobytes 0
Average total (data+stack+text) memory use of the process, in Kilobytes 0
Maximum resident set size of the process during its lifetime, in Kilobytes 0
Average resident set size of the process in Kilobytes 0
Number of minor, or recoverable, page faults(3) 1031
Number of times the process was swapped out of main memory 0
System’s page size in bytes(4) 4096


I/O STATISTICS

Number of file system inputs by the process 0
Number of file system outputs by the process 0
Number of major, or I/O-requiring, page faults that occurred while the process was running(5) 1
Number of socket messages received by the process 0
Number of socket messages sent by the process 0




(1) This is just user + system times divided by the total running time
(2) For instance while waiting for an I/O operation to complete
(3)These are pages that are not valid (so they fault)
but which have not yet been claimed by other virtual pages.
Thus the data in the page is still valid but the system tables must be updated.
(4) This is a per-system constant, but varies between systems.
(5) These are faults where the page has actually migrated out of primary memory.












Instrucción watch

Etiquetas:

Cuando montamos un sistema de alta disponibilidad siempre hay que utilizar redundancia para evitar los SPOF ( single Point Of Failure ) o dicho de otra manera: Si quieres alta disponibilidad necesitas tenerlo todo como mínimo 2 veces porque de los elementos vitales para el servicio ( tarjeta de red, discos, controladora, arquitectura fiber channel, electricidad... ) si solo dispones de uno solo, como ese elemento sufra una caída adiós disponibilidad y adiós servicio.

¿A que viene esto? pues bien, viene a que cuando montamos un sistema de alta disponibilidad antes de entregárselo al cliente hemos de verificar que los elementos redundantes que hemos aplicado funcionan correctamente y el servicio no se pierde en caso de fallo de uno de esos elementos. Para certificar el correcto funcionamiento siempre ejecutamos procedimientos que implican un corte 'a la brava' de todos los SPOF protegidos. Es decir, teniendo el cluster arrancado y dando servicio desconectamos cables de red , certificamos que el sistema es consciente de la falta de ese elemento pero que no se ve afectado, volvemos a conectar el cable y certificamos que todo está OK, ya que tan importante es sobrevivir a la caída de un elemento de un cluster como a la consiguiente recuperación y reuso de dicho elemento una vez se ha solventado la incidencia. Lo mismo hacemos con los discos, las conexiones de fibra óptica...

Cuando hago estos tests necesito una herramienta que me visualice de forma efectiva y rápida los cambios de estado de los distintos elementos. Por ejemplo, para saber el estado del link ( quitar y poner cables ) de las tarjetas de red puedo ejecutar mii-tool

root@nclserver02:~# mii-tool
eth0: negotiated 100baseTx-FD, link ok
eth1: negotiated 100baseTx-FD, link ok
root@nclserver02:~#


Que me indica que en ese momento las 2 tarjetas físicas de red están conectadas mediante cable y tienen link ( eth1: negotiated 100baseTx-FD, link ok )

En caso de quitar uno de los cables, si vuelvo a ejecutar mii-tool me aparece el cambio de estado


root@nclserver02:~# mii-tool
eth0: negotiated 100baseTx-FD, link ok
eth1: no link
root@nclserver02:~#


pero me iría mucho mejor ejecutarlo una vez y poder ver en pantalla el cambio sin tener que volver a ejecutar la instrucción. Esto es aplicable también al estado de los filesystems ( df -k ) , multipath... en fin, que preferiría que en según que casos no tener que ir ejecutando periódicamente la instrucción que me permita ver el cambio.

Para eso utilizo la aplicación watch, que viene de serie en todas las distribuciones que he usado y que francamente me parece de una gran utilidad, todo y que hasta ahora en ninguno de los clientes con los que he trabajado la conocían. Es por esto que dejo esta entrada, para dar a conocer que es esta aplicación y como se usa. Estoy seguro que una vez la empieces a usar se convertirá en una de tus herramientas imprescindibles ;)

Tal y como reza man watch, watch ejecuta periódicamente una instrucción visualizando el resultado en pantalla. Con el ejemplo anterior de mii-tool puedo ejecutar

[root@nclserver03 ~]# watch -n0,5 mii-tool


y cada medio segundo ( -n 0,5 ) watch ejecutará mii-tool y me mostrará el resultado 'full screen' con lo que cada ejecución se solapará encima de la anterior, sin reubicación del contenido. Si necesito hacer un grep para que me muestre solo datos relevantes ( imaginad un ls -l , un cat, etc... podemos entrecomillar ( con la tecla para obtener acentos 'ó' pero sin la 'o', no con la comilla simple " '" ) las sentencias para que watch lo ejecute como un todo, de otra forma las instrucciones posteriores a una tubería ( | ) se aplicarán a la ejecución de watch en sí, no a lo que tiene que ejecutar watch. Por ejemplo si quiero ver como se va llenando el filesystem /dev/sda3 podría ejecutar

root@nclserver02:~# watch -n0,5 'df -k | grep "/dev/sda3"'



Otros parámetros interesantes y no excluyente de watch son

-d pone en video inverso los cambios entre 2 tomas

-t no muestra una cabecera que pone por defecto con información sobre la instrucción que se está ejecutando, el periodo de ejecución y la fecha / hora


Fuentes: watch --help

Oracle XE en Ubuntu Edgy amd64 / em64t ( x86-64 )

Etiquetas:

Oracle XE sólo se distribuye en binarios de 32bits, lo que provoca que no pueda instalarse en distribuciones linux de 64bits 'tal cual'. Por necesidades de un proyecto interno he tenido que ver la viabilidad de instalar y usar una base de datos XE bajo Ubuntu Edgy 64 bits, y después de comentarlo un poco con hali en el canal #oracle de irc.freenode.org y unas búsquedas en Google, no ha resultado nada difícil. Aunque estas explicaciones estén descritas para Ubuntu, con entender la idea del porqué de cada cosa, tiene que ser trivial reproducir el proceso en otras distribuciones basadas por ejemplo en RedHat.

  • Debemos instalar librerías de 32 bits para que el proceso de linkado de los binarios de Oracle se pueda realizar.
apt-get install libc6-i386


Explicación de la librería libc6-i386

( luego me he dado cuenta que existen unas librerías libc6-i686 que son la compilación optimizada para i686 de libc6, así que sería más óptimo usarlas en vez de las libc6-i386 )

  • Debemos instalar la versión de 32bits de la librería libaio. Este proceso tengo que mirar si sería posible hacerlo con apt ( en un post anterior indiqué como instalar paquetes de distintas arquitecturas usando up2date en RedHat ), pero de momento lo haremos de forma manual ya que sólo es un paquete y lo tenemos bien localizado.
Podemos bajarlo de http://packages.ubuntu.com/edgy/libs/libaio1 , clickando en el link i386 del apartado Download libaio1 y seleccionando el mirror que más nos convenga ( leed el porqué de la existencia de estas librerías para que entendáis como mejora el rendimiento de I/O ).

y una vez aceptada la licencia de uso, descargamos el paquete .deb en el apartado Oracle Database 10g Express Edition ( Universal ) para tener soporte para varios idiomas

  • Para instalar estos 2 últimos paquetes ( libaio y oracle XE en 32bits ), deberemos forzar dpkg a que los instale aún viendo que la arquitectura donde estamos corriendo no es la misma o compatible con la compilación del software que tratamos de instalar. Para eso utilizaremos la opción --force-arquitecture
dpkg -i --force-architecture libaio1_0.3.106-0ubuntu1_i386.deb
dpkg -i --force-architecture oracle-xe-universal_10.2.0.1-1.0_i386.deb


Como supongo que quien intenta instalar un Oracle ya sabe mínimamente los requerimientos recomendados de entorno, no me meteré a explicar lo del tamaño de swap, memoria mínima... esto está muy bien explicado en cientos de webs, San Google os puede ayudar:)

Ahora ya tenemos los binarios correctamente instalados ( la instalación ya nos ha creado el usuario 'oracle' y el grupo 'dba', propietarios del software de Oracle que hemos instalado) . Sólo nos falta la configuración final y la puesta en marcha.

  • Debemos ejecutar un script proporcionado por Oracle que entre otras cosas creará los scritps de parada y arranque automático de la instancia Oracle y el listener. Este script debe ejecutarse como root, sin el uso de sudos, para ello primero obtendremos una sesión pura de root ( sin necesidad de habilitar el login directo del superusuario )
sudo -s


  • Ahora que ya tenemos una sesión de root, lanzamos el script de configuración del servicio para Oracle XE ( puerto del listener, de la aplición web de administración, passwords... )
/etc/init.d/oracle-xe configure

  • Al cabo de un rato nos debería dar el ok al porceso de configuración/creación de la BD y tener varios procesos de oracle corriendo ( el listener, pmon, smon, reco... ) y deberíamos poder acceder a la administración de la nueva BD mediante el navegador web local al servidor, yendo a la dirección http://127.0.0.1:(puerto que hayamos configurado antes)/apex
  • Es imperativo la definición de las variables de entorno ORACLE_HOME y ORACLE_SID para el usuario oracle, así podréis trabajar con las herramientas de consola ( lnsrctl, sqlplus, rman... ) sin tener problemas
su - oracle
vi $HOME/.bash_profile
export ORACLE_SID=XE
export ORACLE_HOME=/usr/lib/oracle/xe/app/oracle/product/10.2.0/server
export PATH=$ORACLE_HOME/bin:$PATH
export TNS_ADMIN=$ORACLE_HOME/network/admin


Salid de la sesión oracle, volved a entrar y ya podréis trabajar normalmente con la nueva instancia

oracle@nclserver02:~$ sqlplus /nolog

SQL*Plus: Release 10.2.0.1.0 - Production on Tue Apr 10 16:37:03 2007

Copyright (c) 1982, 2005, Oracle. All rights reserved.

SQL> conn /as sysdba
Connected.

SQL> select INSTANCE_NAME,VERSION,DATABASE_STATUS,EDITION from v$instance;

INSTANCE_NAME VERSION DATABASE_STATUS EDITION
---------------- ----------------- ----------------- -------
XE 10.2.0.1.0 ACTIVE XE

SQL> exit
Disconnected from Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production


oracle@nclserver02:~$ rman target / nocatalog

Recovery Manager: Release 10.2.0.1.0 - Production on Tue Apr 10 16:39:59 2007

Copyright (c) 1982, 2005, Oracle. All rights reserved.

connected to target database: XE (DBID=2500655873)
using target database control file instead of recovery catalog

RMAN>


Fuentes: canal #oracle en irc.freenode.org
Google me llevó a http://valery.bgit.net/blog-en/2006/07/09/oracle-database-10g-express-edition-in-linux
os recomiendo la lectura de acciones post instalación

VMWARE y EXT3-fs error (device xxx ) in ext3_ordered_writepage: Out of memory

Bajo condicciones de mucha carga y consumo de memoria en hosts linux corriendo máquinas virtuales VMWare, me he encontrado con el error siguiente:

VMWARE y EXT3-fs error (device xxx ) in ext3_ordered_writepage: Out of memory

Esto ocurre cuando se consume gran cantidad de RAM ( se debería hacer swap ) y muy rápido ( al proceso de swap no le da tiempo de liberar RAM ) , y ni tan solo queda libre para que EXT3 pueda manejar su journaling ( no se puede hacer swap de estos datos )

Para evitarlo, podemos modificar el parámetro vm.min_free_kbytes para reservar, sí o sí, un numero determinado de bytes para el kernel & company.

Para hacerlo, y de paso, que se cargue este valor cada vez que la máquina arranca, añadir la siguiente línea al fichero /etc/sysct.conf ( fichero para definir los parámetros del kernel que se pueden leer/modificar al vuelo )

#Error: EXT3-fs error (device dm-6) in ext3_ordered_writepage: Out of memory
# Solució per evitar que vmware no deixi l'ext-3 sense ram per al journaling
vm.min_free_kbytes = 5000


una vez grabados los cambios ejecutad

sysctl -p

para que se relean y se apliquen los valores definidos en /etc/sysctl.conf

El valor ( 5000 ) está expresado en kilobytes y es el que yo he puesto en mis máquinas, este valor es facultativo, pero no se recomienda muy alto ( y 5MB se considera 'bastante alto' )

Encontré la solución googleando, que me llevó a este foro de vmware

Una explicación del parámetro vm.min_free_kbytes

Cajón de sastre

Post donde voy guardando comandos, técnicas, tips... que no están muy bien documentados o son poco conocidos, pero que se me han hecho muy útiles o necesarios en el día a día de conslutoría o implementación

Paquetes multi arquitectura en el mismo host usando up2date en RedHat

Ejemplo: Trabajar en arquitectura x86_64 y por especificaciones de producto tener que instalar un paquete rpm compilado para arquitectura x86_64 ( nativa ) y el mismo paquete pero para la arquitectura i386. La forma standard es conseguir el paquete compilado para i386 e instalarlo a mano mendiante rpm -i ( y en algunos casos con el parámetro --force ). Mediante up2date, si intentamos hacer lo mismo, sólo chequeará el repositorio para la arquitectura nativa.

Mediante un parámetro no informado en man up2date se puede indicar que se chequee el paquete para una arquitectura definida en vez de la nativa.

up2date --arch=i386 paquetes

nos instalará los paquetes compilados para arquitectura i386 aunque nuestra plataforma nativa ( y por ende la usada por defecto para el chequeo de software ) sea x86_64 y ya tengamos dichos paquetes instalados para 64 bits



Consultar los paquetes instalados en un sistema RedHat, mostrando la arquitectura para cada paquete

Una vez hemos instalado paquetes iguales con arquitecturas distintas, para poder consultar la arquitectura determinada ( rpm por defecto no muestra la arquitectura ) podemos usar la siguiente parametrización de consulta para que rpm nos muestre la CPU para un paquete determinado

rpm -q --queryformat "%{NAME}-%{VERSION}.%{RELEASE} (%{ARCH})\n" paquetes



Descargar el paquete fuente de una paquete ya instalado en el sistema

up2date --get-source kernel-smp