Configuração de alto desempenho do PostgreSQL

Question

Estou configurando um servidor com as seguintes especificações:
* Qtde 4 processadores (AMD Opterons com 12 núcleos cada)
* Memória de 32 GB
* Qtd 8 HDD (15K SAS Dual Port)
* CentOS 5,5
* JBoss
* PostgreSQL

É provável que, em um momento posterior, eu separe o aplicativo do banco de dados, mas, por enquanto, eles estarão na mesma máquina. Eu li que o desempenho do PostgreSQL se beneficia de:
* RAID 10
* Partição separada do sistema operacional | * Separe a partição xlog
* Separa a partição pgdata

Como meu volume RAID 10 único parece ter um total de 559808 MB disponíveis, esse é o plano de partição atual:
* 337856 MB para o OS
* 102400 MB para pgdata
* 51200 MB para xlog
* 68352 MB para swap -

Aqui estão algumas perguntas:
* Como fica o meu plano de partição?
* Ao instalar o CentOS, quando chego na etapa de configuração do disco, preciso definir pontos de montagem - o que devo inserir para a partição pgdata? (ex. ref este exemplo de configuração dos pontos de montagem / pgdata1 )
* O que devo inserir como o ponto de montagem para a partição xlog?
* Para o tipo de sistema de arquivos, evitar a corrupção é mais importante que o desempenho perfeito, portanto, o plano é usar 'noatime', mas deixar 'data = ordered' para as opções de montagem da partição - o que você acha?
* Alguma outra consideração?

Observação: é provável que o tamanho total de todos os bancos de dados na partição pgdata não ultrapasse 20 GB nos próximos anos.

    

Answer 1

• Ok, vamos a verdade. Banco de dados + servidor de aplicativos em uso não deve realmente trocar. Agora, eu entendo "trocar coisas que não são usadas como partes do kernel, etc.", mas o espaço de troca de 64GB é ridículo. Não há nenhuma maneira o computador pode fazer uso de que, de uma forma sensata, com velocidade decente. Leva muito tempo. Corte isso. Significativo. Muito significante. Gostaria de 8GB ou mais. Talvez 12 ou 16. Mas simplesmente não há como usar remotamente os 64GB que você atribui atualmente.

• Seu servidor provavelmente tem muito a fazer em termos de computação, porque, embora não seja patético, NÃO é um servidor de banco de dados de alto desempenho. Más notícias. REALMENTE más notícias. Um ataque 10 para todas as coisas compartilhadas - não é uma boa ideia. Mas 6 discos não são de alto desempenho 15k ou não. Eu tenho um servidor db menor aqui que tem 6 discos em um RAID 10 apenas para os dados. O que quer que você faça, transacionalmente, você será limitado pelo desempenho do disco novamente, a menos que você faça o OLAP. Não há nenhuma maneira que o subsistema de disco pode empurrar ONE 12 core proessor, 4 deles é absolutamente impossível. Na maioria dos casos, um único núcleo 4 sobrecarregaria os discos. Realmente, é melhor fazer algo do lado computacional.

Sugestões:

• Adicione outro SSD para os registros. Isso é super rápido e tem tempos de resposta muito rápidos. O banco de dados precisa gravar as alterações no disco o mais rápido possível e, em alguns casos, isso é "gravado e liberado".

• Certifique-se de que precisa do que compra. Eu sei que Java pode ser um porco de recursos, mas nessas dimensões? Você realmente precisa de 48 núcleos? O Centos lida com isso decentemente? O Linux DID tem problemas com muitos núcleos. Agora, eu sei que estes tempos estão quase acabados, mas 48 núcleos podem ser bastante agressivos. Eu realmente gosto de servidores poderosos, mas quando eu trabalho normalmente com bancos de dados seu tamanho é de 4 dígitos (1000 + gb) e o subsistema de disco tem um mínimo de 10, muitas vezes mais de 1000 discos para alimentar aquele monstro com o orçamento de IO necessário. Os servidores OR são para virtualização.

• Adicione mais RAM. 32gb som impressionante, mas para 48 núcleos que é um pouco baixo para o meu gosto. Eu prefiro ir com um mínimo de 1-2 gigabytes por núcleo.

• Se você for AMD, lembre-se de dividir seus módulos entre processadores;)

Answer 2

• ++ o que a TomTom escreveu.
• O IIRC, o motivo para partições separadas para o data / xlog / OS, é colocá-las em conjuntos separados de fusos - não vejo como deixá-los cair no mesmo conjunto de RAID faz isso.
• Enquanto o PostgreSQL se adapta muito bem a múltiplos núcleos, 48 parece ser um exagero.
• Há também a velocidade dos núcleos. Pelo que eu vi: quanto maior a contagem de núcleos, mais lentos são os núcleos individuais - você pode ser melhor servido por menos núcleos, mas mais rápidos.

Existe um livro, PostgreSQL 9.0 High Performance que faz um bom trabalho de cobrir os meandros do PostgreSQL de alto desempenho.

    

Answer 3

A divisão de um único grande volume RAID10 em várias partições não realiza nada útil. Os padrões de uso de disco do sistema operacional, do WAL e das unidades de banco de dados são diferentes o suficiente para colocá-los em discos separados tornam o PostgreSQL mais rápido. Por exemplo, o WAL é todas as gravações seqüenciais, portanto, ter uma unidade dedicada para isso pode ajudar com várias coisas. Partições separadas no mesmo volume de disco grande não melhoram o desempenho da mesma maneira.

Em última análise, isso não importa realmente, quando seu conjunto de dados é tão pequeno em relação à quantidade de RAM em seu servidor. Você não precisa realmente de uma configuração de disco de alto desempenho para conseguir isso, apenas CPUs e RAM rápidas.

A única coisa que você não mencionou é o controlador RAID que você está usando e se você tem uma bateria para fornecer backup para o cache. Isso é muito mais importante que as trivialidades do particionamento. Consulte Escritos Confiáveis para obter links para mais informações aqui.

    

Answer 4

Bancos de dados são comumente vinculados a E / S. Sem saber nada sobre seu aplicativo em particular, eu descartaria três dos processadores e verificaria a obtenção de uma placa Fusion IO (ou talvez um SSD) para a partição pgdata.

Eu também configurei o RAID um pouco diferente. O padrão de uso do xlog (sequencial) será tipicamente diferente da partição pgdata (aleatória). Por esse motivo, sugiro colocá-los em dispositivos físicos separados.

    

Answer 5

A resposta de desempenho padrão é "testar e ver". Então, se você puder experimentar algumas configurações diferentes sob carga e ver qual delas é a melhor para sua carga com seus dados , esta seria a configuração 'correta'.

Com um banco de dados de 20 GB, você pode ajustar (quase) todo o banco de dados no cache do sistema de arquivos e / ou no cache do buffer do Postgresql. Você pode nem ter muitos IOs físicos quando o servidor for aquecido.

Talvez um bom lugar para começar seja criar um espelho RAID 1 de 2 discos para o sistema operacional e usar os outros 6 discos em uma matriz RAID 10 para pgdata + swap. Até que você tenha dados para fazer o backup, não vejo necessidade de separar os xlogs e os pgdata. Esta configuração irá pelo menos permitir que você mova o log para o mirror drive se você realmente precisar.

O mesmo vale para as opções de montagem. o noatime é quase sempre uma boa ideia, mas qualquer outra coisa que eu deixaria sozinho até que você precise.

Uma coisa a observar no CentOS / RHEL é LVMs. Isso provavelmente vale outra pergunta, mas eu nunca uso o LVM e, em vez disso, cria partições ext3 simples. (Eu realmente espero que você quis dizer RAID de hardware para seus discos e não LVM RAID)