All posts by duarte

Raster Overviews

Overviews GDAL em modo Turbo

Tempo de leitura: 7 min

TLDR: Neste post discutimos formas de acelerar o processo de criação de overviews, e no fim usamos um script que reduz o tempo de processamento em 20%-50%. O script é apresentado abaixo e está no github.

Na visualização de rasters é obrigatório construir as overviews ou pirâmides, para conseguirmos uma visualização rápida.

As overviews são uma série de cópias do nosso raster com resoluções cada vez menores (pixeis maiores), e geralmente cada nível aplica uma redução de 50% na resolução. Por exemplo, numa resolução original de 0,30m/pixel, as overviews são imagens com resoluções de 0,60 – 1,20 – 2,40m/pixel e assim sucessivamente até que não faz sentido reduzir mais a imagem.

Overviews ou pirâmides permitem uma visualização rápida de rasters, através de imagens de resolução reduzida. (Obitdo em: https://eurogeographics.org/wp-content/uploads/2018/04/WCS-NLSS.pdf.)

Em geral, a construção destas pirâmides é feito com o comando gdaladdo, e é o processo mais moroso quando processamos grandes áreas. Nem a conversão com compressão, nem a união de muitos rasters leva tanto tempo.

Actualmente, com discos SSD rapidíssimos e memória super-abundante, e processadores multi-core, o comando gdaladdo que constrói overviews continua a usar apenas 1 core… por outro lado, é mais lento que outros comandos, como o gdal_translate.

Recentemente processei novos mosaicos para o Alentejo, desta vez com ortofotomapas com 0,30m de resolução, rgb+nir. E, claro, construir overviews foi uma tortura… mais de 8h para cada metade (dividi a área em 2 blocos este/oeste). O processador nunca passou dos 17% (i7 de 4 cores/8threads), e o disco SSD nunca passou de uns miseráveis 5MB/s (quando o disco é capaz de 1000MB/s). Muito frustrante…

O processo que uso consiste sempre em manter os ficheiros independentes, e criar um mosaico .vrt. Por hábito não crio mosaicos tif enormes. Este processo é descrito em artigos anteriores.

Depois de pesquisar online, vi 3 sugestões para melhorar o tempo de criar overviews:

Isto ensinou-me uma série de coisas novas:

  1. Os ficheiros .ovr são na verdade ficheiros TIFF multi-página (herança do tempo dos faxes!), onde um tiff é “colado” a outro dentro do mesmo ficheiro. Eu não sabia isto sobre os .ovr. Ou seja, cada resolução é um tiff, dentro do ovr, que é também um tiff (matrioska?).
  2. É possível juntar vários tiff num só tiff multi-página usando o comando “tiffcp tiff1 tiff2 tiffunido”.
  3. O OSGEO4W inclui uma versão “geo-activada” dos comandos tiff, mantendo as características SIG dos ficheiros.
  4. Podemos ter overviews de overviews, juntando a extensão .ovr ao ficheiro .ovr anterior, numa sucessão que funciona em gdal, qgis, e arcgis. Deve funcionar nos restantes programas, como geoserver, mapserver, etc.
Continue reading Overviews GDAL em modo Turbo

SentinelPT WMS Time Machine

Tempo de leitura: 9 min

Versão abreviada…

Podem aceder aqui a um motor de mosaicos de imagens Sentinel-2 RGB e IRG para Portugal, com serviço WMS, com suporte temporal… O serviço WMS está funcional, mas para usar em QGIS é preciso algumas definições (ler abaixo, muuuito abaixo).

http://sentinelpt.viasig.com/

Alguns avisos: isto é um projecto pessoal, de carolice, tem muitos defeitos, eu sei, que podem ou não vir a ser resolvidos… Estou muito interessado em ouvir sugestões, e para isso nada melhor que o twitter ou os comentários aqui no blog.

Se a carga for demasiada no servidor, os pedidos são “desacelerados”, por forma a manter o servidor equilibrado. Por favor, não usem scripts de download… Pretendo incluir a função de download em breve. Entretanto, se precisarem de alguma imagem é só dizer, eu farei os possíveis para responder atempadamente.

E pronto, agora quem tem curiosidade e paciência pode continuar a ler…

Continue reading SentinelPT WMS Time Machine

PostgreSQL – mover tablespaces

Tempo de leitura: 4 min

É totalmente desaconselhado criar tablespaces na directoria DATA do pgsql. Podem ver-se vários avisos e explicações na net:
https://hunleyd.github.io/posts/Where-Not-To-Put-Your-Tablespaces/

Este post resulta de eu ter cometido este erro há muito tempo atrás (v8.4) e só agora estar a pagar por ele…

Como funcionam os tablespaces no postgres?

Tablespaces em pgsql são pastas onde são colocados os ficheiros de dados, e a teoria é que permitem espalhar os dados em diferentes discos para equilibrar os acessos e o desempenho. Também dão flexibilidade para gerir falta de espaço em disco, p.e. colocando um tablespace noutro disco que tem espaço, e que receberá determinados dados (todos os novos dados, só algumas tabelas, etc.).
Esta divisão também pode ser feita quando temos só um disco, ficando a bd preparada para um cenário futuro com mais discos.

Continue reading PostgreSQL – mover tablespaces

PostgreSQL – autovacuum found orphan temp table

Tempo de leitura: 2 min

Quando o postgresql termina abruptamente de forma anormal, geralmente recupera sem problemas.
Mas recentemente sucedeu-me que no log apareciam milhares de mensagens deste tipo:

2019-01-24 13:31:39 GMT LOG:  autovacuum: found orphan temp table "pg_temp_56"."sde_logfile_data" in database "postgis"

Aparentemente estas mensagens são escritas pelo menos todos os segundos, o que degrada o desempenho e aumenta o tamanho dos logs.

Para resolver, basta apagar os schemas tablespaces problemáticos:

DROP SCHEMA pg_temp_56;

Estes schemas tablespaces “especiais” podem ser listados assim:

select relname,nspname from pg_class join pg_namespace on (relnamespace=
pg_namespace.oid) where pg_is_other_temp_schema(relnamespace);

E confirmando com as mensagens de log, podemos apagar apenas aqueles de que o autovacuum se queixa.

Ao procurar na web, esta queixa não é muito frequente, mas acontece [1]. E nas listas de mail do postgresql [2], vemos até um debate acesso entre os programadores do postgres sobre se continuam a debitar este n.º exagerado de mensagens ou se devem limitar ou eliminar mesmo as mensagens. A opção actual é jogar pelo seguro – manter, para que os responsáveis pela base de dados notem que algo se passa e se preocupem o suficiente para corrigir a situação.

Comigo funcionou…

Evitar conexões…

É conveniente apagar estes schemas tablespaces tendo a certeza de que não há conexões à bd… Para isso, basta editar o ficheiro pg_hba.conf de forma a permitir apenas conexões do localhost.

Devemos comentar as linhas que dão acesso à bd de outros endereços, e deixar ou incluir apenas as linhas que dão acesso ao localhost. Um exemplo seria:

#IPv4 local connections:
host all all 127.0.0.1/32 md5
#IPv6 local connections:
host all all ::1/128 md5
#INTRANET - comentado temporariamente
#host all all 192.168.0.0/16 md5
#host all all 10.10.0.0/16 md5

Reiniciamos o serviço do postgresql o que provocará o fecho de todas as conexões, e o assumir da nova configuração, impedindo conexões indesejadas. No meu caso, antes disto, parei o servidor web e o servidor de mapas. Só para ser simpático e não deixar aplicações em estados de erro…

Depois de apagar os schemas tablespaces, devemos reiniciar o serviço postgresql, e verificar se no log aparecem mais avisos deste tipo, porque o autovacuum é também iniciado. Se sim, apagamos os schemas tablespaces em erro.

Quando tudo estiver ok, revertemos o pg_hba.conf para permitir novamente conexões, e reiniciamos o serviço postgresql. Testamos uma aplicação qualquer para vermos se tudo está bem. Vamos para casa ter com a família…

[1] – https://www.postgresql.org/message-id/flat/51C9975D.1040508%40uib.cat
[2] – https://www.postgresql.org/message-id/flat/48F4599D.7010601%40enterprisedb.com

LXD – upgrades sem riscos

Tempo de leitura: 5 minEste artigo é o 2º da série sobre virtualização com LXD. O 1º artigo fez uma introdução rápida ao lxd.

Já tenho todas as minhas aplicações web instaladas em containers LXD separados, numa vps de 3gb ram e 4 vcores, baseada em kvm. Comprei na última black friday e custa-me 5€/mês. Quem estiver à procura de vps baratas recomendo verem aqui: https://lowendbox.com/.

Nesta altura, tenho 3 máquinas:

~$ lxc list
+------------+---------+----------------------+------+------------+-----------+
|    NAME    |  STATE  |         IPV4         | IPV6 |    TYPE    | SNAPSHOTS |
+------------+---------+----------------------+------+------------+-----------+
| dncplex    | RUNNING | 10.166.62.195 (eth0) |      | PERSISTENT | 0         |
+------------+---------+----------------------+------+------------+-----------+
| planetasig | RUNNING | 10.166.62.245 (eth0) |      | PERSISTENT | 0         |
+------------+---------+----------------------+------+------------+-----------+
| viasigwp   | RUNNING | 10.166.62.152 (eth0) |      | PERSISTENT | 0         |
+------------+---------+----------------------+------+------------+-----------+

A máquina “dncplex” é o meu servidor de música, com plex server e o fantástico MyMedia for Alexa! que permite aceder à minha biblioteca de música no meu Echo!

A “planetasig” é obviamente o PlanetaSIG, e a “viasigwp” é este mesmo blog.

Como tive sempre receio de upgrades de versões major no wordpress fui adiando o upgrade da v3 para a v4. E esta já vai na v4.9.5. Está mesmo na altura de fazer o upgrade à prova de falha.

Uma vez que uso o lxd, o plano é copiar o container para um novo, e fazer aí o upgrade. Se correr bem, paro o container antigo v3, e fico com o novo já com o wordpress v4. Se correr mal, apago e recomeço, ou desisto e fico na mesma… risco 0… Continue reading LXD – upgrades sem riscos

LXD o virtualizador ubuntu

Tempo de leitura: 8 minEste post é sobre o LXD, uma forma de criar “máquinas virtuais” que residem em directorias na nossa máquina, sem mais intermediários (hypervisors). Para quem usa docker podem ver mais info sobre o projecto e como se comparam os 2: https://www.ubuntu.com/containers/lxd.

Fica já a nota que o docker e o lxd são concorrentes, mas talvez sejam mais complementares. O docker isola componentes, o lxd isola sistemas operativos. Terão por isso vantagens e desvantagens muitas vezes simétricas. E ambos são similares na tecnologia de base que usam (lxc e chroot + cgroups). Basicamente, usam capacidades do kernel linux para isolar componentes (é por isso que só podemos “virtualizar” componentes linux e não windows ou mac). Na verdade, e para ser tecnicamente menos incorrecto, não se criam máquinas virtuais, mas sim containers. Mas para simplicidade, no resto do texto quando falo de containers ou VM’s é tudo o mesmo… containers.

Aquilo que me entusiasma no LXD é a simplicidade de uso, com muito poucos  comandos, e a facilidade de gerir sistemas que integram vários componentes, como geralmente acontece numa plataforma SIG (qgis, postgresql, geoserver, etc.). Como o LXD virtualiza um SO inteiro, é natural e fácil usá-lo para conter sistemas aplicacionais inteiros.

As máquinas LXD podem ser criadas em directorias no nosso servidor Ubuntu, e podem conter diversos sistemas operativos. E é muito fácil clonar, fazer snapshots, parar e iniciar estes contentores de SO. Já cópias de segurança obrigam a alguma ginástica, mas estão a trabalhar num método simplificado.

Também é fácil limitar os recursos usados por cada VM, quer na memória máxima, quer no processador (cores, % de tempo, etc.), e vários outros recursos. Podem ver info completa aqui: https://stgraber.org/2016/03/26/lxd-2-0-resource-control-412/.

A existência do LXD vem baixar a complexidade da virtualização baseada em containers, deixando de usar hypervisors como o KVM, OpenVZ, VMWare, VirtualBox, e HyperV.

Podemos instalar o Ubuntu directamente na máquina física, e criar VM’s usando comandos LXD. Os seus defensores indicam ganhos de desempenho, ou mais correctamente menos perda de desempenho, e por isso potencial maior densidade de VM’s. Não posso confirmar nem desmentir porque não testei nada disto. Mas parece-me algo lógico.

Só mais um detalhe – o LXD suporta nested virtualization, ou seja, dentro de uma VM Ubuntu podemos usá-lo para criar VM’s, que estão dentro da nossa VM inicial… confuso? Cuidado, que o OpenVZ não suporta lxd… portanto ao comprarem uma VPS assegurem-se que é baseada em KVM.

Nested Virtualization… whaaat? Continue reading LXD o virtualizador ubuntu

Medir o desempenho do PostGIS

Tempo de leitura: 6 minUma das formas de medir o desempenho do PostgreSQL no nosso servidor, é usar o pgbench, a ferramenta padrão incluída com a instalação do pgsql. Há tempos fiz uns testes de comparação de 2 servidores que publiquei aqui: http://blog.viasig.com/2014/08/medir-o-desempenho-do-postgresql/.

Ora, esses testes usam dados alfanuméricos e queries “normais”, de escrita e leitura, usando tabelas relacionadas. Ou seja, o pgbench tenta simular uma utilização usual do pgsql.

No nosso caso, SIGianos, a utilização usual não tem nada a haver – usamos dados espaciais e queries muito próprias. Este artigo mostra uma forma de medirmos o desempenho do PostGIS, usando também a ferramenta pgbench.

Uso “normal” de SIG

Quando um programa “normal”, não geográfico, consulta uma base de dados, em geral, obtém alguns registos, e pode até cruzá-los, para dar um resultado final. Provavelmente, apresenta uma tabela de resultados, paginados, com algumas colunas (menos de 10?). Um bom exemplo, é um programa de facturação ou de gestão de stocks. É este tipo de programas que o pgbench tenta simular.

Há uma enorme diferença para o uso que um programa de SIG faz de uma base de dados. O uso normal SIG é visualizar um mapa. E isso faz toda a diferença.

image

Este simples mapa de enquadramento usa 7 tabelas. A área visível usa um total de 618 registos (1+261+177+1+3+29+146). Se visualizarmos o país inteiro, a conta passa para 5841 registos. É muita informação para uma das operações mais básicas – pan e zoom.

Do ponto de vista da base de dados, o uso SIG é diferente:

  • Um mapa é, tipicamente, composto por diversos temas (facilmente mais de 10);
  • Cada tema é uma tabela espacial diferente na base de dados, logo em cada visualização vamos ler uma série de tabelas;
  • Cada tema/tabela pode ser lido na totalidade (não paginado) se visualizarmos toda a área do tema;
  • Cada tema/tabela pode ter aplicada uma selecção (filtro) logo de início com base nos atributos (e.g. para vermos apenas uma categoria de rios ou estradas);
  • Cada tema/tabela pode ainda ter aplicado um filtro espacial se estivermos a visualizar apenas uma área específica (ou seja, são apenas pedidos os dados relativos ao rectângulo visível no mapa);
  • Mas, principalmente, os dados geográficos são muitos mais “pesados” ou “gordos”: têm uma coluna que contém todos os vértices da geometria! (Cada vértice tem 2 números do tipo double, o que equivale a 2 colunas em dados alfanuméricos.)
  • Para agravar a coisa, os utilizadores nunca escolhem os campos que precisam para trabalhar, e assim quando abrem a tabela de atributos todos os campos são lidos.

Usar o pgbench para simular utilizadores SIG

Uma das capacidades do pgbench é que permite testar queries à base de dados feitas por nós, em vez de usar as pré-definidas. Basta criar um ficheiro sql que contém as nossas queries e passá-lo ao pgbench com o parâmetro –f. Continue reading Medir o desempenho do PostGIS

MapServer em Windows e IIS

Tempo de leitura: 4 minO MapServer é geralmente instalado com Apache, mesmo em Windows. Para este caso, basta um dos vários instaladores existentes, por exemplo, o OSGeo4W.

Mas, no meu caso e imagino muitos outros, como uso mais servidores Windows, precisei de instalar o MapServer de forma a que funcione com IIS. Para além disto, preciso também que o endereço web dos meus mapas não mostre sempre o ficheiro de configuração usado. É feio, e é um risco de segurança. Ninguém devia saber a estrutura das directorias no disco rígido do servidor.

MapServer como aplicação FastCGI – As melhores instruções

A parte inicial de configurar o IIS de forma a executar o MapServer é mais ou menos fácil de encontrar na net. Esta parte consiste em configurar o IIS de forma a considerar o executável mapserv.exe como sendo uma aplicação FastCGI. Isto é mais ou menos padrão nos IIS >7.0 (win7/win8/win2008/win2012). Este link explica bem como fazer isto, usando os ficheiros do MS4W:

https://github.com/mapserver/mapserver/wiki/Installing-Mapserver-under-IIS-7.n-with-FastCGI

Mas melhor ainda é uma instalação automática – sim existe! Preparada pelo nosso grande Tamas Szekeres:

http://www.gisinternals.com/query.html?content=filelist&file=release-1600-gdal-1-11-1-mapserver-6-4-1.zip

Nesta página escolham o ficheiro mapserver-6.4.1-1600-core.msi.

A minha instalação

Eu preferi fazer uma instalação manual, usando ficheiro zip do Tamas Szekeres contendo todo o software, em vez do .msi. Isto dá-me mais flexibilidade para encontrar a configuração que mais se ajusta às minhas necessidades.

Criei uma directoria wwwroot\MapServer, e descomprimi aqui o ficheiro zip. Este ficheiro contém apenas 2 directorias: bin e doc.

E, para facilitar a organização dos ficheiros map e daquilo que serão os serviços web, acrescentei mais 3 directorias: mapfiles, servicos, e tmp.

O aspecto final é este:

image

Ou seja, tudo o que pertence ao MapServer propriamente dito fica dentro da pasta “binarios”. Agora falta configurar o IIS para executar o mapserv.exe como aplicação FastCGI. A receita é curta e é feita na consola de gestão do IIS…

1) Dar permissões de escrita à pasta tmp.

Este passo é apenas necessário para permitir que o MapServer consiga criar ficheiros, o que apenas sucede em alguns cenários. Em princípio, se servirmos apenas WMS, WFS, não será necessário. Mas pelo sim, pelo não, mais vale configurar…

2) Permitir a execução de scripts na pasta MapServer.

Na pasta MapServer, abrir a funcionalidade “Handler Mappings” :

image

e abrir a acção “Edit Feature Permissions”. Nesta janela dar permissões de “Read”, “Script”:

image

3) Definir um documento default a apontar para o executável.

Mais tarde pode ser removido, mas para testar é muito útil. Nas definições básicas da pasta MapServer, escolher a funcionalidade “Default Document”, e escrever o caminho para o executável mapserv.exe (cuidado com as barras /):

image

4) Criar a aplicação FastCGIS para o MapServer.

Esta configuração é feita no nó principal do nosso site. Por isso, selecionamos o nó “Default web site” ou o nome que demos ao nosso site, a abrimos a funcionalidade “Handler Mappings”:

image

Aqui, clicamos na acção “Add Module Mapping” e definimos estas propriedades:

image

Ou seja, definimos que o executável mapserv.exe deve ser executado como uma aplicação FastCGI. Temos ainda de clicar no botão “Request Restrictions” e definir os “verbos” permitidos e o acesso necessário à aplicação:

imageimage

5) Último passo! Temos de definir as variáveis de ambiente que o MapServer necessita.

Estas variáveis estão todas escritas no ficheiro SDKShell.bat que está na pasta do MapServer. Estas variáveis têm de ser definidas ao nível da aplicação FastCGI, e o único sítio onde se pode fazer é ao nível do servidor IIS e não ao nível do site. Por isso, é preciso selecionar o nó raíz do IIS, e selecionar a opção “FastCGI Settings”:

image

Nesta janela, vemos a nossa aplicação FastCGI já criada. Podemos editar a nossa aplicação, e na janela de configuração clicamos na opção “Environment Variables”. Aqui temos de criar 4 variáveis:

image

As 4 variáveis de ambiente são:

  • PATH = C:\Inetpub\wwwroot\MapServer\binarios;C:\Inetpub\wwwroot\MapServer\binarios\gdal\python\osgeo;C:\Inetpub\wwwroot\MapServer\binarios\proj\apps;C:\Inetpub\wwwroot\MapServer\binarios\gdal\apps;C:\Inetpub\wwwroot\MapServer\binarios\ms\apps;C:\Inetpub\wwwroot\MapServer\binarios\gdal\csharp;C:\Inetpub\wwwroot\MapServer\binarios\ms\csharp;C:\Inetpub\wwwroot\MapServer\binarios\curl;%PATH%
  • GDAL_DATA = C:\Inetpub\wwwroot\MapServer\binarios\gdal-data
  • GDAL_DRIVER_PATH = C:\Inetpub\wwwroot\MapServer\binarios\gdal\plugins
  • PROJ_LIB = C:/Inetpub/wwwroot/MapServer/binarios/proj/share

E é tudo.

Depois desta configuração, os pedidos ao MapServer já devem funcionar:

http://localhost/MapServer

image

Parabéns – o MapServer está a funcionar. A partir daqui o uso é o normal. Podemos indicar o mapa que queremos usando o parâmetro mode=map&map=ficheiro. Por exemplo:

image

Agora, a questão é conseguir ter endereços simpáticos, que não mostrem o nome e caminho do ficheiro de configuração… o que queremos são endereços do tipo:

Mas é opcional… já podemos publicar todos os ficheiros map que quisermos. Fica a promessa de outro artigo com esta configuração para breve.

Ah, e já agora – este processo pode-se usar para instalar o QGIS Server. É exactamente a mesma coisa.

Bons web services!

Medir o desempenho do PostgreSQL

Tempo de leitura: 6 minNão é todos os dias que temos a oportunidade de fazer um upgrade ao nosso velhinho servidor de PostGIS. Quando um servidor usado fica disponível ou, ainda melhor, quando recebemos uma máquina novinha em folha para instalar a nossa base de dados, queremos saber qual a melhoria de desempenho que vamos ter. Pelo menos eu quero Piscar de olho

Por outro lado, se vamos comprar um novo servidor temos de definir as características dentro do preço que podemos pagar. E convém ter uma orientação que nos ajude a perceber que tipo de desempenho podemos obter dentro desse orçamento.

Outra utilidade para este tipo de medição é perceber quais os melhores parâmetros de configuração do PostgreSQL para a nossa nova máquina. Podemos alterar os parâmetros e testar, vendo rapidamente qual a combinação de parâmetros que melhor desempenho consegue.

Este artigo mostra como medir o desempenho do PostgreSQL usando o comando standard para isso – o pgbench. Para outro post fica a proposta de um teste standard para medir o desempenho da componente geográfica – PostGIS – usando o pgbench com dados geográficos disponíveis publicamente. Isto permite que todos os utilizadores de PostGIS possam usar um teste padrão, tal como já existe para dados não-espaciais, e comparar diferentes servidores.

O ideal seria ter uma tabela online onde se pudessem comparar vários servidores, editada pelos utilizadores… isso é que era!

Os 2 servidores em confronto

Ao longo do artigo vão ser feitas comparações de desempenho entre 2 servidores praticamente iguais ao nível do hardware, onde apenas se altera o sistema de disco – o novo servidor promete muito melhor desempenho de disco. Mas há também diferenças no software – a versão do sistema operativo, e as versões do PostgreSQL e PostGIS são mais recentes e passam a 64bit. As características dos servidores são as seguintes:

Servidor CPU RAM Disco SO PostgreSQL PostGIS
velho Xeon E5420, 4cores 2,5GHz 12 GB SAN, 215GB Win 2003 x64 8.4.10, x32 1.4.2
novo Igual Igual SAN, 50GB Win 2008 x64 9.2.8, x64 2.1.1

Ambos os servidores têm a mesma configuração do PostgreSQL:

  • Shared Buffers: 512MB
  • Work Memory: 6MB
  • Effective Cache Size:  256MB

Usar o pgbench

O pgbench é uma ferramenta que vem incluída na instalação do PostgreSQL, e é usada para efectuar testes padronizados de desempenho transacional. Ou seja, é um teste que todos os utilizadores podem fazer e comparar entre si, já que o teste é sempre o mesmo, usando os mesmos dados. Como sempre, a documentação do PostgreSQL é excelente e o manual do pgbench também.

Como o pgbench envia comandos SQL para o servidor tentando levá-lo ao limite das suas capacidades, convém executá-lo a partir de outro computador ligado em rede, como por exemplo, o seu portátil ou desktop.

Para começar, temos de usar o pgbench para criar os dados necessários aos testes. Aqui temos de ter já uma ideia de quantas conexões vamos considerar. Isto depende do(s) processador(es) do nosso servidor. Quanto mais cores mais conexões simultâneas vamos conseguir executar em simultâneo. Podemos jogar pelo seguro e exagerar um pouco. Por exemplo, para o meu processador de 4 cores, vou iniciar os dados para 20 conexões simultâneas, embora saiba de antemão que são demasiadas (vou acabar por fazer os testes com apenas 12 conexões).

Para criar os dados, o pgbench precisa de saber o nome da base de dados a usar (que tem já existir). Se instalámos o PostGIS é provável que tenhamos criado uma bd com o nome “postgis” e é isso que vou usar nos exemplos. Também nos exemplos, o nome do servidor será “pgServer” e o utilizador será “userteste”.

Assim, para começar, executamos o pgbench no nosso computador (não no servidor) com o seguinte comando:

pgbench –i –s 20 –h pgServer –U userteste postgis

Este comando irá criar as tabelas do teste no schema do utilizador “userteste” e criará dados suficientes para testar 20 conexões simultâneas.

Em seguida vamos medir o desempenho do nosso servidor, medido em Transações por segundo, ou TPS.

O pgbench é muito completo, mas vamos simplificar e medir apenas 2 tipos de operações:

  • Transação típica, em que os registos são inseridos em tabelas relacionadas entre elas com chaves primárias e estrangeiras. Este é o desempenho mais típico de uma base de dados. É medida uma mistura de operações de escrita e leitura, com garantia de integridade.
  • Transação apenas de leitura, em que apenas se testa a componente de leitura da bd. Em princípio mede o valor máximo de TPS para o nosso servidor.

Vamos executar todos os testes durante 5 minutos. Assim, para testar a transação típica, vamos usar o comando seguinte:

pgbench –h pgServer –U userteste –c 12 –j 2 –T 300 postgis

A explicação do comando é a seguinte:

  • -c 12 => testar 12 conexões em simultâneo
  • -j 2 => cada conexão em 2 threads
  • -T 300 => testar durante 300 segundos, ou seja, 5 minutos

Já vamos ver os resultados mais à frente… para já temos de discutir como aparecem as 12 conexões…

Um servidor consegue responder a 1 só conexão com uma certa rapidez ou velocidade, medida em TPS. E queremos que seja o mais rápido possível. Ao aumentarmos o número de conexões, em principio, também vai aumentando o número de pedidos à base de dados que são processados por segundo pelo servidor. Até que estagna e começa a reduzir-se. Isto significa que o servidor tem um limite para processar pedidos em simultâneo. O seu máximo de TPS será obtido para um dado número de conexões. Este TPS máximo é um dos melhores indicadores de desempenho de um servidor de base de dados.

A questão que este comando coloca é: como vamos definir o n.º de conexões a testar? De forma geral, o servidor nunca deve ultrapassar os 85% de ocupação de CPU, porque acima deste valor começa a sentir-se contenção no acesso ao processador, ou seja, começa a formar-se uma fila de pedidos que aguardam pela disponibilidade do CPU para serem executados, e o próprio sistema operativo começa a atrapalhar-se. É este o nosso alvo – manter o CPU próximo dos 85% de uso.

Felizmente, podemos perceber rapidamente qual é o n.º de conexões que mantém o CPU perto dos 85%. Em geral, a partir daqui o valor de TPS não aumenta, podendo mesmo baixar.

Isto é muito fácil: basta executar alguns comandos pgbench rápidos, de 30 segundos (usando -T 30 em vez de –T 300), com cada vez mais conexões, e vigiar o CPU do servidor ao mesmo tempo que apontamos os resultados. Há um n.º de conexões que acaba por saturar o processador e partir do qual não se aumenta o desempenho. Por exemplo, podemos usar esta sequência de comandos:

pgbench –h pgServer –U userteste –c 6 –j 2 –T 30 postgis

pgbench –h pgServer –U userteste –c 8 –j 2 –T 30 postgis

pgbench –h pgServer –U userteste –c 10 –j 2 –T 30 postgis

pgbench –h pgServer –U userteste –c 12 –j 2 –T 30 postgis

pgbench –h pgServer –U userteste –c 14 –j 2 –T 30 postgis

No meu caso, as 12 conexões revelaram ser o ideal, o CPU nunca passou os 85%, e o desempenho foi o maior de todos. Já com 14 conexões, o desempenho começou a reduzir ligeiramente.

Resultados do pgbench

Os resultados do comando acima são os seguintes:

starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 20
query mode: simple
number of clients: 12
number of threads: 2
duration: 300 s
number of transactions actually processed: 537417
tps = 1791.328213 (including connections establishing)
tps = 1792.516930 (excluding connections establishing)

Qual a conclusão?

Este servidor conseguiu executar 537.417 transações “normais” do pgbench, em 5 minutos, o que dá um valor de 1.792 transações por segundo (TPS). Com este número já podemos comparar com outros servidores que tenham usado o pgbench.

Em seguida, medimos também o desempenho com transações apenas de leitura, usando um comando quase igual – apenas adicionamos o parâmetro –S:

pgbench –h pgServer –U userteste –c 12 –j 2 –T 300 –S postgis

Os resultados são os seguintes:

starting vacuum...end.
transaction type: SELECT only
scaling factor: 20
query mode: simple
number of clients: 12
number of threads: 2
duration: 300 s
number of transactions actually processed: 6844551
tps = 22815.432028 (including connections establishing)
tps = 22830.845226 (excluding connections establishing)

Ou seja, para queries apenas de leitura, conseguimos um TPS de 22.830, muito mais elevado, como é de esperar.

Assim, a comparação entre o servidor antigo e o novo fica com este aspecto:

Servidor Teste “normal” (TPS) Teste só leitura (TPS)
velho 590 20.944
novo 1.792 22.830

Boas notícias. Tudo aponta que o novo servidor vale a pena… +200% de desempenho em queries mistas, e +9% em queries de leitura apenas. Isto confirma a suspeita inicial: o sistema de discos do novo servidor é muitíssimo melhor, sendo o seu impacto terrivelmente visível no desempenho de escrita na base de dados, e ainda aumentando o desempenho de leitura em 9% (até porque grande parte das queries de leitura são efectuadas em memória). Claro que a introdução de uma nova versão de PostgreSQL também terá a sua influência, e neste caso é impossível determiná-la.

No próximo artigo vamos medir o desempenho do PostGIS, usando o pgbench com dados geográficos.

Até lá, bons desempenhos! Piscar de olho

Mosaicos com áreas transparentes

Tempo de leitura: 9 minNeste artigo regresso a um assunto já familiar neste blog – criar mosaicos de ortofotomapas usando o GDAL – (sim eu sei, outra vez?) mas como tenho andado às voltas com as áreas sem informação, que surgem negras nos mosaicos pensei em postar o que acabei por fazer. A solução final é usar máscaras, e não bandas alfa como habitual. Vamos ver como e porquê… assume-se já alguma familiaridade com o GDAL, mas pode sempre saltar as partes teóricas aborrecidas e ver os comandos usados no final do artigo 😉 Ler artigo completo