Re: [FUG-BR] Benchmark Performance -- PostgreSQL -- FreeBSD x Linux
Boa tarde Pessoal! Utilizei Gentoo, pois pude construir todo o sistema a partir dos fontes ( pelo menos adiante do Stage 3 ), assim como fiz no FreeBSD, utilizando a march nocona, com otimizações para EM64T. No Gentoo, também pude testar o PostgreSQL com ICC ( Intel C++ Compiler ), e observei uma pequena melhora na performance. Nada expressivo! O hardware foi exatamente o mesmo em todos os testes! - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Benchmark Performance -- PostgreSQL -- FreeBSD x Linux
Modelo de benchmark válido. Após ler essa thread estive pensando em como coloca benchmarks válidos sem argumentos de contradição. A primeira nota seria sobre Hardware: Todos os hardware deveria ser de igual configuração sendo eles em lote de fabricação iguais. E que permitiria ao sistema utilizar seus recursos de performace sem interferência. Ou todos os teste executado sobre o mesmo hardware, o que daria ainda um argumento para questionamento do hardware; desgate sofrido pelos teste já executados em outros sistemas. e atravez de teste como o calculo do pi não ouver nenhuma diferença no resultado. Segunda nota Systema. Ultima versão do sistema da data do benchmark. Terceira nota, Implementador do sistema. Atravez de testes em cada sistema por tres implementadores especialista no sistema no qual irá ser testado. diferentes sobre as mesmas condições do benchmark final, o que possuir melhores resultados ser o implementará o sistema final para comparação com os demais sistemas. Quarta nota, Aplicações. A aplicação incluira todo o suporte tanto sobre velocidade como em estabilidade em sua compilação e instalação assim como configuração e baseado em ambiente real de produção. Contento considerações de segurança. Quinta e ultima nota ao meu intendimento não inerente ao benchmark. Cada pessoa tem que respeitar os resultados, e admitir a real situação do sistema atravez dos resultados obtidos. E executar o benchmark sobre o mesmo hardware em no minimo duração de uma semana e o pior resultado será o valido no final do benchmark. Esse seria os criterio creio eu para um benchmark entre sistemas. Não tenho a menor intenção de criar flames e adoraria ter novas considerações dos colegas para uma fidelidade corrente do benchmark. Obrigado a todos e me desculpe caso tenha dado algum criterio errôneo. -- Atenciosamente Paulo Henrique. To Powered By BSD Unix. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Benchmark Performance -- PostgreSQL -- FreeBSD x Linux
Em 05/04/08, Paulo Henrique[EMAIL PROTECTED] escreveu: Modelo de benchmark válido. Após ler essa thread estive pensando em como coloca benchmarks válidos sem argumentos de contradição. A primeira nota seria sobre Hardware: Todos os hardware deveria ser de igual configuração sendo eles em lote de fabricação iguais. Incorreto. Todos eles deveriam ser no mesmo hardware, inclusive no mesmo HD, e sem a questão de ter dual boot, o OS deve estar sozinho no HD, ocupando desde o início, pois de acordo com a posição no HD, o arquivo demora mais ou menos para ser acessado (uma mera questão de física). E que permitiria ao sistema utilizar seus recursos de performace sem interferência. Ou todos os teste executado sobre o mesmo hardware, o que daria ainda um argumento para questionamento do hardware; desgate sofrido pelos teste já executados em outros sistemas. Dificilmente haveria desgaste tão rápido que pudesse ser levado em consideração. e atravez de teste como o calculo do pi não ouver nenhuma diferença no resultado. Segunda nota Systema. Ultima versão do sistema da data do benchmark. ok Terceira nota, Implementador do sistema. Atravez de testes em cada sistema por tres implementadores especialista no sistema no qual irá ser testado. diferentes sobre as mesmas condições do benchmark final, o que possuir melhores resultados ser o implementará o sistema final para comparação com os demais sistemas. ok Quarta nota, Aplicações. A aplicação incluira todo o suporte tanto sobre velocidade como em estabilidade em sua compilação e instalação assim como configuração e baseado em ambiente real de produção. Contento considerações de segurança. ok. Não vale pegar e levantar todas as defesas em um, e baixar no outro para ganhar performance. Deve ser pensado que o sistema sofrerá TODO o tipo de ataque. Quinta e ultima nota ao meu intendimento não inerente ao benchmark. Cada pessoa tem que respeitar os resultados, e admitir a real situação do sistema atravez dos resultados obtidos. Agora ficou doidão. :-P Não, a pessoa pode questionar sim, pois através do questionamento pode trazer itens que não foram inclusos na configuração do sistema que modificam completamente a performance. Então, todo o benchmark é passível de questionamento, se não foss, fazíamos apenas um e usávamos apenas o sistema operacional que prestou na ocasião... E executar o benchmark sobre o mesmo hardware em no minimo duração de uma semana e o pior resultado será o valido no final do benchmark. Esse seria os criterio creio eu para um benchmark entre sistemas. Não tenho a menor intenção de criar flames e adoraria ter novas considerações dos colegas para uma fidelidade corrente do benchmark. Obrigado a todos e me desculpe caso tenha dado algum criterio errôneo. Relaxa, vc pelo menos parou para pensar nisso, eu nem tive tempo. :-P Um abc - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Benchmark Performance -- PostgreSQL -- FreeBSD x Linux
Oi, Paulo Em 05/04/08, Paulo Henrique [EMAIL PROTECTED] escreveu: Modelo de benchmark válido. Após ler essa thread estive pensando em como coloca benchmarks válidos sem argumentos de contradição. Isto parece ser virtualmente impossível. :) Em computação sempre há pontos para contestação. E sempre vai existir a questão de satisfazer gregos e troianos. Fora suas notas, acho importante ressaltar alguns pontos que podem ajudar suas análises. - A avaliação de desempenho e otimização (benchmarking) é uma área específica da ciência da computação ( www.sbc.org.br/wso/ ) e bem complexa, como você já percebeu. - É sempre importante - principalmente na ciência - determinar claramente o que se deseja medir, evitando escopos amplos e muito genéricos, a metodologia e as métricas. Os testes devem ser reproduzíveis por teceiros. Justamente por conta do escopo não amplo (p.ex: benchmarks de subsistemas como escalonador, filesystems, pilha TCP/IP, workload etc.), os testes de benchmark são facilmente contestáveis, mas isso não é necessariamente algo ruim, porque servem como ponto de partida ou parâmetro para outros testes. Algumas referências sobre testes que podem lhe interessar: http://perfsuite.sourceforge.net/ http://people.freebsd.org/~kris/scaling/mysql.html http://people.freebsd.org/~kris/scaling/7.0%20and%20beyond.pdf http://www.kernel.org/pub/linux/kernel/people/npiggin/sysbench/ http://people.freebsd.org/~kris/scaling/ebizzy.html http://bulk.fefe.de/scalability/ http://www.linux.com/feature/41347 http://www.tux.org/~mayer/linux/compare/index.html http://www.linux.com/articles/41348 http://www.intelcapabilitiesforum.net/articles/best_practices_for_benchmarking_on_windows_vista_-_update-page_all/ http://www.enterprisenetworkingplanet.com/nethub/article.php/3485486 http://www.freebsdos.com/news/2008/03/11/freebsd-performance/ Particularmente, acho que seria divertida uma competição amigável entre experts de tuning de sistemas operacionais. []'s - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Benchmark Performance -- PostgreSQL -- FreeBSD x Linux
Valeu Alex estou dando uma lida nos link que mandou alguns já conhecia. E Pablo, a questão sobre segurança é que do que adianta um sistema rápido em produção mais com consideraveis falhas de segurança? Trabalho como tecnico de informatica e vi maquina que já na segunda formatação WINDOWS ter seu desempenho questionado por, falha de hardware, a controladora de disco no caso uma Nvidia já deu problema na segunda formatação que ocorreu no mesmo dia, isso implica questionamentos. Em questão de ser o mesmo hardware é complicado pois teria muito mais variaveis para questionar do que apenas uma placa mãe. -- Atenciosamente Paulo Henrique. To Powered By BSD Unix. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Benchmark Performance -- PostgreSQL -- FreeBSD x Linux
Em 06/04/08, Paulo Henrique [EMAIL PROTECTED] escreveu: E Pablo, a questão sobre segurança é que do que adianta um sistema rápido em produção mais com consideraveis falhas de segurança? Achei que o que eu tinha escrito justamente apoiava isso, pelo visto não fui compreendido. O que coloquei é que se levantar todas as defesas em um, tem que levantar no outro também. Os ambientes devem ser o mais similares o possível, exceto nos itens onde não se tem similaridade mas pode-se ter ganho de performance, então o sistema que tem uma configuração X pode chegar a sair-se melhor no benchmark justamente por isso, e isso é vantagem que deve ser destacada no sistema. Um abc - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Benchmark Performance -- PostgreSQL -- FreeBSD x Linux
Desculpa, agora melhor analisando notei a correta interpretação. Bom em se tratando de segurança azar do sistema não se encontra preparado para mundo atual. Melhor os desenvolvedores dele rever os conceitos. Vejo que estãmos de acordo em muito itens. Obrigado. Em 07/04/08, Pablo Sánchez [EMAIL PROTECTED] escreveu: Em 06/04/08, Paulo Henrique [EMAIL PROTECTED] escreveu: E Pablo, a questão sobre segurança é que do que adianta um sistema rápido em produção mais com consideraveis falhas de segurança? Achei que o que eu tinha escrito justamente apoiava isso, pelo visto não fui compreendido. O que coloquei é que se levantar todas as defesas em um, tem que levantar no outro também. Os ambientes devem ser o mais similares o possível, exceto nos itens onde não se tem similaridade mas pode-se ter ganho de performance, então o sistema que tem uma configuração X pode chegar a sair-se melhor no benchmark justamente por isso, e isso é vantagem que deve ser destacada no sistema. Um abc - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Atenciosamente Paulo Henrique. To Powered By BSD Unix. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Benchmark Performance -- PostgreSQL -- FreeBSD x Linux
Fiz algumas mudanças no FreeBSD, na Shared Memory, e também nos Semaphores, aumentei um pouco o uso de memoria compartilhada do sistema, liberei mais memoria para o cache geral do banco, mas não teve jeito. Com Linux, ainda tive no mínimo, 20% de performance a mais com PostgreSQL. Principalmente, na escrita maciça de dados. Para inserir 1 milhão de registros em uma tabela, o FreeBSD levou 6.44mins. Linux demorou 3.35mins. 4 Mins com arquivamento dos Wal Logs :)! Sempre tive melhores resultados com FreeBSD do que com Linux, tanto que todos os meus servidores são BSD. Mas, acho que cada sistema é um sistema dentro de cada hardware. Isso acaba influênciando também! Vou pegar as configurações que modifiquei e postar para todos aqui. Vale lembrar que não sou nenhum especialista em Tunnings, nem em um sistema, nem em outro OK? Apenas alterei o que estava aos meus olhos, e coisas simples que o pessoal me enviou aqui na Lista, e que encontrei no ORÁCULO :)! Abraços a todos! - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Benchmark Performance -- PostgreSQL -- FreeBSD x Linux
Creio o o linux gentoo é excelente para determinados casos, gostaria de ver este teste realizados com fedora, cent os, debian, ubuntu.. Pq vc escolheu o gentoo ?? Em 04/04/08, Eduardo Frazão[EMAIL PROTECTED] escreveu: Fiz algumas mudanças no FreeBSD, na Shared Memory, e também nos Semaphores, aumentei um pouco o uso de memoria compartilhada do sistema, liberei mais memoria para o cache geral do banco, mas não teve jeito. Com Linux, ainda tive no mínimo, 20% de performance a mais com PostgreSQL. Principalmente, na escrita maciça de dados. Para inserir 1 milhão de registros em uma tabela, o FreeBSD levou 6.44mins. Linux demorou 3.35mins. 4 Mins com arquivamento dos Wal Logs :)! Sempre tive melhores resultados com FreeBSD do que com Linux, tanto que todos os meus servidores são BSD. Mas, acho que cada sistema é um sistema dentro de cada hardware. Isso acaba influênciando também! Vou pegar as configurações que modifiquei e postar para todos aqui. Vale lembrar que não sou nenhum especialista em Tunnings, nem em um sistema, nem em outro OK? Apenas alterei o que estava aos meus olhos, e coisas simples que o pessoal me enviou aqui na Lista, e que encontrei no ORÁCULO :)! Abraços a todos! - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Benchmark Performance -- PostgreSQL -- FreeBSD x Linux
Gostaria de saber se vc compilou dos fontes nas duas situações ou se usou binários pré-compilados. Se compilou do fonte, quais flags foram utilizadas. Se usou pré-compilados, se consegue descobrir os flags utilizados. Um benchmark tem que ser feito com os exatos mesmo parâmetros para poder ter validade. Em 04/04/08, Cristina Fernandes Silva[EMAIL PROTECTED] escreveu: Creio o o linux gentoo é excelente para determinados casos, gostaria de ver este teste realizados com fedora, cent os, debian, ubuntu.. Pq vc escolheu o gentoo ?? Em 04/04/08, Eduardo Frazão[EMAIL PROTECTED] escreveu: Fiz algumas mudanças no FreeBSD, na Shared Memory, e também nos Semaphores, aumentei um pouco o uso de memoria compartilhada do sistema, liberei mais memoria para o cache geral do banco, mas não teve jeito. Com Linux, ainda tive no mínimo, 20% de performance a mais com PostgreSQL. Principalmente, na escrita maciça de dados. Para inserir 1 milhão de registros em uma tabela, o FreeBSD levou 6.44mins. Linux demorou 3.35mins. 4 Mins com arquivamento dos Wal Logs :)! Sempre tive melhores resultados com FreeBSD do que com Linux, tanto que todos os meus servidores são BSD. Mas, acho que cada sistema é um sistema dentro de cada hardware. Isso acaba influênciando também! Vou pegar as configurações que modifiquei e postar para todos aqui. Vale lembrar que não sou nenhum especialista em Tunnings, nem em um sistema, nem em outro OK? Apenas alterei o que estava aos meus olhos, e coisas simples que o pessoal me enviou aqui na Lista, e que encontrei no ORÁCULO :)! Abraços a todos! - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Benchmark Performance -- PostgreSQL -- FreeBSD x Linux
Legal! Eu tinha visto uma apresentação sobre performance no bsd e ele ganhava de todos os SOs no postgres... quando você falou que o Gentoo estava mais rápido fiquei desanimado ;-) (sei que isso é bem relativo, depende do especialista que fez o TUNNING no SO). http://people.freebsd.org/~kris/scaling/7.0%20Preview.pdf Eu uso o postgres no bsd somente para gravar log do SNORT e acessar via BASE, mas pretendo já começar a desenvolver alguns sistemas utilizando o mesmo... no final dos seus testes, se possível posta como ficou seu kernel, sysctl, postgres.conf, etc (se possível é claro ;-) Abraço, -- Welkson Renny de Medeiros Focus Automação Comercial Desenvolvimento / Gerência de Redes [EMAIL PROTECTED] Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org - Original Message - From: Eduardo Frazão [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Tuesday, April 01, 2008 9:50 AM Subject: Re: [FUG-BR] Benchmark Performance -- PostgreSQL -- FreeBSD x Linux Pessoal, mesmo com RAID 1+0, expandindo a shared mem, otimizando o uso dela no postgresql.conf eu consigo bater a performance do Gentoo. Realmente, pelo menos nos meus testes, está dando em média 30% a mais de performance! Ainda estou testando... ( Isso na versão 8.3.1 ) Abraços! - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Benchmark Performance -- PostgreSQL -- FreeBSD x Linux
Gostei da discursão :) aproveitar e ler os links =D Em 01/04/08, Welkson Renny de Medeiros [EMAIL PROTECTED] escreveu: Legal! Eu tinha visto uma apresentação sobre performance no bsd e ele ganhava de todos os SOs no postgres... quando você falou que o Gentoo estava mais rápido fiquei desanimado ;-) (sei que isso é bem relativo, depende do especialista que fez o TUNNING no SO). http://people.freebsd.org/~kris/scaling/7.0%20Preview.pdf Eu uso o postgres no bsd somente para gravar log do SNORT e acessar via BASE, mas pretendo já começar a desenvolver alguns sistemas utilizando o mesmo... no final dos seus testes, se possível posta como ficou seu kernel, sysctl, postgres.conf, etc (se possível é claro ;-) Abraço, -- Welkson Renny de Medeiros Focus Automação Comercial Desenvolvimento / Gerência de Redes [EMAIL PROTECTED] Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org - Original Message - From: Eduardo Frazão [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Tuesday, April 01, 2008 9:50 AM Subject: Re: [FUG-BR] Benchmark Performance -- PostgreSQL -- FreeBSD x Linux Pessoal, mesmo com RAID 1+0, expandindo a shared mem, otimizando o uso dela no postgresql.conf eu consigo bater a performance do Gentoo. Realmente, pelo menos nos meus testes, está dando em média 30% a mais de performance! Ainda estou testando... ( Isso na versão 8.3.1 ) Abraços! - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Thiago Torres T2web Consultoria TI Hospedagem Web Phone: +55 (82) 3035-5734 Mobile: +55 (82) 9351-4490 http://www.t2web.com.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Benchmark Performance -- PostgreSQL -- FreeBSD x Linux
Muito obrigado por todos os links! Vou ler todos! Obrigado também pela dica do RAID 10! Vou criar um enlace deste tipo aqui e testar a escrita com ele! Quanto ao uso do Gentoo: Também adoro a distro! Limpa, leve, organizada e dinâmica, e preocupada com performance! Obrigado a todos! Em 27/03/08, mantunes [EMAIL PROTECTED] escreveu: Parabens.. Não se preocupe em gerar flames.. aqui só tem isso quando o assunto é oferta de emprego com requisito em nível superior. Foi um assunto bastante discutido aqui inclusive o Patrick tem uma teria que eu concordo. http://www.fug.com.br/historico/html/freebsd/2006-08/msg00803.html Esse link é Benchmark. http://people.freebsd.org/~kris/scaling/dfly.html e tem esse é muito bom. http://www.scribd.com/doc/551889/Introducing-Freebsd-70?query2=freebsd+7+vs+linux+benchmarking De qualquer forma.. eu vejo sempre com bons olhos o uso do gentoo. eu gosto muito..não sei pq será que todo mundo faz este tipo de teste com ele ao inves do Debian, Slack, Ubuntu. sds Em 27/03/08, Diego Augusto Dalmolin[EMAIL PROTECTED] escreveu: desculpe o link certo é esse http://developer.postgresql.org/pgdocs/postgres/kernel-resources.html 2008/3/27 Diego Augusto Dalmolin [EMAIL PROTECTED]: Eduardo Seguindo algumas recomendações da oracle, talvez possa se aplicar ao pgsql (e talvez ao seu caso) A oracle recomenda o SAME (strip and mirror everything) ou seja raid 0+1 ou 1+0 ou 10. A raid 5 é mais lenta para operações de escrita. Existe alguns parametros no freebsd pra semafoto e shmem no pgsql Vc pode ter mais informacoes em: http://www.freebsddiary.org/postgresql.php 2008/3/27 Eduardo Frazão [EMAIL PROTECTED]: Bom dia pessoal! Estamos desenvolvendo um sistema de gestão, que utilizará como SGBD, PostgreSQL. Decidi fazer alguns testes antes de escolher qual S.O. vai rodar o banco, e publicar os resultados aqui, para obter alguma ajuda, inclusive nos tunings. Utilizei o sysbench ( http://sysbench.sf.net ) para realizar os testes. Configuração do servidor: Dual Intel Xeon E5410 QuadCore 12MB Cache por CPU 1333Mhz FSB EM64T // 8GB DDR2 ECC FBD // Controladora RAID Perc6/i ( LSI Logic MegaRaid SAS ) 256MB Cache PCI-E // 4 Discos SAS Segate ST3146855SS 146GB / 15k RPM em Raid 5 // Duas Fontes de alimentação de 730W Reais. Configurações da tabela de Testes: Base com 1 Milhão de registros Randômicos Quantidade Limite de Requisições: 10 000 Compilação do SysBench em ambos os sistemas: ( -march=nocona -O3 -pipe -fomit-frame-pointer -m64 ) Versão: 0.4.8 Comando de preparação do banco de dados: # ./sysbench --max-requests=1 --test=oltp --pgsql-user=postgres --pgsql-password=XXX --pgsql-db=sysbench --db-driver=pgsql --oltp-dist-type=special --oltp-table-size=100 --oltp-read-only=off --num-threads=16 prepare Comando para realização do teste # ./sysbench --max-requests=1 --test=oltp --pgsql-user=postgres --pgsql-password=XXX --pgsql-db=sysbench --db-driver=pgsql --oltp-dist-type=special --oltp-table-size=100 --oltp-read-only=off --num-threads=16 run *** * Resultado do primeiro teste *** Sistema Operacional: FreeBSD 7.0Stable AMD64 SMP - Scheduller ULE ( Kernel: removidos apenas suporte a hardware não existentes, e adicionado a opção: options HZ=1000 ) VERSÃO do PostgreSQL: 8.3.1 - ( Flags de compilação: -march=nocona -O3 -pipe -funronll-loops ) Resultado: OLTP test statistics: queries performed: read:140070 write: 50025 other: 20010 total: 210105 transactions:10005 (781.40 per sec.) deadlocks: 0 (0.00 per sec.) read/write requests: 190095 (14846.69 per sec.) other operations:20010 (1562.81 per sec.) Test execution summary: total time: 12.8039s total number of events: 10005 total time taken by event execution: 204.6433 per-request statistics: min:0.0061s avg:0.0205s max:1.9591s approx. 95 percentile: 0.0157s Threads fairness: events (avg/stddev): 625.3125/10.93 execution time (avg/stddev): 12.7902/0.00
Re: [FUG-BR] Benchmark Performance -- PostgreSQL -- FreeBSD x Linux
Com certeza. Estou recompilando meu FreeBSD agora, e já vou tirar resultados. Fiz um teste com escrita massiça em RAID 5 ( 128 arquivos de 16MB cada ), e o mesmo teste em RAID 10 Velocidade de gravação em RAID 5 = 105mb/s Velocidade de gravação em RAID10 = 155mb/s Agora, vamos testar o BD. Muito obrigado! Abraços! Em 27/03/08, Joao Rocha Braga Filho [EMAIL PROTECTED] escreveu: 2008/3/27 Diego Augusto Dalmolin [EMAIL PROTECTED]: Eduardo Seguindo algumas recomendações da oracle, talvez possa se aplicar ao pgsql (e talvez ao seu caso) A oracle recomenda o SAME (strip and mirror everything) ou seja raid 0+1 ou 1+0 ou 10. A raid 5 é mais lenta para operações de escrita. Melhor explicando. O RAID 5 pdoe ser desastroso para pequenas escritas, como é um bando de dados. Acho que o único bando de dados que pode se beneficiar de RAID 5 é o CDB, Contant Data Base (Ver nos ports). Mas o RAID 5 pode ser muito rápido para escritas GRANDES e SEQUENCIAIS, nas quais blocos de muitos MB são escritos sequencialmente. Neste caso a controladora não precisa ficar calculando a paridade com o que está em disco. O RAID 5 SEMPRE implica em leitura antes de escrita, para pequenas escritas, para recalcular o a paridade. Digamos que vai escrever um setor, então ele e a paridade precisam ser lidos, para desfazer a paridade dele, e poder escrever a paridade correta para o novo setor do disco. Espelhamento, RAID 1, não implica em leitura antes de escrita. Pode atrasar a escrita, pois o tempo de escrita seria o tempo levado para escrever no HD que mais demorar, o mais atrasado, que pode mudar devido rotações, seek etc. Mas a escrita pode ser acelerada, pois pode ler alternadamante, e como bancos de dados e sistemas de arquivos tem que ler dados sobre posição onde está certa posição no arquivo (Sei que expliquei isto mal), então pode ser que até a escrita acabe sendo acelerada devido à aceleração das leituras necessárias pelo sistema operacional antes de fazer a escrita. Por favor, refaça os testes em RAID 1 e RAID 10, e nos apresente os resultados. João Rocha. Existe alguns parametros no freebsd pra semafoto e shmem no pgsql Vc pode ter mais informacoes em: http://www.freebsddiary.org/postgresql.php 2008/3/27 Eduardo Frazão [EMAIL PROTECTED]: Bom dia pessoal! Estamos desenvolvendo um sistema de gestão, que utilizará como SGBD, PostgreSQL. Decidi fazer alguns testes antes de escolher qual S.O. vai rodar o banco, e publicar os resultados aqui, para obter alguma ajuda, inclusive nos tunings. Utilizei o sysbench ( http://sysbench.sf.net ) para realizar os testes. Configuração do servidor: Dual Intel Xeon E5410 QuadCore 12MB Cache por CPU 1333Mhz FSB EM64T // 8GB DDR2 ECC FBD // Controladora RAID Perc6/i ( LSI Logic MegaRaid SAS ) 256MB Cache PCI-E // 4 Discos SAS Segate ST3146855SS 146GB / 15k RPM em Raid 5 // Duas Fontes de alimentação de 730W Reais. Configurações da tabela de Testes: Base com 1 Milhão de registros Randômicos Quantidade Limite de Requisições: 10 000 Compilação do SysBench em ambos os sistemas: ( -march=nocona -O3 -pipe -fomit-frame-pointer -m64 ) Versão: 0.4.8 Comando de preparação do banco de dados: # ./sysbench --max-requests=1 --test=oltp --pgsql-user=postgres --pgsql-password=XXX --pgsql-db=sysbench --db-driver=pgsql --oltp-dist-type=special --oltp-table-size=100 --oltp-read-only=off --num-threads=16 prepare Comando para realização do teste # ./sysbench --max-requests=1 --test=oltp --pgsql-user=postgres --pgsql-password=XXX --pgsql-db=sysbench --db-driver=pgsql --oltp-dist-type=special --oltp-table-size=100 --oltp-read-only=off --num-threads=16 run *** * Resultado do primeiro teste *** Sistema Operacional: FreeBSD 7.0Stable AMD64 SMP - Scheduller ULE ( Kernel: removidos apenas suporte a hardware não existentes, e adicionado a opção: options HZ=1000 ) VERSÃO do PostgreSQL: 8.3.1 - ( Flags de compilação: -march=nocona -O3 -pipe -funronll-loops ) Resultado: OLTP test statistics: queries performed: read:140070 write: 50025 other: 20010 total: 210105 transactions:10005 (781.40 per sec.) deadlocks: 0 (0.00 per sec.) read/write requests: 190095 (14846.69 per sec.) other operations:20010 (1562.81 per sec.) Test execution summary: total time: 12.8039s total number of events:
Re: [FUG-BR] Benchmark Performance -- PostgreSQL -- FreeBSD x Linux
Nesse link ele explica a diferença entre raid 0+1 e raid 1+0 http://aput.net/~jheiss/raid10/ Eduardo Frazão escreveu: Com certeza. Estou recompilando meu FreeBSD agora, e já vou tirar resultados. Fiz um teste com escrita massiça em RAID 5 ( 128 arquivos de 16MB cada ), e o mesmo teste em RAID 10 Velocidade de gravação em RAID 5 = 105mb/s Velocidade de gravação em RAID10 = 155mb/s Agora, vamos testar o BD. Muito obrigado! Abraços! - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] Benchmark Performance -- PostgreSQL -- FreeBSD x Linux
Bom dia pessoal! Estamos desenvolvendo um sistema de gestão, que utilizará como SGBD, PostgreSQL. Decidi fazer alguns testes antes de escolher qual S.O. vai rodar o banco, e publicar os resultados aqui, para obter alguma ajuda, inclusive nos tunings. Utilizei o sysbench ( http://sysbench.sf.net ) para realizar os testes. Configuração do servidor: Dual Intel Xeon E5410 QuadCore 12MB Cache por CPU 1333Mhz FSB EM64T // 8GB DDR2 ECC FBD // Controladora RAID Perc6/i ( LSI Logic MegaRaid SAS ) 256MB Cache PCI-E // 4 Discos SAS Segate ST3146855SS 146GB / 15k RPM em Raid 5 // Duas Fontes de alimentação de 730W Reais. Configurações da tabela de Testes: Base com 1 Milhão de registros Randômicos Quantidade Limite de Requisições: 10 000 Compilação do SysBench em ambos os sistemas: ( -march=nocona -O3 -pipe -fomit-frame-pointer -m64 ) Versão: 0.4.8 Comando de preparação do banco de dados: # ./sysbench --max-requests=1 --test=oltp --pgsql-user=postgres --pgsql-password=XXX --pgsql-db=sysbench --db-driver=pgsql --oltp-dist-type=special --oltp-table-size=100 --oltp-read-only=off --num-threads=16 prepare Comando para realização do teste # ./sysbench --max-requests=1 --test=oltp --pgsql-user=postgres --pgsql-password=XXX --pgsql-db=sysbench --db-driver=pgsql --oltp-dist-type=special --oltp-table-size=100 --oltp-read-only=off --num-threads=16 run *** * Resultado do primeiro teste *** Sistema Operacional: FreeBSD 7.0Stable AMD64 SMP - Scheduller ULE ( Kernel: removidos apenas suporte a hardware não existentes, e adicionado a opção: options HZ=1000 ) VERSÃO do PostgreSQL: 8.3.1 - ( Flags de compilação: -march=nocona -O3 -pipe -funronll-loops ) Resultado: OLTP test statistics: queries performed: read:140070 write: 50025 other: 20010 total: 210105 transactions:10005 (781.40 per sec.) deadlocks: 0 (0.00 per sec.) read/write requests: 190095 (14846.69 per sec.) other operations:20010 (1562.81 per sec.) Test execution summary: total time: 12.8039s total number of events: 10005 total time taken by event execution: 204.6433 per-request statistics: min:0.0061s avg:0.0205s max:1.9591s approx. 95 percentile: 0.0157s Threads fairness: events (avg/stddev): 625.3125/10.93 execution time (avg/stddev): 12.7902/0.00 * Resultado do Segundo teste Sistema Operacional: FreeBSD 7.0Stable AMD64 SMP - Scheduller ULE ( Kernel: removidos apenas suporte a hardware não existentes, e adicionado a opção: options HZ=1000 ) VERSÃO do PostgreSQL: 8.2.7 ( Flags de compilação: -march=nocona -O3 -pipe -funronll-loops ) OLTP test statistics: queries performed: read:140056 write: 50020 other: 20008 total: 210084 transactions:10004 (1040.60 per sec.) deadlocks: 0 (0.00 per sec.) read/write requests: 190076 (19771.31 per sec.) other operations:20008 (2081.19 per sec.) Test execution summary: total time: 9.6137s total number of events: 10004 total time taken by event execution: 153.6019 per-request statistics: min:0.0040s avg:0.0154s max:0.6847s approx. 95 percentile: 0.0266s Threads fairness: events (avg/stddev): 625.2500/10.92 execution time (avg/stddev): 9.6001/0.00 * * Resultado do Terceiro Teste * Sistema Operacional: Gentoo Linux 2007.0 Stage 3 AMD64 - Kernel: Gentoo Sources 2.6.23 SMP Core2/Newer Xeons (EM64T) Versão do Banco: PostgreSQL 8.3.1 ( Flags de compilação: -march=nocona -O3 -pipe -funronll-loops -m64 ) Resultado: OLTP test statistics: queries performed: read:14 write: 5 other: 2 total: 21 transactions:1 (1476.05 per sec.) deadlocks: 0 (0.00 per sec.) read/write
Re: [FUG-BR] Benchmark Performance -- PostgreSQL -- FreeBSD x Linux
Eduardo Seguindo algumas recomendações da oracle, talvez possa se aplicar ao pgsql (e talvez ao seu caso) A oracle recomenda o SAME (strip and mirror everything) ou seja raid 0+1 ou 1+0 ou 10. A raid 5 é mais lenta para operações de escrita. Existe alguns parametros no freebsd pra semafoto e shmem no pgsql Vc pode ter mais informacoes em: http://www.freebsddiary.org/postgresql.php 2008/3/27 Eduardo Frazão [EMAIL PROTECTED]: Bom dia pessoal! Estamos desenvolvendo um sistema de gestão, que utilizará como SGBD, PostgreSQL. Decidi fazer alguns testes antes de escolher qual S.O. vai rodar o banco, e publicar os resultados aqui, para obter alguma ajuda, inclusive nos tunings. Utilizei o sysbench ( http://sysbench.sf.net ) para realizar os testes. Configuração do servidor: Dual Intel Xeon E5410 QuadCore 12MB Cache por CPU 1333Mhz FSB EM64T // 8GB DDR2 ECC FBD // Controladora RAID Perc6/i ( LSI Logic MegaRaid SAS ) 256MB Cache PCI-E // 4 Discos SAS Segate ST3146855SS 146GB / 15k RPM em Raid 5 // Duas Fontes de alimentação de 730W Reais. Configurações da tabela de Testes: Base com 1 Milhão de registros Randômicos Quantidade Limite de Requisições: 10 000 Compilação do SysBench em ambos os sistemas: ( -march=nocona -O3 -pipe -fomit-frame-pointer -m64 ) Versão: 0.4.8 Comando de preparação do banco de dados: # ./sysbench --max-requests=1 --test=oltp --pgsql-user=postgres --pgsql-password=XXX --pgsql-db=sysbench --db-driver=pgsql --oltp-dist-type=special --oltp-table-size=100 --oltp-read-only=off --num-threads=16 prepare Comando para realização do teste # ./sysbench --max-requests=1 --test=oltp --pgsql-user=postgres --pgsql-password=XXX --pgsql-db=sysbench --db-driver=pgsql --oltp-dist-type=special --oltp-table-size=100 --oltp-read-only=off --num-threads=16 run *** * Resultado do primeiro teste *** Sistema Operacional: FreeBSD 7.0Stable AMD64 SMP - Scheduller ULE ( Kernel: removidos apenas suporte a hardware não existentes, e adicionado a opção: options HZ=1000 ) VERSÃO do PostgreSQL: 8.3.1 - ( Flags de compilação: -march=nocona -O3 -pipe -funronll-loops ) Resultado: OLTP test statistics: queries performed: read:140070 write: 50025 other: 20010 total: 210105 transactions:10005 (781.40 per sec.) deadlocks: 0 (0.00 per sec.) read/write requests: 190095 (14846.69 per sec.) other operations:20010 (1562.81 per sec.) Test execution summary: total time: 12.8039s total number of events: 10005 total time taken by event execution: 204.6433 per-request statistics: min:0.0061s avg:0.0205s max:1.9591s approx. 95 percentile: 0.0157s Threads fairness: events (avg/stddev): 625.3125/10.93 execution time (avg/stddev): 12.7902/0.00 * Resultado do Segundo teste Sistema Operacional: FreeBSD 7.0Stable AMD64 SMP - Scheduller ULE ( Kernel: removidos apenas suporte a hardware não existentes, e adicionado a opção: options HZ=1000 ) VERSÃO do PostgreSQL: 8.2.7 ( Flags de compilação: -march=nocona -O3 -pipe -funronll-loops ) OLTP test statistics: queries performed: read:140056 write: 50020 other: 20008 total: 210084 transactions:10004 (1040.60 per sec.) deadlocks: 0 (0.00 per sec.) read/write requests: 190076 (19771.31 per sec.) other operations:20008 (2081.19 per sec.) Test execution summary: total time: 9.6137s total number of events: 10004 total time taken by event execution: 153.6019 per-request statistics: min:0.0040s avg:0.0154s max:0.6847s approx. 95 percentile: 0.0266s Threads fairness: events (avg/stddev): 625.2500/10.92 execution time (avg/stddev): 9.6001/0.00 * * Resultado do Terceiro Teste * Sistema Operacional: Gentoo Linux 2007.0 Stage 3 AMD64 - Kernel: Gentoo Sources 2.6.23 SMP Core2/Newer Xeons (EM64T) Versão do
Re: [FUG-BR] Benchmark Performance -- PostgreSQL -- FreeBSD x Linux
desculpe o link certo é esse http://developer.postgresql.org/pgdocs/postgres/kernel-resources.html 2008/3/27 Diego Augusto Dalmolin [EMAIL PROTECTED]: Eduardo Seguindo algumas recomendações da oracle, talvez possa se aplicar ao pgsql (e talvez ao seu caso) A oracle recomenda o SAME (strip and mirror everything) ou seja raid 0+1 ou 1+0 ou 10. A raid 5 é mais lenta para operações de escrita. Existe alguns parametros no freebsd pra semafoto e shmem no pgsql Vc pode ter mais informacoes em: http://www.freebsddiary.org/postgresql.php 2008/3/27 Eduardo Frazão [EMAIL PROTECTED]: Bom dia pessoal! Estamos desenvolvendo um sistema de gestão, que utilizará como SGBD, PostgreSQL. Decidi fazer alguns testes antes de escolher qual S.O. vai rodar o banco, e publicar os resultados aqui, para obter alguma ajuda, inclusive nos tunings. Utilizei o sysbench ( http://sysbench.sf.net ) para realizar os testes. Configuração do servidor: Dual Intel Xeon E5410 QuadCore 12MB Cache por CPU 1333Mhz FSB EM64T // 8GB DDR2 ECC FBD // Controladora RAID Perc6/i ( LSI Logic MegaRaid SAS ) 256MB Cache PCI-E // 4 Discos SAS Segate ST3146855SS 146GB / 15k RPM em Raid 5 // Duas Fontes de alimentação de 730W Reais. Configurações da tabela de Testes: Base com 1 Milhão de registros Randômicos Quantidade Limite de Requisições: 10 000 Compilação do SysBench em ambos os sistemas: ( -march=nocona -O3 -pipe -fomit-frame-pointer -m64 ) Versão: 0.4.8 Comando de preparação do banco de dados: # ./sysbench --max-requests=1 --test=oltp --pgsql-user=postgres --pgsql-password=XXX --pgsql-db=sysbench --db-driver=pgsql --oltp-dist-type=special --oltp-table-size=100 --oltp-read-only=off --num-threads=16 prepare Comando para realização do teste # ./sysbench --max-requests=1 --test=oltp --pgsql-user=postgres --pgsql-password=XXX --pgsql-db=sysbench --db-driver=pgsql --oltp-dist-type=special --oltp-table-size=100 --oltp-read-only=off --num-threads=16 run *** * Resultado do primeiro teste *** Sistema Operacional: FreeBSD 7.0Stable AMD64 SMP - Scheduller ULE ( Kernel: removidos apenas suporte a hardware não existentes, e adicionado a opção: options HZ=1000 ) VERSÃO do PostgreSQL: 8.3.1 - ( Flags de compilação: -march=nocona -O3 -pipe -funronll-loops ) Resultado: OLTP test statistics: queries performed: read:140070 write: 50025 other: 20010 total: 210105 transactions:10005 (781.40 per sec.) deadlocks: 0 (0.00 per sec.) read/write requests: 190095 (14846.69 per sec.) other operations:20010 (1562.81 per sec.) Test execution summary: total time: 12.8039s total number of events: 10005 total time taken by event execution: 204.6433 per-request statistics: min:0.0061s avg:0.0205s max:1.9591s approx. 95 percentile: 0.0157s Threads fairness: events (avg/stddev): 625.3125/10.93 execution time (avg/stddev): 12.7902/0.00 * Resultado do Segundo teste Sistema Operacional: FreeBSD 7.0Stable AMD64 SMP - Scheduller ULE ( Kernel: removidos apenas suporte a hardware não existentes, e adicionado a opção: options HZ=1000 ) VERSÃO do PostgreSQL: 8.2.7 ( Flags de compilação: -march=nocona -O3 -pipe -funronll-loops ) OLTP test statistics: queries performed: read:140056 write: 50020 other: 20008 total: 210084 transactions:10004 (1040.60 per sec.) deadlocks: 0 (0.00 per sec.) read/write requests: 190076 (19771.31 per sec.) other operations:20008 (2081.19 per sec.) Test execution summary: total time: 9.6137s total number of events: 10004 total time taken by event execution: 153.6019 per-request statistics: min:0.0040s avg:0.0154s max:0.6847s approx. 95 percentile: 0.0266s Threads fairness: events (avg/stddev): 625.2500/10.92 execution time (avg/stddev):
Re: [FUG-BR] Benchmark Performance -- PostgreSQL -- FreeBSD x Linux
Parabens.. Não se preocupe em gerar flames.. aqui só tem isso quando o assunto é oferta de emprego com requisito em nível superior. Foi um assunto bastante discutido aqui inclusive o Patrick tem uma teria que eu concordo. http://www.fug.com.br/historico/html/freebsd/2006-08/msg00803.html Esse link é Benchmark. http://people.freebsd.org/~kris/scaling/dfly.html e tem esse é muito bom. http://www.scribd.com/doc/551889/Introducing-Freebsd-70?query2=freebsd+7+vs+linux+benchmarking De qualquer forma.. eu vejo sempre com bons olhos o uso do gentoo. eu gosto muito..não sei pq será que todo mundo faz este tipo de teste com ele ao inves do Debian, Slack, Ubuntu. sds Em 27/03/08, Diego Augusto Dalmolin[EMAIL PROTECTED] escreveu: desculpe o link certo é esse http://developer.postgresql.org/pgdocs/postgres/kernel-resources.html 2008/3/27 Diego Augusto Dalmolin [EMAIL PROTECTED]: Eduardo Seguindo algumas recomendações da oracle, talvez possa se aplicar ao pgsql (e talvez ao seu caso) A oracle recomenda o SAME (strip and mirror everything) ou seja raid 0+1 ou 1+0 ou 10. A raid 5 é mais lenta para operações de escrita. Existe alguns parametros no freebsd pra semafoto e shmem no pgsql Vc pode ter mais informacoes em: http://www.freebsddiary.org/postgresql.php 2008/3/27 Eduardo Frazão [EMAIL PROTECTED]: Bom dia pessoal! Estamos desenvolvendo um sistema de gestão, que utilizará como SGBD, PostgreSQL. Decidi fazer alguns testes antes de escolher qual S.O. vai rodar o banco, e publicar os resultados aqui, para obter alguma ajuda, inclusive nos tunings. Utilizei o sysbench ( http://sysbench.sf.net ) para realizar os testes. Configuração do servidor: Dual Intel Xeon E5410 QuadCore 12MB Cache por CPU 1333Mhz FSB EM64T // 8GB DDR2 ECC FBD // Controladora RAID Perc6/i ( LSI Logic MegaRaid SAS ) 256MB Cache PCI-E // 4 Discos SAS Segate ST3146855SS 146GB / 15k RPM em Raid 5 // Duas Fontes de alimentação de 730W Reais. Configurações da tabela de Testes: Base com 1 Milhão de registros Randômicos Quantidade Limite de Requisições: 10 000 Compilação do SysBench em ambos os sistemas: ( -march=nocona -O3 -pipe -fomit-frame-pointer -m64 ) Versão: 0.4.8 Comando de preparação do banco de dados: # ./sysbench --max-requests=1 --test=oltp --pgsql-user=postgres --pgsql-password=XXX --pgsql-db=sysbench --db-driver=pgsql --oltp-dist-type=special --oltp-table-size=100 --oltp-read-only=off --num-threads=16 prepare Comando para realização do teste # ./sysbench --max-requests=1 --test=oltp --pgsql-user=postgres --pgsql-password=XXX --pgsql-db=sysbench --db-driver=pgsql --oltp-dist-type=special --oltp-table-size=100 --oltp-read-only=off --num-threads=16 run *** * Resultado do primeiro teste *** Sistema Operacional: FreeBSD 7.0Stable AMD64 SMP - Scheduller ULE ( Kernel: removidos apenas suporte a hardware não existentes, e adicionado a opção: options HZ=1000 ) VERSÃO do PostgreSQL: 8.3.1 - ( Flags de compilação: -march=nocona -O3 -pipe -funronll-loops ) Resultado: OLTP test statistics: queries performed: read:140070 write: 50025 other: 20010 total: 210105 transactions:10005 (781.40 per sec.) deadlocks: 0 (0.00 per sec.) read/write requests: 190095 (14846.69 per sec.) other operations:20010 (1562.81 per sec.) Test execution summary: total time: 12.8039s total number of events: 10005 total time taken by event execution: 204.6433 per-request statistics: min:0.0061s avg:0.0205s max:1.9591s approx. 95 percentile: 0.0157s Threads fairness: events (avg/stddev): 625.3125/10.93 execution time (avg/stddev): 12.7902/0.00 * Resultado do Segundo teste Sistema Operacional: FreeBSD 7.0Stable AMD64 SMP - Scheduller ULE ( Kernel: removidos apenas suporte a hardware não existentes, e adicionado a opção: options HZ=1000 ) VERSÃO do PostgreSQL: 8.2.7 ( Flags de compilação: -march=nocona -O3 -pipe -funronll-loops ) OLTP test statistics: queries performed:
Re: [FUG-BR] Benchmark Performance -- PostgreSQL -- FreeBSD x Linux
2008/3/27 Diego Augusto Dalmolin [EMAIL PROTECTED]: Eduardo Seguindo algumas recomendações da oracle, talvez possa se aplicar ao pgsql (e talvez ao seu caso) A oracle recomenda o SAME (strip and mirror everything) ou seja raid 0+1 ou 1+0 ou 10. A raid 5 é mais lenta para operações de escrita. Melhor explicando. O RAID 5 pdoe ser desastroso para pequenas escritas, como é um bando de dados. Acho que o único bando de dados que pode se beneficiar de RAID 5 é o CDB, Contant Data Base (Ver nos ports). Mas o RAID 5 pode ser muito rápido para escritas GRANDES e SEQUENCIAIS, nas quais blocos de muitos MB são escritos sequencialmente. Neste caso a controladora não precisa ficar calculando a paridade com o que está em disco. O RAID 5 SEMPRE implica em leitura antes de escrita, para pequenas escritas, para recalcular o a paridade. Digamos que vai escrever um setor, então ele e a paridade precisam ser lidos, para desfazer a paridade dele, e poder escrever a paridade correta para o novo setor do disco. Espelhamento, RAID 1, não implica em leitura antes de escrita. Pode atrasar a escrita, pois o tempo de escrita seria o tempo levado para escrever no HD que mais demorar, o mais atrasado, que pode mudar devido rotações, seek etc. Mas a escrita pode ser acelerada, pois pode ler alternadamante, e como bancos de dados e sistemas de arquivos tem que ler dados sobre posição onde está certa posição no arquivo (Sei que expliquei isto mal), então pode ser que até a escrita acabe sendo acelerada devido à aceleração das leituras necessárias pelo sistema operacional antes de fazer a escrita. Por favor, refaça os testes em RAID 1 e RAID 10, e nos apresente os resultados. João Rocha. Existe alguns parametros no freebsd pra semafoto e shmem no pgsql Vc pode ter mais informacoes em: http://www.freebsddiary.org/postgresql.php 2008/3/27 Eduardo Frazão [EMAIL PROTECTED]: Bom dia pessoal! Estamos desenvolvendo um sistema de gestão, que utilizará como SGBD, PostgreSQL. Decidi fazer alguns testes antes de escolher qual S.O. vai rodar o banco, e publicar os resultados aqui, para obter alguma ajuda, inclusive nos tunings. Utilizei o sysbench ( http://sysbench.sf.net ) para realizar os testes. Configuração do servidor: Dual Intel Xeon E5410 QuadCore 12MB Cache por CPU 1333Mhz FSB EM64T // 8GB DDR2 ECC FBD // Controladora RAID Perc6/i ( LSI Logic MegaRaid SAS ) 256MB Cache PCI-E // 4 Discos SAS Segate ST3146855SS 146GB / 15k RPM em Raid 5 // Duas Fontes de alimentação de 730W Reais. Configurações da tabela de Testes: Base com 1 Milhão de registros Randômicos Quantidade Limite de Requisições: 10 000 Compilação do SysBench em ambos os sistemas: ( -march=nocona -O3 -pipe -fomit-frame-pointer -m64 ) Versão: 0.4.8 Comando de preparação do banco de dados: # ./sysbench --max-requests=1 --test=oltp --pgsql-user=postgres --pgsql-password=XXX --pgsql-db=sysbench --db-driver=pgsql --oltp-dist-type=special --oltp-table-size=100 --oltp-read-only=off --num-threads=16 prepare Comando para realização do teste # ./sysbench --max-requests=1 --test=oltp --pgsql-user=postgres --pgsql-password=XXX --pgsql-db=sysbench --db-driver=pgsql --oltp-dist-type=special --oltp-table-size=100 --oltp-read-only=off --num-threads=16 run *** * Resultado do primeiro teste *** Sistema Operacional: FreeBSD 7.0Stable AMD64 SMP - Scheduller ULE ( Kernel: removidos apenas suporte a hardware não existentes, e adicionado a opção: options HZ=1000 ) VERSÃO do PostgreSQL: 8.3.1 - ( Flags de compilação: -march=nocona -O3 -pipe -funronll-loops ) Resultado: OLTP test statistics: queries performed: read:140070 write: 50025 other: 20010 total: 210105 transactions:10005 (781.40 per sec.) deadlocks: 0 (0.00 per sec.) read/write requests: 190095 (14846.69 per sec.) other operations:20010 (1562.81 per sec.) Test execution summary: total time: 12.8039s total number of events: 10005 total time taken by event execution: 204.6433 per-request statistics: min:0.0061s avg:0.0205s max:1.9591s approx. 95 percentile: 0.0157s Threads fairness: events (avg/stddev): 625.3125/10.93 execution time (avg/stddev): 12.7902/0.00 * Resultado
