Weno, estos dias voy a ir adaptando una nueva plantilla para el blog espero que sea la definitiva aunque no creo. ;)
Estará adaptada lo antes posible.
martes, 30 de junio de 2009
martes, 23 de junio de 2009
Bash Script con varios nucleos - Parelelizando
Hace unos dias lei un árticulo sobre este tema en LinuxMagazine el cual me pareció de lo más interesante.
La verdad es que hasta ese momento no se me había pasado por la cabeza la posibilidad de explotar la potencia de varios cores en un script bash.
Cuando paralelizar script?
Este es para mi el punto mas importante a tener en cuenta, ya que aunque podríamos vernos tentados a paralelizar a diestro y siniestro, no siempre nos aportará beneficios, es más en determinadas ocasiones supondrá una pérdida de rendimiento.
No es mi intención explicar el concepto de procesamiento paralelo, simplemente mencionar que a menos que el proceso que estemos ejecutando suponga una carga muy alta para un core, no es recomendable, ya que el coste de cambiar de core será mayor que la ganancia obtenida.
Una manera de saber si para nuestro proceso es "rentable" o no, sería ver la salida del comando sar.
En mi caso tengo ejecutandose un find en la maquina:
#find / -name "*".jpg"*"
En una segunda consola miro el consumo de cpu:
#sar -u -P ALL 1 0
Obteniendo salidas como esta:
00:36:34 CPU %user %nice %system %iowait %steal %idle
00:36:35 all 0,95 0,00 1,65 22,22 0,00 75,18
00:36:35 0 1,96 0,00 3,92 76,47 0,00 17,65
00:36:35 1 0,95 0,00 2,86 15,24 0,00 80,95
00:36:35 2 0,89 0,00 0,89 0,00 0,00 98,21
00:36:35 3 0,00 0,00 0,00 0,00 0,00 100,00
Como podemos observar, el procesador "0" esta trabajando mucho más que el resto y sería un candidato para el tema que nos ocupa de ser porque el consumo se debe a operaciones I/O, lo cual hace que no sea buena idea, ya que no es trabajo propiamente del procesador. Otro caso seria si la mayor parte del trabajo fuera en la columna "user" Dicho esto, una vez hayamos decidido si es o no oportuno, comenzamos a paralelizar nuestro script.
1.- Este ejemplo es el más agresivo ya que podría provocar un incremento de procesos en la máquina y un consumo de memoria capaz de dejarla frita.
Para cada orden de nuestro bucle se inicia un proceso distinto, y luego se espera q que todos los procesos hayan finalizado.
funcion(){
for i in XXX do
loquesea $i &
done
wait
}
2.- Este ejemplo intenta distribuir argumentos para la ejecución de procesos, según el número de procesadores de nuestra máquina.(Para que el número total de procesos no aumente demasiado)
Este procesamiento es adecuado siempre que el consumo de cpu sea similar entre procesos ya que si no, podría darse el caso de que todos los procesos con consumo alto recayeran sobre la misma cpu, con lo que no habríamos conseguida nada
Este problema lo tendremos siempre que no hagamos una selección de procesadores en función de su carga.
#Definimos nuestro numero de procesadores
let PMAX=(`ls -ld /sys/devices/system/cpu/cpu*|wc -l`)-1
funcion(){
procesadores=0
#Recorremos la entrada de parametros a procesar
for i in XXX do
#Cada parametro lo añadimos al vector final
items[$procesadores]="${items[procesadores]} \"$i\""
shift
#Modificamos la posicion actual entre 0 y PMAX-1
let procesadores=$((procesadores+1)%PMAX)
done
#Con todos los argumentos en nuestro vector, lanzamos PAMX procesos, con la ejecucion
#de estos parametros
for (procesadores=0 procesadores
ejecucionXXX
done
wait
La verdad es que hasta ese momento no se me había pasado por la cabeza la posibilidad de explotar la potencia de varios cores en un script bash.
Cuando paralelizar script?
Este es para mi el punto mas importante a tener en cuenta, ya que aunque podríamos vernos tentados a paralelizar a diestro y siniestro, no siempre nos aportará beneficios, es más en determinadas ocasiones supondrá una pérdida de rendimiento.
No es mi intención explicar el concepto de procesamiento paralelo, simplemente mencionar que a menos que el proceso que estemos ejecutando suponga una carga muy alta para un core, no es recomendable, ya que el coste de cambiar de core será mayor que la ganancia obtenida.
Una manera de saber si para nuestro proceso es "rentable" o no, sería ver la salida del comando sar.
En mi caso tengo ejecutandose un find en la maquina:
#find / -name "*".jpg"*"
En una segunda consola miro el consumo de cpu:
#sar -u -P ALL 1 0
Obteniendo salidas como esta:
00:36:34 CPU %user %nice %system %iowait %steal %idle
00:36:35 all 0,95 0,00 1,65 22,22 0,00 75,18
00:36:35 0 1,96 0,00 3,92 76,47 0,00 17,65
00:36:35 1 0,95 0,00 2,86 15,24 0,00 80,95
00:36:35 2 0,89 0,00 0,89 0,00 0,00 98,21
00:36:35 3 0,00 0,00 0,00 0,00 0,00 100,00
Como podemos observar, el procesador "0" esta trabajando mucho más que el resto y sería un candidato para el tema que nos ocupa de ser porque el consumo se debe a operaciones I/O, lo cual hace que no sea buena idea, ya que no es trabajo propiamente del procesador. Otro caso seria si la mayor parte del trabajo fuera en la columna "user" Dicho esto, una vez hayamos decidido si es o no oportuno, comenzamos a paralelizar nuestro script.
1.- Este ejemplo es el más agresivo ya que podría provocar un incremento de procesos en la máquina y un consumo de memoria capaz de dejarla frita.
Para cada orden de nuestro bucle se inicia un proceso distinto, y luego se espera q que todos los procesos hayan finalizado.
funcion(){
for i in XXX do
loquesea $i &
done
wait
}
2.- Este ejemplo intenta distribuir argumentos para la ejecución de procesos, según el número de procesadores de nuestra máquina.(Para que el número total de procesos no aumente demasiado)
Este procesamiento es adecuado siempre que el consumo de cpu sea similar entre procesos ya que si no, podría darse el caso de que todos los procesos con consumo alto recayeran sobre la misma cpu, con lo que no habríamos conseguida nada
Este problema lo tendremos siempre que no hagamos una selección de procesadores en función de su carga.
#Definimos nuestro numero de procesadores
let PMAX=(`ls -ld /sys/devices/system/cpu/cpu*|wc -l`)-1
funcion(){
procesadores=0
#Recorremos la entrada de parametros a procesar
for i in XXX do
#Cada parametro lo añadimos al vector final
items[$procesadores]="${items[procesadores]} \"$i\""
shift
#Modificamos la posicion actual entre 0 y PMAX-1
let procesadores=$((procesadores+1)%PMAX)
done
#Con todos los argumentos en nuestro vector, lanzamos PAMX procesos, con la ejecucion
#de estos parametros
for (procesadores=0 procesadores
ejecucionXXX
done
wait
martes, 2 de junio de 2009
Lectura recomendada - La ética del hackers y el espíritu de la era de la información
Acabo de terminar el libro con el que estaba enfrascado estos últimos días.
Aunque no soy quien para andar recomendando libros, creo que siempre está bien leer un poco de todo, y si alguien piensa que merece la pena pues mejor ;)
El libro "La ética del hackers y el espíritu de la era de la información" de Pekka Himanen, es un mezcla entre sociología, filosofía, economía y ética. Una mezcla explosiva pero interesante.
Es un libro corto (200pag. y 50pag de notas.) pero denso.
Weno no es mi intención hacer comentario alguno sobre el contenido del libro ni criticas tampoco, para eso ya hay gente mucho mejor que yo ;), así que para terminar... que me ha sorprendido muy gratamente. Recomendado queda.
martes, 26 de mayo de 2009
Nuevo animalito - HTC MAGIC
Weno hace un par de horas me han traído mi nuevo teléfono, y es que la operadora ha tenido a bien ofrecerme el terminal que me interesaba.
Ahora solo falta ir dándole vueltas para ver que se le puede sacar al "bicho".
A ver si cumple con lo que se espera de el. ;)
......... De momento pinta bien la cosa ;))
De más está comentar que ahora estoy como un "xiquillete" con juguete nuevo ;)
Ahora solo falta ir dándole vueltas para ver que se le puede sacar al "bicho".
A ver si cumple con lo que se espera de el. ;)
......... De momento pinta bien la cosa ;))
De más está comentar que ahora estoy como un "xiquillete" con juguete nuevo ;)
lunes, 18 de mayo de 2009
SSL - "Sin" y "Con" certificado. Renegociando la conexión
Hace ya un par de meses, por requisitos de una aplcación, me vi en la tesitura de configurar
apache para poder ofrecer una parte de los contenidos de una web por ssl sin certificado
de cliente y el resto mediante ssl pero con certificado de cliente.
Al final todo quedo en nada ya que la primera parte del contenido se acabo ofreciendo
sin ssl, pero como suele ocurrir en estos casos, el trabajo ya estaba hecho ;) así que ahí
van los resultados.
El problema con el que me encrontre es que la directiva "SSLVerifyClient" encargada de
solicitar el certificado al cliente, es aplicable y cito textualmente de la página de
apache a... ("server config, virtual host, directory, .htaccess")
Esto evidentemente te lleva a pensar en una solución por ejemplo, de este tipo:
Donde para el patron "/sitio/" solicitamos el certificado del cliente y para el resto no.
Hay que decir, que probamos "mil" conbinaciones más, que no vienen al caso con valores
optional para la directiva SSLVerifyClient.
El proble es que si bien esta directiva es aplicable, lo que no indican es que la
renegociación de certificados no funciona correctamente en mod_ssl. Me explico.......
En el saludo inicial de la conexión, ya sea porque esta definido a nivel del servidor o a
nivel del VirtualHost, apache solicita o no el certificado, pero luego es incapaz de
renegociar esa conexión, para cambiar y usar o dejar de usar este certificado.
Con lo que una vez solicitado o no, esto ya no varia para la conexión.
(He leido referencias a un bug de mod_ssl, aunque no se si es cierto o si simplemente
no esta contemplado en la implementación)
Por este motivo y tras abrir el pertinente caso de soporte (Donde tanto yo como los distintos
técnicos de soporte de los niveles por donde paso la incidencia), decidimos que la
opción viable en este caso era forzar el establecimiento de una conexión nueva en cada caso.
(Es decir dos VH distintos con dos puertos distintos;))
Esto se tradujo en algo de este tipo:
#En este primer VH cuando encontramos el patron para el que no queremos solicitar certificado
#saltamos directamente al destino.
#Cuando encontramos el patron para el que si queremos solicitar certificado, reescrivimos la url
#para saltar al segundo VH
Al final tras todas las pruebas realizadas, decidimos que esta era la opción más adecuada para
solucionar el problema.
No se si será la opción más "limpia" pero se ajustaba perfectamente al problema que queria
resolver. ;)
apache para poder ofrecer una parte de los contenidos de una web por ssl sin certificado
de cliente y el resto mediante ssl pero con certificado de cliente.
Al final todo quedo en nada ya que la primera parte del contenido se acabo ofreciendo
sin ssl, pero como suele ocurrir en estos casos, el trabajo ya estaba hecho ;) así que ahí
van los resultados.
El problema con el que me encrontre es que la directiva "SSLVerifyClient" encargada de
solicitar el certificado al cliente, es aplicable y cito textualmente de la página de
apache a... ("server config, virtual host, directory, .htaccess")
Esto evidentemente te lleva a pensar en una solución por ejemplo, de este tipo:
VirtualHost..........
.....
"<"locationmatch sitio="">
SSLVerifyClient none
"<"/locationmatch>
"<"locationmatch sitio="">
SSLVerifyClient require
"<"/locationmatch>
......
Donde para el patron "/sitio/" solicitamos el certificado del cliente y para el resto no.
Hay que decir, que probamos "mil" conbinaciones más, que no vienen al caso con valores
optional para la directiva SSLVerifyClient.
El proble es que si bien esta directiva es aplicable, lo que no indican es que la
renegociación de certificados no funciona correctamente en mod_ssl. Me explico.......
En el saludo inicial de la conexión, ya sea porque esta definido a nivel del servidor o a
nivel del VirtualHost, apache solicita o no el certificado, pero luego es incapaz de
renegociar esa conexión, para cambiar y usar o dejar de usar este certificado.
Con lo que una vez solicitado o no, esto ya no varia para la conexión.
(He leido referencias a un bug de mod_ssl, aunque no se si es cierto o si simplemente
no esta contemplado en la implementación)
Por este motivo y tras abrir el pertinente caso de soporte (Donde tanto yo como los distintos
técnicos de soporte de los niveles por donde paso la incidencia), decidimos que la
opción viable en este caso era forzar el establecimiento de una conexión nueva en cada caso.
(Es decir dos VH distintos con dos puertos distintos;))
Esto se tradujo en algo de este tipo:
#En este primer VH cuando encontramos el patron para el que no queremos solicitar certificado
#saltamos directamente al destino.
#Cuando encontramos el patron para el que si queremos solicitar certificado, reescrivimos la url
#para saltar al segundo VH
"<"virtualhost xx.xx.xx.xx:443>
DocumentRoot /../sitio1
ServerName sitio1.es
DirectoryIndex index.html index.htm index.php
Options None
AllowCONNECT 443 444
"<"ifmodule>
RewriteEngine On
RewriteRule ^/$ /paso1/ [R,NE]
"<"/ifmodule>
"<"directory>
Order deny,allow
Allow from all
"<"/directory>
ProxyRequests Off
ProxyVia On
ProxyPreserveHost On
SSLVerifyDepth 10
ProxyPass /paso1/ https://maquina_destino:443/paso1/
ProxyPassReverse /paso1/ https://maquina_destino:443/paso1/
RewriteRule /paso2/ https://sitio2.es:444/paso2/
SSLEngine on
SSLVerifyClient none
SSLProxyEngine on
......
"<"/virtualhost>
#########################################
#En el segundo VH cuando encontramos el patron que nos indica que queremos certificado de cliente
#que es el que nos ha traido a este VH, saltamos al destino.
"<"virtualhost 444>
DocumentRoot /../sitio2
ServerName sitio2.es
ErrorLog logs/sitio2_ssl-error-log
TransferLog logs/sitio2_ssl_access_log
LogLevel warn
DirectoryIndex index.html index.htm index.php
Options None
AllowCONNECT 443 444
"<"ifmodule>
RewriteEngine On
RewriteRule ^/$ /sitio2/ [R,NE]
"<"/ifmodule>
"<"directory>
Order deny,allow
Allow from all
"<"/directory>
ProxyRequests Off
ProxyVia On
ProxyPreserveHost On
SSLVerifyDepth 10
ProxyPass /sitio2/ https://maquina_destino:443/sitio2/
ProxyPassReverse /sitio2/ https://maquina_destino:443/sitio2/
SSLEngine on
SSLVerifyClient require
SSLProxyEngine on
.....
"<"/virtualhost>
Al final tras todas las pruebas realizadas, decidimos que esta era la opción más adecuada para
solucionar el problema.
No se si será la opción más "limpia" pero se ajustaba perfectamente al problema que queria
resolver. ;)
Suscribirse a:
Entradas (Atom)