> > Fiz isso e aparentemente o problema está na CPU. Ao executar a consulta, > inicialmente os dados são lidos do HD (somente da primeira vez, pois da > segunda ele pega do shared_buffers), mas a demanda é pequena. Depois disso > existe somente processamento de CPU e memória. Durante esse tempo não é > feita nenhuma leitura de HD, e nem criado nenhum arquivo temporário. >
Embora você possa estar correto quanto a questão do processador, como o fike afirma. Se tudo corre bem e apenas esta consulta apresenta problema, com certeza vale a pena rodar um 'EXPLAIN ANALYZE' para esta consulta. Existe uma enorme possibilidade de com um tuning nesta consulta você conseguir um ganho muito mais expressivo do que mexendo no hardware ou nos ajustes do Linux ou do PostgreSQL. Poste aqui a sua consulta inteira com o resultado do explain para a gente dar uma olhada. A chance de uma pequena mudança ter um efeito absurdo do desempenho é grande. > > Acontece que um consultor de Linux está dizendo que o problema de > lentidão está no fato do Post 8.x não estar homologado para o Redhat > que eles usam. > > > Olha, esse consultor de GNU/Linux está meio estranho... eu trocaria de > consultor na hora. Outras coisas que tenho que concordar com os colegas que me antecederam: botar a culpa na versão do PostgreSQL é muito tosco. O seu consultor realmente comeu bola ou está escondendo a ignorância dele sobre o assunto. É uma opinião tão conceituada quando a do técnico que manda você trocar todas as placas do seu computador e formatar o HD para resolver um problema de configuração. Alias, tem muito consultor bom aqui na lista que pode lhe ajudar. Basta pedir, que com certeza muitas mão se levantarão por aqui. > > Ainda não consegui falar com ele. > > Outra coisa que ele alega é que o os dados do Post foram colocados > na partição "/" (/dados/pgdata/base/...) e isso também degrada a > performance. Isso procede? > > > Depende. Realmente não é boa prática; o ideal seria uma partição > própria, inclusive sem jornalização de dados, apenas de metadados. > Verdade absoluta. Bancos de dados se beneficiam muito de um planejamento detalhado no uso dos discos (muitos, sempre!) e particionamento cuidadoso. > > Neste caso você sugere usar um EXT2 ou XFS? Hã... muita calma nesta hora. Isso vai depender da paranóia que você tem em relação a segurança. Particularmente eu não mexeria neste tipo de coisa se você não tiver uma boa retaguarda na hora do sufoco (coisa que você sempre deve ter alias). Afinal, todos sistemas de arquivos estão sujeitos a enfrentarem tempestades. Cada um reage de um jeito a tempestade. Saber o que fazer em cada caso é algo que deve ser muito bem ponderado junto com outras questões: como estão os discos (tem RAID? qual tipo? como estão distribuídos os dados pelos discos), qual é sua política de backup e restore? Tem cópia dos logs gerados pelo WAL? Antes de mexer em sistemas de arquivos e usar opções mais arrojadas neles pense que sempre haverá uma troca entre desempenho e segurança. Não sai de graça não. Se você não tem um SLA bem definido e tem uma boa consultoria por trás, vai em frente. Caso contrário, não troque desempenho por segurança... > > Estive pesquisando sobre essa familia de processadores Xeon > (familia 15, modelo 4) e descobri que ele foi descontinuado pela > Intel já em 2005 por ter péssima performance para servidores (o > processador internamente é constituído por dois Pentium 4, com > apenas 2MB de cache cada, sendo bem baixa a velocidade de > comunicação com a memória principal). Já o Xeon da família 6, > modelo 15, é outra história. > > > Geralmente bases de dados não são limitadas por processamento, como > está a espera por CPU? > > E uma diferença de 3x é difícil de atribuir a um processador tão > próximo do outro. > > > > > O Load Average varia entre 1.3 e 1.8 (isso com 60 conexões, porém executando > somente essa consulta em questão). Mesmo assim a consulta leva entre 6 a 8 > minutos. Como eu já disse essa mesma consulta, na mesma base, porém em outra > máquina mas com CPU Xeon mais atual (inclusive com clocke menor), a consulta > leva 3 minutos. > Vide acima. um tuning nesta consulta deve lhe ajudar. Pense que mesmo que você troque o processador, 3 minutos é bastante coisa. Se a base crescer, e certamente ela o irá... os 3 minutos podem virar 30 de repente. Boa sorte por aí. []s Fábio Telles -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: [EMAIL PROTECTED] _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
