Em 20 de janeiro de 2014 18:46, Euler Taveira <eu...@timbira.com.br> escreveu: > On 20-01-2014 15:58, Tiago Adami wrote: >> Colegas, acompanhando os posts anteriores do tópico "pg_restore >> extremamente lento" questiono se meus métodos de validação de >> desempenho em disco são válidos. >> >> Hoje utilizo os seguintes testes: >> >> -- Testes de gravação em server de homologação virtualizado (SUSE >> Linux 11 SP 3) - Xen Server, 4xIntel(R) Xeon(R) CPU E5-2620 0 @ >> 2.00GHz, 8 GB RAM, partições ReiserFS >> dd if=/dev/zero of=teste.dd bs=8k count=10000 oflag=direct >> 10000+0 records in >> 10000+0 records out >> 81920000 bytes (82 MB) copied, 5.44287 s, 15.1 MB/s >> > Você precisa minimizar o efeito da cache do disco, 82MB ele salva na > memória de uma máquina com 8GB. Você precisa copiar ao menos o tamanho > da memória; um tamanho razoável seria 16GB (vide [1]).
Para eu entender melhor, o argumento 'oflag=direct' - pelo menos em tese - não faria com que o buffer cache fosse ignorado? Ao remover este argumento os resultados são bem diferentes, mais rápidos. Refiz o teste alterando o tamanho do arquivo superando o total de memória RAM (dessa vez apenas no ambiente de homologação que é virtualizado, os resultados podem ser bem diferentes em um servidor bare-metal mas não tenho previsão de testar nele): -- oflag=direct dd if=/dev/zero of=teste.dd bs=8k count=1310720 oflag=direct 1310720+0 records in 1310720+0 records out 10737418240 bytes (11 GB) copied, 880.474 s, 12.2 MB/s -- sem oflag=direct dd if=/dev/zero of=teste.dd bs=8k count=1310720 1310720+0 records in 1310720+0 records out 10737418240 bytes (11 GB) copied, 253.158 s, 42.4 MB/s > ReiserFS? Você tem certeza que confia nesse sistema de arquivos? Isso é um assunto para outra thread, mas sim, em servidores SUSE 'SLES' 10/11 não houve motivo algum para não-confiar. Já ocorreu um crash na controladora de discos que desligou o servidor, e o tempo de recuperação foi muito rápido. Também usamos XFS (com /largeio/, e às vezes, /nobarrier/ - depende do hardware) mas a melhor relação desempenho/segurança atingimos com ReiserFS. Tudo indica que usaremos estes dois sistemas de arquivos até que BTRFS torne-se maduro. Usamos SUSE como distro padrão, e EXT4 não é nativamente suportado. >> Uso 'oflag=direct' [1] para ignorar o buffer de gravação do SO. Minha >> dúvida é: quais parâmetros do comando dd chegariam mais próximos a uma >> gravação do PostgreSQL? >> > O PostgreSQL utiliza blocos de 8k tanto para escrita como para leitura > (que foi exatamente o que você especificou 'bs=8k'). Para simular uma > gravação do PostgreSQL, você precisaria se basear em alguma carga pois > há tanto escritas sequenciais (WAL) quanto escritas randômicas > (datafiles). Se é para ter todo esse trabalho, é melhor utilizar um > benchmark menos artificial [2]. > > [1] http://www.postgresql.org/message-id/c164cb8c.51bd%lloner...@greenplum.com > [2] http://wiki.postgresql.org/wiki/DBT-5 Entendido. Já esto lendo a respeito do DBT-5. Compreendo que o /dd/ exibirá apenas valores nominais de gravação sequencial, porém a idéia é ter um índice para comparar com discos/storages que funcionam bem, algo para usar como referência. Agradeço pelas informações, Euler. TIAGO J. ADAMI http://www.adamiworks.com @tiadami _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
