curl script

Si necesitas hacer repetidas llamadas curl via script Linux:

curl -S -w "%{url_effective}\n" -L "http://dominio.com:7080/api/pepe.php?apikey=56de&parametro1=390&parametro2=elquesea"

Componer fechas

Como componer en postgres una fecha con partes de otras fechas:

select date (
date_part('year' ,current_timestamp) || '-' ||
date_part('month',current_timestamp) || '-' ||
date_part('day' ,current_timestamp));

Redes Servidores y UDP confiable

Pregunta sobre Reliable UDP con interesantes comentarios:

http://stackoverflow.com/questions/2940106/simple-reliable-udp-c-libraries

Boost.Asio

http://www.boost.org/doc/libs/1_51_0/doc/html/boost_asio.html

Librería muy utilizada encuadrada dentro del framework Boost con múltiples utilidades. Tiene sockets asincronos, ejemplo de un servidor de chat,

UDP - UDP reliable protocol

http://udt.sourceforge.net/index.html

Se parece mucho a las funciones normales de sockets, minima barrera de entrada. Usado por Raknet y otros frameworks. El mejor protocolo para envío de mucha información en redes de amplio ancho de banda.

NOTA: en documentos de paco hay un ejemplo de implementación de EPOLL.

Estadísticas de acierto de la cache

Es muy interesante saber en nuestra base de datos cuantas veces encontramos en la caché el resultado de las consultas. Si tenemos valores altos, seguro que no accedemos al disco a buscar los resultados y por lo tanto nuestra base de datos está funcionando bien.

Vamos a ver el porcentaje de acierto a nivel de base de datos:

SELECT d.datname, pg_database_size(d.datname), SUM(pg_stat_get_db_blocks_hit(d.oid)) / SUM(pg_stat_get_db_blocks_fetched(d.oid)) AS hit_rate
FROM pg_database d
GROUP BY d.datname
HAVING SUM(pg_stat_get_db_blocks_fetched(d.oid)) > 0

Pero aún más interesante es ver el resultado a nivel de tabla:

select t.schemaname, t.relname, heap_blks_hit*100/(heap_blks_hit+heap_blks_read) as BCHR
from pg_statio_user_tables t
where t.heap_blks_read > 0

Si tus tablas más accedidas tienen valores superiores a 95% todo va bien.


Sino revisa tus valores de "shared_buffers" y "effective_cache_size", si son correctos quizá tengas que revisar tus sentencias o aumentar tu memoria.

Referencias:
http://blog.kimiensoftware.com/2011/05/postgresql-vs-oracle-differences-4-shared-memory-usage-257

Indices OnlyScan

A partir de Postgres 9.2 tenemos índices que si contienen los campos necesarios de una consulta, no acuden a la tabla a recuperar la información, sino que la recuperan directamente del índice. Para disfrutar de esta mejora tenemos que activar la consulta de este modo:
 
SET enable_indexonlyscan TO true;

Podeis ver ejemplos de uso en: 
http://michael.otacoo.com/postgresql-2/postgresql-9-2-highlight-index-only-scans/

Tened cuidado al utilizarlo para no crear índices sobre campos que se actualicen muy a menudo, ya que perderemos rendimiento durante las actualizaciones e inserciones y no compensará la ganancia sobre las consultas.

Enlaces útiles de Postgres

Analizador de logs

http://michael.otacoo.com/postgresql-2/postgres-pgbadger-sneaking-in-log-files-for-you/#comment-10881

Estadisticas Postgres

Es interesante revisar las estadísticas de acceso a cada tabla de tu base de datos:

select * from pg_stat_database;

select * from pg_stat_user_tables;

select * from pg_stat_user_indexes;

Guarda esta información, antes de hacer optimizaciones, y luego reseteala y posteriormente compara los resultados:

select * from pg_stat_reset();

Para ver cuantas conexionest tienes establecidas y que están ejecutando:

select * from pg_stat_activity;

Y los bloqueos con:

 select * from pg_locks;

Si haces uso intensivo de procedimientos almacenados, también puedes consultar su rendimiento:

select * from pg_stat_user_functions

Si no tienes estadísticas calculadas, será porque no tienes activada la recopilación de las mismas,



Referencias:
http://www.postgresql.org/docs/9.1/static/monitoring-stats.html#MONITORING-STATS-SETUP