Aqui eu falei que os SSDs são 100 vezes mais rápidos, mas somente para
leitura....
deixo aqui uma referencia, de pesquisadores da HP que fizeram um estudo,
já antigo...
http://www.cs.cmu.edu/~damon2007/pdf/graefe07fiveminrule.pdf
Já vi artigos atuais em que os SSDs atuais chegam a ser 1000 vezes mais
rápidos.... Veja na pagina 2 do artigo que o custo de leitura de um SSD
é 0,16 ms enquanto que de um HD é 12 ms, ou seja 75 vezes mais rápido.
Note que eles são 75 vezes mais rápidos em... latência. Tempo para
responder a uma requisição aleatória.
A taxa de transferência, naquela época do estudo, é até mais baixa que
os discos comuns.
necessitam de bastante escrita, quando os dados não cabem na
RAM, e se
Não há escrita em SELECT. Você está falando de temporários? Ajustar
o work_mem para a consulta é uma alternativa válida em muitos casos,
mesmo quando se tem SSD, que em alguns casos é péssimo em escrita.
Estou falando de escrita, que são utilizadas na Junção para armazenar
resultados intermediários..
Sim, você está falando dos arquivos temporários do PostgreSQL.
Como os SSD tem performance ruim em escrita, acredito que vou tentar
implementar um ambiente hibrido, deixando os HDD para os arquivos
write-intensive (temp, logs) assim deixaria SSD somente para tabelas que
tenham bastante leitura... vale explicar para quem não tenha experiencia
com SSDs que a escrita não tem boa performance, devido a não
A escrita depende muito do tipo de SSD e de controladora.
Logo, o melhor seria você testar a capacidade dos discos que você tem em
mãos, antes de fazer suposições.
Já tive a oportunidade de testar matrizes de SSD que só faltanvam servir
o cafezinho. Pelo preço que ela custava deveria mesmo era me servir um
Whiskey.
possibilidade de sobrescrever ou atualizar dados. Ao invés disso, é
realizado o processo conhecido como /erase-before-write/onde um bloco
inteiro deve ser apagado e depois os novos dados podem ser escritos nas
páginas do bloco, isso significa que todas as outras páginas do bloco
(que nao precisariam ser alteradas), precisam ser lidas e, em seguida,
escritas novamente. Em um SSD um dado só pode ser escrito em um bloco
vazio, por isso o processo de erase-before-write.
Controladoras modernas tem algoritmo automático de wear levelling.
Normalmente isso não é preocupação do usuário.
Alguem teria uma sugestão de quais seguimentos de arquivos deixaria no
SSDs e quais nos HDs ?
Se sua controladora tem taxa ruim de escrita, deixe fora dos SSDs :
1) O diretório de logs do PostgreSQL (configurável no postgresql.conf)
2) O diretório pg_xlog (praticamente só escrita, sequencial e intensa)
3) O diretório pg_stats_tmp (coloque este em RAM mesmo, ele não precisa
de persistência).
Tudo também vai depender da carga do seu banco de dados, o que ele faz.
Em alguns casos, criar uma tablespace dentro do SSD e jogar lá só
algumas tabelas ou índices já é a melhor opção.
Veja bem, estou respondendo suas perguntas baseado no fim do filme, não
na história toda. Infelizmente, muita gente faz otimização assim, compra
o Hardware e depois estuda como enfiar o sistema lá dentro.
Eu, particularmente, prefiro fazer ao contrário.
[]s
Flavio Gurgel
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
