Hace unos días por necesidades del trabajo, necesite instalarme unos certificados, que habian sido generados y exportados desde una maquina Windows.
La verdad es nunca me habia puesto a trastear con certificados, así que al ver que no podía usarlos, empezaron mis problemillas.
Los formatos no coincidian con los que se suponía.
Para poder exportar el certificado de usuario junto con su clave, el cual esta en formato "pfx"
Lanzamos lo siguiente:
[root@gollum satec]# openssl pkcs12 -in manuel.pfx -out EXPORTADO.TXT -chain -nodes
Tras esto, copiamos el fichero exportado como:
manuel.crt y manuel.key
En cada uno de estos ficheros, editandolos con "vi", dejaremos solo la parte del certificado en el fichero crt y la parte de la firma en el fichero key
CRT
-----BEGIN CERTIFICATE-----
.....
-----END CERTIFICATE-----
KEY
-----BEGIN RSA PRIVATE KEY-----
.....
-----END RSA PRIVATE KEY-----
Con esto tenemos el certificado de cliente, listo para usar.
Ahora vamos a adecuar los certificados raices que estan en formato "pb7"
[root@gollum satec]# openssl pkcs7 -inform DER -outform PEM -in Certificados\ Raices.p7b -out certname.pem -print_certs
Esto nos deja el fichero con los certificados raices listo.
Estos ficheros ya los podemos usar en una máquina Linux.
domingo, 20 de septiembre de 2009
miércoles, 9 de septiembre de 2009
Optimización MySql
Hace ya bastante tiempo comente acerca de un problema de rendimiento con MySql y las SlowQuerys
Bueno pues como la historia siempre se repite (o eso dicen), ha vuelto a ocurrir, pero esta vez hasta que se ha descubierto, que el problema era el mismo, se han probado y profundizado en aspectos que mejoran el rendimiento de MySql
Esto es lo que voy a comentar brevemente.
1.- Lo primero ha sido garantizar que este error no se produce otra vez y para eso he creado un mini script que me vacíe la tabla en cuestión, citada en el post anterior.
NUM_ROWS=`mysql -u root -pXXXXX NOMBRE_BBDD -e"SELECT COUNT(*) FROM NOMBRE_TABLA;"`
#Quitamos 9 caracteres "COUNT(*) " que aparecen en la salida de mysql
NUM_ROWS=`echo${NUM_ROWS:8}`
if [ $NUM_ROWS -gt 2500000 ]; then
echo `date`
echo "El tamano es excesivo, $NUM_ROWS de entradas, hay que vaciar la tabla
NOMBRE_TABLA"
RESULT=`mysql -u root -pXXXXX NOMBRE_BBDD -e"TRUNCATE TABLE NOMBRE_TABLA;"`
echo $RESULT
fi
2.- Thread_cache_size y Thread_cache_concurrency
Esta es la primera parte de la "optimización" que se ha realizado.
Parece que Linux no gestiona bien la creacion de threads, por lo que crear nuevos supone un coste muy elevado.
Cuando tenemos muchas conexiones nuevas a BBDD, es necesario crear estos threads, mientras que si almacenamos los que van quedando libres al desconectarse un usuario, la reasignación de estos es mucho menos costosa, con lo que mejoramos el rendimiento.
Para decidir el valor optimo, podemos empezar por el recomendado "8", he ir ajustándolo de la siguiente manera.
mysql> show status like '%Thread%'; .... | Threads_created | 214 | ....
mysql> show status like '%Conn%'; ... | Connections | 14250 | ...
Threads_created/connections
Si este valor se aproxima a "1", significa que creamos tantos threads como conexiones tenemos, por lo que habria que aumentar el tamaño de la cache de threads.
Si este valor se aprixima a "0" significa que apenas creamos threads nuevos con lo que el tamaño de cache es correcto.
3.-Key_buffer_size
Esta variable indica el tamaño del buffer donde se almacenaran los indices de las tablas MyIsam.
A mas indices cacheados mas accesos en las consultas se servirán desde RAM y menos desde disco, con al aumento de rendimiento que esto supone.
Aquí ya que aún no lo hemos ajustado no voy a profundizar mucho más simplemente comentar que.
key_read_request (indices servidos desde RAM)
key_reads (indices servidos desde disco)
Con estas dos variables podemos ver lo siguiente.
key_read_request 10000
key_reads = 100
key_read_request/key_reads=100
Por lo que estamos obteniendo una proporción de 100 a 1, es decir por cada 100 indices servidos desde RAM 1 es servido desde disco.
Esta es la relación mínima que se cita en la documentación que he encontrado aunque también hablan de valores de 1000 a 1, por lo que cuanto más alto mejor.
Bueno con los ajustes necesarios de estas variables deberíamos notar una mejora de rendimiento en nuestros servidores.
Bueno pues como la historia siempre se repite (o eso dicen), ha vuelto a ocurrir, pero esta vez hasta que se ha descubierto, que el problema era el mismo, se han probado y profundizado en aspectos que mejoran el rendimiento de MySql
Esto es lo que voy a comentar brevemente.
1.- Lo primero ha sido garantizar que este error no se produce otra vez y para eso he creado un mini script que me vacíe la tabla en cuestión, citada en el post anterior.
NUM_ROWS=`mysql -u root -pXXXXX NOMBRE_BBDD -e"SELECT COUNT(*) FROM NOMBRE_TABLA;"`
#Quitamos 9 caracteres "COUNT(*) " que aparecen en la salida de mysql
NUM_ROWS=`echo${NUM_ROWS:8}`
if [ $NUM_ROWS -gt 2500000 ]; then
echo `date`
echo "El tamano es excesivo, $NUM_ROWS de entradas, hay que vaciar la tabla
NOMBRE_TABLA"
RESULT=`mysql -u root -pXXXXX NOMBRE_BBDD -e"TRUNCATE TABLE NOMBRE_TABLA;"`
echo $RESULT
fi
2.- Thread_cache_size y Thread_cache_concurrency
Esta es la primera parte de la "optimización" que se ha realizado.
Parece que Linux no gestiona bien la creacion de threads, por lo que crear nuevos supone un coste muy elevado.
Cuando tenemos muchas conexiones nuevas a BBDD, es necesario crear estos threads, mientras que si almacenamos los que van quedando libres al desconectarse un usuario, la reasignación de estos es mucho menos costosa, con lo que mejoramos el rendimiento.
Para decidir el valor optimo, podemos empezar por el recomendado "8", he ir ajustándolo de la siguiente manera.
mysql> show status like '%Thread%'; .... | Threads_created | 214 | ....
mysql> show status like '%Conn%'; ... | Connections | 14250 | ...
Threads_created/connections
Si este valor se aproxima a "1", significa que creamos tantos threads como conexiones tenemos, por lo que habria que aumentar el tamaño de la cache de threads.
Si este valor se aprixima a "0" significa que apenas creamos threads nuevos con lo que el tamaño de cache es correcto.
3.-Key_buffer_size
Esta variable indica el tamaño del buffer donde se almacenaran los indices de las tablas MyIsam.
A mas indices cacheados mas accesos en las consultas se servirán desde RAM y menos desde disco, con al aumento de rendimiento que esto supone.
Aquí ya que aún no lo hemos ajustado no voy a profundizar mucho más simplemente comentar que.
key_read_request (indices servidos desde RAM)
key_reads (indices servidos desde disco)
Con estas dos variables podemos ver lo siguiente.
key_read_request 10000
key_reads = 100
key_read_request/key_reads=100
Por lo que estamos obteniendo una proporción de 100 a 1, es decir por cada 100 indices servidos desde RAM 1 es servido desde disco.
Esta es la relación mínima que se cita en la documentación que he encontrado aunque también hablan de valores de 1000 a 1, por lo que cuanto más alto mejor.
Bueno con los ajustes necesarios de estas variables deberíamos notar una mejora de rendimiento en nuestros servidores.
Suscribirse a:
Entradas (Atom)