Em 11 de fevereiro de 2016 11:44, Flavio Henrique Araque Gurgel <fha...@gmail.com> escreveu: >> 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. >
Ola Faltou no meu email, falar do ambiente que estou projetando. O ambiente é um clássico Data warehouse, com 1 carga diária noturna de INSERT/UPDATE/DELETE, e o restante do tempo será ambiente read-intensive. Mudei de ideia e não quero mais ambiente SOMENTE SSD, pretendo seguir o padrão que a maioria usa, ou seja, deixar no HDD, os segmentos: temp, log. Mas sendo um ambiente Hibrido (hdd e ssd) se eu mudar o parametro random_page_cost para 1 (leituras aleatorias = sequencial), então para os HDD o postgreSQL irá achar que o "custo" da leitura sequencial e aleatória sao iguais, o que para os HDD estara incorreto, irá acontecer isso, correto??. Esse parametro é para o banco inteiro ou da para setar por tablespace ou segmento ??? Saudações Neto > 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 > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
