Ajustando a performance do PostgreSQL: o papel do random_page_cost
Fernando Laudares Camargos
Percona
Essa apresentação discute a influência do ajuste do random_page_cost na performance do PostgreSQL rodando em servidores modernos.
Enquanto alguns parâmetros de configuração do PostgreSQL têm um efeito direto na alocação de recursos, como o famoso shared_buffers, outros exercem influência indireta sobre o desempenho do banco de dados, como é o caso do random_page_cost.
Quando fazemos uma consulta ao banco, um componente importante do PostgreSQL chamado "planner" atua na construção de um plano de execução para a query enviada. Para tanto, ele avalia os possíveis caminhos a percorrer utilizando diferentes estratégias e calcula o custo prático para cada uma delas. Ou seja, o "esforço" necessário para localizar e retornar os dados solicitados pela consulta. Por fim, ele define aquele considerado mais eficiente, ou com o melhor custo-benefício.
Esse cálculo é puramente matemático e inclui tanto dados estatísticos, como a cardinalidade dos índices disponíveis, quanto outras variáveis utilizadas para dar dicas ("hints") ao planner e ajudá-lo a precificar o custo de acesso ou utilização de um dado recurso, como a quantidade de memória disponível no servidor para cache de dados (effective_cache_size, que, além do shared_buffers, considera a memória utilizada pelo file system cache também). Outro exemplo é o custo de acessar a página de dados seguinte àquela que está sendo ou acabou de ser lida no disco (seq_page_cost), comparado ao custo de acessar outra página qualquer no disco (random_page_cost).
Historicamente, essas duas variáveis foram acrescentadas ao PostgreSQL numa época em que os servidores ainda eram equipados com discos rígidos, nos quais o acesso sequencial é muitas vezes mais rápido do que o acesso aleatório (“random”). Todavia, até hoje, ainda que os discos rígidos tenham sido substituídos por discos que utilizam memória flash (sem partes móveis), onde o tempo de acesso a uma página qualquer é similar, o PostgreSQL continua vindo configurado com um valor padrão para o random_page_cost (4) quatro vezes maior do que o do seq_page_cost (1).
Afinal, quando se fala em ajustar a performance do PostgreSQL em servidores modernos, é correto equipararmos esses valores de custo, ou ainda existem situações onde a diferença existe e devemos informar o planner sobre ela?
Essa apresentação busca esclarecer o que é preciso medir para responder a essa pergunta e apresenta os resultados de alguns testes realizados com essa finalidade.
Ajustando a performance do PostgreSQL: o papel do random_page_cost
Fernando Laudares Camargos
Percona
Essa apresentação discute a influência do ajuste do random_page_cost na performance do PostgreSQL rodando em servidores modernos.
Enquanto alguns parâmetros de configuração do PostgreSQL têm um efeito direto na alocação de recursos, como o famoso shared_buffers, outros exercem influência indireta sobre o desempenho do banco de dados, como é o caso do random_page_cost.
Quando fazemos uma consulta ao banco, um componente importante do PostgreSQL chamado "planner" atua na construção de um plano de execução para a query enviada. Para tanto, ele avalia os possíveis caminhos a percorrer utilizando diferentes estratégias e calcula o custo prático para cada uma delas. Ou seja, o "esforço" necessário para localizar e retornar os dados solicitados pela consulta. Por fim, ele define aquele considerado mais eficiente, ou com o melhor custo-benefício.
Esse cálculo é puramente matemático e inclui tanto dados estatísticos, como a cardinalidade dos índices disponíveis, quanto outras variáveis utilizadas para dar dicas ("hints") ao planner e ajudá-lo a precificar o custo de acesso ou utilização de um dado recurso, como a quantidade de memória disponível no servidor para cache de dados (effective_cache_size, que, além do shared_buffers, considera a memória utilizada pelo file system cache também). Outro exemplo é o custo de acessar a página de dados seguinte àquela que está sendo ou acabou de ser lida no disco (seq_page_cost), comparado ao custo de acessar outra página qualquer no disco (random_page_cost).
Historicamente, essas duas variáveis foram acrescentadas ao PostgreSQL numa época em que os servidores ainda eram equipados com discos rígidos, nos quais o acesso sequencial é muitas vezes mais rápido do que o acesso aleatório (“random”). Todavia, até hoje, ainda que os discos rígidos tenham sido substituídos por discos que utilizam memória flash (sem partes móveis), onde o tempo de acesso a uma página qualquer é similar, o PostgreSQL continua vindo configurado com um valor padrão para o random_page_cost (4) quatro vezes maior do que o do seq_page_cost (1).
Afinal, quando se fala em ajustar a performance do PostgreSQL em servidores modernos, é correto equipararmos esses valores de custo, ou ainda existem situações onde a diferença existe e devemos informar o planner sobre ela?
Essa apresentação busca esclarecer o que é preciso medir para responder a essa pergunta e apresenta os resultados de alguns testes realizados com essa finalidade.