Além da lita dos 500 maiores supercomputadores do mundo disponibilizada pela top500, existe uma lista organizada pelo Centro de Pesquisa em Computação da Universidade Estadual de Lomonosov em Moscovo e o Centro Conjunto de Supercomputadores da Academia Russa da Ciência que em Abril deste ano teve a sua 8ª edição. A lista em russo está aqui, e uma tradução do Google pode ser encontrada aqui.
Da análise desta lista, temos alguns dados curiosos:
- As primeiras 5 posições são ocupadas por sistemas baseados em "QuadCore" Intel.
- O primeiro sistema não-Intel está na posição 14 e consiste em processadores HP SuperDome. Este é também o sistema mais rápido com processadores "Single Core".
- O sistema que ocupa a primeira posição é cerca de 100 vezes mais rápido que o último sistema da lista.
A distribuição de arquitecturas de processador é a seguinte:
- 36 dos 50 sistemas (72%) são construidos com base em Intel Xeon.
- 6 Opteron (AMD)
- 4 PowerPC (IBM)
- 2 Itanium (Intel)
- 1 HP SuperDome (HP)
- 1 POWER5 (IBM)
A primeira edição da lista foi divulgada em Dezembro de 2004. Comparando as duas edições, temos também alguns dados interessantes:
- Em 2004 havia 4 sistemas SMP e os restantes 46 eram Clusters. Em 2008 todos os 50 sistemas têm uma arquitectura em Cluster.
- Em 2004 a distribuição de arquitecturas de processadores mostrava a Sun com um sistema, enquanto que a AMD tinha 18 sistemas e a Inetl apenas 24. Não havia sistemas HP.
- Enquanto que em 2004 o tipo de ligação entre os diversos nós era essencialmente Gigabit Ethernet (com 12 sistemas), Myrinet (11) e SCI (10), em 2008 a Infiniband passou para 26 sistemas, Gigabit Ethernet para 9 e Myrinet para 8.
Esperemos pela próxima edição para ver como vão evoluindo as coisas no "Leste"...
Mostrar mensagens com a etiqueta performance. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta performance. Mostrar todas as mensagens
2008-02-01
Lista Top500 - 11/2007
Como qualquer geek que se preze, gosto de ir visitando o site www.top500.org que mantém dados sobre os maiores supercomputadores do mundo. Esta lista já existe desde 1993 e é actualizada de 6 em 6 meses. A edição mais recente data de Novembro de 2007.
Ora, aqui há dias resolvi passar por lá e fazer uma comparação rápida entre a lista actual e a lista de há 10 anos atrás. Alguns dados interessantes:
De notar que além destes 5 existem outros vendendores na lista dos 500 maiores. Nestes 10 anos de intervalo, apareceu um outro fabricante que é actualmente o terceiro maior, a Dell, com 24 sistemas. Dos 5 maiores de 1997, apenas a Sun se viu arredada deste grupo, substituída pela Dell. Em 1997, havia ainda mais 90 sistemas distribuídos por meia dúzia de fabricantes enquanto que em 2007 sobram 63 sistemas divididos entre 19 fabricantes.
Interessante é o facto de todos estes fabricantes terem aumentado enormemente o número de processadores incluidos nos seus sistemas.
Para além da família Intel EM64T, entraram também na lista do Top5, os processadores AMD x86-64, os Intel IA64 e mesmo os Intel IA32. Em dez anos apenas a família Power se manteve no Top5... De facto, dez anos representam uma vida em termos de arquitectura de computadores. Tal como no caso dos vendedores, mesmo arquitecturas que são praticamente residuais em termos de número de sistemas, aumentaram largamente o número de processadores, como é o caso da Cray e mesmo da Alpha que apenas num sistema consegue ter quase metade do número de processadores que detinha em 1997.
Resta agora ver a situação do software:
Falta ver agora do lado do software
Destes resultados se conclui que o "ecosistema" dos supercomputadores mudou radicalmente, tanto em hardware, como em software, já que há dez anos atrás o Unix era o dominador inconstestado e agora ocupa o terceiro lugar, bem atrás do Linux (que tomou o lugar cimeiro) e de sistemas que correm vários sistemas operativos em simultâneo. Interessante é o aparecimento neste sector de sistemas operativos ligados tradicionalmente a ambientes "desktop".
Outro dado interessante é a evolução do número médio de processadores por sistema, que em dez anos subiu dos 127 para 3296 :)
Ora, aqui há dias resolvi passar por lá e fazer uma comparação rápida entre a lista actual e a lista de há 10 anos atrás. Alguns dados interessantes:
| Vendedor | 1997 | 2007 | Var % | |||
|---|---|---|---|---|---|---|
| Sistemas | Procs. | Sistemas | Procs. | Sistemas | Procs. | |
| Cray | 113 | 17983 | 14 | 116463 | -87,6% | 547% |
| SGI | 104 | 5186 | 22 | 74800 | -78,8% | 1342% |
| Sun | 85 | 2835 | 3 | 10308 | -96,5% | 264% |
| IBM | 76 | 6849 | 232 | 963520 | 205,2% | 13968% |
| HP | 32 | 1500 | 166 | 293726 | 418,7% | 19482% |
| Total | 410 | 34353 | 437 | 1458817 | 6,6% | 4146% |
De notar que além destes 5 existem outros vendendores na lista dos 500 maiores. Nestes 10 anos de intervalo, apareceu um outro fabricante que é actualmente o terceiro maior, a Dell, com 24 sistemas. Dos 5 maiores de 1997, apenas a Sun se viu arredada deste grupo, substituída pela Dell. Em 1997, havia ainda mais 90 sistemas distribuídos por meia dúzia de fabricantes enquanto que em 2007 sobram 63 sistemas divididos entre 19 fabricantes.
Interessante é o facto de todos estes fabricantes terem aumentado enormemente o número de processadores incluidos nos seus sistemas.
| Processador | 1997 | 2007 | Var % | |||
|---|---|---|---|---|---|---|
| Sistemas | Procs. | Sistemas | Procs. | Sistemas | Procs. | |
| MIPS | 104 | 5186 | -- | -- | -- | -- |
| Intel - EM64T | -- | -- | 320 | 550682 | -- | -- |
| Sparc | 90 | 4599 | 1 | 1664 | -98,9% | -63,8% |
| Power | 76 | 6849 | 61 | 634894 | -19,7% | 9170% |
| Alpha | 74 | 17532 | 1 | 8192 | -98,6% | -53,0% |
| Cray | 45 | 743 | 2 | 2034 | -95,5% | 210% |
| Total | 389 | 34909 | 385 | 1458817 | -1,0% | 4079% |
Para além da família Intel EM64T, entraram também na lista do Top5, os processadores AMD x86-64, os Intel IA64 e mesmo os Intel IA32. Em dez anos apenas a família Power se manteve no Top5... De facto, dez anos representam uma vida em termos de arquitectura de computadores. Tal como no caso dos vendedores, mesmo arquitecturas que são praticamente residuais em termos de número de sistemas, aumentaram largamente o número de processadores, como é o caso da Cray e mesmo da Alpha que apenas num sistema consegue ter quase metade do número de processadores que detinha em 1997.
Resta agora ver a situação do software:
Falta ver agora do lado do software
| Sistema operativo | 1997 | 2007 | Var % | |||
|---|---|---|---|---|---|---|
| Sistemas | Procs. | Sistemas | Procs. | Sistemas | Procs. | |
| Unix | 496 | 63904 | 30 | 73532 | -94,0% | 15% |
| BSD | 4 | 12 | 2 | 5696 | -50,0% | 47366% |
| Linux | -- | -- | 426 | 970790 | -- | -- |
| Vários | -- | -- | 34 | 580693 | -- | -- |
| Windows | -- | -- | 6 | 12112 | -- | -- |
| MacOS | -- | -- | 2 | 5272 | -- | -- |
| Total | 500 | 63916 | 500 | 1648095 | 0,0% | 24785% |
Destes resultados se conclui que o "ecosistema" dos supercomputadores mudou radicalmente, tanto em hardware, como em software, já que há dez anos atrás o Unix era o dominador inconstestado e agora ocupa o terceiro lugar, bem atrás do Linux (que tomou o lugar cimeiro) e de sistemas que correm vários sistemas operativos em simultâneo. Interessante é o aparecimento neste sector de sistemas operativos ligados tradicionalmente a ambientes "desktop".
Outro dado interessante é a evolução do número médio de processadores por sistema, que em dez anos subiu dos 127 para 3296 :)
2007-11-13
Partições de Dados
As Bases de Dados são, essencialmente, repositórios de informação. Com o passar do tempo, a quantidade de dados a gerir aumenta,assim como a difculdade em geri-los bem.
Para ajudar os DBAs nesta tarefa surgiu o conceito de partição da Base de Dados.
Uma partição, numa Base de Dados, serve três propósitos: facilidade de gestão dos dados, disponibilidade, performance. Dos diversos sistemas de gestão de bases de dados disponíveis no mercado, existem alguns que implementam este conceito, nomeadamente os comerciais IBM DB2, Oracle, MS SQL Server 2005 e os livres MySQL 5.2 e PostgreSQL 8.
Os benefícios de particionar os dados revelam-se quando temos um grande conjunto de dados e facilmente encontramos um parâmetro que define um sub-conjunto desses dados, distinto dos restantes, o qual nos é útil para fazermos as nossas consultas. Um exemplo comum são dados históricos, e.g., dados de anos anteriores que são menos consultados, ou então dados referentes a áreas geográficas diversas.
Com as potencialidades dos SGBD aqui apresentados, torna-se relativamente simples implementar um esquema de "rotação" dos dados, que coloque os mais antigos e menos usados em partições diferentes.
Vamos supor que temos um sistema de facturação no qual vamos guardando os movimentos diários. Ao fim de um certo tempo, temos um conjunto de dados que já não é actual mas que ainda tem valor histórico. Se, em vez de guardar tudo numa tabela, criarmos uma tabela particionada em função do tempo, podemos ir movendo os dados mais antigos para as partições correspondentes e evitamos que interfiram com a operação diária da Base de Dados.
Para ajudar os DBAs nesta tarefa surgiu o conceito de partição da Base de Dados.
Uma partição, numa Base de Dados, serve três propósitos: facilidade de gestão dos dados, disponibilidade, performance. Dos diversos sistemas de gestão de bases de dados disponíveis no mercado, existem alguns que implementam este conceito, nomeadamente os comerciais IBM DB2, Oracle, MS SQL Server 2005 e os livres MySQL 5.2 e PostgreSQL 8.
Os benefícios de particionar os dados revelam-se quando temos um grande conjunto de dados e facilmente encontramos um parâmetro que define um sub-conjunto desses dados, distinto dos restantes, o qual nos é útil para fazermos as nossas consultas. Um exemplo comum são dados históricos, e.g., dados de anos anteriores que são menos consultados, ou então dados referentes a áreas geográficas diversas.
Com as potencialidades dos SGBD aqui apresentados, torna-se relativamente simples implementar um esquema de "rotação" dos dados, que coloque os mais antigos e menos usados em partições diferentes.
Vamos supor que temos um sistema de facturação no qual vamos guardando os movimentos diários. Ao fim de um certo tempo, temos um conjunto de dados que já não é actual mas que ainda tem valor histórico. Se, em vez de guardar tudo numa tabela, criarmos uma tabela particionada em função do tempo, podemos ir movendo os dados mais antigos para as partições correspondentes e evitamos que interfiram com a operação diária da Base de Dados.
2007-10-27
Optimizações
Ao fazer a análise a uma Base de Dados para resolver problemas de performance ou optimizar as queries que são realizadas, começamos, normalmente, por verificar quais as queries mais lentas, que levam mais tempo a executar, de modo a actuar nessas queries.
Ora, além do tempo de execução das queries, temos também que analizar a "big picture", isto é, a actividade geral do sistema e o número de vezes que cada uma dessas queries é executada num determindao período de tempo.
Vamos a um exemplo concreto:
- Um sistema que analisei tinha problemas de performance (tempo de resposta) na Base de Dados. Após obter uma lista das queries que estavam a demorar mais de 10 segundos a executar, verifiquei que havia algumas que demoravam mesmo mais de 60 segundos em tempo de execução.
- Ao verificar o número de vezes que cada query corria no período em análise,foi fácil verificar que era mais preocupante uma query que estava a demorar entre 10 e 20 segundos que as que demoravam mais tempo, e isto porque essa query era executada cerca de 30 vezes mais que a que demorava 60 segundos !!
- Após algumas mudanças no sistema, que dispensaram 99% das execuções dessa dita query, o número de queries que ultrapassaram os 10 segundos de execução caiu para menos de um quinto, no mesmo período da análise anterior !!
Conclusões:
- Muitas vezes ganha-se mais em actuar numa query relativamente "normal" que é executada muitas vezes que procurar optimizar logo uma queriy muito longa;
- Ao optimizar um sistema, neste caso uma Base de Dados, a solução pode estar "fora" da Base de Dados, ou seja, podemos actuar noutro ponto do sistema e obter ganhos de performance na Base de Dados;
Até breve !
Ora, além do tempo de execução das queries, temos também que analizar a "big picture", isto é, a actividade geral do sistema e o número de vezes que cada uma dessas queries é executada num determindao período de tempo.
Vamos a um exemplo concreto:
- Um sistema que analisei tinha problemas de performance (tempo de resposta) na Base de Dados. Após obter uma lista das queries que estavam a demorar mais de 10 segundos a executar, verifiquei que havia algumas que demoravam mesmo mais de 60 segundos em tempo de execução.
- Ao verificar o número de vezes que cada query corria no período em análise,foi fácil verificar que era mais preocupante uma query que estava a demorar entre 10 e 20 segundos que as que demoravam mais tempo, e isto porque essa query era executada cerca de 30 vezes mais que a que demorava 60 segundos !!
- Após algumas mudanças no sistema, que dispensaram 99% das execuções dessa dita query, o número de queries que ultrapassaram os 10 segundos de execução caiu para menos de um quinto, no mesmo período da análise anterior !!
Conclusões:
- Muitas vezes ganha-se mais em actuar numa query relativamente "normal" que é executada muitas vezes que procurar optimizar logo uma queriy muito longa;
- Ao optimizar um sistema, neste caso uma Base de Dados, a solução pode estar "fora" da Base de Dados, ou seja, podemos actuar noutro ponto do sistema e obter ganhos de performance na Base de Dados;
Até breve !
2007-10-09
Picuinhices com dados
Uma Base de Dados Relacional não é apenas um conjunto de dados "arrumadinhos" em tabelas, obedece a uma teoria matemática baseada na lógica de predicados e teoria dos conjuntos. Esta teoria é conhecida como o Modelo Relacional e foi descrito em 1969 por E.F.Codd, numa publicação para consumo interno da IBM, e em 1970 num artigo público.
Hoje em dia, a maioria dos sistemas profissionais de gestão de bases de dados (tanto comerciais como open-source), implementam este Modelo, portanto têm como base para a forma como guardam e acedem aos dados uma construção matemática já bem conhecida.
Portanto, ao desenhar ou desenvolver uma Base de Dados, devemos sempre procurar aproximarmo-nos do modelo matemático e não afastarmo-nos dele. Ao seguir com rigor este modelo e escolher uma implementação de qualidade do mesmo (o SGBD), podemos estar certos que os problemas de performance associados a uma determinada aplicação não se deverão atribuir a "mau desenho" da Base de Dados. Desta maneira, eliminam-se as "desculpas" para des-normalizar, para criar dados redundantes e outros artifícios que tais...
Tudo isto é válido numa lógica de OLTP, ou seja,em Bases de Dados que servem essencialmente sistemas de transacções, tais como sistemas de venda, de recolha de dados de produção, etc. Para sistemas que suportam Sistemas de Apoio à Decisão o caso é outro, mas fica para a próxima...
Hoje em dia, a maioria dos sistemas profissionais de gestão de bases de dados (tanto comerciais como open-source), implementam este Modelo, portanto têm como base para a forma como guardam e acedem aos dados uma construção matemática já bem conhecida.
Portanto, ao desenhar ou desenvolver uma Base de Dados, devemos sempre procurar aproximarmo-nos do modelo matemático e não afastarmo-nos dele. Ao seguir com rigor este modelo e escolher uma implementação de qualidade do mesmo (o SGBD), podemos estar certos que os problemas de performance associados a uma determinada aplicação não se deverão atribuir a "mau desenho" da Base de Dados. Desta maneira, eliminam-se as "desculpas" para des-normalizar, para criar dados redundantes e outros artifícios que tais...
Tudo isto é válido numa lógica de OLTP, ou seja,em Bases de Dados que servem essencialmente sistemas de transacções, tais como sistemas de venda, de recolha de dados de produção, etc. Para sistemas que suportam Sistemas de Apoio à Decisão o caso é outro, mas fica para a próxima...
2007-09-24
Sobre a definição de dados
Num qualuqer sistema de informação, talvez o contributo mais importante para o seu desempenho seja a definição das estruturas de dados que o vão suportar...
Após tantos anos decorridos da criação do modelo relacional, é ainda habitual criarem-se bases de dados não normalizadas e que a desculpa para a desnormalização das mesmas seja sempre a mesma: performance.
Este problema afecta em maior grau os chamados sistemas de OLTP, ou seja, bases de dados muito dinâmicas com grande percentagem de operações de alteração de dados em relação ao total de operações realizadas.
Embora haja casos específicos em que um pequeno grau de desnormalização traz alguma melhoria de performance, são situações que envolvem a replicação de dados em tabelas diferentes, o que obriga a um maior esforço dos programadores do sistema para que não existam dados incoerentes. Esta duplicação de dados vai aumentar o espaço necessário para guardar a base de dados e a complexidade das operações de alteração de dados.
Um outro problema que afecta a performance dos sistemas de informação é o tipo de dados com que se criam os diversos camposnas tabelas. Muitas vezes, ao tentar definir o tipo de dados que queremos atribuir a determinado campo deparamo-nos com a dificuldade de prever os valores que irão "povoar" esse campo e existe sempre a tendência de "usar o maior que se possa", ou seja, definir os campos de inteiros como BIGINT e os campos de caracteres como VARCHAR(2000) ou algo semelhante. Para além deste erro, existem outros que indicam desperdício de recursos, tais como usar dois campos DATETIME para guardar data e hora de entrada (um dos campos só tem datas e o outro só tem horas)...
Ao estruturar correctamente os dados, e criar código SQL eficiente estamos a contribuir de modo muito importante para que o sistema de informação tenha a maior performance possível.
No caso de ser necessário alterar ou expandir um esquema que tenha erros de concepção pode ser mais fácil redesenhar o sistema (ou a parte a intervencionar) do que tentar rodear os problemas, pois como diz o ditado popular: "O que nasce torto, tarde ou nunca se endireita".
Após tantos anos decorridos da criação do modelo relacional, é ainda habitual criarem-se bases de dados não normalizadas e que a desculpa para a desnormalização das mesmas seja sempre a mesma: performance.
Este problema afecta em maior grau os chamados sistemas de OLTP, ou seja, bases de dados muito dinâmicas com grande percentagem de operações de alteração de dados em relação ao total de operações realizadas.
Embora haja casos específicos em que um pequeno grau de desnormalização traz alguma melhoria de performance, são situações que envolvem a replicação de dados em tabelas diferentes, o que obriga a um maior esforço dos programadores do sistema para que não existam dados incoerentes. Esta duplicação de dados vai aumentar o espaço necessário para guardar a base de dados e a complexidade das operações de alteração de dados.
Um outro problema que afecta a performance dos sistemas de informação é o tipo de dados com que se criam os diversos camposnas tabelas. Muitas vezes, ao tentar definir o tipo de dados que queremos atribuir a determinado campo deparamo-nos com a dificuldade de prever os valores que irão "povoar" esse campo e existe sempre a tendência de "usar o maior que se possa", ou seja, definir os campos de inteiros como BIGINT e os campos de caracteres como VARCHAR(2000) ou algo semelhante. Para além deste erro, existem outros que indicam desperdício de recursos, tais como usar dois campos DATETIME para guardar data e hora de entrada (um dos campos só tem datas e o outro só tem horas)...
Ao estruturar correctamente os dados, e criar código SQL eficiente estamos a contribuir de modo muito importante para que o sistema de informação tenha a maior performance possível.
No caso de ser necessário alterar ou expandir um esquema que tenha erros de concepção pode ser mais fácil redesenhar o sistema (ou a parte a intervencionar) do que tentar rodear os problemas, pois como diz o ditado popular: "O que nasce torto, tarde ou nunca se endireita".
2007-08-29
Análise de Performance em Linux e Windows - II
Acho que encontrei um modo bastante fácil para resolver um problema que já me vinha a atormentar há algum tempo.
Eu explico, como fazer para recolher, a certas horas do dia, alguns dados dos computadores que interessam, uns Linux e outros Windows e fazer uns gráficos todos bonitos para que depois o administrador de sistemas olhasse para eles (os gráficos) ?
Ora a solução por mim adoptada envolve uns scripts, criados para a funçao, e um programa muito versátil e simples de usar chamado Gnuplot.
Para recolher os dados em Linux uso um shell-script que me vai ler as informações que quero ao /proc e coloca num ficheiro do tipo .csv; Para efectuar a recolha em Windows uso um script VBS, executado através do "motor" WSH e que também exporta esses dados pera um ficheiro tipo .csv.
Por fim tenho um terceiro script, para o gnuplot, que me vai criar os gráficos relevantes e exporta-os para um ficheiro de imagem (no caso PNG).
A vantagem de executar todas estas acções através de scripts é a facilidade de parametrização e definição de horários para a recolha e geração dos ditos gráficos.
Assim, basta um cron job no Linux ou uma tarefa agendada no Windows para criar automaticamente o que é pretendido.
Um resultado possível é este :
Mostra um gráfico com três indicadores relativos à utilização de memória numa máquina Linux.
2007-08-20
Análise de Performance em Linux e Windows - I
Tenho estado a experimentar a melhor maneira de analisar a performance de sistemas Windows e Linux em Windows e Windows e Linux em Linux... Parece uma lenga-lenga mas interessa por vezes ter dados de performance de um conjunto de servidores, em ambientes heterogéneos (ou seja, dados de máquinas Linux e máquinas Windows) e analizá-los numa outra máquina (normalmente um computador pessoal ou portátil)...
Para recolher as informações relevantes podemos recorrer a diversos métodos mas, para o caso, sigo "a lei do menor esforço" e uso as ferramentas disponíveis com os diversos S.O., no caso do Windows uso o Performance Monitor e no caso do Linux uso informações do /proc. Esta acção permite-me obter os dados que quero todos "arrumadinhos" num ficheiro de texto que é facilmente "importável" para a aplicação de análise.
Ora aqui é que a porca torce o rabo... porquê ? Porque não me apetece usar o MS Excel para analisar os dados e fazer os respectivos gráficos, e nem sequer me apetece muito usar o OpenOffice.org Calc... Não é que estes dois programas não sejam capazes, nada disso, mas gosto das coisas mais automáticas. Gostava de fazer assim:
E gostava que isto fosse possível nos dois S.O., sem grandes complicações, artimanhas ou "instala-mais-este-software-que-te-faz-isso-e-te-tira-cafés-mas-
-que-só-dá-para-ver-assim-ou-assado".
E gostava que houvesse maneira de fazer isto tudo a partir de um scriptezito às segundas de manhã ou quartas à tarde ou quando quisesse sem pensar mais nisso.
E gostava de receber os ditos gráficos por mail...
Para já concluí a fase 1. Tanto no Windows como no Linux. Agora vou passar à fase 2, penso que daqui a um ou dois dias já tenho o que quero !
Ah!, é verdade, e também gostava de ganhar o EuroMilhões.... :)
Para recolher as informações relevantes podemos recorrer a diversos métodos mas, para o caso, sigo "a lei do menor esforço" e uso as ferramentas disponíveis com os diversos S.O., no caso do Windows uso o Performance Monitor e no caso do Linux uso informações do /proc. Esta acção permite-me obter os dados que quero todos "arrumadinhos" num ficheiro de texto que é facilmente "importável" para a aplicação de análise.
Ora aqui é que a porca torce o rabo... porquê ? Porque não me apetece usar o MS Excel para analisar os dados e fazer os respectivos gráficos, e nem sequer me apetece muito usar o OpenOffice.org Calc... Não é que estes dois programas não sejam capazes, nada disso, mas gosto das coisas mais automáticas. Gostava de fazer assim:
- Correr o script de recolha / tarefa do PerfMonitor
- Criar os gráficos relevantes.
- Ver os ditos num PDF todo geitoso.
E gostava que isto fosse possível nos dois S.O., sem grandes complicações, artimanhas ou "instala-mais-este-software-que-te-faz-isso-e-te-tira-cafés-mas-
-que-só-dá-para-ver-assim-ou-assado".
E gostava que houvesse maneira de fazer isto tudo a partir de um scriptezito às segundas de manhã ou quartas à tarde ou quando quisesse sem pensar mais nisso.
E gostava de receber os ditos gráficos por mail...
Para já concluí a fase 1. Tanto no Windows como no Linux. Agora vou passar à fase 2, penso que daqui a um ou dois dias já tenho o que quero !
Ah!, é verdade, e também gostava de ganhar o EuroMilhões.... :)
2007-08-08
SAN - NAS
Ao dimensionar um Sistema de Informação existem vários pontos a ter em conta, um dos quais é o espaço necessário para armazenar a informação pretendida.
Ora, visto que um Sistema de Informação não é uma entidade estática mas irá sofrer evoluções, é necessário contar também com as necessidades futuras que possam vir a exigir mais espaço de armazenamento.
Nesta área há duas tecnologias principais que permitem maior flexibilidade do nosso armazém de dados: NAS e SAN, ou seja "Netwok Attached Storage" e "Storage Area Network". Embora os nomes sejam parecidos e o fim seja o mesmo, os conceitos que estão por detrás de cada uma delas são muito diferentes e assentam em pressupostos também diferentes. Uma SAN é constituída por um conjunto de discos (o armazenamento propriamente dito) que se liga a um computador através de uma rede dedicada, normalmente de fibra óptica. Um sistema NAS é um conjunto de discos que está ligado à rede local (LAN) através de Ethernet. Dito assim, até parece que não existe grande diferença entre os dois, a não ser a tecnologia de rede usada. A outra (maior) diferença entre as duas opções é o tipo de informação que fornecem aos sistemas a eles ligados.
Uma SAN fornece os dados que tem armazenados sob a forma de "blocos" tal como se fosse mais um disco interno de um servidor. Deste ponto de vista a SAN serve para "esticar" o espaço disponível para armazenar ficheiros num servidor.
Um sistema NAS fornece os dados sob a forma de ficheiros, ou seja, comporta-se como um servidor de ficheiros independente do resto dos servidores da rede.
Apresentado um exemplo:
Temos um computador na rede, que precisa de aceder ao ficheiro "Projecto1.odt" armazenado num sistema NAS. O caminho para esse ficheiros será do género [Usando caminhos SAMBA/CIFS]:
\\SistemaNAS\Partilha\Projecto1.odt
Se, pelo contrário, o mesmo ficheiro estiver numa SAN, gerida pelo servidor Server1:
\\Server1\Partilha\Projecto1.odt
Portanto, do ponto de vista dos clientes, nada a assinalar. Então porquê esta "questão" à volta da tecnologia a implementar ? Porque não escolher uma delas e seguir em frente ??
Essencialmente porque as Bases de Dados não gostam de NAS, i.e., se tivermos que alojar uma Base de Dados de alguma dimensão torna-se incomportável transferir um ficheiro "pela rede".
Vendo outro exemplo:
Supomos que existe uma Base de Dados de suporte ao nosso Sistema de Informação que irá ter cerca de 10 GiB.
Ao alojar este ficheiro no NAS, teremos que configurar o SGBD para o usar e, uma vez que os SGBD requerem acesso exclusivo a todo o ficheiro da BD, este teria que ser transferido na totalidade para o sistema que corre o SGBD sempre que houvesse necessidade de leitura/escrita na BD. Mesmo com FastEthernet de 1Gb/s, a transferência do ficheiro demoraria cerca de 2 minutos. Claro que este tempo de espera ao abrir o ficheiro será incomportável para as aplicações, já para não falar em recursos de memória que seria necessários do lado do SGBD.
Se o alojarmos numa SAN, podemos atribuir essa área da SAN ao servidor do SGBD e comportar-se-á como armazenamento local. Quer isto dizer que nunca haverá necessidade de transferir todo o ficheiro, pois em caso de acesso a ficheiros locais só os blocos envolvidos são transferidos.
Para além das razões "técnicas" de acesso a ficheiros, ecistem também diferenças significativas na instalação, configuração e administração dos dois tipos de armazenamento, o que leva a que muitas vezes o NAS seja preferido pelo seu menor custo e maior facilidade de implementação. Pelo contrário, quando o que está em causa é a velocidade de acesso e facilidade de expansão (e o dinheiro chega) prefere-se implementar uma SAN.
Ultimamente tem-se vindo a aproximar as duas filosofias pela junção de um NAS na interface da SAN com a rede, o que cria, na prática, um NAS muito escalável e bastante rápido.
Tanto num NAS como numa SAN, são aplicáveis outros conceitos relativos ao armazenamento, nomeadamente níveis de RAID e tecnologias de Discos, que fiarão ar uma próxima ocasião.
Ora, visto que um Sistema de Informação não é uma entidade estática mas irá sofrer evoluções, é necessário contar também com as necessidades futuras que possam vir a exigir mais espaço de armazenamento.
Nesta área há duas tecnologias principais que permitem maior flexibilidade do nosso armazém de dados: NAS e SAN, ou seja "Netwok Attached Storage" e "Storage Area Network". Embora os nomes sejam parecidos e o fim seja o mesmo, os conceitos que estão por detrás de cada uma delas são muito diferentes e assentam em pressupostos também diferentes. Uma SAN é constituída por um conjunto de discos (o armazenamento propriamente dito) que se liga a um computador através de uma rede dedicada, normalmente de fibra óptica. Um sistema NAS é um conjunto de discos que está ligado à rede local (LAN) através de Ethernet. Dito assim, até parece que não existe grande diferença entre os dois, a não ser a tecnologia de rede usada. A outra (maior) diferença entre as duas opções é o tipo de informação que fornecem aos sistemas a eles ligados.
Uma SAN fornece os dados que tem armazenados sob a forma de "blocos" tal como se fosse mais um disco interno de um servidor. Deste ponto de vista a SAN serve para "esticar" o espaço disponível para armazenar ficheiros num servidor.
Um sistema NAS fornece os dados sob a forma de ficheiros, ou seja, comporta-se como um servidor de ficheiros independente do resto dos servidores da rede.
Apresentado um exemplo:
Temos um computador na rede, que precisa de aceder ao ficheiro "Projecto1.odt" armazenado num sistema NAS. O caminho para esse ficheiros será do género [Usando caminhos SAMBA/CIFS]:
\\SistemaNAS\Partilha\Projecto1.odt
Se, pelo contrário, o mesmo ficheiro estiver numa SAN, gerida pelo servidor Server1:
\\Server1\Partilha\Projecto1.odt
Portanto, do ponto de vista dos clientes, nada a assinalar. Então porquê esta "questão" à volta da tecnologia a implementar ? Porque não escolher uma delas e seguir em frente ??
Essencialmente porque as Bases de Dados não gostam de NAS, i.e., se tivermos que alojar uma Base de Dados de alguma dimensão torna-se incomportável transferir um ficheiro "pela rede".
Vendo outro exemplo:
Supomos que existe uma Base de Dados de suporte ao nosso Sistema de Informação que irá ter cerca de 10 GiB.
Ao alojar este ficheiro no NAS, teremos que configurar o SGBD para o usar e, uma vez que os SGBD requerem acesso exclusivo a todo o ficheiro da BD, este teria que ser transferido na totalidade para o sistema que corre o SGBD sempre que houvesse necessidade de leitura/escrita na BD. Mesmo com FastEthernet de 1Gb/s, a transferência do ficheiro demoraria cerca de 2 minutos. Claro que este tempo de espera ao abrir o ficheiro será incomportável para as aplicações, já para não falar em recursos de memória que seria necessários do lado do SGBD.
Se o alojarmos numa SAN, podemos atribuir essa área da SAN ao servidor do SGBD e comportar-se-á como armazenamento local. Quer isto dizer que nunca haverá necessidade de transferir todo o ficheiro, pois em caso de acesso a ficheiros locais só os blocos envolvidos são transferidos.
Para além das razões "técnicas" de acesso a ficheiros, ecistem também diferenças significativas na instalação, configuração e administração dos dois tipos de armazenamento, o que leva a que muitas vezes o NAS seja preferido pelo seu menor custo e maior facilidade de implementação. Pelo contrário, quando o que está em causa é a velocidade de acesso e facilidade de expansão (e o dinheiro chega) prefere-se implementar uma SAN.
Ultimamente tem-se vindo a aproximar as duas filosofias pela junção de um NAS na interface da SAN com a rede, o que cria, na prática, um NAS muito escalável e bastante rápido.
Tanto num NAS como numa SAN, são aplicáveis outros conceitos relativos ao armazenamento, nomeadamente níveis de RAID e tecnologias de Discos, que fiarão ar uma próxima ocasião.
2007-07-23
Mais dicas sobre o tamanho
Boa noite,
O comentário de um "corajoso internauta" a um post anterior, leva-me a fazer mais um post relacionado com tamanhos :)
Tem isto a ver com o que se pode ganhar em termos de tamanho de uma BD ao aplicar algumas técnicas de optimização de dados.
Hoje estive a ver uma BD, real, que tem uma tabela com cerca de um milhão e meio de registos. Um dos campos é do tipo "bigint", ou seja ocupa 8 bytes de armazenamento e permite que sejam guardados números inteiros entre -2^63 a 2^63-1. Se não forem necessários valores tão grandes podemos transformar este campo para um tipo "int" (valores entre -2^31 e 2^31) ou até um "smallint" (valores entre -65000 e 65000 aprox.)
Nestas transformações ganham-se respectivamente 4 ou 6 bytes de cada registo. Como a tabela tem um milhão e meio de registos, diz-nos a matemática que se podem ganhar entre 6 a 9 MiB de espaço nesta coluna :)
Parece pouco, mas podemos ainda fazer a análise de outro modo: podemos medir a "largura" de uma tabela, ou seja, o tamanho de cada registo. Nesta tabela em particular vamos começar com uma largura de 356 bytes. Se cada página de armazenamento da BD tiver 8KiB, temos cerca de 8000 bytes para armazenar os dados (devido a headers e informação administrativa da BD). Desta quantidade, pode estar definida uma percentagem máxima de ocupação (vamos supor 80%), que nos dá uma capacidade efectiva de 6400 bytes. Dividindo 6400 por 356 podemos armazenar 17 registos completos numa página (os registos não podem estar divididos por duas páginas), ou seja, para 1500000 de registos, necessitamos de 88236 páginas, ou cerca de 689 MiB. Se reduzirmos 6 bytes a cada registo e fizermos novamente as contas passamos a ocupar 83334 páginas, ou cerca de 651 MiB, poupamos 38 MiB de espaço efectivo de armazenagem... e isto numa tabela de dimensão média... :)
Propagando estas alterações para outras colunas e outras tabelas dentro desta BD, podemos poupar dezenas ou centenas de MiB, conforme o grau que quisermos levar esta análise. Claro que estas mudanças têm o seu preço e poderão envolver também alterações na programação subjacente ao Sistema que faz uso destes dados.
E para já é tudo !
Até breve.
O comentário de um "corajoso internauta" a um post anterior, leva-me a fazer mais um post relacionado com tamanhos :)
Tem isto a ver com o que se pode ganhar em termos de tamanho de uma BD ao aplicar algumas técnicas de optimização de dados.
Hoje estive a ver uma BD, real, que tem uma tabela com cerca de um milhão e meio de registos. Um dos campos é do tipo "bigint", ou seja ocupa 8 bytes de armazenamento e permite que sejam guardados números inteiros entre -2^63 a 2^63-1. Se não forem necessários valores tão grandes podemos transformar este campo para um tipo "int" (valores entre -2^31 e 2^31) ou até um "smallint" (valores entre -65000 e 65000 aprox.)
Nestas transformações ganham-se respectivamente 4 ou 6 bytes de cada registo. Como a tabela tem um milhão e meio de registos, diz-nos a matemática que se podem ganhar entre 6 a 9 MiB de espaço nesta coluna :)
Parece pouco, mas podemos ainda fazer a análise de outro modo: podemos medir a "largura" de uma tabela, ou seja, o tamanho de cada registo. Nesta tabela em particular vamos começar com uma largura de 356 bytes. Se cada página de armazenamento da BD tiver 8KiB, temos cerca de 8000 bytes para armazenar os dados (devido a headers e informação administrativa da BD). Desta quantidade, pode estar definida uma percentagem máxima de ocupação (vamos supor 80%), que nos dá uma capacidade efectiva de 6400 bytes. Dividindo 6400 por 356 podemos armazenar 17 registos completos numa página (os registos não podem estar divididos por duas páginas), ou seja, para 1500000 de registos, necessitamos de 88236 páginas, ou cerca de 689 MiB. Se reduzirmos 6 bytes a cada registo e fizermos novamente as contas passamos a ocupar 83334 páginas, ou cerca de 651 MiB, poupamos 38 MiB de espaço efectivo de armazenagem... e isto numa tabela de dimensão média... :)
Propagando estas alterações para outras colunas e outras tabelas dentro desta BD, podemos poupar dezenas ou centenas de MiB, conforme o grau que quisermos levar esta análise. Claro que estas mudanças têm o seu preço e poderão envolver também alterações na programação subjacente ao Sistema que faz uso destes dados.
E para já é tudo !
Até breve.
2007-07-18
Tamanho e performance
Boas noites,
No seguimento dos posts sobre performance de sistemas e tamanho, cá vai mais um texto supostamente inteligente :)
Ao fazer umas pesquisas sobre sistemas de alta disponibilidade de servidores SQL, deparei-me com um artigo interessante sobre a relação entre o tamanho das bases de dados e a possível performance dos servidor.
O que se passa é que, ao desenhar uma Base de Dados, se deve ter em conta o tamanho máximo dos campos das tabelas necessário para guardar os dados e não sobre-estimar esta medida. Passo a explicar:
Queremos criar uma tabela que contenha 2 campos:
Numero - campo numérico que contém o número de funcionário;
Nome - campo de texto que irá ter o nome do dito funcionário.
Ao criar os campos temos várias hipóteses para o tipo de dados que podemos usar. Se usarmos o tipo numérico comum (int) ocupamos 4 bytes em cada valor, ora se pensarmos que não iremos ter mais de 65000 funcionários, podemos poupar 2 bytes em cada registo se mudarmos o tipo de int para smallint. Do mesmo modo se tivermos o cuidado de verificar o tamanho máximo dos nomes dos funcionários, podemo-nos cingir a uma coluna do tipo char em vez de varchar e mais ainda se prescindirmos dos tipos Unicode.
Claro que este é um exemplo muito simples mas se extrapolarmos para toda uma Base de Dados com vários gigabytes de tamanho podemos poupar vários megabytes.
Mas no fundo, qual é o interesse desta redução de tamanho?
É essencialmente uma maneira de poder guardar mais dados por página da Base de Dados, ou seja, as Bases de Dados estão normalmente estruturadas (em termos de armazenamento em disco) numa série de páginas que têm entre 4 e 32 KiB, e cada página pode guardar um número limitado de registos. Se conseguirmos colocar mais registos por páginas beneficiamos as operações de entrada/saída de dados (feitas a nível de página) ao movimentar mais registos de cada vez.
Claro que estas considerações terão mais importância à medida que aumenta a dimensão geral dos dados, mas é sempre útil termos noção destes factores para optimizarmos o mais possível o desempenho dos sistemas.
Por hoje não vos maço mais...
No seguimento dos posts sobre performance de sistemas e tamanho, cá vai mais um texto supostamente inteligente :)
Ao fazer umas pesquisas sobre sistemas de alta disponibilidade de servidores SQL, deparei-me com um artigo interessante sobre a relação entre o tamanho das bases de dados e a possível performance dos servidor.
O que se passa é que, ao desenhar uma Base de Dados, se deve ter em conta o tamanho máximo dos campos das tabelas necessário para guardar os dados e não sobre-estimar esta medida. Passo a explicar:
Queremos criar uma tabela que contenha 2 campos:
Numero - campo numérico que contém o número de funcionário;
Nome - campo de texto que irá ter o nome do dito funcionário.
Ao criar os campos temos várias hipóteses para o tipo de dados que podemos usar. Se usarmos o tipo numérico comum (int) ocupamos 4 bytes em cada valor, ora se pensarmos que não iremos ter mais de 65000 funcionários, podemos poupar 2 bytes em cada registo se mudarmos o tipo de int para smallint. Do mesmo modo se tivermos o cuidado de verificar o tamanho máximo dos nomes dos funcionários, podemo-nos cingir a uma coluna do tipo char em vez de varchar e mais ainda se prescindirmos dos tipos Unicode.
Claro que este é um exemplo muito simples mas se extrapolarmos para toda uma Base de Dados com vários gigabytes de tamanho podemos poupar vários megabytes.
Mas no fundo, qual é o interesse desta redução de tamanho?
É essencialmente uma maneira de poder guardar mais dados por página da Base de Dados, ou seja, as Bases de Dados estão normalmente estruturadas (em termos de armazenamento em disco) numa série de páginas que têm entre 4 e 32 KiB, e cada página pode guardar um número limitado de registos. Se conseguirmos colocar mais registos por páginas beneficiamos as operações de entrada/saída de dados (feitas a nível de página) ao movimentar mais registos de cada vez.
Claro que estas considerações terão mais importância à medida que aumenta a dimensão geral dos dados, mas é sempre útil termos noção destes factores para optimizarmos o mais possível o desempenho dos sistemas.
Por hoje não vos maço mais...
2007-06-17
Performance em Linux e Windows
Bom dia,
Em relação aos processos de medição de performance de sistemas de Informação, importa ter em conta o tipo de sistema que temos, nomeadamente, se se trata de um sistema baseado em Linux, em Windows ou noutro Sistema Operativo. Este facto obriga-nos a fazer algumas escolhas quanto ao processo de recolha da informação.
Se nos computadores com Windows podemos usar o "Performance Monitor" para recolher informação do computador local, ou remoto, nos computadores com Linux beneficiamos do sistema /proc que nos dá, em modo texto, informação sobre vários aspectos do sistema do computador local. Se exportarmos o /proc via nfs para um cliente remoto podemos obter indicadores de várias máquinas de uma forma centralizada.
Além do tipo de sistema devemos ter em conta a versão que estamos a analizar, já que a informação disponibilizada pelas diferentes versões dos sistemas operativos não é a mesma. Por exemplo, no Linux, com kernel da série 2.4 o ficheiro /proc/stat tem o seguinte aspecto :
já nas versões 2.6 será mais como (para dois CPUs) :
Para já é só... até breve !
Em relação aos processos de medição de performance de sistemas de Informação, importa ter em conta o tipo de sistema que temos, nomeadamente, se se trata de um sistema baseado em Linux, em Windows ou noutro Sistema Operativo. Este facto obriga-nos a fazer algumas escolhas quanto ao processo de recolha da informação.
Se nos computadores com Windows podemos usar o "Performance Monitor" para recolher informação do computador local, ou remoto, nos computadores com Linux beneficiamos do sistema /proc que nos dá, em modo texto, informação sobre vários aspectos do sistema do computador local. Se exportarmos o /proc via nfs para um cliente remoto podemos obter indicadores de várias máquinas de uma forma centralizada.
Além do tipo de sistema devemos ter em conta a versão que estamos a analizar, já que a informação disponibilizada pelas diferentes versões dos sistemas operativos não é a mesma. Por exemplo, no Linux, com kernel da série 2.4 o ficheiro /proc/stat tem o seguinte aspecto :
cpu 1132 34 1441 11311718 3675 127 438
cpu0 1132 34 1441 11311718 3675 127 438
intr 114930548 113199788 3 0 5 263 0 4 (...)
ctxt 1990473
btime 1062191376
já nas versões 2.6 será mais como (para dois CPUs) :
cpu 2255 34 2290 22625563 6290 127 456
cpu0 1132 34 1441 11311718 3675 127 438
cpu1 1123 0 849 11313845 2614 0 18
intr 114930548 113199788 3 0 5 263 0 4 [... lots more numbers ...]
ctxt 1990473
btime 1062191376
processes 2915
procs_running 1
procs_blocked 0
Para já é só... até breve !
2007-06-05
Promessas....
Boa noite,
Como prometido, cá estou eu para "falar" mais um pouco do tema da performance nos sistemas de informação.
O primeiro passo para poder avaliar com alguma confiança a performance de um sistema consiste em conhecer o sistema, ou seja, conseguir obter uma série de indicadores que nos digam como se está a comportar. Esta medida inicial, também chamada "baseline", server para termos uma base para comparação futura.
E aqui entra a segunda fase do processo de avaliação da performance: fazer comparações com a baseline e inferir tendências de comportamento que nos indiquem se a performance se está a degradar ou se, pelo contrário, se mantêm.
E para que serve isto, no fim de contas ?
Serve, principalmente, para tomar decisões informadas sobre assuntos como: actualização dos sistemas, planeamento de expansão futura, determinação de problemas ou até de potenciais problemas....
Um resultado prático pode ser demonstrado pelo exemplo seguinte:
Vamos supor que temos um servidor de Base de Dados, já com algum tempo em operação "em velocidade de cruzeiro" e começa a apresentar algumas dificuldades de desempenho.
Se não houver algum cuidado na avaliação da situação podemos ser tentados a investir em mais RAM ou em processadores mais rápidos, quando, por exemplo, o factor limitante pode ser a resposta do tempo de E/S do sistema de armazenamento (discos) e, portanto, podemos investir em discos diferentes/mais rápidos para resolver o problema inicial em vez de deitar dinheiro fora a melhorar componentes que provavelmente não precisarão de actualizações.
Para concluir, devo referir que estas análises devem ser feitas a intervalos regulares para melhores resultados.
Por agora ficamos por aqui... até breve.
Como prometido, cá estou eu para "falar" mais um pouco do tema da performance nos sistemas de informação.
O primeiro passo para poder avaliar com alguma confiança a performance de um sistema consiste em conhecer o sistema, ou seja, conseguir obter uma série de indicadores que nos digam como se está a comportar. Esta medida inicial, também chamada "baseline", server para termos uma base para comparação futura.
E aqui entra a segunda fase do processo de avaliação da performance: fazer comparações com a baseline e inferir tendências de comportamento que nos indiquem se a performance se está a degradar ou se, pelo contrário, se mantêm.
E para que serve isto, no fim de contas ?
Serve, principalmente, para tomar decisões informadas sobre assuntos como: actualização dos sistemas, planeamento de expansão futura, determinação de problemas ou até de potenciais problemas....
Um resultado prático pode ser demonstrado pelo exemplo seguinte:
Vamos supor que temos um servidor de Base de Dados, já com algum tempo em operação "em velocidade de cruzeiro" e começa a apresentar algumas dificuldades de desempenho.
Se não houver algum cuidado na avaliação da situação podemos ser tentados a investir em mais RAM ou em processadores mais rápidos, quando, por exemplo, o factor limitante pode ser a resposta do tempo de E/S do sistema de armazenamento (discos) e, portanto, podemos investir em discos diferentes/mais rápidos para resolver o problema inicial em vez de deitar dinheiro fora a melhorar componentes que provavelmente não precisarão de actualizações.
Para concluir, devo referir que estas análises devem ser feitas a intervalos regulares para melhores resultados.
Por agora ficamos por aqui... até breve.
2007-05-19
Velocidades II
Boa noite,
Antes de mais, quero agradecer ao elmig o comentário, já que foi o primeiro :)
Em resposta a esse comentário resolvi escrever um novo post, sobre o mesmo tema.
Para optimizar o desempenho de um sistema de informação temos que ter em conta vários factores, sendo que um dos mais importantes é o software que serve de interface entre os utilizadores e o sistema de gestão de base de dados(SGBD) que o suporta, vulgo software de gestão ou ERP. Alguns dos outros factores que tem muita importância no desempenho final do Sistema de Informação vão desde o hardware escolhido até à configuração do SGBD.
Como o software de gestão é o factor que mais impacto tem na performance final do Sistema (pois um programa mal arquitectado raramente terá bom desempenho), devemos começar por avaliar o desempenho dos vários factores envolvidos, escolher a melhor configuração possível e desenvolver o programa de acordo com essa configuração.
Para além destas medidas, que podem ser distintas para cada situação, há um conjunto de opções geralmente aceites pela comunidade no que respeita a configurações recomendadas do SGBD, opções de arquitectura do hardware (nomeadamente sistema de armazenamento), práticas de programação, estruturação das bases de dados, etc...
Claro que tudo isto é muito bonito quando se está a desenvolver o sistema, mas quando este já existe há algum tempo e não é viável alterar a sua arquitectura ? Só nos resta medir a performance do mesmo e melhorar o que for possível, ou seja, actuar onde se puder, nomeadamente a nível de opções de configuração do SGBD, hardware, etc...
Mas como medir a performance ? Que indicadores escolher ? Hoje em dia quase todos os SGBD têm opções, plugins ou ferramentas para obter indicadores acerca do desempenho do SGDB. Devemos recolher essa informação e interpretá-la para alterar o que for necessário.
Vamos a um exemplo: Vamos imaginar que temos um sistema que está suportado pelo PostgreSQL. Neste SGBD existe uma opção para obter estatisticas. Um dos indicadores que podemos obter, chamado pg_stat_all_indexes (é uma tabela) dá-nos informação importante sobre a utilização dos índices das tabelas. Com esta informação podemos afinar os índices que nos dêm mais problemas, ou então podemos usar uma das tabelas pg_stat_io_* que nos dão informações sobre a performance de I/O da Base de Dados, ao analizar estes valores podemos descobrir que temos que optimizar a configuração do sistema de armazenamento...
Isto é só a ponta do iceberg... há imensas opções diferentes e abordagens que variam conforme o SGBD usado, o hardware, etc...
Por agora espero que tenham ficado com a ideia geral...
Até breve !
Antes de mais, quero agradecer ao elmig o comentário, já que foi o primeiro :)
Em resposta a esse comentário resolvi escrever um novo post, sobre o mesmo tema.
Para optimizar o desempenho de um sistema de informação temos que ter em conta vários factores, sendo que um dos mais importantes é o software que serve de interface entre os utilizadores e o sistema de gestão de base de dados(SGBD) que o suporta, vulgo software de gestão ou ERP. Alguns dos outros factores que tem muita importância no desempenho final do Sistema de Informação vão desde o hardware escolhido até à configuração do SGBD.
Como o software de gestão é o factor que mais impacto tem na performance final do Sistema (pois um programa mal arquitectado raramente terá bom desempenho), devemos começar por avaliar o desempenho dos vários factores envolvidos, escolher a melhor configuração possível e desenvolver o programa de acordo com essa configuração.
Para além destas medidas, que podem ser distintas para cada situação, há um conjunto de opções geralmente aceites pela comunidade no que respeita a configurações recomendadas do SGBD, opções de arquitectura do hardware (nomeadamente sistema de armazenamento), práticas de programação, estruturação das bases de dados, etc...
Claro que tudo isto é muito bonito quando se está a desenvolver o sistema, mas quando este já existe há algum tempo e não é viável alterar a sua arquitectura ? Só nos resta medir a performance do mesmo e melhorar o que for possível, ou seja, actuar onde se puder, nomeadamente a nível de opções de configuração do SGBD, hardware, etc...
Mas como medir a performance ? Que indicadores escolher ? Hoje em dia quase todos os SGBD têm opções, plugins ou ferramentas para obter indicadores acerca do desempenho do SGDB. Devemos recolher essa informação e interpretá-la para alterar o que for necessário.
Vamos a um exemplo: Vamos imaginar que temos um sistema que está suportado pelo PostgreSQL. Neste SGBD existe uma opção para obter estatisticas. Um dos indicadores que podemos obter, chamado pg_stat_all_indexes (é uma tabela) dá-nos informação importante sobre a utilização dos índices das tabelas. Com esta informação podemos afinar os índices que nos dêm mais problemas, ou então podemos usar uma das tabelas pg_stat_io_* que nos dão informações sobre a performance de I/O da Base de Dados, ao analizar estes valores podemos descobrir que temos que optimizar a configuração do sistema de armazenamento...
Isto é só a ponta do iceberg... há imensas opções diferentes e abordagens que variam conforme o SGBD usado, o hardware, etc...
Por agora espero que tenham ficado com a ideia geral...
Até breve !
2007-05-14
Velocidades...
Boas,
Na base de um qualquer sistema de informação (afinal o assunto principal deste blog), existe sempre uma Base de Dados. Ora, as bases de dados, ou melhor, os sistemas de gestão de bases de dados não são um arquivo morto de dados mas sim um ponto fundamental da arquitectura e desempenho dos sistemas de informação.
Como deve ser (será ?) óbvio a arquitectura, o desenvolvimento e a manutenção da dita base de dados são pontos de extrema importância na criação e evolução dos sistemas de informação.
Esta introdução resume a minha opinião sobre a importância deste tema, e também para apresentar uma históriazinha:
Era uma vez um sistema de informação (vulgo ERP) sustentado por uma base de dados não muito grande (< 20 GiB) que demorava cerca de 17 horas (eu escrevo outra vez, 17 horas) a fazer um fecho de mês. Colocado o problema a um dos programadores do sistema, este respondeu: "eh pá isso é muito, deviam ser aí umas 8 ou 9 horas !!"...
(cai o pano para evitar mais vergonhas)
8 ou 9 horas para fazer umas contas a stocks e custos, enfim... será preciso mais para tirar a conclusão lógica ?
Será que isto é um sistema vagamente optimizado ??
Por hoje não digo mais nada...
Na base de um qualquer sistema de informação (afinal o assunto principal deste blog), existe sempre uma Base de Dados. Ora, as bases de dados, ou melhor, os sistemas de gestão de bases de dados não são um arquivo morto de dados mas sim um ponto fundamental da arquitectura e desempenho dos sistemas de informação.
Como deve ser (será ?) óbvio a arquitectura, o desenvolvimento e a manutenção da dita base de dados são pontos de extrema importância na criação e evolução dos sistemas de informação.
Esta introdução resume a minha opinião sobre a importância deste tema, e também para apresentar uma históriazinha:
Era uma vez um sistema de informação (vulgo ERP) sustentado por uma base de dados não muito grande (< 20 GiB) que demorava cerca de 17 horas (eu escrevo outra vez, 17 horas) a fazer um fecho de mês. Colocado o problema a um dos programadores do sistema, este respondeu: "eh pá isso é muito, deviam ser aí umas 8 ou 9 horas !!"...
(cai o pano para evitar mais vergonhas)
8 ou 9 horas para fazer umas contas a stocks e custos, enfim... será preciso mais para tirar a conclusão lógica ?
Será que isto é um sistema vagamente optimizado ??
Por hoje não digo mais nada...
Subscrever:
Mensagens (Atom)