Archive for the ‘Probando herramientas’ Category
Este es un mini post, para tenerlo a mano y que alguno que busque lo encuentre. Postgresql en los escenarios que la he probado, ha resultado más lenta que MySQL usando MyISAM e InnoDB. Por supuesto esto con la configuración que trae de base en una instalación Debian, Ubuntu o con el instalador (con perfiles) en Windows. O modificándole muy pocos parámetros.
Hace un tiempo ya que para un trabajo que estamos haciendo buscábamos la forma de acelerar los updates en Postgres. No es que fuera algo intolerable, pero a veces necesitabamos correr varias consultas que actualizaban unos 2M registros en base a si cumplían o no unas 40 expresiones regulares bastante complejas.
Bueno, me dirán, por qué no usaste MySQL entonces. Bueno, porque no je. En realidad porque en cuanto a extensibilidad usando los lenguajes en Postgres (plpythonu, plpgsql,plphp y quizá pljava) teníamos más flexibilidad. Tenía mejores capacidades de gestión de expresiones regulares y posibilidad de usar tipos de datos vectores (para los matching de las reg. exp.).
El post corto se está alargando y me voy a explayar en otros. Lo que intentamos fue meter commits entre medio de los updates, pero de nada servía. Incluso encerrar en una transacción varios updates. Tampoco.
Leyendo encontré que tiene que ver en la performance de PgSQL las copias que se genera de cada tabla que se está accediendo para mantener consistencia en cuanto a las consultas d ediferentes usuarios. Los checkpoints que va haciendo en el log (log de transacciones, no el log de errores) del sistema son los que estaban afectando. En definitiva aumentando el tamaño de los segmentos de los checkpoints debería haber una mejora en performance.
Este parámetro se cambia en
/etc/postgresql/8.3/main/postgresql.conf
checkpoint_segments = 256
Si hubiese mirado el log (avisos y errores) de PgSQL quizá me hubiese dado cuenta. Se la pasaba imprimiendo:
2009-02-10 11:23:09 ARST LOG: los checkpoints están ocurriendo con demasiada frecuencia (cada 2 segundos)
2009-02-10 11:23:09 ARST HINT: Considere incrementar el parámetro de configuración «checkpoint_segments».
Prometo en otro post contar los resultados y ordenar esto.
Fuentes:
http://pugs.postgresql.org/node/499
http://www.linux-es.org/node/660
Por qué: http://www.network-theory.co.uk/docs/postgresql/vol1/Increasecheckpoint_segments.html
http://archives.postgresql.org/pgsql-performance/2008-06/msg00119.php
Dreamhost, la empresa norteamericana de hosting, está ofreciendo en su etapa beta (fase 2 actualmente) su servicio Dreamhost Apps en forma gratuita. Los que se registren ahora en la beta podrán continuar el servicio sin pagar, según se explica en este post.
Pero… ¿de qué se trata este servicio?
Bien, uno puede tener un dominio propio, un .com.ar, o comprarles un .com a USD 9,90. Luego con ese dominio u otros más, puede comenzar a utilizar el servicio, previo registro de la cuenta. El servicio ofrece instalación con un sólo click varias aplicaciones web, apenas indicando cómo queremos accederlas. Por ejemplo se puede instalar Media Wiki, WordPress, Zend photo, PHPbb y Drupal hasta ahora (http://www.dreamhostapps.com/free-web-app-hosting.html). Las actualizaciones de las nuevas versiones son automáticas y se encarga la empresa.
Además se puede utilizar en forma integrada el servicio de Google Apps, que brinda Google Docs, Google Sites, GMail y Google Calendar para nuestro dominio. Una descripción de Google Apps pueden leer aquí.
La diferencia con el servicio pago que ofrece la misma empresa, es que Dreamhost Apps no provee de acceso FTP o Shell, no tenemos gestión de Cron Jobs, etc. En realidad los clientes pagos gozan de muchos beneficios y además de Dreamhos Apps (que dentro del panel se llaman One Click Installs).
Creo que todo este servicio es una buena movida, así salga unos pesos (o dólares) luego, ya que muchas personas podrán tener su sitio web completo, con varias aplicaciones por (posiblemente) poco dinero y sin conocer como gestionar una cuenta de hosting. Cuando necesiten un poco más se pueden actualizar a un hosting pago que ofrecen.
En este momento quedan unas 9000 cuentas gratuitas, saquen una los interesados y compartimos las experiencias! No hace falta tener dominio propio, ya que se puede utilizar el dominio dreamhoster.com usando subdominios para nosotros.
Link https://panel.dreamhostapps.com/signup/
Si se quieren registrar acá tienen un descuento de USD 50 para cualquier servicio pago de la empresa. Es el máximo de descuento que pueden obtener (cambio en las políticas… .
Dreamhost Promo Code: NAGRUM4CODE
Existe un plugin o complemento para Gedit (el editor por defecto en Gnome) que permite unir/dividir líneas en un texto. Esto permite que si tenemos un texto con líneas demasiado largas, podamos dividirlas en líneas de por ejemplo 80 caracteres. Este plugin me estaba siendo muy útil para manejar los textos en LATEX. Sin embargo, debía ir haciendo la separación de líneas párrafo a párrafo, ya que el plugin sino mezclaba todos los parrafos en uno sólo. Para comprender lo que les digo, inténten usarlo.
Lo que hice fue hacer un parche para el plugin para que soporte párrafos. No es que haya tenido algún error ni nada, sino que esta funcionalidad me resulta más útil. Les dejo el parche, y adjunto además, un nuevo plugin igual al Unir/Dividir líneas pero con el parche aplicado para los que no quieran parchear el original. Éste tiene las mismas combinaciones de teclas, por lo que no será compatible a la vez con el otro (le cambie apenas el nombre para que no haya conflictos). Para utilizarlo cópienlo en su $HOME/.gnome2/gedit/plugins/
El plugin si se selecciona todo (CTRL+A), y se presiona la combinación de teclas (CTRL+SHIFT+J) funcionando logra lo siguiente (espero que las imagenes expliquen más que las palabras)
(CTRL+A)
(CTRL+SHIFT+J)
El parche a aplicar sobre /usr/lib/gedit-2/plugins/joinlines.py
220c220,221
< while ord(char) and (not (char in (' ', '\t', '\n', '\r'))):
---
> twoBL = False
> while ord(char) and (not twoBL) and (not (char in (' ', '\t'))):
222a224,233
> if (char in ('\n', '\r')):
> text_iter.forward_char()
> char = text_iter.get_char()
> if (char in ('\n', '\r')):
> while (char in ('\n', '\r')):
> text_iter.forward_char()
> char = text_iter.get_char()
> else:
> text_iter.backward_char()
> twoBL = True |
220c220,221
< while ord(char) and (not (char in (' ', '\t', '\n', '\r'))):
---
> twoBL = False
> while ord(char) and (not twoBL) and (not (char in (' ', '\t'))):
222a224,233
> if (char in ('\n', '\r')):
> text_iter.forward_char()
> char = text_iter.get_char()
> if (char in ('\n', '\r')):
> while (char in ('\n', '\r')):
> text_iter.forward_char()
> char = text_iter.get_char()
> else:
> text_iter.backward_char()
> twoBL = True
Archivos del complemento modificados. Además el patch.
joinlines2.tar.gz
Actualización:
El que subí tenía un error (además que el parche era reverso). Ahora joinlines2.tar.gz apunta al script corregido. El parche anteriormente publicado se puede aplicar sobre el joinlines.py que trae Gedit. Debajo dejo un parche para corregir el error sobre mi script si ya lo están utilizando (o sea sobre joinlines2.py)
231d230
< twoBL = True
234c233
<
---
> twoBL = True |
231d230
< twoBL = True
234c233
<
---
> twoBL = True
En un post anterior, escribí acerca de un «bug» que tenía el winepreloader, el cual no permitía ejecutar aplicaciones de 16 bit o aquellas que requirieran el área de memoria ahora protegida por el kernel. Sin embargo en su release candidate 1.0 esto fue solucionado.
En este artículo donde muestro como correr Smalltalk Express con Wine, se explica como actualizar el respositorio para tener la última versión de Wine.
http://nacho.larrateguy.com.ar/2008/03/04/smalltalk-express-corriendo-con-wine-de-nuevo/
Actualización:
La solución al bug, se puede ver acá
winevdm: Move the DOS memory range check to not trigger for Win16 apps.
Que lindo encontrarse con este error, más estando con una distribución que se va a convertir seguro en la principal en mi PC de escritorio y en el portátil. Estoy hablando de Hardy Heron, la nueva distro de Ubuntu.
Aunque según estuve investigando, el error se debe a una nueva política de seguridad en el Kernel. Acá se explica el por qué del cambio. Este error o mejor dicho advertencia (warning) es visible cuando quiero ejecutar cualquier programa mediante el Wine preloader. Especificamente me comenzó a ocurrir cuando quise probar el Smalltalk Express (que documenté aquí como hacerlo correr en GNU/Linux). Para mi desgracia luego de estos warnings terminó en un error.
Para ir al grano. La aplicación es de 16 bits, por lo tanto seguramente el error es reproducible con otras. Les pego el error que obtengo:
nacho@nacho-laptop:~/programas/oSTEXPRES$ wine VW.EXE
preloader: Warning: failed to reserve range 00000000-60000000
preloader: Warning: failed to reserve range 00000000-60000000
preloader: Warning: failed to reserve range 00000000-60000000
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report
preloader: Warning: failed to reserve range 00000000-60000000
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report
preloader: Warning: failed to reserve range 00000000-60000000
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report
err:dosmem:load_winedos Could not load winedos.dll, DOS subsystem unavailable
winevdm: unable to exec '--app-name': 16-bit support missing |
nacho@nacho-laptop:~/programas/oSTEXPRES$ wine VW.EXE
preloader: Warning: failed to reserve range 00000000-60000000
preloader: Warning: failed to reserve range 00000000-60000000
preloader: Warning: failed to reserve range 00000000-60000000
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report
preloader: Warning: failed to reserve range 00000000-60000000
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report
preloader: Warning: failed to reserve range 00000000-60000000
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report
err:dosmem:load_winedos Could not load winedos.dll, DOS subsystem unavailable
winevdm: unable to exec '--app-name': 16-bit support missing
Buscando por la red encontré varios bugs anteriores que daban el mismo error. Pero fue éste y precisamente éste comentario, el que me enseñó la luz. En un artículo de Kerneltrap se puede leer que se decidió para evitar futuros ataques, proteger ese espacio de memoria. Sin embargo hay un mínimo que se puede utilizar, continuando con la protección, y que permite que se ejecuten en este caso, las aplicaciones de 16 bits con Wine sin problemas.
Hay que editar el archivo /etc/sysctl.conf y modificar la línea con el valor 4096 (0 desactiva la protección)
# protect bottom 64k of memory from mmap to prevent NULL-dereference
# attacks against potential future kernel security vulnerabilities.
# (Added in kernel 2.6.23.)
# vm.mmap_min_addr = 65536
vm.mmap_min_addr = 4096 |
# protect bottom 64k of memory from mmap to prevent NULL-dereference
# attacks against potential future kernel security vulnerabilities.
# (Added in kernel 2.6.23.)
# vm.mmap_min_addr = 65536
vm.mmap_min_addr = 4096
para que el cambio se efectúe permanentemente. Si lo queremos hacer temporal, se puede hacer con
# echo 4096 > /proc/sys/vm/mmap_min_addr
o bien
# sysctl -w vm.mmap_min_addr=4096 |
# echo 4096 > /proc/sys/vm/mmap_min_addr
o bien
# sysctl -w vm.mmap_min_addr=4096
En cuanto al proyecto Wine, están proponiendo un parche que al menos informe sobre esta incompatibilidad con el cambio en el parámetro del Kernel.