Quando eu era um garoto, meu pai me levava nas feiras de informática que ocorriam no Anhembi, ainda no final da década de 80. Eram meus primeiros contatos com a informática. Eu fazia meus primeiros programas em BASIC num CP400 e gravava tudo em fitas cassetes. Foi um alívio quando usei pela primeira vez um disquete no Apple IIe. Era algo realmente incrível. Então veio o primeiro PC com um incrível HD de 20MB. Fantástico. Depois veio um moderno 486 que tinha um disco de fantásticos 200MB. Logo foi trocado por um de 2GB, 6GB e quando pisquei o olho já usava um disco de 40GB. Hoje os dois discos SATA de 200GB não parecem muito grandes…

Mas voltemos para os tempos das feiras de informática, antes da FENASOFT surgir e depois sumir. Um dia vimos as primeiras memórias flash ainda como protótipo numa destas feiras… Meu pai olhou para aquilo e pensou: “Hum, sem partes móveis? Mais rápido e mais confiável… isso ainda vai aposentar os discos rígidos em menos de 10 anos”. Bom, naquele tempo eu já fazia o curso Técnico em Eletrônica e via as memórias EEPROM e UVPROM e também as “memórias CMOS”. Para um mercado que tinha saído das ROMs puras há pouco… tudo já parecia fantástico. Mas de fato as memórias FLASH foram chegando. Primeiro os disquetes foram saindo e sua morte foi enfim anunciada com os primeiro iMacs sem unidades de disquetes e com as novas portas USB! Os gravadores de CD também inundavam o mercados e padrões proprietários que melhoravam os disquetes como os ZIP Disks afundaram. Então vieram os pendrives, 128K, 512K, 1GB, 4GB e já temos os de 32GB. Em 2007 os notebooks entraram na dança e os primeiros HDs finalmente foram saindo de cena.

Até aí, ninguém decretou o fim dos HDs… os HDs continuam firme e forte. Os IDEs e SCSI deram lugar aos modenos SATA e SAS e vão evoluindo em capacidade e velocidade. Os HDs SATA de 10Krpm e os SAS de 15Krpm se tornaram comuns. Controladoras SATA com RAID 0, 1 e 10 já são comuns. Controladoras SAS com capacidade para dezenas de discos, baterias para o cache estão a pleno vapor. Sem contar com os Storages que são mais flexíveis usando interfaces iSCSI, Fibre Channel e InfiniBand e flexibilidade para usar discos Fibre Channel, SAS e até SATA. A indústria de discos rígidos continua a pleno vapor. Com a excessão dos notebooks, os desktops e servidores parecem estar com seu mercado garantido. Até quando?

É claro que os notebooks, subnotebooks, palms, mp3 e outros gadgets estão inundando um mercado que se acostuma com a ausência dos discos rígidos. Mas quando se fala em performance e confiabilidade, as memórias flash são em geral descartadas. Elas tem por tradição seram mais lentas e terem a mania de ir perdendo alguns bits com o tempo. Por outro lado, há uma demanda cada vez maior por performance. Quando eu escrevi o meu artigo sobre PostgreSQL, discos & cia eu fui pesquisando alguns dados para melhorar o artigo. Ao fazer uma busca por IOPS eu tive que fazer uma longa pausa na escrita do artigo. Algo mudou no ar. Não é uma coisa qualquer… isso é grande, é uma “mudança disruptiva”. Daqui para frente, após todo esse blábláblá, vou tentar explicar o que se passa nos bastidores.

Tratar grandes volumes de dados nem sempre foi a trarefa principal dos computadores. A IBM nasceu construindo máquinas que pudessem tratar grandes volumes de dados, mas estes não eram computadores, eram máquinas de tabular dados. O primeiro sucesso foi com o censo dos Estados Unidos em 1890 e depois em 1900. Nascia a época dourada dos cartões perfurados para o tratamento de grandes volumes de dados. Os primeiros computadores tratavam principalmente de cálculos complexos. Foi o surgimento dos discos magnéticos que propiciou o algo parecido com o que hoje chamamos de banco de dados. A primeira unidade de discos rígidos foi o IBM 305 RAMAC em 1956 com seus 5MB em uma unidade de disco rígido com quase uma tonelada e do tamanho de uma lavadora de roupas . Em 1965 já vemos o surgimento do CODASYL, a primeira tentativa de padronizar o acesso a dados, que mais tarde deu origem ao COBOL. A questão aqui é que discos rígidos e bancos de dados nasceram juntos e cresceram juntos. Não haveria como os bancos de dados crescerem se não houvesse um correspondente aumento de capacidade e velocidade dos discos. Os custo, é claro, também caiu muito.

Vejamos uma comparação entre o IBM 1311 lançado em 1961 e um disco SAS atual.

	IBM 1311 (1961)	Disco SAS (2007)
Capacidade	28MB	300GB
Número de Discos	20	4
Diâmetro do Disco	18″	3,5″
Velocidade de Rotação	1,8Krpm	15Krpm
Taxa de transferência	90KB/s	300KB/s
Custo	US$115.500	US$300

Enfim o que mudou? Discos menores, com maior densidade magnética, maior velocidade de rotação e menor custo. Claro que há muito mais que isso. Há interfaces como SATA, SAS, FC, InfiniBand, vários tipos de RAID, cache e uma infinidade de tecnologias destinadas a melhorar a performance, confiabilidade e preço dos discos. Mas, mesmo com enorme ganho nestas 3 áreas, em algum momento da história, os discos deixaram de acompanhar o rítimo de desenvolvimento dos processadores quanto ao desempenho. O custo dos storages em grandes bancos de dados é cada vez mais significativo no custo total do hardware. Enquanto se mensurava o custos dos discos em US$/GB, hoje se mede também em US$/IOPS. Ou seja, não se trata mais apenas de conseguir espaço em disco. Se trata também manter um volume de operações de leitura e gravação por segundo adequada as exigências do seu banco de dados.

Bom, para o mercado de Banco de Dados, as demandas parecem que cresceram mais que a tecnologia. Não são apenas as bases com mais de 10TB que assustam os DBAs. Em apenas um Rack de 19″ podemos ter 10TB com RAID e tudo o mais. Claro que não vai sair barato. Mas discos grandes não são tão caros. Um disco SAS de 1TB não custa muito. Mas e para se conseguir 10 mil IOPS? Sim, aí você terá problemas. Discos rápidos são caros. Você vai precisar de um RAID 10 muitos discos velozes para conseguir alguma coisa próxima a 10 mil IOPS. Os modernos storages atuais podem ter atingir mais de 200 mil IOPS. E mais, pode ser que você use estes discos apenas para guardar seus logs de transação do banco de dados. Parece um exageiro, mas em bases com fortes demandas OLTP isso não é nenhum absurdo. Não é a toa que discos de 36GB não saem do mercado, mesmo com os discos de 1TB disponíveis.

Hoje se fala de “unidades de estado sólido” ou Solid State Drives, ou ainda apenas SSD. Apesar de serem internamente completamente diferentes das unidades de discos rígidos, para o SO, se comportam de forma idêntica. Possuem sistemas de arquivos, partições e tudo o mais. De fato, a idéia é poder trocar um disco rígido por memórias de estado sólido de forma natural. O conector, a interface (SATA ou SAS) e as características lógicas são as mesmas. Isto realmente torna as coisas muito mais simples. Na verdade, uma disco de estado sólido pode ter inclusive o mesmo tamanho de um disco de 3.5″, se encaixando normalmente no lugar de um disco rígido. Vejam a foto abaixo. Trocar uma unidade de disco rígido e inserir um SSD não parece uma tarefa nada assustadora.

Bom, vamos com calma agora. Eu sei que tenho falado muito até agora, mas leia isso com atenção. Todos devem lembrar das diferenças entre a RAM e a ROM:

• Os dados na RAM são volateis enquanto os dados na ROM são persistentes;
• As memórias ROM podem ser do tipo ROM, PROM, EEPROM ou Flash
  • A ROM pura vem gravada de fábrica e nunca pode ter seu conteúdo gravado;
  • A PROM pode ser gravada uma única vez por um processo especial de queima de microfusíveis;
  • A EPROM ou UVPROM que podia ser apagada expondo o chip a luz ultra violeta e depois regravada;
  • A EEPROM que podia se apagada e regravada por meio de pulsos elétricos;
  • A Memória Flash que pode apagar apenas uma parte da sua memória e regrava-la. Ela pode ser do tipo NOR ou NAND. As memórias Flash também são chamadas de RAM não volátil ou NVRAM. Mas sua origem histórica vem do ramo das ROMs.
    • A Flash do tipo NOR veio a substituir as memórias PROM, EPROM e EEPROM;
    • A Flash do tipo NAND é adequada para leituras e gravações em bloco como em memórias de massa, AKA. discos. A Flash de tipo NAND são hoje de dois tipos:
      • A MLC pode armazenar mais de um bit por célula, possuindo um custo por bit mais baixo. A memória Flash MLC é a utilizada em pendrives e cartões de memória fartamente encontrados no mercado.
      • A SLC armazena apenas um bit por célula, tendo menor densidade e maior custo. Por outro lado ela é mais rápida e tem uma vida útil maior.
• As memórias RAM podem ser do tipo dinâmicas ou DRAM ou estáticas SRAM:
  • A SRAM utiliza uma estrutura de transistors conhecida como FLIP-FLOP para armazenar os dados, são mais caras e podem ser to tipo:
    • TTL que é a mais rápidas e a que consome mais energia. Utilizada sempre em buffers e caches;
    • CMOS que é lenta mas é a que menos consome energia quando está em repouso. Utilizada para armazenar os dados do setup, por exemplo;
  • A DRAM é mais barata e possui alta densidade, é utilizada nas memórias DDR;

Bom, isto só para ter um panorama simplificado das memórias utilizadas comercialmente hoje em dia. Siga os links acima para ter mais detalhes. Ocorre que na maioria das vezes em que estamos falando de SSD, estamos falando de dispositivos que utilizam memória Flash MLC. Estes são os discos com preços competitivos, feitos para competir com discos SATA. É para este camimnho que os notebooks topo de linha estão migrando massivamente e que devem aposentar os HDs rapidamente neste segmento. Mas há uma nova geração SSD feitos para competir no quesito desempenho.

Em agosto de 2007, uma empresa anunciou um dispositivo que pode ser conectado numa porta PCIe de 20GB/s. Com 2U e 504GB de memória este dispositivo alcança 3 milhões de IOPS. E não é só: taxas de transferência de 1400MB/s em leitura e 1000MB/s em gravação. Qual o milagre? Simples, não há discos nem flash… e sim a boa e velha memória SDRAM. Bom… é óbvio que esse pessoal não espera que a energia acabe. Mas de toda forma o Violin 1010 quando ligado num bom nobreak oferece um desempenho incrível com menor consumo de energia, baixo custo e sem exigir mudanças na sua aplicação. Veja os números você mesmo e imagine sua aplicação ficando 30 a 60 vezes mais rápida de uma hora para outra!

No final de setembro, a Fusion-IO lança uma placa PCIe 4x com 640GB utilizando memória flash NAND SLC e com um software novo capaz de diminuir as deficiências das memórias flash. A performance? 10 mil IOPS e 800 MB/s. Em novembro a BitMicro anuncia a venda de SSDs com memória flash NAND SLC de 1,6TB mas utilizando a interface Fibre Channel.Então em Janeiro de 2008, a Texas Memory Systems publica seus testes com o RAM-SAN 400. O RAM-SAN 400 vem de uma linhagem de storages que utilizam memórias DDR RAM para armazenar dados emulando discos rígidos. Neste sentido o RAM-SAM é parecido com a solução da BitMicro por se portar como um Storage, por outro lado é parecido com o Violin 1010 que utiliza RAM. A diferença é que o RAM-SAN tem 3 baterias internas e um HD internamente. Se a energia acabar, as baterias entram em ação e gravam todos os dados no HD. Outro detalhe é que o RAM-SAM já tem esta solução há algum tempo no mercado, sendo homologado pela IBM, Microsoft e SUN… e com a publicação dos seus testes no Storage Performance Council (SPC) que é para o storage o que o TPC é para os bancos de dados.

O RAM-SAN 400 é um storage com até 8 portas Fibre Channel e até 128GB de memória RAM. O os testes no SPC tiveram o seguinte resultado: mais de 291 mil IOPS ao custo total de 194785 US$ ou seja: US$0,67 US$/IOPS . Vamos comparar com outro teste recente no mesmo site? O teste da 3PAR InServ® T800 Storage Server alcança quase 225 mil IOPS ao custo de mais de 2 milhões de dólares ou 9,3 US$/IOPS. O resultado é um desempenho 13 vezes mais baixo. O milagre? Enquanto o RAM-SAM usa um storage de 3U e 128GM de memória SDRAM, o T800 usa 5 racks de 44U, e tem 77TB com 4 x 320 discos fibre channel de 146GB cada. Agora imagine a diferença de consumo de energia?

OK, o RAM-SAN é comprovadamente uma solução viável. Mas foi quando a EMC lançou também em janeiro de 2008 que o mercado entrou em polvorosa definitivamente. A solução é simples. Você pode utilizar o storage topo de linha da EMC o Symmetrix e escolher utilizar alguns SSDs no lugar de discos convencionais. Resultado? Um nome de peso como o da EMC com um storage de alto nível e o melhor dos dois mundos: espaço com discos SAS e velocidade com discos SSD. A EMC apostou em discos SSD com memórias FLASH NAND SLC, assim como a Fusion-IO e a BitMicro. A diferença é que você tem integrado ao SSD, agora chamado de “Enterprise Flash Drive” junto com um storage reconhecido no mercado. A entrada da EMC neste mercado pode ser comparado com a entrada da IBM no segmento de microcomputadores. Ok, talvez eu esteja exagerando um pouco, talvez não. O fato é que a EMC alega que seus SSDs tem 30 pelo menos vezes mais IOPS que os discos mais rápidos disponíveis e um ciclo de vida maior.

São notícias realmente animadoras. Os SSDs com memórias flash NAND SLC utilizam mecanismos mais sofisticados para minimizar a possibilidade de perda de dados. E não parou por aí… em junho a HP e Fusion-IO anunciam que vão adaptar os discos SSD da Fusion-IO para os sistemas Blade da HP. A Texas Memory Systens criou o RAM-SAN 440 com memórias DDR2 e mais velocidade e o RAM-SAN 500 utilizando agora memória flash NAND SLC também. E assim, todos estão correndo atrás da nova onda. Uma virada deste tipo pode dar a possibilidade para novas empresas crescerem e grandes empresas que venham a perder o bonda da história sumirem do mapa. Ainda é tudo muito incerto. Vejamos como está o mercado hoje:

• Alguns apostam em placas PCI para conectar diretamente as memórias. Faz sentido… para que eu preciso ser uma caríssima controladora quando eu posso me conectar diretamente ao barramento do sistema. Muita coisa nova pode surgir daí;
• Por outro lado, ter uma unidade onde eu possa retirar um disco e colocar um SSD na mesma baia parece algo muito interessante, tanto num desktop quanto num caríssimo storage;
• Os SSDs baseados em memórias Flash NAND MLC vão continuar substituindo os HDs SATA em notebooks, desktops e há quem já fale nestes brinquedinhos como o futuro dos CPDs verdes. Tudo o que sabemos é que o preço está caindo enquanto a capacidade, velocidade e confiabilidade vem aumentando rapidamene;
• Os SSDs baseados em memórias Flash NAND SLC são a opção mais confiável para conseguir dispositivos rápidos. É nesta direção que a maioria das pesquisas estão se concentrando. Conseguir 100 mil IOPS parece um bom ganho para muitos;
• As soluções SSD baseadas em DRAM são o que há de mais rápido no mercado. O RAM-SAN parece que está conquistando muitos adeptos com um custo atraente. O RAM-SAN 440 atingiu mais de 600 mil IOPS enquanto o Violin conseguiu mais de 3 milhão de IOPS. Enquanto no RAM-SAN você acaba tendo que confiar nas baterias redundantes do equipamento, no Violin, o abacaxi está inteiramente na sua mão. Performance sempre tem preço.

É cedo ainda, mas é real. Está acontecendo e quem está no limite do desempenho está convidado a experimentar as novas tecnologias SSD para o mercado de alto desempenho transacional. Eu gostaria muito de poder testar um brinquedinho destes. Seria interessante testar diferentes particionamentos utilizando SSDs de alto desempenho. Outro desafio seria rever a parte de tuning nos SGDBs. O otimizador de consultas está sempre privilegiando leituras sequenciais e atribuindo um custo diferente para operações de leitura/escrita sequencial/randômica. É claro que não dá para sonhar colocar todos os seus tablespaces num caro SSD de alto desempenho. O fato de colocar apenas os logs transacionais e tablespaces específicos vai exigir novamente mais habilidade dos DBAs para tirar todo proveito desta nova tecnologia. Particularmente eu já vejo os DBAs bem aparelhados com o PostgreSQL, uma vez que as estimativas de custos são parametrizadas. O que pode acontecer é ter que fazer ajustes específicos para operações que utilizam ou não tablespaces armazenadas em SSD. De qualquer forma, um futuro mais rápido surge no nosso horizonte.

Qual meu maior medo nisso tudo? Que os desenvolvedores continuem embarcando cegamente na onda dos ORMs e quando a performance gritar… fazer o que todo mau programador adora fazer: aumentar a performance do hardware ao invés de concertar a aplicação. A aplicação sentou o banco? Compra uns SSDs que rezolve….

Tags: DBA, Fibre Channel, HD, IOPS, PostgreSQL, SAS, SSD, tuning

ou…

Tudo que você sempre quis saber sobre discos em servidores PostgreSQL e tinha vergonha de perguntar

Este é um texto que eu tenho vontade de escrever já faz bem um ano. Não escrevi antes por preguiça (é um texto longo) e porque é um texto um tanto pretensioso (tive receio de falar bobagem). Esta semana eu resolvi correr o risco. Já fazia um tempo que eu não me debruçava sobre um texto técnico um pouco mais longo, então tomei coragem e coloquei as idéias no papel, ou melhor, no blog. Muitos DBAs experientes sentirão que eu posso ter escorregado ou simplificado demais aqui ou ali. O propósito era escrever algo didático e não um livro inteiro sobre o assunto. Mas se você encontrar imprecisões técnicas ou tiver alguma sugestão para melhorar/corrigir o texto, por favor deixe um comentário.

Todo DBA é ou deveria ser tarado por discos. A não ser que você seja um daqueles que acreditam que um banco de dados possa conviver inteiro na memória sem nenhum problema (já ouviram falar de um SGDB escrito em Java que é mais rápido que o MySQL e o PostgreSQL?) você verá que os discos são o ponto chave no desempenho, na segurança e no custo do hardware. Neste texto vamos abordar alguns aspectos importantes e tentar visualizar ver como aplicar um pouco disso práticos no final. Vejamos os tópicos a serem abordados:

• RAID
• Discos
• Controladoras de Discos
• Tipos de Arquivos
• Particionamento
• Como distribuir as partições nos discos existentes

RAID

Em termos de desempenho o mantra sempre foi “quanto mais discos melhor”. Mas algo mudou no meio do caminho. Há tempos atrás as pessoas ficavam fazendo uma ginastica danada para distribuir os tablespaces em discos diferentes. O resultado era a paralelização no acesso ao disco. Se realizado com sucesso, o processo iria dobrar a velocidade quando uma operação fosse realizada em dois discos ao mesmo tempo. Fazer isso não é simples. Uma formula mágica muito divulgada era o de separar os índices das tabelas. Como é comum acessar uma tabela e acessar seus índices também, isto parecia fazer muito sentido. Surpresa, não é bem assim que as coisas funcionam. Você tem que fazer uma avaliação real de quais objetos (tabelas e índices) são acessados mais concomitantemente. Isso era o que se chama de “evitar a contenção de discos”. Ocorre que o otimizador ao fazer uma consulta que envolve várias tabelas pode realizar o acesso a disco de diversas formas diferentes. De acordo com a época do ano, a freqüência no acesso aos objetos pode mudar, enfim, são inúmeros detalhes para serem avaliados. Resultado: distribuir os objetos em dois discos ao invés de um não significa ter o dobro de velocidade o tempo todo.

O uso massivo do RAID começou a trazer uma nova abordagem. Quanto mais discos você colocar no RAID, mais rápido o acesso será para todas as operações. Então se você dobra o número de discos no RAID, você dobra a velocidade em todo o acesso aos objetos armazenados naqueles discos. Então a questão fundamental é em quantos discos a informação vai ser dividida para gravarmos ela simultaneamente. É aqui que começa a guerra dos tipos de RAID a se utilizar.

Com o RAID 0, você tem o aproveitamento máximo dos discos. A implementação é simples e o ganho de desempenho é máximo também: o ganho de desempenho é exatamente igual ao número de discos utilizados. 2 discos, 2 vezes mais rápido. 5 discos, 5 vezes mais rápido, 100 discos, 100 vezes mais rápido. Não é maravilhoso? Simples, barato e eficiente. Só tem um problema. Se um único disco falhar… todos os seus dados em todos os discos do RAID vão para o espaço, junto com o seu emprego. Resultado, o RAID 0 só pode ser utilizado em um servidor de banco de dados em uma situação: dados temporários cuja perda não causa perda de dados nem indisponibilidade no sistema. Há um bom exemplo disso. Se você utiliza sistemas que fazem consultas muito complexas, numa base grande (vejamos, pelo menos uns 500GB é algo de tamanho considerável) como num data warehouse, você terá um volume de dados temporários considerável. Neste caso, vale a pena ter um RAID separado só para os tablespaces temporários. O PostgreSQL 8.3 traz a capacidade de indicar um lugar específico para os dados temporários. Aqui é o lugar para isso.

Então vem o nosso amigo RAID 5, que é muito rápido para leitura, mas é considerado lento para gravação. Se você tem um grande volume de dados estáticos, com muita leitura e pouca gravação, o RAID 5 pode ser para você. É verdade que o RAID 5 tem desempenho inferior em gravação. Mas se você colocar um volume grande de discos, com pelo menos 5 discos, este custo passa a ser compensado pelo aumento no número de discos. Existem também implementações do RAID 5 em hardwares proprietários que não apresentam uma penalização de gravação tão alta quanto se divulga por aí. É claro que isto depende do uso de uma ótima controladora de discos. Mas o fato é que o RAID 5 tem má fama devido ao seu problema com a segurança. Enquanto no RAID 0 você não tem segurança nenhuma, o RAID 5 permite que você perca até um disco. O problema é que se você comprar vários discos num mesmo lote, existe uma grande chance deles apresentarem defeito em no mesmo período. Se você observar dezenas de lâmpadas trocadas ao mesmo tempo, verá que elas começam a queimar na mesma época. Se isto ocorrer com seu RAID 5, você terá problemas. Então, se você se preocupa com segurança, não use RAID 5. No RAID 5 você precisa ter no mínimo 3 discos, mas você não deveria jamais montar um RAID 5 com 3 discos. Por outro lado, se você se preocupa com a segurança, colocar um número muito grande de discos aumenta a chance de haver uma falha em mais de um disco. Outro detalhe bizarro é que se ocorrer uma falha e você tiver um hot spare, este entrará em operação e começará a remontar todo o esquema de redundância novamente. Essa operação de reconstrução da paridade do RAID 5 é pesada e lenta, então se o seus discos forem do mesmo lote, a chance de um segundo disco quebrar durante a reconstrução é grande. Se isso ocorrer, você perderá todos os seus dados. Se você se preocupa com desempenho só use RAID 5 com pelo menos 5 discos. Se você se preocupa com a segurança, use um hot spare e também não aumente muito o número de discos.

Então porquê todos usam tanto o RAID 5? É simples… ele é muito mais barato que o RAID 1. Destes discos, o espaço total de armazenamento será equivalente ao espaço de todos os discos juntos menos 1. Então se você tem 10 discos de 300 GB, o espaço útil é de 3TB - 300GB = 2.7TB. Nada mau, não? Mas veja bem… a quantidade de discos tem influência enorme não apenas no custo, mas na segurança e no desempenho também. Então onde posso usar o RAID 5? Se você se preocupa exclusivamente com o custo, o RAID 5 é uma solução barata em termos de capacidade de armazenamento, combinando uma segurança mínima que diminui conforme o número de discos aumenta. Se você pensa em desempenho e tem dados atualizados com pouca freqüência, como em dados históricos, o RAID 5 é uma boa solução. Mas se você se preocupa com segurança, evite o RAID 5 e só use para armazenar dados não críticos.

Existe também o RAID 6 que começou a ser utilizado recentemente. Ele é muito semelhante ao RAID 5, mas permite a perda de até 2 discos sem interrupção no funcionamento. É mais seguro sem ser muito mais caro. Você provavelmente só vai encontrar o RAID 6 em controladoras mais sofisticadas e storages externos. Num RAID 6, com 10 discos de 300GB o espaço útil é de 2.4TB. Para um número pequeno de discos (o mínimo são 4 discos, mas você deveria pensar e começar com 6) o uso de um disco a mais para a paridade é significativo, mas para um número grande isto se torna uma questão menor. Em termos de segurança, poder perder 2 discos é muito interessante. O RAID 6 não sofre tanto com o problema da reconstrução da paridade como no RAID 5, o que aumenta bem a sua segurança. Em termos de desempenho ele é semelhante ao RAID 6.

O nosso amigo RAID 1 é o mais simples e o mais caro tipo de RAID. O ganho de desempenho dele é nulo na gravação e mas dobra a velocidade na leitura. Além disso a capacidade total de armazenamento é metade da soma dos discos. O RAID 1 é o simples espelhamento dos discos. Vejamos como as coisas ficam. Se você tem dois discos de 300GB em RAID 1, o seu espaço útil é de 300GB. Simples assim. Se você tem apenas 2 discos e não quer se arriscar com o RAID 0, o RAID 1 é sua única opção.

O tipo de RAID que fez as pessoas largarem mão de distribuir os dados em diferentes discos isolados (sem RAID), foi o RAID 10, ou RAID 1 + 0. O RAID 10 combina o aumento de segurança do RAID 1 com o aumento de desempenho do RAID 0. Só tem um problema, assim como o RAID 1, ele precisa de 50% dos discos para o espelhamento, o que encarece a solução. Outro detalhe, é que você começa a brincar de RAID 10 a partir de 4 discos e daí para frente sempre em números pares como 4, 6, 8, 10, 12, etc. Com dois discos você tem apenas o RAID 1. Assim, o único problema do RAID 10 é o custo. Imagine que com 4 discos de 300GB, você só aproveitará 600GB. Com 10 discos de 300GB, só aproveitará 1,5TB. É bem possível também que com 10 discos em RAID 5 ou 6 você tenha um desempenho de gravação semelhante ou superior e um desempenho em leitura muito maior. Então a questão do RAID 10 é realmente a segurança.

Então fica a questão: quando eu devo usar o RAID? Resposta: SEMPRE, escolhendo o RAID 10, 1, 5 ou 6 dependendo das suas prioridades e RAID 0 para casos muito especiais como um esquema complementar. A cultura que está se formando em tornos dos DBAs hoje é a de usar RAID 1 ou 10 para tudo, uma vez que a segurança raramente é uma questão menor e o custo $/GB estar caindo, particularmente com os discos SAS em substituição aos SCSI.

Discos

Falando em tipos de discos, outra coisa que você deve lembrar é que existem no mercado 3 tipos de interfaces para discos: fibre channel, SAS e SCSI. Não exite SATA, esqueça que eles existem mesmo em RAID. Não importa o que você leu no blog do beltrano, SATA é muito mais lento e muito menos confiável. Mesmo os discos SAS estão ainda sob vigilância, uma vez que sempre que o preço dos discos cai muito, a desconfiança aumenta. De qualquer forma, os discos SAS devem dominar o mercado rapidamente. Os discos fibre channel são usados apenas em storages externos de alto desempenho. É comum ver storages que suportem discos SCSI, fibre channel, SAS e SATA. Mesmo que o seu storage seja caríssimo, o fato dele suportar os discos SATA não significa que eles sejam adequados para bancos de dados. Pode ser que para servidores de arquivo o seu uso junto com RAID seja aceitável, para bancos de dados não. Você realmente vai ter que comprar uma controladora descente e discos dedicados a servidores e não a desktops.

Sobre o tamanho dos discos, há outro detalhe importante. Pelo menos na tradição dos discos SCSI, os discos de maior capacidade são os que tem o custo de $/GB melhor e o pior desempenho. Não sei se a mesma tendência se repetirá com os discos SAS, mas é bom ficar de olho. Mesmo porquê, se você precisa de muito espaço em disco, é claro que a melhor solução é ter muitos discos pequenos e não poucos discos enormes. Aumentar o número de discos é sinônimo de aumentar o desempenho. Não existem servidores de bancos de dados sérios com 1 disco. Comece com 2 discos e aumente este número aos pares. Isto o deixa na posição de começar com um RAID 1 que é uma solução aceitável para um servidor pequeno e crescer para 4 ou 6 no futuro com um RAID 10. É claro que se você não utiliza um storage externo, o gabinete do servidor vai limitá-lo seriamente. Então evite os servidores 1U (estou falando da altura do servidor no rack, é claro) que só comportam cerca de 2 discos e prefira os servidores com 2U que comportam em geral até 6 discos ou 4U que comportam cerca de 15 discos. Existem discos novos com tamanho de 2,5 polegadas ao invés das tradicionais 3,5 polegadas. Estes devem possibilitar um aumento no número de discos num mesmo gabinete além de diminuir o consumo de energia. Ainda é muito cedo para fazer uma comparação séria.

A estatística que realmente interessa para o desempenho do banco de dados é o número de operações por segundo, o IOPS e a taxa de transferência sustentada. O IOPS depende não apenas dos discos, mas da controladora e do SO utilizado. Você pode verificar o IOPS do seu servidor no Linux através do iostat. A coluna “tps” do relatório do iostat é equivalente ao IOPS do seu disco. A taxa de transferência sustentada é a quantidade de bytes que o disco consegue transferir por um longo período. Os fabricantes costumam publicar nas suas especificações a taxa de transferência e a taxa de transferência sustentada. Você deve se preocupar apenas com a segunda. É aqui que os HDs SATA perdem e muito, pois o protocolo utilizado pelo HD SATA não consegue manter uma taxa de transferência razoável. Já os discos Fibre Channel, SCSI e SAS (lembre-se que o SAS nada mais é do que o protocolo SCSI com uma interface serial).

Ao comparar os últimos lançamentos dos discos da Seagate por exemplo, vemos o disco Savvio de 2.5 polegadas, 15Krpm com interface SAS e capacidade de 36GB e 72GB. Já em 3.5 polegadas temos o Cheetah um disco de 15,6Krpm com interface SAS ou Fibre Channel e capacidade de 146GB, 300GB ou 450GB. Vejamos alguns detalhes das especificações:

Especificação	2,5″ SAS 73GB	3,5″ SAS 146GB	3,5″ FC 146GB
Taxa de transferência externa (MB/s)	300	300	400
Taxa de transferência sustentada interna(MB/s)	79 a 112	110 a 178	110 a 178
Latência média (ms)	2	2	2
Tempo de busca médio Leitura/Gravação (ms)	2.9/3.3	3.4/3.9	3.4/3.9
Tempo de busca trilha a trilha Leitura/Gravação (ms)	0,2/0,4	0,2/0,4	0,2/0,4
Potência media (W)	7,9	14,4	15,0

Notamos que:

• A taxa de transferência externa do Fibre Channel é maior que o SAS;
• A taxa de transferência sustentada é menor nos discos de 2.5 polegadas. Vale a pena lembrar que quanto maior o diâmetro do disco, maior a quantidade de setores nas trilhas externas do disco. Assim, mantendo o número de rotações do disco, os discos com maior diâmetro conseguem transferir um número maior de dados;
• O tempo de busca que mede a velocidade com a qual o cabeçote se move (de trilha para trilha) é igual, mas como o disco de 3,5 polegadas tem que se movimentar por um disco com maior diâmetro, o tempo médio de busca dele é maior.
• O consumo de energia dos discos de 2,5 é substancialmente menor, devido ao menor peso dos discos;

O custo de cada um destes discos, está entre 400 e 600 dólares. Acredite ou não, este é um preço muito razoável. Não faz nem 2 anos e tive que comprar discos de 146GB em Fibre Channel e 10Krpm por nada menos que R$ 15.000,00 cada um. Então, considerando que estamos olhando para um hardware de ponta, podemos esperar que em 2 anos estes discos se tornar opções standard.

Controladoras de discos

Bom, para encerrar a questão do hardware, você tem que pensar com cuidado na sua controladora de discos. Assim como quem vê processador não vê chipset, quem vê discos, não vê controladora de discos. Não adianta ter vários discos de 15Krpm SAS e uma controladora standard. Uma boa controladora faz toda a diferença. Há quem diga que com uma controladora ruim, vale mais a pena utilizar RAID por software do que aproveitar o RAID nativo da controladora. Além disso, a quantidade de discos que a controladora suporta, as modalidades de RAID, a quantidade de buffer cache disponível, a presença de bateria, tudo isso influencia muito. Uma controladora mais simples pode ter seu preço em torno dos 250 dólares e uma mais poderosa pode ultrapassar os 1000. Mas você deve reservar uma parte do orçamento para alguns acessórios para a sua controladora como cabos, pentes de memória e baterias externas que podem fazer você chegar facilmente aos 2 mil dólares.

Apesar de haverem controladoras que suportam até 128 discos SAS no mercado, pode ser que alocar esta quantidade de discos dentro do seu servidor não seja tão simples. Se você chegar neste ponto, pode ser interessante pensar num storage externo. Há diversos modelos de storage, escaláveis para quantidades consideráveis de discos. Você pode começar com uma gaveta contendo uma dezena de discos e ir adicionando novas gavetas e até mesmo racks chegando aos milhares de discos. Há outras vantagens consideráveis no uso de um storage externo. Você pode compartilhar o mesmo storage com mais de um servidor e montar uma SAN (Storage Area Network), o que pode ser muito interessante, para migrar dados de produção para teste, usar replicação ou até técnicas de cluster. A performance também é um fator fundamental. Eles chegam a ter vários GB de cache e boas baterias internas, o que lhe permite utilizar o cache de gravação com segurança. Além disso, os storages costumam vender alguns softwares (proprietários até a alma) que ativam capacidades especiais do hardware como tuning de discos, monitoramento avançado e o meu preferido: snapshots! O custos de soluções de médio porte de storage despencaram. Acredite ou não, já é possível contar com uma estrutura de storage completa com menos de R$ 50 mil. Vale a pena ressaltar, que para bancos de dados, os storages iSCSI embora mais baratos, não são recomendados, pois até o momento apresentam um desempenho inferior ao fibre channel. Acha muito? Você não tem idéia de o quanto os preços já caíram. Não faz muito tempo que um storage básico com Fibre Channel e 1TB não saia por menos de uns R$200 mil. É claro que esta conta pode chegar na casa dos milhões muito rápido. É só colocar milhares de discos na conta. Você acha que utilizar milhares de discos é um exagero? Convido você a olhar os testes de performance do TPC… o teste mais simples, não usam menos de 100 discos. Realmente vale a pena olhar os testes, pois além do resultado de performance, eles detalham todos os custos de hardware e software, incluindo suporte para 3 anos.

Tipos de arquivos

Agora vem uma parte realmente importante que é entender os diferentes tipos de informação que serão gravados no seu servidor. Mesmo se você tem um pequeno servidor de banco de dados com apenas dois discos (se você só tem 1, bem… sinto muito), isso é fundamental antes de sair particionando os discos.

Vejamos como podemos classifica-los:

• Sistema Operacional

Estamos imaginando obviamente que você está criando um servidor dedicado. Servidores de bancos de dados são serviços que gostam de exclusividade, principalmente no acesso a disco. Então, se for inevitável ter que colocar mais um serviço no mesmo servidor, que este não seja um servidor de e-mail ou arquivos. Nada que vá disputar o acesso aos discos com o banco de dados. De toda a forma a idéia é que o SO não costuma ocupar muito espaço, não é um gargalo de desempenho e não compõe uma parte crítica dos dados uma vez que ele pode sempre ser reinstalado. Claro que perder o SO, vai lhe causar um bom tempo com o servidor fora do ar até que ele seja reinstalado, portanto algum tipo de proteção deve existir, como um RAID 1, 5, 6 ou 10. Em geral, uma partição com alguns GB devem ser suficientes para todo o SO, e executáveis do SGDB. Se estiver usando Linux, não esqueça de guardar uma pequena partição para o kernel (algo como 100 ou 200 MB).

• Swap

O Linux e outros SOs utilizam uma parte do disco para servir de memória virtual paginada em caso de falta de memória. Em tese isto nunca deve acontecer e você deve ter memória suficiente para evitar este tipo de situação na maior parte do tempo. No entanto, se acontecer o Swap deve estar lá para evitar que todos os processos se percam repentinamente. O Swap deve sempre possuir sua própria partição que em geral possui o mesmo tamanho da sua memória RAM. Se você tiver mais de 4GB, pode pensar em usar um pouco menos de isso, chegando a 50% da RAM a partir dos 8GB para cima.

• Logs

O seu servidor gera uma série de logs sobre o que acontece no banco de dados e no servidor. A quantidade de logs gerados variam muito conforme a configuração do banco de dados e demais serviços. Em geral a configuração standard do SO é suficiente para a maioria dos casos enquanto as configurações do banco de dados devem ser estudadas caso a caso. Você deve determinar onde colocar seus logs, o que logar, quando logar, etc. Uma análise de performance num ambiente de produção pode gerar alguns GB de logs em poucos minutos. Guardar uma partição para estes logs é importante. Os logs devem ficar sob controle e não devem ocupar um espaço maior do que o previsto. É comum executar faxinas periódicas nos logs. Não esqueça de configurar os logs do PostgreSQL.

• Tablespace padrão.

O tablespace padrão é aquele utilizado para guardar o dicionário de dados. Este tablespace é crítico. Ele ocupa pouco espaço pois só consiste nos metadados a respeito dos demais objetos do banco. Se você perder o dicionário de dados, não conseguirá acessar mais nenhum objeto do banco, tornando-o completamente inútil. Em termos de segurança, este é um tablespace que deve ser muito bem protegido. Se você tiver muita memória, provavelmente o dicionário do sistema deve estar quase sempre no buffer tornando o desempenho uma questão secundária. O problema que se encontra com freqüência é que as pessoas não criam novos tablespaces para uso dos objetos normais das aplicações. Misturar ambos não é uma boa idéia. O espaço ocupado pelo tablespace default costuma ser mínimo, se ele realmente contiver apenas o dicionário de dados. A não ser que você tenha uma quantidade muito grande de objetos, particularmente visões e funções, destinar 1GB para este tablespace costuma ser mais que o suficiente.

• Tablespace temporário

O tablespace temporário não tem impacto em termos de segurança para as informações. As informações lá armazenadas são apenas uma área de trabalho para operações intermediárias e tabelas temporárias. Em tese, estas informações jamais precisariam ser guardadas em disco, porém operações pesadas como a ordenação de uma tabela muito grande podem exigir muito deste tablespace. Particularmente os DataWarehouse, Data Marts e relatórios pesados exigem um volume considerável em disco. O desemprenho das consultas pesadas podem fazer deste tablespace algo crítico também. Vale a pena conhecer o perfil de carga da sua aplicação para saber se vale a pena investir em uma abordagem específica para este tablespace. Por padrão o tablespace temporário fica junto com o dicionario de dados, mas você pode setar a partir da versão 8.3 do PostgreSQL o parâmetro temp_tablespaces para escolher um local diferente.

• Outros tablespaces

As informações do banco de dados ficam armazenadas ao fim e ao cabo nos seus arquivos de dados que devem possuir seus próprios tablespaces. Um critério para dividir os tablespaces é usar um par de tablespaces para tabelas e outro para índices em cada aplicações. Apesar de não ser mais comum dividir índices e tabelas em discos distintos, isto pode lhe ajudar muito em termos administrativos, resolução e recuperação de desastres. Além disso, você pode fazer ajustes de desempenhos mais agressivos nos índices, uma vez que eles podem ser reconstruídos facilmente. No entanto, alguns objetos muito grandes podem exigir particionamento. Os benefícios do particionamento de tabelas e índices se fazem mais presentes quando colocamos cada partição em um tablespace distinto que por duas vez devem estar em discos distintos. Outra questão é o tipo de uso do tablespace de acordo com o perfil de operações SQL executadas sobre seus objetos. Vou deixar aqui classificados 5 tipos básicos:

Tablespace para OLTP: é o tablespace mais crítico em termos de desempenho e segurança. Isto ocorre pois ele sofre um grande volume de pequenas gravações concorrentes. As gravações concorrentes são o verdadeiro inferno em termos de desempenho. Por outro lado, exigem técnicas mais sofisticadas para evitar a perda de dados. Tablespaces de aplicações com forte carga OLTP devem estar em discos distintos dos demais pois precisam de atenção especial.

Tablespace para BI: as aplicações de BI são completamente diferentes. Elas sofrem em geral grandes cargas periódicas de dados e não sofrem atualizações constantes. Ao contrario da carga em OLTP, em BI temos poucos usuários simultâneos e quase nenhuma operação de gravação. O grande desafio é conseguir suportar consultas complexas que envolvem um grande volume de dados. Aqui o desempenho também é crucial, pois uma única consulta pode facilmente levar dias para se concluir. A segurança não é em geral um ponto crucial, visto que os dados podem ser reconstruídos a partir de cargas externas.

Tablespace para Web: as aplicações web tradicionais são aquelas que possuem um volume absurdo de conexões simultâneas em operações predominantemente de pequenas leituras. Devido ao grande volume de acessos que um site na web pode ter, o desempenho é novamente um fator crucial. Se por um lado o baixo número de gravações costuma minimizar a chance de perda de dados, a indisponibilidade costuma ser um problema muito sério.

Tablespace Histórico: algumas aplicações ou parte delas, carregam um volume enorme de informações históricas e quase sempre estáticas. Estes dados precisam estar on-line para fins de auditoria ou consultas esporádicas. Este é um raro caso onde o desempenho e a segurança não são tão importantes. Aqui é um dos locais onde, tomando os devidos cuidados, podemos economizar um pouco nos discos.

• Logs de transação

Os logs de transação, no PostgreSQL, são conhecidos como WAL ou Write Ahead Log. Estes arquivos são arquivos de tamanho fixo utilizados para assegurar a segurança dos dados em caso de queda de energia. Sem eles a segurança do banco de dados seria tragicamente comprometida. Os logs são então alvo de enorme preocupação em termos de segurança contra a perda de dados e ao mesmo tempo tem uma influência enorme no desempenho. Para se ter uma idéia de como o WAL é importante, em um artigo do Indiano Jignesh Hah (veja os comentários também…) ele demonstra que numa aplicação OLTP pesada com cerca de 3000 transações por segundo, seriam necessários 25 discos para atingir o IOPS necessário para não ter uma grande degradação de performance. Se adicionarmos o espelhamento que é praticamente obrigatório nestes casos estaremos falando de 50 discos só para o WAL! Veja que como as gravações no WAL são seqüenciais, deixa-los isolados em discos vai garantir uma maior velocidade, mas isto se não houver nenhum outro acesso em paralelo naquele disco ou RAID.

• Arquivamento dos logs de transação

O archive consiste na cópia dos logs de transação que são reciclados. Fazer um backup do WAL é considerado obrigatório em ambientes de produção. Sem ele, qualquer arquivo de dados corrompido implicaria obrigatoriamente em perda de dados. O archive junto com o backup on-line dos tablespaces permitem o uso de uma técnica avançadas para recuperações de desastres conhecida como “Point In Time Recovery”. Enquanto o WAL precisa de um pouco espaço de armazenamento, é de praxe deixar em disco algo em torno de uma semana de backups do WAL, o que pode significar vários GB em disco de acordo com o volume de atualizações que o banco sofre.

• Backup físico

A não ser em caso de bases pequenas com alguns poucos GB, o backup físico é praticamente obrigatório. Isto significa que você tem que ter espaço em disco (local ou remoto) para armazenar uma cópia de todos os seus datafiles. As exigências de desempenho aqui vão depender da sua janela de backup. Se você estiver na graça de possuir um storage com software de snapshot, então sua vida se tornará muito mais simples aqui. Lembre-se que os backups em disco não devem jamais substituir os backups em fita. Em último caso, fique apenas com os backups em fita. Mas ter uma cópia do último backup físico em disco, pode acelerar muito o processo de recuperação de desastres.

• Backup lógico

O backup lógico não é uma estratégia recomendada para bases medias e grandes. Mesmo assim, você deve pensar em reservar um espaço em disco para os backups lógicos. O motivo é que a movimentação de dados entre as bases de produção, homologação e testes costumam ser frequentes. Seria decepcionante perceber que você não tem espaço em disco para isso. Aqui, o desempenho e a segurança não costumam ser algo fundamental.

Particionamento

É possível utilizar apenas uma partição para todo o servidor? Sim. Isto é bom? Não. Existem quatro bons motivos para você separar diferentes tipos de arquivos em diferentes partições:

1. Segurança contra perda de dados: se você tiver os dados do seu servidor em um grupo de discos, o WAL e seus arquivamentos em outro e possuir um backup físico em algum lugar, a perda completa do grupo de discos onde os tablespaces estão não implicarão em perda de dados. Separar os tablespaces do WAL e seus archives e possuir um backup físico em algum outro lugar (em outro servidor, outro disco local, outra fita, etc) são uma política muito segura para se evitar a perda de dados e conseqüentemente a perda de emprego…
2. Segurança contra indisponibilidade: se você tiver apenas uma partição e um erro qualquer acontecer no servidor ou mesmo numa aplicação que acessa o banco de dados, ele pode começar a exigir repentinamente um montante enorme de espaço em disco até que ele fique completamente cheio. Se você tiver uma única partição no seu servidor, você terá não apenas o seu banco de dados travado, como o seu SO também. Separando os tipos de arquivos em partições distintas, você limita drasticamente o impacto deste tipo de situação;
3. Administração: Fica mais fácil detectar áreas que estão crescendo demais se elas estiverem guardadas em caixas separadas. Dividir os tipos de arquivos em diferentes partições permite que com um único comando no SO (um ‘df’ no caso do Linux) seja possível verificar como andam se comportando diferentes tipos de arquivos;
4. Desempenho: Se você separar diferentes tipos de arquivos em diferentes partições, poderá utilizar diferentes sistemas de arquivos em cada um deles. Além disso, discos, controladoras e sistemas de arquivos possuem diferentes configurações que podem ajudar a aumentar o desempenho em algumas áreas críticas.

Ter tipos de arquivos diferentes em partições diferentes, nem sempre significa utilizar discos ou grupos de discos em RAID distintos. Se você tiver apenas 2 discos, não será possível fazer muita coisa. Ainda assim, separar algumas coisas como: SO, logs, tablespace padrão, outros tablespaces, WAL, archives e backups em partições distintas, costuma fazer muito sentido. Um problema com as partições é que elas tem tamanho fixo, obrigando você a prever quanto espaço será necessário para cada partição. Em geral, prever isso costuma ser um dever do DBA, mas em bases novas isto pode ser mais difícil. Em todo caso, os storages e controladoras modernas permitem o uso de LUNs que mudam de tamanho dinamicamente. Se você não tiver acesso a este tipo de tecnologia, pode usar também o LVM que funciona muito bem, apesar que causar uma pouco de perda de desempenho no acesso a disco.

Como distribuir as partições nos discos existentes

Vamos imaginar aqui diferentes números de discos no servidor e possíveis configurações que poderiam ser utilizadas. Aqui estamos fazendo um chute grosseiro, você pode mudar um pouco as configurações dos discos e partições de acordo com algumas das dicas acima entre outras coisas, inclusive por exigências contratuais ou SLA.

• Um disco

Bom, esta é a pior situação que você pode encontrar pois não é possível montar um RAID. A sua segurança contra falhas de discos é nula e o seu desempenho também será pobre. Neste caso, você deve pelo menos adorar uma política de backups freqüentes para minimizar a possível perda de dados a qual você está sujeito. Tenha certeza de alertar sobre os riscos por escrito aos seus superiores.

Mesmo tendo apenas um disco, você deve ter ao menos ter as seguintes partições:

/boot para o kernel do linux (100MB a 200MB)

/ para o restante do SO (algo entre 5 e 10GB)

/var/log ou outro local destinado aos logs (algo entre 1 e 10 GB costumam ser valores razoáveis)

swap (o mesmo tamanho do tamanho da memória RAM)

/var/lib ou /postgres outro local destinado aos dados (cerca da metade do espaço em disco restante

/backup ou outro local para os backups lógicos e/ou físicos (o restante do espaço em disco)

• Dois discos

A não ser que você tenha dois discos de tamanhos diferentes, use RAID 1 e mantenha o esquema de particionamento descrito acima;

• Três discos

Se você se preocupa com disponibilidade, use um RAID 1 com dois discos e deixe o disco restante como hot spare. Se você está precisando desesperadamente de mais espaço em disco, você pode montar um RAID 1 com dois discos e utilizar o 3º disco ser RAID para guardar os seus backups

• Quatro discos

Se a sua prioridade for segurança, você pode montar dois RAIDs 1. No primeiro RAID 1 coloque o seu SO, os logs, o WAL, o archive e os backups físicos. No segundo RAID 1 coloque os tablespaces e os backups lógicos. Voucê também pode montar um RAID 1 com 2 discos, mais um disco de hot spare e utilizar o 4º disco para guardar seus backups.

Se a sua prioridade for desempenho, coloque tudo em um RAID 10 com os 4 discos.

• Cinco discos

Use dois RAIDs 1 ou um RAID 10 e deixe um disco de hot spare.

• Seis discos

Use a mesma configuração de 5 discos, mas reserve um disco só para backup lógico e/ou físico

• Sete discos

Um disco ficará para hot spare, as os 6 discos sobrando podem ser divididos em um RAID 1 com dois discos e um RAID 10 com 4 discos (opção recomendada para aumentar a segurança) ou montar um RAID 10 com 6 discos (opção recomendada para privilegiar o desempenho).

Você verá que com um maior número de discos você pode separar mais as coisas em pelo menos 3 grupos:

• Logs de transação e archives
• Datafiles
• Backups

Se você tiver algo como 15 ou mais discos, poderá começar a separar tablespaces em discos diferentes, optar ocasionalmente por um RAID 5 ou 6 para arquivos menos críticos e coisas do tipo. É claro que isso vai depender do seu conhecimento da aplicação, das suas exigências de performance e segurança e é claro… do seu bolso.

Tags: backup, Fibre Channel, IOPS, LVM, PostgreSQL, RAID, SAS, SCSI, security, storage, tablespace, tuning, WAL

Hoje recebi um e-mail de alguém me perguntando porque os testes dele com o pgbench variam tanto, mesmo usando os mesmos parâmetros todas as veses. Para quem não sabe o pgbench é um pequeno aplicativo que lhe ajuda a fazer medições de perfomance no banco de dados simulando um teste TPC-B. Ele é muito simples de se utilizar e permite realizar testes com diferentes volumes de dados, conexões simultâneas e transações por conexão. O pgbench NÃO SERVE para fazer tuning em servidores de produção, mas serve para ajudar medir a diferença entre diferentes hardwares, SOs, sistemas de arquivo, etc. No mínimo, com o pgbench você vai começar a aprender muito sobre performance no PostgreSQL, comparando seus resultados em diferentes cenários.

Mas, voltando ao nosso colega, vejamos os resultados que ele obteve:

TPS: 19
TPS: 23
TPS: 18
TPS: 25
TPS: 23
TPS: 29
TPS: 35
TPS: 17

Veja que de 17 para 35, a direrença é de mais de 100%. Realmente, não dá para desprezar uma diferença tão grande. Eu diria que de qualquer forma, apredi no laboratório de física que você tem que realizar a mesma experiência pelo menos umas 5 vezes. Além disso, se você encontra um resultado que está destoando demais dos outros, é melhor repetir o teste mais umas 5 vezes com cuidado redobrado e se apenas um valor destoar, você deve descarta-lo. Assim o seu resultado é uma média entre os testes considerados válidos (sem o resultado descartado). No caso de um instrumento de medida direta (como uma régua ou termômetro) é fácil saber qual é a precisão da sua medida (metade da menor divisão, repetia o professor todas em as aulas no laboratório). No nosso caso, temos que ficar com o dado estatístico das medições considerando a variação dos resultados obtidos.

Veja, se você faz um ajuste na configuração do PostgreSQL e tem um aumento de desempenho de 2%, mas as suas amostras tem uma margem de erro (em relação a média) de 10%, você pode se questionar se realmente pode afirmar alguma coisa. Bom, mas se você tem 100% de variação… alguma coisa está realmente errada.

O primeiro detalhe sobre o nosso colega é que ele usa o PostgreSQL em Windows. Veja… usar o PostgreSQL em Windows funciona… mas fazer tuning em Windows não é tão eficiente. Não sou um profundo conhecedor do Windows, mas que eu saiba você tem muitas opções de ajustes de desempenho neste SO. O PostgreSQL, assim como outros grandes SGDBs, foram construídos para funcionar originalmente em sistemas operacionais Unix. Outro problema é que como o SO é uma caixa preta, você nunca sabe o que está rodando em paralelo exatamente e dificilmente tem controle sobre isso. Isto não quer dizer que não é possível ver o PostgreSQL rodando satisfatóriamente em Windows, significa que o Windows não é a opção número um de quem procura um SO robusto, confiável, seguro e rápido. Mas se você não está querendo levar o seu banco de dados ao limite, não há nada de errado em usar o Windows e ajustar o PostgreSQL para que ele tenha um desempenho melhor nele.

Vejamos alguns outros ítens que você deve se perguntar antes de avaliar os resultados:

1. Qual tipo de disco você usa? Os discos SATA são muito instáveis para testes, pois não conseguem manter um fluxo de dados em alta velocidade por muito tempo. Este não é um problema do disco físico em si e sim do protocolo do SATA. Usar discos SCSI ou SAS lhe trarão resultados mais confiáveis.
2. Você deixou os discos isolados para o banco? Deixou discos isolados para o Wall?? A questão aqui é saber se alguma outra aplicação pode estar competindo com o acesso aos discos.
3. Você tem certeza absoluta que não tem nenhuma outra aplicação rodando em segundo plano. O ideal é deixar uma instalação do SO o mais crua possível. O principio básico da experimentação científica é ter um ambiente controlado para que qualquer pessoa possa reproduzir exatamente os mesmos testes. Isto significa que você tem de documentar exatamente como o SO foi instalado, incluindo parâmetros de configuração.
4. Você tem que realizar testes mais longos para que ocorram checkpoints no meio. Se você parar para estudar o mecanismo de funcionamento interno do PostgreSQL, descobrirá que o momento em que o checkpoint ocorre há uma degradação de performance significativa. Realize testes que garantam a ocorrencia de pelo menos uns 10 checkpoints. Imagine testes que durem no mínimo uma hora cada.
5. Você precisa decidir como vai configurar o vacuum. Se usar o autovacuum, tem que utilizar testes longos para que a ocorrencia do autovacuum nas tabelas seja computado e ocorram um número de vacuuns semelhantes em cada testes.
6. O cache de memória é um ponto crítico. Cada vez que você roda um teste, uma parte dos dados fica em memória, seja o IPC, cache em userspace, kernespace, o cache da controladora de discos ou o cache dos discos em si. Resultado: para ter certeza que a memória está num estado idêntico entre os testes… reinicie o servidor entre cada testes. Após reiniciar o servidor, tenha o cuidado de realizar exatamente as mesmas operações na mesma órdem para minimizar as diferenças de quais dados entram no cache. Podem haver outras formas de controlar o cache do disco, mas eu só conheço esta.
7. Use uma quantidade gererosa de dados, usar menos de 1GB de dados dificilmente reproduz cenários realistas. A não ser que o seu alvo sejam bases realmente pequenas, é melhor fazer testes com diferentes tamanhos de bases. 1GB, 10GB e 100GB são um bom começo.
8. Se você pretende realizar os testes simulando uma grande quantidade de conexões, faça-o a partir de 1 ou mais clientes remotos e não a partir do servidor. Testes com 100, 200, 500, 1000 conexões simultâneas podem exigir uma estrutura considerável para os clientes. Você vai querer medir o impácto da rede no desempenho e ao mesmo tempo não vai querer que os clientes sejam um peso no desempenho do servidor, a não ser que a sua aplicação e o seu banco de dados fiquem no mesmo servidor. Se for esse o seu caso, prepare-se para um ajuste de desempenho bem mais complexo.

Antes de você achar que o PostgreSQL é um banco “instável”, “lento” ou pouco confiável, Recomendo enfáticamente que você estude mais sobre o funcionamento do PostgreSQL, realize testes em um SO Unixlike como Linux, Solaris e FreeBSD, e use outras ferramentas de testes como o DBT-2 e os testes do TPC como o TPC-C, TPC-E e TPC-H.

Em tempo, escrevi um pequeno texto para quem está começando: “12 dicas para aprender a ajustar a performance em bancos de dados“.

Tags: Database, performance, pgbench, PostgreSQL, tpc, tuning

ou “Zen e a arte do tuning em banco de dados”

Nada mais fácil do que reclamar do desempenho do banco de dados. Algumas aplicações que se comportavam bem por anos começam a se tornar lentas sem aviso prévio. Aplicações que tinham um excelente desempenho num banco de dados ficam exorbitantemente lento ao adotar outro fornecedor. É comum alguns desacreditarem completamente um fornecedor por não conseguir o desempenho esperado. Vejo pessoas pedindo ajuda, ficando perdidos no meio do caminho, desistindo e colocando a culpa no banco de dados. O fato é que muita gente acha que sabe como fazer ajustes de desempenho (também conhecido como tuning) em bancos de dados, mas poucos realmente o fazem. Eu aqui como aprendiz de feiticeiro resolvi deixar algumas dicas para quem pretende se enveredar nesta mistura de arte, ciência e bruxaria.

1 - Entre no espírito do tuning

A primeira lição para os os jovens padawans do tuning é ter paciência, humildade e persistência. Você não desvendará tudo de uma hora para outra. Os seus segredos serão revelados aos poucos. Mesmo que você disponha da melhor bibliografia sobre o assunto, você só aprenderá de fato com o tempo. Seja humilde, ouça os desenvolvedores, os administradores de sistemas e redes, escute DBAs mais experientes e menos experientes também. Nunca cometa o erro de achar que você já domina bem o assunto. Sempre há mais para se aprender e o conhecimento pode vir das fontes menos esperadas. Seja persistente, não desista facilmente. Achar o ajuste ideal pode levar meses até mesmo para um DBA experiente. Você deve realmente se concentrar no assunto e se dispor a gastar muito tempo nele. Nunca espere ou prometa resultados rápidos. Alguns ajustes podem levar alguns minutos e terem resultados fantásticos enquanto outros podem levar meses para atingir uma melhoria de 10%. Lembre-se que em alguns casos, 10% pode significar a economia de milhões de dólares.

2 - Seja um aprendiz que realmente aprende

Se você tem a intenção de aprender, esteja disposto a estudar e experimentar. Estudar não significa ler alguns tutoriais e sair realizando baterias de testes. Estudar não significa pegar o Date, Tanenbaun ou qualquer outro clássico e achar que irá absorver tudo e depois estará craque no assunto. Tuning é um daqueles assuntos que exigem conhecimento genuíno que só pode ser obtido através da fusão entre teoria e prática. Portanto, estamos falando um processo de vários ciclos de ação, reflexão e revolução. Outra forma de encarar a mesma coisa seria dizer que não importa se você fez doutorado em banco de dados ou se você trabalha a 20 anos como DBA. Importam as oportunidades que você teve de dissecar casos reais e descobrir causas concretas dos problemas de performance.

3 - Concentre-se na Lei do 80/20 dos bancos de dados

Por mais que os desenvolvedores reclamem do servidor de banco de dados, em 80% dos casos o problema está na aplicação e em 20% no SGDB. Não que a aplicação seja ruim em si, mas ela pode não usar o SGDB de forma eficiente. Existem várias formas de se obter os mesmos dados de forma ineficiente. Pior, uma consulta que funcionava bem num SGDB pode ter uma performance catastrófica em outro SGDB. Infelizmente isto pode ocorrer também com migrações para outra versão do mesmo SGDB. Mesmo assim, a culpa ainda não é do SGDB. A aplicação que tem (infelizmente) de adaptar às especificidades de cada fornecedor e cada versão.
Na verdade, se formos levar a questão de forma mais ponderada, a lei não seria 80/20, seria 99,9/0,01 . Isto ocorre por um motivo simples, ajustes de SQL e modelagem podem resultar em ganhos de performance da ordem de 10, 100 ou até 1000 vezes. Enquanto isso, ajustes no SO e SGDB tem ganhos da ordem de até 10 vezes. Portanto, antes de mais nada aprenda a modelar bem e conheça as minúcias do SQL do seu SGDB. Depois aprenda a analisar com profundidade os planos de execução e reescreva consultas complexas a partir deste tipo de análise.

4 - Concentre-se na Lei do 80/20 da informática

20% dos parâmetros de configuração do seu SGDB são utilizados em 80% do tempo. Aprenda a manejar bem estes parâmetros antes de mais nada. A maioria dos outros parâmetros são utilizados em ocasiões específicas e não tem um impacto tão forte no desempenho. Normalmente o tuning do SGDB começa por estes parâmentros mais importantes, os demais só são utilizados se você conhece especificidades da sua aplicação que sugerem o seu uso, caso contrário são deixados em seus valores padrão.

5 - Conheça o perfil das suas aplicações

A forma como a sua aplicação utiliza o seu SGDB é de suma importante para o DBA. Existem alguns padrões que lhe indicam caminhos já trilhados por outros. Sendo assim identificar o tipo de carga que a aplicação projeta sobre o banco de dados é muito importante. Aqui alguns tipos clássicos:

• OLTP ou On Line Trasactional Processing consiste na maior parte da carga das aplicações corporativas atuais. É caracterizado por um grande volume de pequenas transações conconrretes e alto volume de gravações. As cargas OLTP são as que tem o desempenho de disco mais crítico.
• BI ou Business Inteligence consistem num universo paralelo com diversas tecnologias como Data Mining, OLAP, Data Warehouse, Data Mart, Balanced Scored Card, etc. A questão é que quando falamos em BI, o banco de dados sempre acaba de um jeito ou de outro, tendo que suportar consultas enormes, com grande quantidade de dados e cálculos complexos. As cargas de BI exigem muita velocidade em leitura de disco, memória para ordenações e uso intenso do processador.
• Sites Web Dinâmicos: os sites dinâmicos são aqueles que armazenam o seu conteúdo num banco de dados. Desta forma um único acesso numa página web pode representar uma dúzia de pequenas leituras no banco de dados. As cargas de sites web são caracterizadas por um enorme número de conexões simultâneas realizando pequenas leituras.
• Operações em lote ou bath são cargas de trabalho intensas no banco de dados que podem durar várias horas para se completar e tem um grande impacto na performance. São comuns tanto em aplicações OLTP (cálculo de uma folha de pagamento, fechamento de ano fiscal, etc), como em BI (carga de grandes tabelas vindas de fontes externas). As cargas em lote sempre são alvos de estudos cuidadosos tem o potencial de crescer rapidamente em tempo de execução até inviabilizar os negócios da empresa.

É claro que uma única aplicação pode ter todas estas características ao mesmo tempo. É óbvio também que tem-se o hábito de abrigar várias aplicações no mesmo banco de dados, tornando tudo muito mais divertido…

6 - Monitore hoje, monitore sempre

Estar sempre atento a fatos notáveis no seu banco de dados são atitudes de valor inestimável para quem se preocupa com desempenho. Quem participa da equipe de desenvolvimento tem sempre a oportunidade de ser mais proativo e detectar possíveis problemas antes deles ocorrerem. Mas quem cuida de um banco de dados já em produção acaba sendo mais reativo. É claro que se você conhece bem o seu banco de dados, você sabe em que momentos o desempenho se torna crítico e quando não. Ter isso bem documentado é fundamental. Você pode saber que uma determinada rotina demora normalmente 2 horas para ser executada. Um dia esta rotina começa a demorar 3 ou 4 horas e você quer saber o porquê. Se você tiver documentado o perfil da carga quando tudo funcionava bem, você poderá comparar isso com a nova situação e detectar rapidamente o que realmente mudou. Se você não tiver isto documentado, será muito mais difícil de saber porque o tempo de execução aumentou.

7 - Crie suas próprias métricas e guarde-as com cuidado

É muito fácil coletar zilhões de estatísticas através do SO, SGDB ou até mesmo através dea aplicação. No entanto elas não tem muito valor se você não souber o que elas realmente significam e se não puder inferir uma estatística a um dado evento. De nada adianta saber o volume de leituras do seu disco num dado momento. No entanto saber quantas leituras em disco uma determinada transação provoca, é muito mais útil. Conheça as estatísticas disponíveis. Saiba como extraí-las através das ferramentas disponíveis, saiba como extrair estas informações do forma a torna-las relevantes e saiba o que elas realmente significam. Para isto é preciso criar pequenos programas que gerem cargas padronizadas no seu banco de dados.

Quanto mais próxima a carga gerada se assemelhar da sua aplicação, maior será o valor da sua métrica. Há programas sofisticados que são capazes de gerar cargas idênticas a de um ambiente de produção. Estes sistemas simulam cargas concorrentes e até mesmo criam robôs que utilizam as suas aplicações como se fossem usuários normais. Como é possível imaginar, testes que simulam uma carga de stress muito próxima da realidade tem um custo exorbitante. Há ferramentas intermediárias que geram cargas como o TPC-H ou TPC-C que podem ser muito interessantes para medir a capacidade do servidor para gargas genéricas.

8 - Saia do geral e vá para o específico

A maioria dos SGDBs permite que você realize uma configuração geral do banco de dados para o uso cotidiano e uma configuração específica para situações especiais. É comum você ter uma carga específica que possui um perfil diferenciado das demais. Este tipo de operação pode receber uma configuração específica. Você pode fazer com que todo o banco de dados assuma uma determinada configuração em um determinado momento, pode isolar isso para um usuário específico, para uma sessão específica ou até para uma transação específica. Apesar de ser trabalhoso, operações em lote, grandes relatórios e outras cargas mais pesadas se beneficiam muito deste tipo de atenção do DBA. Outra questão a se analisar sempre é a de evitar ao máximo a concorrência junto a este tipo de operação agendando sempre que possível para um horário de menor demanda.

9 - Tenha rigor científico

Apesar de todo o ar de mistério e magia em torno do tuning, a melhor forma de você saber o que está fazendo é utilizar do rigor científico. Uma das premissas da ciência é a de que você só tem um experimento válido se puder reproduzi-lo. Isto significa que não adianta rodar uma determinada carga num banco de dados em produção para ver como ele se comporta. No ambiente em produção, há outras pessoas agindo sobre ele de forma que você nunca conseguirá reproduzir exatamente as mesmas condições de teste. O tamanho das tabelas, índices, estatísticas tem de ser todos idênticos. Não preciso dizer que o servidor tem que ter o mesmo hardware, o mesmo software e exatamente a mesma configuração, para que o teste seja válido.

Outra coisa importante e que dá trabalho é a entediante tarefa de lidar com apenas uma variável por vez. É comum alguém querer alterar diversas coisas de uma vez só para depois testar o seu impacto sobre a performance. Você nunca vai saber qual das suas alterações ajudou e qual atrapalhou na performance final se fizer assim. Há vezes em que se chega numa configuração muito boa assim. No entanto você nunca tem o conhecimento claro sobre a influência de cada variável. Assim, o êxito pode se transformar em fracasso miserável quando aplicado em outra situação.

10 - Saiba gerar e analisar métricas manualmente

Os bancos de dados proprietários como o Oracle e o DB2 levam uma enorme vantagem (talvez a mais importante delas) sobre os livres no que diz respeito a ferramentas de monitoramento, gerenciamento e autotuning. São recursos poderosos que coletam métricas pré-determinadas, fazem análises e recomendações. Estas ferramentas são excelentes para resolver problemas comuns do dia-a-dia. Em empresas de pequeno e médio porte, estas ferramentas podem diminuir bastante a dependência do DBA para as tarefas mais cotidianas. Mas existem 2 problemas intrínsecos a este tipo de ajuda:

• Você aprende menos, uma vez que se acomoda com os resultados já enlatados pela sua ferramenta. O uso constante dos conselheiros (ou ‘advisors’), assistentes (ou ‘wizards’) e outras tecnologias no estilo nnf (next, next, finish) embrutecem muito o profissional de informática que deixa de entender completamente o que se passa de fato nos bastidores do SGDB. Veja, não é porque existe calculadora que as pessoas deixaram de aprender a fazer as contas na mão.
• A ferramenta pode errar. Nem sempre as recomendações da sua ferramenta serão as melhores. É impossível para quem desenvolve uma ferramenta deste tipo prever todas as situações possíveis. Além disso, a ferramenta nunca tem todas as informações relevantes ao negócio para poder fazer uma avaliação realmente segura. O ser humano ainda não pode ser substituído na sua capacidade de julgamento. Existem muitas ações que podem ser conveniente automatizadas, outras não. É por isso que a figura do “conselheiro” apenas aconselha, não decide. Um DBA experiente saberá quando o conselho é útil e quando não. Mas para isso você não pode ter se acomodado com o uso apenas da sua ferramenta automatizada.

11 - Torne-se um ninja em discos

10 entre 10 DBAs se preocupam com discos mais do que qualquer outro componente do hardware. Não se trata apenas de ter espaço de armazenamento para seus dados. Trata-se de desempenho. Os custos de uma boa solução de storage podem ser estratosféricos, com um custo de mais de R$ 30 mil num único disco. E não se surpreenda se ouvir falar em bancos de dados com milhares de discos. Então este é um universo que o DBA precisa dominar. SATA, SCSI, SAS, Fibre Channel, iSCSI, RAID e outras tecnologias devem ser bem conhecidas. Não basta saber quais tipos de RAID existem, é preciso testa-los, saber quais as diferenças quando implementados via software, por uma controladora local ou em um storage externo. Os sistemas de arquivo também são motivos de intermináveis discussões. Conhecer as suas diferenças, seus parâmetros e seu desempenho e estabilidade são obrigações do DBA. Um detalhe capcioso aqui é que ferramentas de benchmarks para discos e sistemas de arquivo costumam ser de pouca utilidade para o DBA. A carga que estas ferramentas criam nos discos dificilmente equivale a carga que um banco de dados cria na prática. Assim, a melhor forma de testa-los, continua sendo através de programas que gerem carga diretamente no banco de dados. Baseie as suas métricas de disco neste tipo de teste.

12 - Não troque segurança por desempenho

É muito fácil conseguir aumentar o desempenho de um banco de dados abrindo mão da segurança. Lembre-se que as pessoas utilizam bancos de dados mais pela sua confiabilidade e versatilidade do que pelo seu desempenho. Rotinas de backup, tolerância a falhas, garantia de ACID e outras questões não podem ser jogadas pela janela de uma hora para outra, a não ser que você se permita ser jogado pela janela quando as coisas derem errado. Existem parâmetros no SO, no SGDB e configurações de hardware que fazem o seu SGDB decolar, mas o tornam muito vulnerável ao menor problema que acontecer.

É fundamental conhecer bem os mecanismos de logs de transação e rollback. Ajustes nestes mecanismos tem grande impacto nas operações de gravação. Ao mesmo tempo, qualquer falha nesta área compromete definitivamente a integridade do banco de dados.

Tags: Database, performance, tuning

Segue abaixo a tradução do texto do Josh Berkus (desenvolvedor do PostgreSQL). Este texto é um bom ponto de partida para quem está aprendendo sobre tuning no PostgreSQL 8.0. Espero em breve atualizar o artigo para as versões 8.1 e 8.2.

Tradução livre do texto: “PostgreSQL 8.0 Performance Checklist” Publicado por Josh Berkus em 12/01/2005 em http://www.powerpostgresql.com/PerfList

Copyright (c) 2005 by Josh Berkus and Joe Conway. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/).

Aqui está um conjunto de regras para configurar seu servidor PostgreSQL 8.0 . Muito do que está abaixo é baseado em evidências ou testes de escalabilidade práticos; há muito sobre performance de bancos de dados que nós e a OSDL, ainda estamos trabalhando. Contudo, isto deve ser um inicio. Todas as informações abaixo são úteis a partir de 12 de janeiro de 2005 e serão atualizadas depois. Discussões sobre configurações abaixo superam as que eu realizei no General Bits.

Cinco Princípios de Hardware para Configurar o seu Servidor PostgreSQL

1. Discos > RAM > CPU

   Se você vai gastar dinheiro em um servidor PostgreSQL, gaste em arranjos de discos de alta performance e tenha processadores medianos e uma memória adequada. Se você tiver um pouco mais de dinheiro, adquira mais RAM. PostgreSQL, como outros SGDBs que suportam ACID, utilizam E/S muito intensamente e é raro uma aplicação utilizar mais a CPU do que a placa SCSI (com algumas exceções, claro). Isto se aplica tanto a pequenos como grandes servidores; obtenha uma CPU com custo baixo se isso permitir você comprar uma placa RAID de alta performance ou vários discos.

2. Mais unidades de discos == Melhor

   Tendo múltiplos discos, o PostgreSQL e a maioria dos sistemas operacionais irão paralelizar as requisições de leitura e gravação no banco de dados. Isto faz uma enorme diferença em sistemas transacionais, e uma significativa melhoria em aplicações onde o banco de dados inteiro não cabe na RAM. Com os tamanhos mínimos de discos (72GB) você será tentado a utilizar apenas um disco ou um único par espelhado em RAID 1; contudo, você verá que utilizando 4, 6 ou até 14 discos irá render um impulso na performance. Ah, e SCSI é ainda significativamente melhor em fluxo de dados em BD que um IDE ou mesmo um Serial ATA.

3. Separe o Log de Transações do Banco de Dados

   Assumindo que você já investiu dinheiro num arranjo com tamanho decente num conjunto de discos, existe um monde de opções mais inteligentes do que jogar tudo num único RAID. De inicio coloque o log de transações (pg_xlog) no seu próprio recurso de discos (um arranjo ou um disco), o que causa uma diferença de cerca de 12% na performance de bancos de dados com grande volume de gravações. Isto é especialmente vital em pequenos sistemas com discos SCSI ou IDE lentos: mesmo em um servidor com dois discos, você pode colocar o log de transações sobre o disco do sistema operacional e tirar algum benefício.

4. RAID 1+0/0+1 > RAID 5

   RAID 5 com 3 discos tem sido um desafortunado padrão entre vendedores de servidores econômicos. Isto possibilita a mais lenta configuração de discos possível para o PostgreSQL; você pode esperar pelo menos 50% a menos de velocidade nas consultas em relação ao obtido com discos SCSI normais. Por outro lado, foque em RAID 1 ou 1+0 para um conjunto de 2, 4 ou 6 discos. Acima de 6 discos, o RAID 5 começa a ter uma performance aceitável novamente, e a comparação tende a ser bem melhor com base na sua controladora individual. No entanto, o mais importante, usar uma placa RAID barata pode ser um risco; é sempre melhor usar RAID por software do que um incorporado numa placa Adaptec que vem com seu servidor.

5. Aplicações devem rodar bem junto

   Outro grande erro que eu vejo em muitas organizações e colocar o PostgreSQL em um servidor com várias outras aplicações competindo pelos mesmos recursos. O pior caso é colocar o PostgreSQL junto com outros SGDBs na mesma máquina; ambos bancos de dados irão lutar pela banda de acesso aos discos e o cache de disco do SO, e ambos vão ter uma performance pobre. Servidores de arquivo e programas de log de segurança também são ruins. O PostgreSQL pode compartilhar a mesma máquina com aplicações que utilizam principalmente CPU e RAM intensamente, como o Apache, garantindo que exista RAM suficiente.

Doze Ajustes que Você Irá Querer Fazer no Seu Arquivo PostgreSQL.Conf

Existem um monte de novas opções verdadeiramente assustadoras no arquivo PostgreSQL.conf. Mesmo as já familiares opções das 5 últimas versões mudaram de nomes e formato dos parâmetros. Elas tem a intenção de dar ao administrador de banco de dados mais controle, mas podem levar algum tempo para serem usados.

O que segue são configurações que a maioria dos DBAs vão querer alterar, focado no aumento de performance acima de qualquer outra coisa. Existem algumas poucas configurações que particularmente a maioria dos usuários não querem mexer, mas quem o fizer irá descobri-las indispensáveis. Para estes, vocês terão de aguardar pelo livro.

Lembre-se: as configurações no PostgreSQL.conf precisam ser descomentadas para fazerem efeito, mas recomentá-las não restaurará necessariamente o valor padrão!

Conexão

listen_addresses: Substitui as configurações tcp_ip e o virtual_hosts do 7.4. O padrão é localhost na maioria das instalações, habilitando apenas conexões pelo console. A maioria dos DBAs irá querer mudar isto para “*”, significando que todas as interfaces avaliáveis, após configurar as permissões em hba.conf apropriadamente, irão tornar o PostgreSQL acessível pela rede. Como uma melhoria sobre a versão anterior, o”localhost” permite conexões pela interface de “loopback”, 127.0.0.1, habilitando vários utilitários baseados em servidores web.

max_connections: exatamente como na versão anterior, isto precisa ser configurado para o atual número de conexões simultâneas que você espera precisar. Configurações altas vão requerer mais memória compartilhada (shared_buffers). Como o overhead por conexão, tanto do PostgreSQL como do SO do host podem ser bem altos, é importante utilizar um pool de conexões se você precisar servir um número grande de usuários. Por exemplo, 150 conexões ativas em um servidor Linux com um processador médio de 32 bits consumirá recursos significativos, e o limite deste hardware é de 600. Claro que um hardware mais robusto irá permitir mais conexões.

Memoria

shared_buffers: Como um lembrete: Este não é a memória total do com o qual o PostgreSQL irá trabalhar. Este é o bloco de memória dedicado ao PostgreSQL utilizado para as operações ativas, e deve ser a menor parte da RAM total na máquina, uma vez que o PostgreSQL usa o cache de disco também. Infelizmente, o montante exato de shared buffers requer um complexo cálculo do total de RAM, tamanho do banco de dados, número de conexões e complexidade das consultas. Assim, é melhor seguir algumas regras na alocação, e monitorar o servidor (particularmente as visões pg_statio) para determinar ajustes.
Em servidores dedicados, valores úteis costumas ficar entre 8MB e 400MB (entre 1000 e 50.000 para páginas de 8K). Fatores que aumentam a quantidade de shared buffers são grandes porções ativas do banco de dados, consultas grandes e complexas, grande número de conexões simultâneas, longos procedimentos e transações, maior quantidade de RAM disponível, CPUs mais rápidas ou em maior quantidade obviamente, outras aplicações na mesma máquina. Contrário a muitas expectativas, alocando, muita, demasiadamente shared_buffers pode até diminuir a performance, aumentando o tempo requerido para explora-la. Aqui estão alguns exemplos baseados em experiências e testes TPC em máquinas Linux:

• Laptop, processador Celeron, 384MB RAM, banco de dados de 25MB: 12MB/1500
• Servidor Athlon, 1GB RAM, banco de dados de 10GB para suporte a decisão: 120MB/15000
• Servidor Quad PIII, 4GB RAM, banco de dados de 40GB, com 150 conexões e processamento pesado de transações: 240MB/30000
• Servidor Quad Xeon, 8GB RAM, banco de dados de 200GB, com 300 conexões e processamento pesado de transações: 400MB/50000

Favor notar que incrementando shared_buffer, e alguns outros parâmetros de memória, vão requerer que você modifique o System V do seu sistema operacional. Veja a documentação principal do PostgreSQL
para instruções nisto.

work_mem: costuama ser chamado de sort_mem, mas foi renomeado uma vez que ele agora cobre ordenações, agregações e mais algumas operações. Esta memória não é compartilhada, sendo alocada para cada operação (uma a várias veses por consulta); esta configuração está aqui para colocar um teto na quantidade de memória que uma única operação ocupar antes de ser forçada para o disco. Este deve ser calculado dividindo a RAM disponível (depois das aplicações e do shared_buffers) pela expectativa de máximo de consultas concorrentes vezes o número de memória utilizada por conexão. Considerações devem ser tomadas sobre o montante de work_mem por consulta; processando grandes conjuntos de de dados requisitará mais. Bancos de dados de aplicações Web geralmente utilizam números baixos, com numerosas conexões mas consultas simples, 512K a 2048K geralmente é suficiente. Contrariamente, aplicações de apoio a decisão com suas consultas de 160 linhas e agregados de 10 milhões de linhas precisam de muito, chegando a 500MB em um servidor com muita memória. Para bancos de dados de uso misto, este parâmetro pode ser ajustado por conexão, em tempo de execução, nesta órdem, para dar mais RAM para consultas específicas.

maintenance_work_mem: formalmente chamada de vacuum_mem, esta quantidade de RAM é utilizada pelo PostgreSQL para o VACUUM, ANALYZE, CREATE INDEX, e adição de chaves extrangeiras. Você deve aumentar quanto maior forem suas tabelas do banco de dados e quanto mais memória RAM você tiver de reserva, para fazer estas operações o mais rápidas possível. Uma configuração com 50% a 75% da sua maior tabela ou índice em disco é uma boa regra, ou 32MB a 256MB onde isto não pode ser determinado.

Disco e WAL

checkpoint_segments: define o tamanho do cache de disco do log de transações para operações de escrita. Você pode ignorar isto na maioria dos bancos de dados web com a maioria das operações em leitura, mas para bancos de dados de processamento de transações ou para bancos de dados envolvendo grandes cargas de dados, o aumento dele é crítico para a performance. Dependendo do volume de dados, aumente ele para algo entre 12 e 256 segmentos, começando conservadoramente e aumentando se você ver mensagens de aviso no log. O espaço requerido no disco é igual a (checkpoint_segments * 2 + 1) * 16MB, então tenha certeza de ter espaço em disco suficiente (32 significa mais de 1GB).

max_fsm_pages: dimensiona o registro que rastreia as páginas de dados partialmente vazias para popular com novos dados; se configurado corretamente, torna o VACCUM mais rápido e remove a necessidade do VACUUM FULL ou REINDEX. Deve ser um pouco maior que o total de número páginas de dados que serão tocados por atualizações e remoções entre vacuums. Os dois modos de determinar este número são rodar o VACUUM VERBOSE ANALYZE, ou se estiver utilizando autovacuum (veja abaixo) configures este de acordo com o parâmetro -V como uma porcentagem do total de páginas de dados utilizado por seu banco de dados. fsm_pages requer muito pouco memória, então é melhor ser generoso aqui.

vacuum_cost_delay: Se você tiver tabelas grandes e um significativo montante de atividades de gravações concorrentes, você deve querer fazer uso deste novo recurso que diminui a carga de I/O do VACUUM sobre o custo de fazê-las mais longas. Como este é um novo recurso, é um complexo de 5 configurações dependentes para o qual nós temos apenas poucos testes de performance. Aumentando o vacuum_cost_delay para um valor não zero ativa este recurso; use um atrazo razoável, algo entre 50 e 200ms. Para um ajuste fino, aumente o vaccum_cost_page_hit e diminua o vacuum_cost_page_limit irá diminuir o impacto dos vacuums e tornará eles mais longos; em testes de Jan Wieck’s num teste de processamento de transações, um delay de 200, page_hit de 6 e limit de 100 diminuiu o impacto do vacuum em mais de 80% enquanto triplicou o tempo de execução dele.

Planejador de Consultas

Estas configurações permitem o planejador de consultas fazer estimativas mais precisas dos custos de operação e assim escolher o melhor plano de execução. Os dois valores de configurações para se preocupar são:

effective_cache_size: diz ao planejador de consultas o mais largo objeto do banco de dados que pode se esperar ser cacheado. Geralmente ele deve ser configurado em cerca de 2/3 da RAM, se estiver num servidor dedicado. Num servidor de uso misto, você deve estimar quanto de RAM e cache de disco outras aplicações estarão utilizando e subtrair eles.

random_page_cost: uma variável que estima o custo médio em buscas por páginas de dados indexados. Em máquinas mais rápidas, com arranjos de discos velozes ele deve ser reduzido para 3.0, 2.5 ou até mesmo 2.0. Contudo, se a porção ativa do seu banco de dados é muitas vezes maior que a sua RAM, você vai querer aumentar o fator de volta para o valor padrão de 4.0. Alternativamente, você pode basear seus ajustem na performance. Se o planejador injustamente a favor de buscas seqüenciais sobre buscas em índices, diminua-o. Se ele estiver utilizando índices lentos quando não deveria, aumente-o. Tenha certeza de testar uma variedade de consultas. Não abaixe ele para menos de 2.0; se isto parecer necessário, você precisa de ajustem em outras áreas, como as estatísticas do planejador.

Logging

log_destination: isto substitui o intuitivo a configuração syslog em verssões anteriores. Suas escolhas são usar o log administrativo do SO (syslog ou eventlog) ou usar um log separado para o PostgreSQL (stderr). O primeiro é melhor para monitorar o sistema; o último é melhor para encontrar problemas no banco de dados e para o tuning.

redirect_stderr: Se você decidir usr um log separado para o PostgreSQL, esta configuração permitirá registrar num arquivo utilizando uma ferramenta nativa do PostgreSQL ao invés do redirecionamento em linha de comando, permitindo a rotação do log. Ajuste para True, e então ajuste o log_diretory para dizer onde colocar os logs. A configuração padrão para o log_filename, log_reotation_size e log_rotation)age são bons para a maioria das pessoas.

Autovacuum e Você

Assim que você entra em produção no 8.0, você vai querer fazer um plano de manutenção incluindo VACUUMs e ANALYZEs. Se seus bancos de dados envolvem um fluxo contínuo de escrita de dados, mas não requer a maciças cargas e apagamentos de dados ou freqüentes reinícios, isto significa que você deve configurar o pg_autovacuum. Isto é melhor que agendar vaccuns porque:

• Tabelas sofrem o vaccum baseados nas suas atividades, excluindo tabelas que apenas sofrem leituras.
• A freqüência dos vaccums cresce automaticamente com o crescimento da atividade no banco de dados.
• É mais fácil calcular o mapa de espaço livre e evitar o inchaço do banco de dados.

Configurando o autovacuum requer a fácil compilação de um módulo do diretório contrib/pg_autovacuum da fonte do seu PostgreSQL (usuários Windows devem procurar o autovacuum incluído no pacote do instalador). Você liga as estatísticas de configuração detalhadas no README. Então você inicia o autovacuum depois de o PostgreSQL ser iniciado como um processo separado; ele será desligado automaticamente quando o PostgreSQL desligar.

As configurações padrões do autovacuum são muito conservadores, imagino, e são mais indicadas para bancos de dados muito pequenos. Eu geralmente uso algo mais agressivo como:

-D -v 400 -V 0.4 -a 100 -A 0.3

Isto irá rodar o vaccum nas tabelas após 400 linhas + 40% da tabela ser atualizada ou apagada e irá rodar o analyze após 100 linhas + 30% da tabelas sofres inserções, atualizações ou ser apagada. As configurações acima também me permitem configurar o meu max_fsm_pages para 50% das páginas de dados com a confiança de que este número não será subestimado gerando um inchaço no banco de dados. Nós atualmente estamos testando várias configurações na OSDL e teremos mais informações em breve.

Note que você também pode usar o autovacuum para configurar opções de atraso ao invés de configura-lo no PostgreSQL.conf. O atraso no Vaccum pode ser de vital importância em sistemas que tem tabelas e índices grandes; em último caso pode parar uma operação importante.

Existem infelizmente um par de limitações sérias para o autovacuum no 8.0 que serão eliminadas em versões futuras:

• Não tem memória de longa duração: autovacuum esquece toda a sua atividade quando você reinicia o banco de dados. Então se você reinicia regularmente, você deve realizar um VACUUM ANALYZE em todo o banco de dados imediatamente antes ou depois.
• Preste atenção em quanto o servidor está ocupado: há planos de checar a carga do servidor antes de realizar o vacuum, mas não é uma facilidade corrente. Então se você tem picos de carga extremos, o autovacuum não é para você.

Tags: Josh Berkus, performance, PostgreSQL, tuning