Performance

<< Click to Display Table of Contents >>

Navigation:  PostgreSQL > Avançado >

Performance

Previous pageReturn to chapter overviewNext page

O PostgreSQL, ao meu ver, já possui um desempenho bem interessante para um SGBD... No entanto, ele nos permite uma certa customização para ganhar desempenho. E como nem tudo é de graça, alguma coisa tem que ser perdida, e no caso, é a garantia de consistência e integridade. Desde que seu chefe não saiba, não há problemas nisso.

 

Antes de tudo, meu case consiste em ~46 milhões de registros, cada um com aproximadamente 1kb. O hardware utilizado é um Intel 2.2GHz, 8 core (2 proc quadcore), 16GB de RAM.

 

 

 

 

Sem qualquer alteração no PostgreSQL, aí vão os tempos medidos:

 

Insert : 997 registros por segundo

Select usando LIKE ‘JOAQ%’: Não tive tempo de esperar o resultado…</p>

 

 

 

 

 

O primeiro tuning é uma modificação para melhorar os tempos de insert.

 

 

 

postgres.conf

 

syncronous_commit=off

Essa customização vai desincronizar a transação do WAL (write ahead log), sendo assim, o PG não vai mais esperar a gravação do WAL em filesystem para retornar o commit. Não há risco de corromper os dados desabilitando o syncronous_commit.

 

 

 

 

 

fsync = off

Esse sim é um tuning de macho. Desabilitando o fsync, o PG não vai mais esperar a gravação do dado efetivo no disco para retornar ao cliente. Há um risco de perda de dados caso o servidor seja desligado no exato instante entre a transação e a gravação em disco. O ganho de desempenho com esse campo é mínimo, mas para quem busca o máximo de performance e pode tolerar um certo risco, vale a pena.

 

 

 

kernel.shmmax =  67108864SHMMAX é o tamanho máximo de um segmento de memória compartilhada pelo SO. Esse é tuning manjado e deve ser feito em quase todos os servidores de banco. No Ubuntu/Debian:

 

/sbin/sysctl -w kernel.shmmax=67108864

 

 

Agora vamos aos testes (lembrando que o tuning feito até agora só serve pra melhorar a inserção):

 

Insert: 3.030 registros por segundo (ganho de ~300%!)

 

 

 

 

 

O segundo tuning é voltado a melhorar a consulta usando LIKE.

 

A primeira dica é criar um tablespace só pra colocar os índices e mapeando esse tablespace em memória (memfs). Isso dá pra tirar um ganho muito bom. É claro que esse ganho torna-se realmente interessante para grande quantidade de dados, pois o Postgres já faz isso normalmente. No meu caso em particular, são 46 milhões de registros, e isso deu diferença.

 

Obviamente, se caso seu servidor cair, você terá que refazer os índices. Crie um script de startup pra isso.

 

Mapeando o Tablespace em memória

 

mount -t tmpfs /dev/shm /memfs -o size=12g

 

 

 

 

Criando o tablespace em memória (no memfs)...

 

psql database

create tablespace really_fuckin_fast on '/memfs';

 

 

 

 

Criando o índice:

 

create index idx_nome on tabela (nome varchar_pattern_ops) tablespace really_fuckin_fast ;

set enable_seqscan to off; //força o pg a não usar seqscan nesse campoO segredo aqui é o varchar_pattern_ops, o que faz com que o próprio valor do campo seja usado como chave na árvore de busca. Por default, o PG faz um hash para usar na chave da árvore.

 

 

 

Por fim... o teste:

 

SELECT * FROM tabela WHERE nome LIKE 'JOAQ%'

 

Found 103 on 46.395.911 records. Total Time :  [*20ms | 0.020s*]

 

Repare, são 46 milhões de registros... É o like mais rápido que já fiz na vida.

 

 

Observe que essa consulta só vai usar o índice se seu LIKE buscar o início da String. Se for o caso, separe seus campos em primeiro_nome, segundo_nome, ultimo_nome...

 

tags postgres 9 tuning memfs