Re: [pgbr-geral] Desempenho no Linux
2009/11/29 Leonardo Cezar lhce...@gmail.com: 2009/11/29 Dickson S. Guedes lis...@guedesoft.net: 2009/11/29 renato centrisco...@gmail.com: A princípio hardware não é problema, tens máquina de sobra. Que tal por o PostgreSQL em uma máquina virtual com Linux ou FreeBSD? O uso de banco de dados para ambientes críticos em uma máquina virtualizada é muito controverso. Para alguns casos pode ser uma solução interessante, como em ambientes de teste ou homologação onde o quesito desempenho não faz parte do escopo. Taí um assunto interessante ... Paravirtualização é uma tendência, portanto entender, aprender a customizar e otimizar o comportamento do VMM é o novo desafio para o DBA dentro desta tendência. Seria interessante termos alguns benchmarks para ver o quanto custa este almoço. Alguém conhece alguns? []s Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desempenho no Linux
A princípio hardware não é problema, tens máquina de sobra. Que tal por o PostgreSQL em uma máquina virtual com Linux ou FreeBSD? Renato ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desempenho no Linux
2009/11/29 renato centrisco...@gmail.com: A princípio hardware não é problema, tens máquina de sobra. Que tal por o PostgreSQL em uma máquina virtual com Linux ou FreeBSD? O uso de banco de dados para ambientes críticos em uma máquina virtualizada é muito controverso. Para alguns casos pode ser uma solução interessante, como em ambientes de teste ou homologação onde o quesito desempenho não faz parte do escopo. Por outro lado, o uso de uma maquina virtual cria um overhead cujo custo pode ser muito alto para a aplicação corrente, tornando inviável o seu uso. É importante salientar também que o sistema operacional por trás da máquina virtual continuaria sendo o Windows, o que pode ser um dos gargalos nesta história. Desconheçendo a realidade da aplicação que o Tiago está trabalhando não temos como inferir qual o melhor caminho, o que podemos sugerir é que sejam feitos testes de comparação de desempenho entre sistemas operacionais, tuning no banco *e* na aplicação, como também a geração de estatisticas de uso do banco com algumas ferramentas específicas, como já citado neste mesmo tópico em e-mails anteriores. []s Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desempenho no Linux
2009/11/29 Dickson S. Guedes lis...@guedesoft.net: 2009/11/29 renato centrisco...@gmail.com: A princípio hardware não é problema, tens máquina de sobra. Que tal por o PostgreSQL em uma máquina virtual com Linux ou FreeBSD? O uso de banco de dados para ambientes críticos em uma máquina virtualizada é muito controverso. Para alguns casos pode ser uma solução interessante, como em ambientes de teste ou homologação onde o quesito desempenho não faz parte do escopo. Taí um assunto interessante ... Paravirtualização é uma tendência, portanto entender, aprender a customizar e otimizar o comportamento do VMM é o novo desafio para o DBA dentro desta tendência. -Leo -- Leonardo Cezar http://www.aslid.org.br http://postgreslogia.wordpress.com http://www.dextra.com.br/postgres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desempenho no Linux
(corte das mensagens anteriores) Consegui ler os últimos posts somente agora. Surgiram diversas dicas interessantes, vou avaliar todas com a devida atenção. Já estamos aguardando uma máquina nova para realizar os testes de desempenho com o nosso ERP (primeiro com Windows e depois com Linux), enquanto isso revisamos algumas rotinas SQL ineficientes. No momento não conseguirei responder a todas as perguntas, mas assim que realizar os testes vou postar aqui os resultados. Agradeço a atenção de todos. Obrigado. -- TIAGO J. ADAMI http://www.adamiworks.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desempenho no Linux
Le dimanche 29 novembre 2009 à 13:47 -0200, Leonardo Cezar a écrit : Paravirtualização é uma tendência, portanto entender, aprender a customizar e otimizar o comportamento do VMM é o novo desafio para o DBA dentro desta tendência. ¿Mais uma tendência para matar o desempenho? Que eu soubesse, virtualização em x86 mata o desempenho justo no que é crítico para dados, E/S de disco de armazenamento em massa. Como nunca soube exatamente por quê, não sei se o problema foi corrigido com as extensões VT-x. Que eu saiba, não existe problema semelhante em RISC e /mainframes/. Mas adoraria descobrir que estou errado… -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 9406 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 3854 7191 ICQ: aim:GoIM?screenname=61287803 +55 (11) 5546 8716msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desempenho no Linux
2009/11/29 Leandro Guimarães Faria Corcete DUTRA leandro.gfc.du...@gmail.com: Le dimanche 29 novembre 2009 à 13:47 -0200, Leonardo Cezar a écrit : Paravirtualização é uma tendência, portanto entender, aprender a customizar e otimizar o comportamento do VMM é o novo desafio para o DBA dentro desta tendência. ¿Mais uma tendência para matar o desempenho? Infelizmente sim. Redução do desempenho de E/S é o preço que se paga para adquirir isolamento, consolidação de ambientes, alta disponibilidade de serviços (sim, controverso), manutenibilidade, recuperação e utilização de hardware legado. Estas características são pontos fundamentais (*críticos*) do ponto de vista da *gestão* de TIC. Que eu soubesse, virtualização em x86 mata o desempenho justo no que é crítico para dados, E/S de disco de armazenamento em massa. Eu imaginava que tal lentidão se relacionava com requisições a CPU que demandam um pouco mais de ciclos na arquitetura CISC do que na RISC. Como nunca soube exatamente por quê, não sei se o problema foi corrigido com as extensões VT-x. Em processadores que suportam IOMMU (AMD-v ou Intel Direct-I/O VT-d) a tradução do acesso a alguns dispositivos é feita de forma direta, sem precisar que o hypervisor realize o mapeamento virtual da memória, por isto, a performance de E/S é, em alguns casos, 30-60% maior para dispositivos que utilizam SMA. Que eu saiba, não existe problema semelhante em RISC e /mainframes/. AFAIK processadores mais atuais utilizam arquiteturas híbridas. Mas adoraria descobrir que estou errado… Até onde eu sei, não está ... Abraço! -Leo -- Leonardo Cezar http://www.aslid.org.br http://postgreslogia.wordpress.com http://www.dextra.com.br/postgres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desempenho no Linux
Opa, 2009/11/27 mateusgra mateus...@bol.com.br De acordo com o Sr. Josh Berkus. http://archives.postgresql.org/pgsql-hackers/2008-08/msg00841.php Veja que tem exemplos para small server,web application database,data warehousing database Acho que o pgtune usa esses dados. Não minha concepção não existe uma receita de bolo para questão de tuning. Por exemplo, o pgtune fornece uma base de valores para alguns parâmetros, porém isso não indica que eles não necessitam um ajuste fino. O pgtune é uma ferramenta para auxiliar sim a questão de configuração dos parâmetro, mas não é possível se basear apenas nos parâmetros fornecidos. Acredito que sempre antes de qualquer ajuste de performance é necessário o conhecimento da aplicação, pois se existe uma consulta ou um conjunto de consultas que necessita ordenação e agrupamento pode ser que o valor de work_mem sugerido sofra alterações e por ai vai. Acredito que os valores apresentados são uma base inicial, mas não eles sejam definitivos e que não necessitem algum ajuste depois. JotaComm wrote: Olá, 2009/11/27 mateusgra mateus...@bol.com.br Como esta os parametros dos postgresql.conf shared_buffers work_mem maintenance_work_mem wal_buffers effective_cache_size checkpoint_segments max_fsm_pages default_statistics_target Tamanho da base sem compactação : select pg_size_pretty(sum(pg_database_size(d.oid))::bigint) from pg_database d; Exemplo: Se sua base tem 50GB com 200 usuarios shared_buffers = 1GB work_mem = 4MB maintenance_work_mem = 500MB wal_buffers = 1MB effective_cache_size = 1200MB checkpoint_segments = 16 max_fsm_pages = 80 default_statistics_target = 30 Como assim? Você sugere uma configuração assim para uma base de 50GB? Baseado em quais requisitos você sugere esta configuração? Tiago J. Adami wrote: Olá pessoal. Antes de começar, quero dizer que não sou xiita e tampouco quero transformar este post em uma discussão sobre qual SO é melhor por um ou outro motivo. Quero que o foco seja restrito apenas ao uso do PostgreSQL. Temos um cliente com uma base de dados onde o arquivo de backup no formato compactado com -F c -Z 9 tem próximo de 400 MB. Eu sei que para o padrão de vocês é pouco, mas para nossa aplicação já é um tamanho grande. O servidor do cliente é Windows 2008 64 bits, rodando em um servidor Dell com Intel Xeon 3 Ghz de 4 núcleos e 4 GB de RAM e um disco SCSI (sem RAID). Neste servidor havia reclamações de lentidão. Acontecia em um determinado horário (das 16:00hs em diante), e nada de anormal aparecia no status do servidor (observado pelo pgAdmin). Existiam apenas transações abertas desde às 08:00 hs da manhã no modo In Transaction ou Idle. Mas de uns dias para cá, a lentidão passou a ser incessante, mesmo sem atualizações do aplicativo, e não há backup/restore ou vacuum que resolva. A versão atual rodando é a 8.2.13. Primeiro, sugerimos a atualização para a versão 8.3.8 (homologada para o nosso ERP, a 8.4.1 nem está em testes ainda). Mas sinceramente, este é o primeiro passo apenas... Se não der muita diferença, vamos sugerir a atualização para o Linux... eu confio neste SO, trabalho com a instalação e configuração de servidores Linux a muito tempo, não sou um expert mas me viro. Acontece que agora, eu preciso de justificativas plausíveis, informações que possam convencer o cliente de que realmente o PostgreSQL foi feito para Linux, roda melhor no Linux e é mais rápido nele. A questão é mais ou menos como uma elaboração de monografia de graduação. Eu sei que no Linux é mais rápido, mas quem disse isso? Quais as fontes eu poderia citar? E antes que perguntem: - A aplicação não foi atualizada, portanto não foi nenhuma alteração que causou a lentidão; - O servidor é dedicado (apesar disso ser essencialmente impossível no Windows com todos os serviços que ele roda + o ambiente gráfico); - Já verifiquei processos como Vacuum e Backup. Não rodam enquanto está lento, somente pela madrugada; - Existe sim um software antivírus no servidor, um tal de Eset. Mas mesmo com ele desabilitado, a lentidão continua; A minha pergunta essencial é: quais as diferenças da versão do PostgreSQL para Linux e para Windows no que diz respeito à segurança, integridade e desempenho? -- TIAGO J. ADAMI http://www.adamiworks.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- View this message in context: http://old.nabble.com/Desempenho-no-Linux-tp26523053p26543306.html Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br
Re: [pgbr-geral] Desempenho no Linux
2009/11/26 JotaComm jota.c...@gmail.com Olá, pessoal To chegando atrasado para a discussão mas eu queria participar. Também estou chegando atrasado mas vou dar meu singelo pitaco... Um problema até que comum que gera um grande atraso é a rede. Já foi verificada? - Se a latência estiver maior que deveria, o atraso é inevitável e não será culpa do server nem do postgresql. - Há perda de pacotes? Placas de rede com problema ou cabeamento podem gerar perda de pacotes, o que não é sentido pelo servidor, mas sim pelo cliente da rede, pois acabam ocorrendo muita retransmissão de pacotes. Imagine que 20% dos pacotes sejam perdidos, qual o custo disto no tempo de execução de uma tarefa... Como as conexões são físicas, então sofrem ação de intempéries e fatores externos - porta de switch defeituosas - cabeamento precisando de reparo (conector quebrado, oxidado) - cabeamento com vias partidas - cabeamento sofrendo interferência elétrica Desconfiei disto quando você comenta sobre Acontecia em um determinado horário (das 16:00hs em diante), e nada de anormal aparecia no status do servidor , verifique se há algum equipamento que comumente era acionado neste período. Já aconteceu comigo que havia uma máquina de xerox de um departamento na faculdade que funcionava a noite e quando ligavar causava interferência elétrica na rede, visto que o cabo de rede corria junto com o da energia no setor. E isso é muito comum nas empresas que fazem cabeamento por conta própria ou contratam entendidos ou o sobrinho que faz o curso técnico. Depois de um certo tempo com interferência, pode provocar pane na porta do switch e seus problemas se agravarm. Então verifique isto (um simples ping de um cliente já avalia). PS: Tem muito cliente que não entende e não quer gastar com canaletas em separado para o cabeamento de rede. Infelizmente eles só aprendem depois que as coisas começam a funcionar mal, e começarem a substituir equipamentos. PS: Historinha venérea ;-), só pra não perder a viagem. Todo o dia um equipamento em teste desligava entre 19:01 e 19:03, horário que não havia mais ninguém no setor. Várias hipósteses foram verificadas e quase uma semana de trabalho foi perdida, até que um membro da equipe resolveu esperar até o horário que ocorria. Descoberto o poblema: às 19hs a faxineira batia o ponto e esta era a primeira sala que ela entrava. Então tirava um cabo da tomada (o do equipamento) e colocava seu aspirador de pó... -- Rudinei Dias ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desempenho no Linux
Como esta os parametros dos postgresql.conf shared_buffers work_mem maintenance_work_mem wal_buffers effective_cache_size checkpoint_segments max_fsm_pages default_statistics_target Tamanho da base sem compactação : select pg_size_pretty(sum(pg_database_size(d.oid))::bigint) from pg_database d; Exemplo: Se sua base tem 50GB com 200 usuarios shared_buffers = 1GB work_mem = 4MB maintenance_work_mem = 500MB wal_buffers = 1MB effective_cache_size = 1200MB checkpoint_segments = 16 max_fsm_pages = 80 default_statistics_target = 30 Tiago J. Adami wrote: Olá pessoal. Antes de começar, quero dizer que não sou xiita e tampouco quero transformar este post em uma discussão sobre qual SO é melhor por um ou outro motivo. Quero que o foco seja restrito apenas ao uso do PostgreSQL. Temos um cliente com uma base de dados onde o arquivo de backup no formato compactado com -F c -Z 9 tem próximo de 400 MB. Eu sei que para o padrão de vocês é pouco, mas para nossa aplicação já é um tamanho grande. O servidor do cliente é Windows 2008 64 bits, rodando em um servidor Dell com Intel Xeon 3 Ghz de 4 núcleos e 4 GB de RAM e um disco SCSI (sem RAID). Neste servidor havia reclamações de lentidão. Acontecia em um determinado horário (das 16:00hs em diante), e nada de anormal aparecia no status do servidor (observado pelo pgAdmin). Existiam apenas transações abertas desde às 08:00 hs da manhã no modo In Transaction ou Idle. Mas de uns dias para cá, a lentidão passou a ser incessante, mesmo sem atualizações do aplicativo, e não há backup/restore ou vacuum que resolva. A versão atual rodando é a 8.2.13. Primeiro, sugerimos a atualização para a versão 8.3.8 (homologada para o nosso ERP, a 8.4.1 nem está em testes ainda). Mas sinceramente, este é o primeiro passo apenas... Se não der muita diferença, vamos sugerir a atualização para o Linux... eu confio neste SO, trabalho com a instalação e configuração de servidores Linux a muito tempo, não sou um expert mas me viro. Acontece que agora, eu preciso de justificativas plausíveis, informações que possam convencer o cliente de que realmente o PostgreSQL foi feito para Linux, roda melhor no Linux e é mais rápido nele. A questão é mais ou menos como uma elaboração de monografia de graduação. Eu sei que no Linux é mais rápido, mas quem disse isso? Quais as fontes eu poderia citar? E antes que perguntem: - A aplicação não foi atualizada, portanto não foi nenhuma alteração que causou a lentidão; - O servidor é dedicado (apesar disso ser essencialmente impossível no Windows com todos os serviços que ele roda + o ambiente gráfico); - Já verifiquei processos como Vacuum e Backup. Não rodam enquanto está lento, somente pela madrugada; - Existe sim um software antivírus no servidor, um tal de Eset. Mas mesmo com ele desabilitado, a lentidão continua; A minha pergunta essencial é: quais as diferenças da versão do PostgreSQL para Linux e para Windows no que diz respeito à segurança, integridade e desempenho? -- TIAGO J. ADAMI http://www.adamiworks.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- View this message in context: http://old.nabble.com/Desempenho-no-Linux-tp26523053p26543306.html Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desempenho no Linux
Olá, 2009/11/27 mateusgra mateus...@bol.com.br Como esta os parametros dos postgresql.conf shared_buffers work_mem maintenance_work_mem wal_buffers effective_cache_size checkpoint_segments max_fsm_pages default_statistics_target Tamanho da base sem compactação : select pg_size_pretty(sum(pg_database_size(d.oid))::bigint) from pg_database d; Exemplo: Se sua base tem 50GB com 200 usuarios shared_buffers = 1GB work_mem = 4MB maintenance_work_mem = 500MB wal_buffers = 1MB effective_cache_size = 1200MB checkpoint_segments = 16 max_fsm_pages = 80 default_statistics_target = 30 Como assim? Você sugere uma configuração assim para uma base de 50GB? Baseado em quais requisitos você sugere esta configuração? Tiago J. Adami wrote: Olá pessoal. Antes de começar, quero dizer que não sou xiita e tampouco quero transformar este post em uma discussão sobre qual SO é melhor por um ou outro motivo. Quero que o foco seja restrito apenas ao uso do PostgreSQL. Temos um cliente com uma base de dados onde o arquivo de backup no formato compactado com -F c -Z 9 tem próximo de 400 MB. Eu sei que para o padrão de vocês é pouco, mas para nossa aplicação já é um tamanho grande. O servidor do cliente é Windows 2008 64 bits, rodando em um servidor Dell com Intel Xeon 3 Ghz de 4 núcleos e 4 GB de RAM e um disco SCSI (sem RAID). Neste servidor havia reclamações de lentidão. Acontecia em um determinado horário (das 16:00hs em diante), e nada de anormal aparecia no status do servidor (observado pelo pgAdmin). Existiam apenas transações abertas desde às 08:00 hs da manhã no modo In Transaction ou Idle. Mas de uns dias para cá, a lentidão passou a ser incessante, mesmo sem atualizações do aplicativo, e não há backup/restore ou vacuum que resolva. A versão atual rodando é a 8.2.13. Primeiro, sugerimos a atualização para a versão 8.3.8 (homologada para o nosso ERP, a 8.4.1 nem está em testes ainda). Mas sinceramente, este é o primeiro passo apenas... Se não der muita diferença, vamos sugerir a atualização para o Linux... eu confio neste SO, trabalho com a instalação e configuração de servidores Linux a muito tempo, não sou um expert mas me viro. Acontece que agora, eu preciso de justificativas plausíveis, informações que possam convencer o cliente de que realmente o PostgreSQL foi feito para Linux, roda melhor no Linux e é mais rápido nele. A questão é mais ou menos como uma elaboração de monografia de graduação. Eu sei que no Linux é mais rápido, mas quem disse isso? Quais as fontes eu poderia citar? E antes que perguntem: - A aplicação não foi atualizada, portanto não foi nenhuma alteração que causou a lentidão; - O servidor é dedicado (apesar disso ser essencialmente impossível no Windows com todos os serviços que ele roda + o ambiente gráfico); - Já verifiquei processos como Vacuum e Backup. Não rodam enquanto está lento, somente pela madrugada; - Existe sim um software antivírus no servidor, um tal de Eset. Mas mesmo com ele desabilitado, a lentidão continua; A minha pergunta essencial é: quais as diferenças da versão do PostgreSQL para Linux e para Windows no que diz respeito à segurança, integridade e desempenho? -- TIAGO J. ADAMI http://www.adamiworks.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- View this message in context: http://old.nabble.com/Desempenho-no-Linux-tp26523053p26543306.html Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral []s -- JotaComm http://jotacomm.wordpress.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desempenho no Linux
De acordo com o Sr. Josh Berkus. http://archives.postgresql.org/pgsql-hackers/2008-08/msg00841.php Veja que tem exemplos para small server,web application database,data warehousing database Acho que o pgtune usa esses dados. JotaComm wrote: Olá, 2009/11/27 mateusgra mateus...@bol.com.br Como esta os parametros dos postgresql.conf shared_buffers work_mem maintenance_work_mem wal_buffers effective_cache_size checkpoint_segments max_fsm_pages default_statistics_target Tamanho da base sem compactação : select pg_size_pretty(sum(pg_database_size(d.oid))::bigint) from pg_database d; Exemplo: Se sua base tem 50GB com 200 usuarios shared_buffers = 1GB work_mem = 4MB maintenance_work_mem = 500MB wal_buffers = 1MB effective_cache_size = 1200MB checkpoint_segments = 16 max_fsm_pages = 80 default_statistics_target = 30 Como assim? Você sugere uma configuração assim para uma base de 50GB? Baseado em quais requisitos você sugere esta configuração? Tiago J. Adami wrote: Olá pessoal. Antes de começar, quero dizer que não sou xiita e tampouco quero transformar este post em uma discussão sobre qual SO é melhor por um ou outro motivo. Quero que o foco seja restrito apenas ao uso do PostgreSQL. Temos um cliente com uma base de dados onde o arquivo de backup no formato compactado com -F c -Z 9 tem próximo de 400 MB. Eu sei que para o padrão de vocês é pouco, mas para nossa aplicação já é um tamanho grande. O servidor do cliente é Windows 2008 64 bits, rodando em um servidor Dell com Intel Xeon 3 Ghz de 4 núcleos e 4 GB de RAM e um disco SCSI (sem RAID). Neste servidor havia reclamações de lentidão. Acontecia em um determinado horário (das 16:00hs em diante), e nada de anormal aparecia no status do servidor (observado pelo pgAdmin). Existiam apenas transações abertas desde às 08:00 hs da manhã no modo In Transaction ou Idle. Mas de uns dias para cá, a lentidão passou a ser incessante, mesmo sem atualizações do aplicativo, e não há backup/restore ou vacuum que resolva. A versão atual rodando é a 8.2.13. Primeiro, sugerimos a atualização para a versão 8.3.8 (homologada para o nosso ERP, a 8.4.1 nem está em testes ainda). Mas sinceramente, este é o primeiro passo apenas... Se não der muita diferença, vamos sugerir a atualização para o Linux... eu confio neste SO, trabalho com a instalação e configuração de servidores Linux a muito tempo, não sou um expert mas me viro. Acontece que agora, eu preciso de justificativas plausíveis, informações que possam convencer o cliente de que realmente o PostgreSQL foi feito para Linux, roda melhor no Linux e é mais rápido nele. A questão é mais ou menos como uma elaboração de monografia de graduação. Eu sei que no Linux é mais rápido, mas quem disse isso? Quais as fontes eu poderia citar? E antes que perguntem: - A aplicação não foi atualizada, portanto não foi nenhuma alteração que causou a lentidão; - O servidor é dedicado (apesar disso ser essencialmente impossível no Windows com todos os serviços que ele roda + o ambiente gráfico); - Já verifiquei processos como Vacuum e Backup. Não rodam enquanto está lento, somente pela madrugada; - Existe sim um software antivírus no servidor, um tal de Eset. Mas mesmo com ele desabilitado, a lentidão continua; A minha pergunta essencial é: quais as diferenças da versão do PostgreSQL para Linux e para Windows no que diz respeito à segurança, integridade e desempenho? -- TIAGO J. ADAMI http://www.adamiworks.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- View this message in context: http://old.nabble.com/Desempenho-no-Linux-tp26523053p26543306.html Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral []s -- JotaComm http://jotacomm.wordpress.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- View this message in context: http://old.nabble.com/Desempenho-no-Linux-tp26523053p26545354.html Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desempenho no Linux
Pablo Sánchez escreveu: PostgreSQL performance is very close on both platforms (within 6/100 of a second for 1000 Operations) – It’s faster on Windows and faster still on Windows with PHP 5.3 Ugh?! Quem disse que 'SELECT * FROM tabela' mede performance de um SGBD? O autor deve estar brincando, né? Temos benchmarks padronizados (aka TPC) para isso; eles implementam modelos que simulam um ambiente real de acordo com a arquitetura (OLTP, OLAP ou Web) do seu sistema. Não conheço nenhuma diferença... Com exceção do fato de que há tunnings que podem ser feitos com os semáforos do kernel em Linux/FreeBSD que não se conseguem no Windows. Como eu disse esses conceito *não* existe (é emulado) no Windows. -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desempenho no Linux
Pessoal, não vamos esquecer de outros fatores que fazem o Linux ter um desempenho muito melhor. - Sistemas de aquivos (Qual a opção que existe no Windows além de NTFS?) - Parâmetros do Kernel (Só se você por um expert no registro do Windows, quais os parâmetros que você pode mudar?) - Instalação via código fonte (Sei que tb dá pra compilar no Windows, mas duvido alguém que faça sem dor de cabeça e tb duvido do desempenho) - Melhor uso de hardware (Isso é senso comum, o Linux faz uso do hardware de maneira muito mais otimizada que o Windows) - Segurança (Bom como diz o Telles "Existem 2 tipos de Windows, aquele que tem vírus e aquele que você acha que não tem vírus") Para convencer o seu cliente você poderia fazer uma instalação em um servidor da sua própria em empresa e comparar o desempenho, duvido que ele não irá se convencer. Abraço, Fabiano Euler Taveira de Oliveira escreveu: Pablo Sánchez escreveu: "PostgreSQL performance is very close on both platforms (within 6/100 of a second for 1000 Operations) – It’s faster on Windows and faster still on Windows with PHP 5.3" Ugh?! Quem disse que 'SELECT * FROM tabela' mede performance de um SGBD? O autor deve estar brincando, né? Temos benchmarks padronizados (aka TPC) para isso; eles implementam modelos que simulam um ambiente real de acordo com a arquitetura (OLTP, OLAP ou Web) do seu sistema. Não conheço nenhuma diferença... Com exceção do fato de que há tunnings que podem ser feitos com os semáforos do kernel em Linux/FreeBSD que não se conseguem no Windows. Como eu disse esses conceito *não* existe (é emulado) no Windows. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desempenho no Linux
(corte das mensagens anteriores) Respondendo à todos os posts (economizando texto): A idéia de que o PostgreSQL foi feito _para_ linux e _portado_ para o Windows está baseada no fato de que foi desenvolvido sob a licença BSD, portanto _assumi_ que dificilmente os desenvolvedores iniciais estivessem utilizando Windows (me corrijam se estiver errado). Já investigamos a causa da lentidão antes. Aparentemente não há nada de incomum, apenas a velocidade para consultas simples (cadastros de itens, por exemplo) torna-se baixa e tarefas como gravação de nota fiscal que levavam segundos passam a demorar minutos. São mais de 30 usuários simultâneos em um sistema cliente/servidor (conecta ao fazer login, desconecta ao fechar o aplicativo). O volume transacional é considerado alto, visto que a todo momento alguma operação é feita nos terminais simultaneamente. Também, não conseguimos identificar nenhum outro aplicativo que faça o consumo de recursos do servidor. Mas... ... o array dos dois discos que contém o banco possui pastas compartilhadas sim, e com muitos arquivos nela. Isto passou despercebido em um primeiro momento. Mesmo assim, a atividade nestas pastas é muito pequena, não justifica a queda de desempenho tão brusca que ocorreu de uns dias para cá. Enfim... o jeito é fazer benchmarks próprios para verificar o desempenho entre os dois SO. Uma vantagem que visualizo com a troca para Linux é que não existirá muita coisa rodando como serviço, coisa que infelizmente o Windows possui desde a sua concepção. -- TIAGO J. ADAMI http://www.adamiworks.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desempenho no Linux
2009/11/26 Euler Taveira de Oliveira eu...@timbira.com: Pablo Sánchez escreveu: PostgreSQL performance is very close on both platforms (within 6/100 of a second for 1000 Operations) – It’s faster on Windows and faster still on Windows with PHP 5.3 Ugh?! Quem disse que 'SELECT * FROM tabela' mede performance de um SGBD? O autor deve estar brincando, né? Temos benchmarks padronizados (aka TPC) para isso; eles implementam modelos que simulam um ambiente real de acordo com a arquitetura (OLTP, OLAP ou Web) do seu sistema. Acho que o teste foi mais para medir o PHP que o PostgreSQL mesmo... Ainda assim, não é um teste muito profundo mesmo não... -- = Pablo Santiago Sánchez Análise e Desenvolvimento de Sistemas Web Zend Certified Engineer #ZEND006757 phack...@gmail.com (61) 9975-0883 http://www.sansis.com.br http://www.corephp.com.br Quidquid latine dictum sit, altum viditur = ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desempenho no Linux
2009/11/26 Wolak Sistemas - Fabiano Machado Dias fabi...@wolaksistemas.com.br: Pessoal, não vamos esquecer de outros fatores que fazem o Linux ter um desempenho muito melhor. - Sistemas de aquivos (Qual a opção que existe no Windows além de NTFS?) Mas será que precisa de algum outro além desse para ele? (obs, existe fat32, vc pode compilar partições maiores que 4GB de fat32 utilizando uma ferramenta chamada fat32format.exe - não é padrão do windows, mas é gratuita) - Parâmetros do Kernel (Só se você por um expert no registro do Windows, quais os parâmetros que você pode mudar?) Eu faço uma limpeza de alguns parâmetros que já conheço serem desnecessários e que só deixam o OS mais lento, mas isso desde o winnt 4... então meio que realmente, não sei de muita gente que faça isso na mão hoje em dia. - Instalação via código fonte (Sei que tb dá pra compilar no Windows, mas duvido alguém que faça sem dor de cabeça e tb duvido do desempenho) Sem dor de cabeça é complicado mesmo, mas vai falar com o Guilherme Blanco que é o cara responsável pelo windows.php.net. ;-) - Melhor uso de hardware (Isso é senso comum, o Linux faz uso do hardware de maneira muito mais otimizada que o Windows) Senso comum não é comprovação. Os drivers de placas 3D para windows são no geral muito melhores que o do Linux, até mesmo porque tem pouquíssima placa com driver oficial para o Linux... É senso comum que o céu é azul, mas é cientificamente comprovado que não existem as cores, apenas o espectro de luz. A cor é mera interpretação do cérebro, e o que é azul para mim (ou seja, exatamente como meu cérebro me apresenta) poderia ser o verde para vc. Senso comum é subjetivo, não serve como parâmetro... é a interpretação ordinária de cada um sobre o que todo mundo fala e quase ninguém para para comprovar. Tem pesquisas por aí que suportam a argumentação, e acho que nosso amigo precisa delas, e não de senso comum. - Segurança (Bom como diz o Telles Existem 2 tipos de Windows, aquele que tem vírus e aquele que você acha que não tem vírus) Para convencer o seu cliente você poderia fazer uma instalação em um servidor da sua própria em empresa e comparar o desempenho, duvido que ele não irá se convencer. Abraço, Fabiano Euler Taveira de Oliveira escreveu: Pablo Sánchez escreveu: PostgreSQL performance is very close on both platforms (within 6/100 of a second for 1000 Operations) – It’s faster on Windows and faster still on Windows with PHP 5.3 Ugh?! Quem disse que 'SELECT * FROM tabela' mede performance de um SGBD? O autor deve estar brincando, né? Temos benchmarks padronizados (aka TPC) para isso; eles implementam modelos que simulam um ambiente real de acordo com a arquitetura (OLTP, OLAP ou Web) do seu sistema. Não conheço nenhuma diferença... Com exceção do fato de que há tunnings que podem ser feitos com os semáforos do kernel em Linux/FreeBSD que não se conseguem no Windows. Como eu disse esses conceito *não* existe (é emulado) no Windows. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- = Pablo Santiago Sánchez Análise e Desenvolvimento de Sistemas Web Zend Certified Engineer #ZEND006757 phack...@gmail.com (61) 9975-0883 http://www.sansis.com.br http://www.corephp.com.br Quidquid latine dictum sit, altum viditur = ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desempenho no Linux
2009/11/26 Pablo Sánchez phack...@gmail.com: - Segurança (Bom como diz o Telles Existem 2 tipos de Windows, aquele que tem vírus e aquele que você acha que não tem vírus) tab + enter por acidente, desculpem. Bom, então estou na segunda parcela, porque nem entro mais no windows do meu note, só para jogar e muito de vez em quando, hehehe. Para convencer o seu cliente você poderia fazer uma instalação em um servidor da sua própria em empresa e comparar o desempenho, duvido que ele não irá se convencer. Isso é verdade. A apresentação seria essencial. Mas aí vem a questão da realização dos testes e do cliente não achar que o teste foi maquiado ou manipulado, afinal de contas, ele está tentando salvar a reputação do sistema da empresa que não está rodando bem com a afirmação de que a culpa é de software de terceiros. Eu acho que tem que fazer uma análise um pouco mais profunda do que poderia estar acontecendo. Sugerir a troca do OS que o cliente já adquiriu licença e tem suporte (deve ter algum admin lá windowzer) é complicado. Vamos usar este, que é de graça e é melhor. Poucas pessoas entendem que esse de graça não é realmente de graça - quem vai administrar o servidor? - e mais ainda, que neste caso o de graça realmente é melhor (de graça o santo desconfia que é des-graça). -- = Pablo Santiago Sánchez Análise e Desenvolvimento de Sistemas Web Zend Certified Engineer #ZEND006757 phack...@gmail.com (61) 9975-0883 http://www.sansis.com.br http://www.corephp.com.br Quidquid latine dictum sit, altum viditur = ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desempenho no Linux
2009/11/25 Tiago Adami adam...@gmail.com: Olá pessoal. Antes de começar, quero dizer que não sou xiita e tampouco quero transformar este post em uma discussão sobre qual SO é melhor por um ou outro motivo. Quero que o foco seja restrito apenas ao uso do PostgreSQL. Temos um cliente com uma base de dados onde o arquivo de backup no formato compactado com -F c -Z 9 tem próximo de 400 MB. Eu sei que para o padrão de vocês é pouco, mas para nossa aplicação já é um tamanho grande. Tenhos clientes com dumps menores que esse... :P O servidor do cliente é Windows 2008 64 bits, rodando em um servidor Dell com Intel Xeon 3 Ghz de 4 núcleos e 4 GB de RAM e um disco SCSI (sem RAID). Poxa, isso faz diferença. Nesse windão deve ter alguns compartilhamentos e serviços. Todos concorrendo com o postgres. Neste servidor havia reclamações de lentidão. Acontecia em um determinado horário (das 16:00hs em diante), e nada de anormal aparecia no status do servidor (observado pelo pgAdmin). Existiam apenas transações abertas desde às 08:00 hs da manhã no modo In Transaction ou Idle. A query estava 'in transaction' desde as 8h e ficou pendurada até agora? já descrobriu a causa disso? Mas de uns dias para cá, a lentidão passou a ser incessante, mesmo sem atualizações do aplicativo, e não há backup/restore ou vacuum que resolva. A versão atual rodando é a 8.2.13. Primeiro, sugerimos a atualização para a versão 8.3.8 (homologada para o nosso ERP, a 8.4.1 nem está em testes ainda). Mas sinceramente, este é o primeiro passo apenas... Mudar a versão pode trazer alguns ganhos de desempenho, mas se você utiliza o padrão do postgresql.conf não deve ser grande a diferença. É o seu caso? corte -- Atenciosamente, Sebastian Selau Webber Colombo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desempenho no Linux
2009/11/26 Tiago Adami adam...@gmail.com: (corte das mensagens anteriores) Respondendo à todos os posts (economizando texto): A idéia de que o PostgreSQL foi feito _para_ linux e _portado_ para o Windows está baseada no fato de que foi desenvolvido sob a licença BSD, portanto _assumi_ que dificilmente os desenvolvedores iniciais estivessem utilizando Windows (me corrijam se estiver errado). Na verdade, ele foi desenvolvido para os BSDs (FreeBSD, por exemplo, ou outros Unices derivados do BSD mesmo) e depois portado para o Linux, ou seja, afirmar que é melhor no Linux porque para o Windows foi portado é o mesmo que dizer que no Linux não seria bom, já que ele também foi portado para o Linux. Vide a história do PostgreSQL, e vai ver que em 1987 não existia Linux... mas já tinha os BSDs (não o Free, nem o Open, nem o Net, que só vieram anos depois que a universidade de Berkeley liberou as BSDTapes.., mas mesmo assim, esses são sistemas derivados do código original de 1969...) Já investigamos a causa da lentidão antes. Aparentemente não há nada de incomum, apenas a velocidade para consultas simples (cadastros de itens, por exemplo) torna-se baixa e tarefas como gravação de nota fiscal que levavam segundos passam a demorar minutos. Já checou se o HD está ok? Problemas físicos podem fazer com que o HD fique tentando gravar e gravar e gravar e desvie de setores defeituosos para localizar alguns pouco blocks que estejam ok. São mais de 30 usuários simultâneos em um sistema cliente/servidor (conecta ao fazer login, desconecta ao fechar o aplicativo). O volume transacional é considerado alto, visto que a todo momento alguma operação é feita nos terminais simultaneamente. Também, não conseguimos identificar nenhum outro aplicativo que faça o consumo de recursos do servidor. Mas... ... o array dos dois discos que contém o banco possui pastas compartilhadas sim, e com muitos arquivos nela. Isto passou despercebido em um primeiro momento. Mesmo assim, a atividade nestas pastas é muito pequena, não justifica a queda de desempenho tão brusca que ocorreu de uns dias para cá. Enfim... o jeito é fazer benchmarks próprios para verificar o desempenho entre os dois SO. Uma vantagem que visualizo com a troca para Linux é que não existirá muita coisa rodando como serviço, coisa que infelizmente o Windows possui desde a sua concepção. Não é bem assim... O Linux tb tem vários processos rodando à toa por lá. Se quer usar um OS para isso, te aconselho FreeBSD ao invés do Linux. -- = Pablo Santiago Sánchez Análise e Desenvolvimento de Sistemas Web Zend Certified Engineer #ZEND006757 phack...@gmail.com (61) 9975-0883 http://www.sansis.com.br http://www.corephp.com.br Quidquid latine dictum sit, altum viditur = ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desempenho no Linux
2009/11/26 Pablo Sánchez phack...@gmail.com: corte Eu acho que tem que fazer uma análise um pouco mais profunda do que poderia estar acontecendo. Sugerir a troca do OS que o cliente já adquiriu licença e tem suporte (deve ter algum admin lá windowzer) é complicado. Vamos usar este, que é de graça e é melhor. Poucas pessoas entendem que esse de graça não é realmente de graça - quem vai administrar o servidor? - e mais ainda, que neste caso o de graça realmente é melhor (de graça o santo desconfia que é des-graça). Se o cliente questiona o custo do software dê a sugestão de linux pago como o RedHat, etc, etc. Com todas as respostas na mão o cliente não tem como negar a migração do sistema operacional. O único motivo que pode impedir é que o cliente utilize essa máquina para outro proposito secundário e não tenha como colocar esses serviços em outra máquina/servidor. -- Atenciosamente, Sebastian Selau Webber Colombo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desempenho no Linux
2009/11/26 Pablo Sánchez phack...@gmail.com: corte Enfim... o jeito é fazer benchmarks próprios para verificar o desempenho entre os dois SO. Uma vantagem que visualizo com a troca para Linux é que não existirá muita coisa rodando como serviço, coisa que infelizmente o Windows possui desde a sua concepção. Não é bem assim... O Linux tb tem vários processos rodando à toa por lá. Se quer usar um OS para isso, te aconselho FreeBSD ao invés do Linux. A não ser que ele tenha alguém experiente em FreeBSD na equipe não parece uma boa idéia. -- Atenciosamente, Sebastian Selau Webber Colombo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desempenho no Linux
2009/11/26 Sebastian SWC sebastian...@gmail.com: Se o cliente questiona o custo do software dê a sugestão de linux pago como o RedHat, etc, etc. Com todas as respostas na mão o cliente não tem como negar a migração do sistema operacional. O único motivo que pode impedir é que o cliente utilize essa máquina para outro proposito secundário e não tenha como colocar esses serviços em outra máquina/servidor. Considerando o fato do servidor já ser dedicado, acho que não vai ser problema. Tem que ver é se o pessoal da rede vai dar conta ou topar o desafio... Espero que eles topem. -- = Pablo Santiago Sánchez Análise e Desenvolvimento de Sistemas Web Zend Certified Engineer #ZEND006757 phack...@gmail.com (61) 9975-0883 http://www.sansis.com.br http://www.corephp.com.br Quidquid latine dictum sit, altum viditur = ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desempenho no Linux
2009/11/26 Sebastian SWC sebastian...@gmail.com: A não ser que ele tenha alguém experiente em FreeBSD na equipe não parece uma boa idéia. Não sabemos nem se ele tem alguém experiente em Linux na equipe (não digo na dele, digo na do cliente). -- = Pablo Santiago Sánchez Análise e Desenvolvimento de Sistemas Web Zend Certified Engineer #ZEND006757 phack...@gmail.com (61) 9975-0883 http://www.sansis.com.br http://www.corephp.com.br Quidquid latine dictum sit, altum viditur = ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desempenho no Linux
2009/11/26 Pablo Sánchez phack...@gmail.com: 2009/11/26 Sebastian SWC sebastian...@gmail.com: A não ser que ele tenha alguém experiente em FreeBSD na equipe não parece uma boa idéia. Não sabemos nem se ele tem alguém experiente em Linux na equipe (não digo na dele, digo na do cliente). Tudo depende quem gerencia o servidor. Se o cliente deixa tudo por conta do fornecedor, é possível que não faça diferença desde que tudo funciona normalmente. Cada caso é um caso. Sem muitos detalhes fica bem difícil opinar. -- Atenciosamente, Sebastian Selau Webber Colombo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desempenho no Linux
Pablo Sánchez escreveu: 2009/11/26 Wolak Sistemas - Fabiano Machado Dias fabi...@wolaksistemas.com.br: Pessoal, não vamos esquecer de outros fatores que fazem o Linux ter um desempenho muito melhor. - Sistemas de aquivos (Qual a opção que existe no Windows além de NTFS?) Mas será que precisa de algum outro além desse para ele? (obs, existe fat32, vc pode compilar partições maiores que 4GB de fat32 utilizando uma ferramenta chamada fat32format.exe - não é padrão do windows, mas é gratuita FAT 32? Bah, tá loco, isso nem deveria ser considerado um sistema de arquivos. E acho que é importante você poder contar com mais opção de file system, já tive situações onde coloquei os dados em XFS, indíces em EXT2, e logs em ReiserFS. Era um caso específico e a performance ficou melhor, mas me diz qual a opção que teria em Windows? Nenhuma! - Parâmetros do Kernel (Só se você por um expert no registro do Windows, quais os parâmetros que você pode mudar?) Eu faço uma limpeza de alguns parâmetros que já conheço serem desnecessários e que só deixam o OS mais lento, mas isso desde o winnt 4... então meio que realmente, não sei de muita gente que faça isso na mão hoje em dia. Blz, acho que pode até ser válido, agora muda os semáforos do SO, ajusta a memória compartilhada, muda o tamanho da pilha, e outra sem reiniciar o sistema, afinal tu vai derrubar a empresa só pra mudar alguns parâmetros? - Instalação via código fonte (Sei que tb dá pra compilar no Windows, mas duvido alguém que faça sem dor de cabeça e tb duvido do desempenho) Sem dor de cabeça é complicado mesmo, mas vai falar com o Guilherme Blanco que é o cara responsável pelo windows.php.net. ;-) - Melhor uso de hardware (Isso é senso comum, o Linux faz uso do hardware de maneira muito mais otimizada que o Windows) Senso comum não é comprovação. Os drivers de placas 3D para windows são no geral muito melhores que o do Linux, até mesmo porque tem pouquíssima placa com driver oficial para o Linux... É senso comum que o céu é azul, mas é cientificamente comprovado que não existem as cores, apenas o espectro de luz. A cor é mera interpretação do cérebro, e o que é azul para mim (ou seja, exatamente como meu cérebro me apresenta) poderia ser o verde para vc. Senso comum é subjetivo, não serve como parâmetro... é a interpretação ordinária de cada um sobre o que todo mundo fala e quase ninguém para para comprovar. Tem pesquisas por aí que suportam a argumentação, e acho que nosso amigo precisa delas, e não de "senso comum". Bom quis dizer senso comum porque a maioria das pessoas que trabalham e conhecem o Linux sabem disso, mas só para elucidar o porque posso citar algumas coisas: - Linux e o Kernel foram feitos para rodar em hardware barato, desde o início a preocupação com performance foi uma constante. - O uso de memória e processador e a maneira de controlar os processos são melhores que qualquer sistema Windows, até pouco tempo atrás o Windows tinha problema em gerenciar 4 gb de memória. - Drivers de Placa 3d? Bom estamos ou pelo menos eu estava falando em servidores, onde os drivers realmente importantes são os das controladoras de disco, rede etc... Lembro de uma situação onde estava instalando um Debian em um servidor Dell, durante a instalação veio uma mensagem dizendo que eu precisaria de um pacote para a atualização do firmware da placa de rede, pois a mesma tinha problemas no driver nativo. Entrei no repositório de pacotes, baixei, pluguei um pendrive e a instalação continuou e este server está rodando até agora. Talvez a expressão senso comum não foi a mais correta, mas sei lá até leigos hoje em dia sabem que Linux é mais rápido que Windows, talvez porque é o sistema mais usado em servidores no mundo inteiro, sei lá! - Segurança (Bom como diz o Telles "Existem 2 tipos de Windows, aquele que tem vírus e aquele que você acha que não tem vírus") Para convencer o seu cliente você poderia fazer uma instalação em um servidor da sua própria em empresa e comparar o desempenho, duvido que ele não irá se convencer. Abraço, Fabiano Euler Taveira de Oliveira escreveu: Pablo Sánchez escreveu: "PostgreSQL performance is very close on both platforms (within 6/100 of a second for 1000 Operations) – It’s faster on Windows and faster still on Windows with PHP 5.3" Ugh?! Quem disse que 'SELECT * FROM tabela' mede performance de um SGBD? O autor deve estar brincando, né? Temos benchmarks padronizados (aka TPC) para isso; eles implementam modelos que simulam um ambiente real de acordo com a arquitetura (OLTP, OLAP ou Web) do seu sistema. Não conheço nenhuma diferença... Com exceção do fato de que há tunnings que podem ser feitos com os semáforos do kernel em Linux/FreeBSD que não se conseguem no Windows. Como eu disse esses conceito *não* existe (é emulado) no Windows. ___ pgbr-geral mailing
Re: [pgbr-geral] Desempenho no Linux
2009/11/26 Wolak Sistemas - Fabiano Machado Dias fabi...@wolaksistemas.com.br: FAT 32? Bah, tá loco, isso nem deveria ser considerado um sistema de arquivos. E acho que é importante você poder contar com mais opção de file system, já tive situações onde coloquei os dados em XFS, indíces em EXT2, e logs em ReiserFS. Era um caso específico e a performance ficou melhor, mas me diz qual a opção que teria em Windows? Nenhuma! k, eu sei, só lembrei que existe, não falei que prestava. :-D Eu faço uma limpeza de alguns parâmetros que já conheço serem desnecessários e que só deixam o OS mais lento, mas isso desde o winnt 4... então meio que realmente, não sei de muita gente que faça isso na mão hoje em dia. Blz, acho que pode até ser válido, agora muda os semáforos do SO, ajusta a memória compartilhada, muda o tamanho da pilha, e outra sem reiniciar o sistema, afinal tu vai derrubar a empresa só pra mudar alguns parâmetros? Fato. ;-) Bom quis dizer senso comum porque a maioria das pessoas que trabalham e conhecem o Linux sabem disso, mas só para elucidar o porque posso citar algumas coisas: - Linux e o Kernel foram feitos para rodar em hardware barato, desde o início a preocupação com performance foi uma constante. - O uso de memória e processador e a maneira de controlar os processos são melhores que qualquer sistema Windows, até pouco tempo atrás o Windows tinha problema em gerenciar 4 gb de memória. Na verdade é uma limitação por conta de sistemas 32bits, que só conseguem registrar os endereços até 3gb. Isso é para todos os OS... - Drivers de Placa 3d? Bom estamos ou pelo menos eu estava falando em servidores, onde os drivers realmente importantes são os das controladoras de disco, rede etc... Sim, apenas citei um caso, de resto o Linux e o FreeBSD batem fácil. Lembro de uma situação onde estava instalando um Debian em um servidor Dell, durante a instalação veio uma mensagem dizendo que eu precisaria de um pacote para a atualização do firmware da placa de rede, pois a mesma tinha problemas no driver nativo. Entrei no repositório de pacotes, baixei, pluguei um pendrive e a instalação continuou e este server está rodando até agora. Tive um server FreeBSD com uptime de 5 anos, só reiniciei no dia em que tive que atualizar o OS mesmo Talvez a expressão senso comum não foi a mais correta, mas sei lá até leigos hoje em dia sabem que Linux é mais rápido que Windows, talvez porque é o sistema mais usado em servidores no mundo inteiro, sei lá! Que o diga o boot do Linux dos eeePC 701... Otimização é pouco! Quero um boot daqueles até hoje e não consegui. - Segurança (Bom como diz o Telles Existem 2 tipos de Windows, aquele que tem vírus e aquele que você acha que não tem vírus) Para convencer o seu cliente você poderia fazer uma instalação em um servidor da sua própria em empresa e comparar o desempenho, duvido que ele não irá se convencer. :-D -- = Pablo Santiago Sánchez Análise e Desenvolvimento de Sistemas Web Zend Certified Engineer #ZEND006757 phack...@gmail.com (61) 9975-0883 http://www.sansis.com.br http://www.corephp.com.br Quidquid latine dictum sit, altum viditur = ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desempenho no Linux
2009/11/26 Tiago Adami adam...@gmail.com: Já investigamos a causa da lentidão antes. Aparentemente não há nada de incomum, apenas a velocidade para consultas simples (cadastros de itens, por exemplo) torna-se baixa e tarefas como gravação de nota fiscal que levavam segundos passam a demorar minutos. Você tem um histórico do tempo que tem levado para que os CHECKPOINTs sejam executados? Você tem um histórico de como está a utilização de disco quanto à entrada e saida? O I/O pode ser uma das causas. (...) ... o array dos dois discos que contém o banco possui pastas compartilhadas sim, e com muitos arquivos nela. O que são muitos arquivos ? Há problemas quanto há muitos arquivos (~1k) em um único diretório num NTFS. Enfim... o jeito é fazer benchmarks próprios para verificar o desempenho entre os dois SO. Uma vantagem que visualizo com a troca para Linux é que não existirá muita coisa rodando como serviço, coisa que infelizmente o Windows possui desde a sua concepção. Faça os benchmarks e se possível publique-os para referências futuras. []s Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desempenho no Linux
2009/11/26 Dickson S. Guedes lis...@guedesoft.net: 2009/11/26 Tiago Adami adam...@gmail.com: Já investigamos a causa da lentidão antes. Aparentemente não há nada de incomum, apenas a velocidade para consultas simples (cadastros de itens, por exemplo) torna-se baixa e tarefas como gravação de nota fiscal que levavam segundos passam a demorar minutos. Você tem um histórico do tempo que tem levado para que os CHECKPOINTs sejam executados? Como visualizo isso? Você tem um histórico de como está a utilização de disco quanto à entrada e saida? O I/O pode ser uma das causas. Há como ler um histórico de I/O do banco? Esta informação fica armazenada? (...) ... o array dos dois discos que contém o banco possui pastas compartilhadas sim, e com muitos arquivos nela. O que são muitos arquivos ? Há problemas quanto há muitos arquivos (~1k) em um único diretório num NTFS. Imagine uma pasta onde todos e qualquer um podem gravar arquivos, desde planilhas do Excel, relatórios emitidos pelo sistema em TXT, MP3. Mas pelo o que observei, o movimento nestas pastas é bem pequeno. Enfim... o jeito é fazer benchmarks próprios para verificar o desempenho entre os dois SO. Uma vantagem que visualizo com a troca para Linux é que não existirá muita coisa rodando como serviço, coisa que infelizmente o Windows possui desde a sua concepção. Faça os benchmarks e se possível publique-os para referências futuras. Posso fazer sim, sem problemas, mas terei que usar parâmetros da nossa aplicação. (corte) -- TIAGO J. ADAMI http://www.adamiworks.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desempenho no Linux
Não sou muito conhecedor desta parte de configurações em sistemas operacionais, mas creio que para ver o motivo de tal lentidão poderia inicial verificar o eventviewer, acho que escreva-se assim mesmo. Nele você tem todas as operações certos? do SO. Atenciosamente, Guilherme de Carvalho Carneiro 2009/11/26 Tiago Adami adam...@gmail.com 2009/11/26 Dickson S. Guedes lis...@guedesoft.net: 2009/11/26 Tiago Adami adam...@gmail.com: Já investigamos a causa da lentidão antes. Aparentemente não há nada de incomum, apenas a velocidade para consultas simples (cadastros de itens, por exemplo) torna-se baixa e tarefas como gravação de nota fiscal que levavam segundos passam a demorar minutos. Você tem um histórico do tempo que tem levado para que os CHECKPOINTs sejam executados? Como visualizo isso? Você tem um histórico de como está a utilização de disco quanto à entrada e saida? O I/O pode ser uma das causas. Há como ler um histórico de I/O do banco? Esta informação fica armazenada? (...) ... o array dos dois discos que contém o banco possui pastas compartilhadas sim, e com muitos arquivos nela. O que são muitos arquivos ? Há problemas quanto há muitos arquivos (~1k) em um único diretório num NTFS. Imagine uma pasta onde todos e qualquer um podem gravar arquivos, desde planilhas do Excel, relatórios emitidos pelo sistema em TXT, MP3. Mas pelo o que observei, o movimento nestas pastas é bem pequeno. Enfim... o jeito é fazer benchmarks próprios para verificar o desempenho entre os dois SO. Uma vantagem que visualizo com a troca para Linux é que não existirá muita coisa rodando como serviço, coisa que infelizmente o Windows possui desde a sua concepção. Faça os benchmarks e se possível publique-os para referências futuras. Posso fazer sim, sem problemas, mas terei que usar parâmetros da nossa aplicação. (corte) -- TIAGO J. ADAMI http://www.adamiworks.com ___ 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
Re: [pgbr-geral] Desempenho no Linux
2009/11/26 Tiago Adami adam...@gmail.com 2009/11/26 Dickson S. Guedes lis...@guedesoft.net: 2009/11/26 Tiago Adami adam...@gmail.com: Já investigamos a causa da lentidão antes. Aparentemente não há nada de incomum, apenas a velocidade para consultas simples (cadastros de itens, por exemplo) torna-se baixa e tarefas como gravação de nota fiscal que levavam segundos passam a demorar minutos. Você tem um histórico do tempo que tem levado para que os CHECKPOINTs sejam executados? Como visualizo isso? Nos logs é um bom começo. Mas você precisa logar esta informação, basta habilitar no postgresql.conf [1]. É bom ter uma noção porque enquanto o banco está fazendo um checkpoint seu desempenho cai. Você tem um histórico de como está a utilização de disco quanto à entrada e saida? O I/O pode ser uma das causas. Há como ler um histórico de I/O do banco? Esta informação fica armazenada? Ao menos nos discos sim, no banco voce tem várias informações que podem ser obtidas com os dados das tabelas pg_stats_*. Um CACTI com um plugin check_postgresql.pl do nagios [2] por exemplo pode ter dar boas informações de historico destes dados. Além disto, no caso do Windows existem ferramentas de tempo real que você consegue visualizar esta utilização. (...) ... o array dos dois discos que contém o banco possui pastas compartilhadas sim, e com muitos arquivos nela. O que são muitos arquivos ? Há problemas quanto há muitos arquivos (~1k) em um único diretório num NTFS. Imagine uma pasta onde todos e qualquer um podem gravar arquivos, desde planilhas do Excel, relatórios emitidos pelo sistema em TXT, MP3. Mas pelo o que observei, o movimento nestas pastas é bem pequeno. Quantos arquivos existem? Já tive problemas em Windows 2003 com NTFS em um cliente onde foi necessários dividir uma única pasta em 256 pastas distintas cada uma com 16 subpastas, distribuindo então os arquivos entre elas. Enfim... o jeito é fazer benchmarks próprios para verificar o desempenho entre os dois SO. Uma vantagem que visualizo com a troca para Linux é que não existirá muita coisa rodando como serviço, coisa que infelizmente o Windows possui desde a sua concepção. Faça os benchmarks e se possível publique-os para referências futuras. Posso fazer sim, sem problemas, mas terei que usar parâmetros da nossa aplicação. Também pode ser interessante logar as consultas que demoram mais que um certo tempo (~100ms por exemplo?) e analisá-las com um pgfouine por exemplo, pois podem ser consultas que não se dão muito bem em ambientes muito concorridos. [1] http://www.postgresql.org/docs/8.2/static/runtime-config-wal.html#RUNTIME-CONFIG-WAL-CHECKPOINTS [2] http://bucardo.org/check_postgres/ []s Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desempenho no Linux
2009/11/26 Dickson S. Guedes lis...@guedesoft.net: 2009/11/26 Tiago Adami adam...@gmail.com 2009/11/26 Dickson S. Guedes lis...@guedesoft.net: 2009/11/26 Tiago Adami adam...@gmail.com: Já investigamos a causa da lentidão antes. Aparentemente não há nada de incomum, apenas a velocidade para consultas simples (cadastros de itens, por exemplo) torna-se baixa e tarefas como gravação de nota fiscal que levavam segundos passam a demorar minutos. Você tem um histórico do tempo que tem levado para que os CHECKPOINTs sejam executados? Como visualizo isso? Nos logs é um bom começo. Mas você precisa logar esta informação, basta habilitar no postgresql.conf [1]. É bom ter uma noção porque enquanto o banco está fazendo um checkpoint seu desempenho cai. Ok, vou verificar. Você tem um histórico de como está a utilização de disco quanto à entrada e saida? O I/O pode ser uma das causas. Há como ler um histórico de I/O do banco? Esta informação fica armazenada? Ao menos nos discos sim, no banco voce tem várias informações que podem ser obtidas com os dados das tabelas pg_stats_*. Um CACTI com um plugin check_postgresql.pl do nagios [2] por exemplo pode ter dar boas informações de historico destes dados. Além disto, no caso do Windows existem ferramentas de tempo real que você consegue visualizar esta utilização. Também vou verificar com mais tempo... (...) ... o array dos dois discos que contém o banco possui pastas compartilhadas sim, e com muitos arquivos nela. O que são muitos arquivos ? Há problemas quanto há muitos arquivos (~1k) em um único diretório num NTFS. Imagine uma pasta onde todos e qualquer um podem gravar arquivos, desde planilhas do Excel, relatórios emitidos pelo sistema em TXT, MP3. Mas pelo o que observei, o movimento nestas pastas é bem pequeno. Quantos arquivos existem? Já tive problemas em Windows 2003 com NTFS em um cliente onde foi necessários dividir uma única pasta em 256 pastas distintas cada uma com 16 subpastas, distribuindo então os arquivos entre elas. A quantidade não importa muito, ainda não contei os arquivos. Fato é que no caso deste cliente, o servidor deve ser dedicado. Se rodar Windows, pelo menos o disco deve ser dedicado. O difícil é colocar isso na cabeça dos clientes, sempre querem baixo custo e alto desempenho. Fato é que, também, praticamente todos os nossos clientes mantém compartilhamentos no mesmo disco onde está instalado o PostgreSQL, pois eles _acham_ que por ser um servidor, deve guardar tudo. Outro detalhe é que sempre rodou assim antes, e nunca deu estes problemas. Vou tentar banir os compartilhamentos, mas será uma tarefa árdua. Enfim... o jeito é fazer benchmarks próprios para verificar o desempenho entre os dois SO. Uma vantagem que visualizo com a troca para Linux é que não existirá muita coisa rodando como serviço, coisa que infelizmente o Windows possui desde a sua concepção. Faça os benchmarks e se possível publique-os para referências futuras. Posso fazer sim, sem problemas, mas terei que usar parâmetros da nossa aplicação. Também pode ser interessante logar as consultas que demoram mais que um certo tempo (~100ms por exemplo?) e analisá-las com um pgfouine por exemplo, pois podem ser consultas que não se dão muito bem em ambientes muito concorridos. Já implementamos um logging na aplicação em todos os comandos SQL que são executados, e as primeiras modificações já começaram a ser feitas em comandos SQL pouco eficientes. [1] http://www.postgresql.org/docs/8.2/static/runtime-config-wal.html#RUNTIME-CONFIG-WAL-CHECKPOINTS [2] http://bucardo.org/check_postgres/ []s Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- TIAGO J. ADAMI http://www.adamiworks.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desempenho no Linux
Olá, pessoal To chegando atrasado para a discussão mas eu queria participar. Você tem habilitado o log do PostgreSQL? Se sim, tem alguma informação nele? Você percebeu se consultas anteriormente rápidas passaram a ficar extremamente lentas? Se o seu log de atividades do PostgreSQL não está habilitado eu iria sugerir você habilitar os seguintes parâmetros. redirect_stderr = on log_min_duration_statement = 1s log_line_prefix = '%t [%p]: [%l-1] ' - permite a leitura dos logs pelo pgFouine, conforme o Guedes comentou. Assim, como o Guedes comentou seria interessante você analisar o período de quanto em quanto tempo ocorreu o checkpoint. O padrão é de 5 em 5 minutos, ou a cada 48MB, isto porque, checkpoint_segments=3*16 que é o tamanho de cada segmento. Se você tivesse trabalhando com a versão 8.3 você poderia habilitar o parâmetro log_checkpoints = on, que ele mostraria as informações de cada ocorrência de checkpoint. Outra dúvida é que não vi ninguem comentar. Vocè tem algum processo de analyze rodando diariamente. Eu vi que você falou que nenhum restore ou vacuum resolve, mas você não comentou nada sobre vacuum ou autovacuum. Você faz uso de algum destes procedimentos de manutenção? Outro detalhe, você ou alguem mais realizou alguma configuração no arquivo de configuração do PostgreSQL? Lembro de ter visto você comentado sobre conexões em idle ou idle transaction. As conexões em idle transaction ficam muito tempo penduradas? Será que você não ta ficando com alguma transação em aberto que esteja bloqueando alguma coisa? Seu banco cresceu nos últimos dias? Ou teve algum processo de carga que tenha aumentado o volume de dados de alguma tabela e isso possa estar impactando por derrepente algum atributo que não era consultado e agora esta sendo bastante consultado e não tem um índice por exemplo? Tem a questão dos discos, se o disco tiver problema certamente você terá sua problema global prejudicada. Outra dúvida, é só o PostgreSQL que está lento ou toda a máquina esta lenta? 2009/11/26 Tiago Adami adam...@gmail.com 2009/11/26 Dickson S. Guedes lis...@guedesoft.net: 2009/11/26 Tiago Adami adam...@gmail.com 2009/11/26 Dickson S. Guedes lis...@guedesoft.net: 2009/11/26 Tiago Adami adam...@gmail.com: Já investigamos a causa da lentidão antes. Aparentemente não há nada de incomum, apenas a velocidade para consultas simples (cadastros de itens, por exemplo) torna-se baixa e tarefas como gravação de nota fiscal que levavam segundos passam a demorar minutos. Você tem um histórico do tempo que tem levado para que os CHECKPOINTs sejam executados? Como visualizo isso? Nos logs é um bom começo. Mas você precisa logar esta informação, basta habilitar no postgresql.conf [1]. É bom ter uma noção porque enquanto o banco está fazendo um checkpoint seu desempenho cai. Ok, vou verificar. Você tem um histórico de como está a utilização de disco quanto à entrada e saida? O I/O pode ser uma das causas. Há como ler um histórico de I/O do banco? Esta informação fica armazenada? Ao menos nos discos sim, no banco voce tem várias informações que podem ser obtidas com os dados das tabelas pg_stats_*. Um CACTI com um plugin check_postgresql.pl do nagios [2] por exemplo pode ter dar boas informações de historico destes dados. Além disto, no caso do Windows existem ferramentas de tempo real que você consegue visualizar esta utilização. Também vou verificar com mais tempo... (...) ... o array dos dois discos que contém o banco possui pastas compartilhadas sim, e com muitos arquivos nela. O que são muitos arquivos ? Há problemas quanto há muitos arquivos (~1k) em um único diretório num NTFS. Imagine uma pasta onde todos e qualquer um podem gravar arquivos, desde planilhas do Excel, relatórios emitidos pelo sistema em TXT, MP3. Mas pelo o que observei, o movimento nestas pastas é bem pequeno. Quantos arquivos existem? Já tive problemas em Windows 2003 com NTFS em um cliente onde foi necessários dividir uma única pasta em 256 pastas distintas cada uma com 16 subpastas, distribuindo então os arquivos entre elas. A quantidade não importa muito, ainda não contei os arquivos. Fato é que no caso deste cliente, o servidor deve ser dedicado. Se rodar Windows, pelo menos o disco deve ser dedicado. O difícil é colocar isso na cabeça dos clientes, sempre querem baixo custo e alto desempenho. Fato é que, também, praticamente todos os nossos clientes mantém compartilhamentos no mesmo disco onde está instalado o PostgreSQL, pois eles _acham_ que por ser um servidor, deve guardar tudo. Outro detalhe é que sempre rodou assim antes, e nunca deu estes problemas. Vou tentar banir os compartilhamentos, mas será uma tarefa árdua. Enfim... o jeito é fazer benchmarks próprios para verificar o desempenho entre os dois SO. Uma vantagem que visualizo com a troca para Linux é que não existirá muita coisa
Re: [pgbr-geral] Desempenho no Linux
Tiago Adami escreveu: Temos um cliente com uma base de dados onde o arquivo de backup no formato compactado com -F c -Z 9 tem próximo de 400 MB. Eu sei que para o padrão de vocês é pouco, mas para nossa aplicação já é um tamanho grande. O servidor do cliente é Windows 2008 64 bits, rodando em um servidor Dell com Intel Xeon 3 Ghz de 4 núcleos e 4 GB de RAM e um disco SCSI (sem RAID). Você não disse quantos usuários simultâneos e nem o volume transacional mas... backup/restore ou vacuum que resolva. A versão atual rodando é a 8.2.13. 8.2 é a *primeira* versão que é suportada ainda; deve ser descontinuada pela grupo de desenvolvimento daqui a algum tempo. Primeiro, sugerimos a atualização para a versão 8.3.8 (homologada para o nosso ERP, a 8.4.1 nem está em testes ainda). Mas sinceramente, este é o primeiro passo apenas... Eu não executaria em plataforma Windows se não fosse a última versão (8.4.1). Por quê? Simplesmente porque a versão para Windows é muito recente (5 anos) comparado ao tempo de desenvolvimento em plataforma Unix-like. Além disso, existem poucos desenvolvedores para Windows; o que quer dizer que esta plataforma tem menos atenção do que as outras. Acontece que agora, eu preciso de justificativas plausíveis, informações que possam convencer o cliente de que realmente o PostgreSQL foi feito para Linux, roda melhor no Linux e é mais rápido nele. Quem disse que o PostgreSQL foi feito para Linux? É fato que a maioria dos desenvolvedores utilizam Linux para desenvolvimento mas ele de nenhuma maneira funciona _somente_ em Linux. A questão é mais ou menos como uma elaboração de monografia de graduação. Eu sei que no Linux é mais rápido, mas quem disse isso? Quais as fontes eu poderia citar? Você pode dizer. Basta fazer um benchmark e provar para o cliente esta premissa. Em plataforma Windows o PostgreSQL vai ser _sempre_ mais lento pois os elementos base (aka memória compartilhada e semáforos) utilizados são emulados (o Windows não dispõe de uma API para isso). Além disso, a própria arquitetura do PostgreSQL (múltiplos processos) não tem um desempenho bom no Windows. - Existe sim um software antivírus no servidor, um tal de Eset. Mas mesmo com ele desabilitado, a lentidão continua; Você já investigou a causa da lentidão? A minha pergunta essencial é: quais as diferenças da versão do PostgreSQL para Linux e para Windows no que diz respeito à segurança, integridade e desempenho? Quanto a segurança e integridade, não há diferença; o desempenho é outra história (há muita diferença). -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desempenho no Linux
2009/11/26 Tiago Adami adam...@gmail.com: Temos um cliente com uma base de dados onde o arquivo de backup no formato compactado com -F c -Z 9 tem próximo de 400 MB. Eu sei que para o padrão de vocês é pouco, mas para nossa aplicação já é um tamanho grande. O servidor do cliente é Windows 2008 64 bits, rodando em um servidor Dell com Intel Xeon 3 Ghz de 4 núcleos e 4 GB de RAM e um disco SCSI (sem RAID). Neste servidor havia reclamações de lentidão. Acontecia em um determinado horário (das 16:00hs em diante), e nada de anormal aparecia no status do servidor (observado pelo pgAdmin). Existiam apenas transações abertas desde às 08:00 hs da manhã no modo In Transaction ou Idle. Mas de uns dias para cá, a lentidão passou a ser incessante, mesmo sem atualizações do aplicativo, e não há backup/restore ou vacuum que resolva. A versão atual rodando é a 8.2.13. Você está se focando apenas no banco. Podem ser outros 500.000 motivos, desde atualização do windows comendo a banda de rede do servidor, até o uso do servidor para guardar mp3 por algum admin mais metido a esperto. Antes de sair mudando o OS (seu cliente não vai gostar, com certeza) verifique se não é o OS em si que está lento. Primeiro, sugerimos a atualização para a versão 8.3.8 (homologada para o nosso ERP, a 8.4.1 nem está em testes ainda). Mas sinceramente, este é o primeiro passo apenas... Se não der muita diferença, vamos sugerir a atualização para o Linux... eu confio neste SO, trabalho com a instalação e configuração de servidores Linux a muito tempo, não sou um expert mas me viro. Acontece que agora, eu preciso de justificativas plausíveis, informações que possam convencer o cliente de que realmente o PostgreSQL foi feito para Linux, roda melhor no Linux e é mais rápido nele. A questão é mais ou menos como uma elaboração de monografia de graduação. Eu sei que no Linux é mais rápido, mas quem disse isso? Quais as fontes eu poderia citar? Complicado... O resultado que encontrei pesquisando diz justamente o contrário... PostgreSQL performance is very close on both platforms (within 6/100 of a second for 1000 Operations) – It’s faster on Windows and faster still on Windows with PHP 5.3 http://misfitgeek.com/blog/aspnet/php-versus-asp-net-ndash-windows-versus-linux-ndash-who-rsquo-s-the-fastest/ Tem o código utilizado para fazer o teste... http://www.misfitgeek.com/pages/perftest-pg.htm E antes que perguntem: - A aplicação não foi atualizada, portanto não foi nenhuma alteração que causou a lentidão; - O servidor é dedicado (apesar disso ser essencialmente impossível no Windows com todos os serviços que ele roda + o ambiente gráfico); - Já verifiquei processos como Vacuum e Backup. Não rodam enquanto está lento, somente pela madrugada; - Existe sim um software antivírus no servidor, um tal de Eset. Mas mesmo com ele desabilitado, a lentidão continua; A minha pergunta essencial é: quais as diferenças da versão do PostgreSQL para Linux e para Windows no que diz respeito à segurança, integridade e desempenho? Não conheço nenhuma diferença... Com exceção do fato de que há tunnings que podem ser feitos com os semáforos do kernel em Linux/FreeBSD que não se conseguem no Windows. -- = Pablo Santiago Sánchez Análise e Desenvolvimento de Sistemas Web Zend Certified Engineer #ZEND006757 phack...@gmail.com (61) 9975-0883 http://www.sansis.com.br http://www.corephp.com.br Quidquid latine dictum sit, altum viditur = ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
