Corriendo tests con instancia de PostgreSql en ram

Otra manera de optimizar la ejecución de tests de Django, pero SIN modificar la instalación de PostgreSql del sistema operativo es crear una nueva instancia, corriendo totalmente en ram.

Para crear una nueva instancia usamos initdb:

$ /usr/lib/postgresql/9.1/bin/initdb \
    --pgdata=/dev/shm/pgtesting \
    -U horacio

Y para lanzar la instancia en segundo plano:


$ /usr/lib/postgresql/9.1/bin/postgres \
    -F -i -p 5444 -S $((1024*64)) \
    -D /dev/shm/pgtesting \
    --unix_socket_directory=/dev/shm/pgtesting \
    -r /dev/shm/pgtesting/postgresql.log &


Luego creamos el usuario y BD para la aplicación Django:

psql -h 127.0.0.1 \
    -c "create user vindler with password 'x' superuser" postgres
psql -h 127.0.0.1 \
    -c "create database vindler owner vindler" postgres


Mejora en tiempos de ejecución de test: 28%

La ejecución de los tests con PostgreSql en disco, con las optimizaciones de mi artículo anterior tardan alrededor de 7 segundos:


Ran 18 tests in 7.071s
5.44user 0.58system 0:10.40elapsed 57%CPU (0avgtext+0avgdata 122880maxresident)k
0inputs+1184outputs (0major+16964minor)pagefaults 0swaps


Ran 18 tests in 6.843s
5.28user 0.65system 0:10.27elapsed 57%CPU (0avgtext+0avgdata 122976maxresident)k
0inputs+1176outputs (0major+16956minor)pagefaults 0swaps


Ran 18 tests in 7.032s
5.42user 0.64system 0:10.42elapsed 58%CPU (0avgtext+0avgdata 124304maxresident)k
0inputs+1168outputs (0major+17122minor)pagefaults 0swaps

Los mismos tests ejecutandose en la nueva instancia de PostgreSql totalmente en ram, tardan alrededor de 5 segundos:


Ran 18 tests in 5.220s
4.41user 0.65system 0:08.38elapsed 60%CPU (0avgtext+0avgdata 117904maxresident)k
8inputs+1176outputs (0major+16524minor)pagefaults 0swaps


Ran 18 tests in 5.047s
4.32user 0.53system 0:08.04elapsed 60%CPU (0avgtext+0avgdata 117888maxresident)k
0inputs+1168outputs (0major+16504minor)pagefaults 0swaps


Ran 18 tests in 4.665s
3.95user 0.64system 0:07.79elapsed 58%CPU (0avgtext+0avgdata 117856maxresident)k
0inputs+1176outputs (0major+16502minor)pagefaults 0swaps

Al ejecutar los tests de stress: 33%

Con PostgreSql en disco:


Ran 1 test in 24.601s
15.21user 2.72system 0:27.98elapsed 64%CPU (0avgtext+0avgdata 130944maxresident)k
0inputs+9616outputs (0major+18298minor)pagefaults 0swaps


Ran 1 test in 24.458s
15.16user 2.51system 0:27.57elapsed 64%CPU (0avgtext+0avgdata 131488maxresident)k
472inputs+9608outputs (0major+18457minor)pagefaults 0swaps


Ran 1 test in 24.552s
15.23user 2.63system 0:27.95elapsed 63%CPU (0avgtext+0avgdata 131088maxresident)k
232inputs+9616outputs (0major+18310minor)pagefaults 0swaps

Con PostgreSql en ram:

Ran 1 test in 16.082s

11.30user 2.46system 0:19.22elapsed 71%CPU (0avgtext+0avgdata 126080maxresident)k

0inputs+9616outputs (0major+17675minor)pagefaults 0swaps

Ran 1 test in 15.736s

11.25user 2.20system 0:18.82elapsed 71%CPU (0avgtext+0avgdata 126192maxresident)k

0inputs+9608outputs (0major+17684minor)pagefaults 0swaps

Ran 1 test in 15.408s

10.78user 2.27system 0:18.44elapsed 70%CPU (0avgtext+0avgdata 126384maxresident)k

0inputs+9608outputs (0major+17693minor)pagefaults 0swaps

Listar BD y tablas con sus respectivos tamaños

Para listar las bases de datos con el tamaño ocupado en disco de cada una:

• SELECT pg_database.datname, pg_size_pretty(pg_database_size(pg_database.datname)) AS size FROM pg_database ORDER BY pg_database_size(pg_database.datname);

Para listar las tablas con el tamaño ocupado en disco de cada una, pero solo del schema 'public' (probado en PostgreSql 8.1):

• SELECT tablename, pg_size_pretty(pg_total_relation_size(tablename)) FROM pg_tables WHERE schemaname = 'public'  ORDER BY pg_total_relation_size(tablename);

Para que la última consulta funcione en Postgre 8:4, hay que utilizar casting:

• SELECT tablename, pg_size_pretty(pg_total_relation_size(tablename::TEXT)) FROM pg_tables WHERE schemaname = 'public' ORDER BY pg_total_relation_size(tablename::TEXT);

Esto lo probé en 8.1 y 8.4 (únicas versiones que tengo a mano).

pg_dump y "canceling statement due to statement timeout"

Al realizar backups de tablas grandes, pueden producirse "statement timeout":

pg_dump: SQL command failed
pg_dump: Error message from server: ERROR:  canceling statement due to statement timeout

Si esto sucede porque tenemos configurado "statement_timeout" a nivel general, esta configuración también está afectando las sentencias ejecutadas por pg_dump (esto sucede al menos con PostgreSql 8.1). Este se soluciona seteando la siguiente variable de entorno:

~# export PGOPTIONS="-c statement_timeout=0"
~# pg_dump test_db

También podemos hacerlo en 1 línea

~# PGOPTIONS="-c statement_timeout=0" pg_dump test_db

o también:

~# env PGOPTIONS="-c statement_timeout=0" pg_dump test_db

Tomado de: http://www.mail-archive.com/pgsql-general@postgresql.org/msg79518.html

Django + tsearch2

Encontré 2 artículos explicando cómo usar tsearch2 de PostgreSql desde Django, para realizar búsquedas de texto de forma eficaz.
- http://www.rossp.org/blog/2009/jan/28/django-postgresql-fulltext/
- http://barryp.org/blog/entries/postgresql-full-text-search-django/

Como backupear usuarios y grupos de PostgreSql

Respuesta:

pg_dumpall --globals-only

(también backupea tablespaces)

Artículo original y respuestas más largas: Backing up Login Roles aka Users and Group Roles

Tuning Your PostgreSQL Server

Encontré un artículo con buenas referencias, con información para afinar la configuración de PostgreSql.

http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server

Cheat sheet de PostgreSql

Encontré 2 páginas con "cheat sheets" de PostgreSql (no sé cuál sería la traducción de "cheat sheets", quizá "machetes", pero para lo que no saben: son resúmenes sobre lenguajes, programas, etc. con información normalmente usada de referencia cuando no nos acordamos cómo especificar ciertas cosas).
Estas "cheat sheets" las bajé de aqui y aqui.

Tamaño de tablas/BD en PostgreSql

PostgreSql posee algunas funciones muy útiles para determinar el tamaño en disco que ocupa una tabla o una base de datos. Estas son:

• pg_relation_size
• pg_total_relation_size
• pg_database_size

Para visualizar mas facilmente el resultado de las funciones anteriores, de puede utilizar pg_size_pretty. Por ejemplo:

intranet=# select pg_size_pretty(pg_total_relation_size('requerimiento'));
pg_size_pretty
----------------
23 MB
(1 row)


Estas y otras funciones están documentadas en el sitio de PostgreSql.