anolan yamilé milanés barrientos uma arquitetura para auto ...postgresql/conteudo/... · 3.2...

Anolan Yamilé MilanésBarrientos

Uma arquitetura paraauto-sintonia global deSGBDs usando agentes

DISSERTAÇÃO DE MESTRADO

DEPARTAMENTO DE INFORMÁTICA

Programa de Pós�graduação em Ciências

da Computação

Rio de Janeiroabril de 2004

Anolan Yamilé Milanés Barrientos

Uma arquitetura para auto-sintoniaglobal de SGBDs usando agentes

Dissertação de Mestrado

Dissertação apresentada como requisito parcial para obten-ção do grau de Mestre pelo Programa de Pós�graduaçãoem Ciências da Computação do Departamento de Informá-tica da PUC-Rio

Orientador: Prof. Sérgio Lifschitz

Rio de Janeiroabril de 2004


Uma arquitetura para auto-sintoniaglobal de SGBDs usando agentes

Dissertação apresentada como requisito parcial para obten-ção do grau de Mestre pelo Programa de Pós�graduaçãoem Ciências da Computação do Departamento de Informá-tica do Centro Técnico Cientí�co da PUC-Rio.Aprovadapela Comissão Examinadora abaixo assinada.

Prof. Sérgio LifschitzOrientador

Departamento de Informática � PUC-Rio

Prof. Fabio André Machado PortoIME-RJ

Prof. Geraldo Bonorino XexéoDCC/IM UFRJ

Prof. José Eugênio LealCoordenador Setorial do Centro Técnico Cientí�co �

PUC-Rio

Rio de Janeiro, 14 de abril de 2004

Todos os direitos reservados. É proibida a reproduçãototal ou parcial do trabalho sem autorização da univer-sidade, do autor e do orientador.


Ficha Catalográ�caBarrientos, Anolan Yamilé Milanés

Uma arquitetura para auto-sintonia global deSGBDs usando agentes/ Anolan Yamilé Milanés Bar-rientos; orientador: Sérgio Lifschitz. � Rio de Janeiro :PUC-Rio, Departamento de Informática, 2004.

v., 81 f: il. ; 29,7 cm

1. Dissertação (mestrado) - Pontifícia UniversidadeCatólica do Rio de Janeiro, Departamento de Informá-tica.

Inclui referências bibliográ�cas.

1. Informática � Teses. 2. Banco de dados. 3. Agen-tes de software. 4. Sintonia global. 5. Auto-sintonia. I.Lifschitz, Sérgio. II. Pontifícia Universidade Católica doRio de Janeiro. Departamento de Informática. III. Título.

CDD: 004

A Paula y Sebastian, por el tiempo perdido. Aos meus pais e irmã.

Agradecimentos

Chegada a página mais difícil por todos aqueles que irão �car injusta-

mente fora por causa do espaço e da minha memória, quero aproveitar de

qualquer jeito para agradecer a todas as pessoas que intervieram de alguma

forma com que este trabalho tenha sido �nalmente terminado.

A minha mãe, pela sua valiosa ajuda durante quase meio ano. A minha

irmã pela sua ajuda quase o tempo todo.

Aos amigos do Labpos, em especial a Silvana, Cláudio, Renato, Thiago

(e Sergina), Sebastián e Paula, pela ajuda e simpatia nas horas difíceis.

À Marcos V. Salles, que não economizou horas de ajuda e de quem

aprendi muito nesse tempo de trabalho em conjunto.

Ao pessoal da Secretaria pela ajuda e in�nita paciência.

A Carmen pela simpatia, a conversa e o lanchinho.

Aos amigos de Cuba, ao Pruza, à Danays e à professora Lucina Garcia

da Universidade da Havana e ao Msc. Hector Dache, sem a ajuda dos quais

teria sido impossível começar o mestrado.

Ao CNPq e à PUC�Rio, pelos auxílios concedidos, sem os quais este

trabalho não poderia ter sido realizado.

E �nalmente ao departamento de Informática pela oportunidade única

de estudar aqui e pelo ótimo ambiente que tem mantido todo esse tempo,

e em especial ao meu orientador o Professor Sérgio Lifschitz por me dar a

oportunidade de realizar um trabalho tão interessante e complexo. Obrigada

pela simpatia, ajuda e ensinamento durante o período de realização deste

trabalho.

Resumo

Barrientos, Anolan Yamilé Milanés; Lifschitz, Sérgio. Uma arqui-tetura para auto-sintonia global de SGBDs usando agentes.Rio de Janeiro, 2004. 81p. Dissertação de Mestrado � Departa-mento de Informática, Pontifícia Universidade Católica do Rio deJaneiro.

O aumento da complexidade dos SGBDs comerciais e a carga que supor-

tam, além da crescente utilização destes por pessoal pouco familiarizado

com a administração de bancos de dados, entre outras causas, sugerem a

introdução de técnicas que automatizem o processo de sintonia de bancos de

dados. A auto-sintonia (self-tuning) é uma característica que faz os sistemas

se adaptarem para manter um bom desempenho, reduzindo a interação do

administrador com o sistema. Este trabalho propõe uma abordagem para

o ajuste automático dos parâmetros em um SGBD usando agentes de soft-

ware. A tarefa de sintonia é tratada nesta pesquisa como um problema glo-

bal, dado que alterações de um parâmetro podem se re�etir em outros. Os

detalhes da arquitetura, sua implementação e avaliação de funcionamento

são também discutidos nesta dissertação.

Palavras�chave

Banco de Dados; Auto-sintonia; Sintonia Global; Agentes de Software

Abstract

Barrientos, Anolan Yamilé Milanés; Lifschitz, Sérgio. An agent-based architecture for DBMS Global Self-tuning. Rio deJaneiro, 2004. 81p. MSc. Dissertation � Departamento de Infor-mática, Pontifícia Universidade Católica do Rio de Janeiro.

The increasing complexity of the commercial DBMSs as well as the workload

they manage, besides the fact that many users do not have deep knowledge

about database administration, among other reasons, strongly suggests the

introduction of techniques that automates the database tuning process. Self-

Tuning, or auto-tuning, is a feature that makes systems adaptable in order

to keep a good overall performance, reducing as possible the interaction

between the administrator and the system. This work proposes an approach

for the automatic tuning of DBMSs parameters using an architecture based

on software agents. We consider tuning as a global issue, given that changes

of a single parameter can be re�ected in others. The architecture details,

its implementation and a practical evaluation are also discussed in this

dissertation.

Keywords

Databases; Self-Tuning; Global Tuning; Software Agents

Conteúdo

1 Introdução 11

2 Auto-sintonia de sistemas de bancos de dados 132.1 Agentes 132.2 A arte da sintonia de desempenho 162.3 Auto-Sintonia 192.4 Trabalhos relacionados 222.5 Operação do sistema de auto-sintonia 262.6 Motivação da pesquisa 342.7 Conclusões 35

3 Arquitetura 363.1 Requisitos 363.2 Propostas de Arquitetura 393.3 Abordagem centralizada 413.4 Abordagem distribuída 433.5 Agentes na arquitetura 483.6 Conclusões 48

4 Implementação 494.1 Infra-estrutura 494.2 Exemplo de aplicação 594.3 Ambiente de desenvolvimento 604.4 Aspectos de implementação 634.5 Conclusões 65

5 Conclusões e Contribuições 665.1 Resumo 665.2 Principais contribuições 665.3 Conclusões 675.4 Trabalhos futuros 68

Referências Bibliográ�cas 68

A Anexo 76A.1 Substituição de páginas em cache 76A.2 Nível de Multiprogramação 78

Lista de Figuras

2.1 Arquiteturas de integração de agentes em SGBDs [66]. 152.2 Desempenho da transação em função do MPL limite [66]. 172.3 Cadeia de Consumo em SGBDs [36] 312.4 Etapas de um processo de auto-sintonia [11] 34

3.1 Abordagem centralizada para auto-sintonia global 423.2 Arquitetura distribuída para auto-sintonia global 43

4.1 Framework para a construção de agentes [33] 504.2 Processo executado pelas camadas de Crença, Raciocínio e Ação

para o controle da estratégia de substituição de páginas em bu�er. 524.3 Envio de uma mensagem 544.4 Recebimento de uma mensagem (comunicação assíncrona) 554.5 Interações no sistema de auto-sintonia 574.6 Atividade do sistema em um evento de violação de razão de

con�itos 63

A.1 A estratégia LRU toma uma página limpa do extremo LRU dacache 77

A.2 O princípio de trabalho do controle de carga orientado a con�itos[66]. 79

Lista de Tabelas

3.1 Satisfação dos requisitos propostos para um sistema de auto-sintonia global de SGBDs na arquitetura. 47

1

Introdução

Os Sistemas de Gerência de Bancos de Dados (SGBDs) atuais oferecem

um grupo de parâmetros que permitem modi�car a alocação de recursos1 no

sistema. A modi�cação desses parâmetros de forma a satisfazer os objetivos

dos usuários em cada contexto é chamada de sintonia (tuning). A sintonia de

SGBDs é una tarefa rotineira que exige dos DBAs (Database Administrators

- Administradores de Bancos de Dados) uma alta dose de criatividade,

conhecimentos e dedicação. A situação ideal seria, entretanto, que os SGBDs

conseguissem se adaptar às mudanças no ambiente de forma que o DBA

pudesse se ocupar de tarefas relacionadas com a gerência dos dados.

Vários trabalhos têm sido realizados objetivando resolver o problema

da auto-sintonia (self-tuning) de sistemas de computação em geral e de

SGBDs em particular [34]. A grande maioria deles se concentra em compo-

nentes ou problemas isolados, sendo chamados na literatura de mecanismos

de auto-sintonia local. As interações que existem entre os componentes do

sistema podem provocar, no entanto, que ações executadas por um meca-

nismo de auto-sintonia local afetem outros componentes e, como conseqüên-

cia, se deteriore o desempenho do sistema. Isso leva à necessidade de adotar

uma visão global do problema da auto-sintonia de SGBDs. Essa abordagem

tem sido adotada em trabalhos como [8, 9, 28, 39, 68].

A presente proposta se concentra no estudo dos aspectos relacionados

ao tema da auto-sintonia global de SGBDs usando agentes de software.

Sua motivação está na elaboração do contexto global onde o mecanismo de

auto-sintonia de índices proposto em [11] seria inserido. Seguimos a linha de

trabalho do nosso grupo de pesquisa cujo interesse é a utilização de agentes

de software para aumentar as funcionalidades dos sistemas de bancos de

dados [40, 50].

Os trabalhos de auto-sintonia global podem dividir-se naqueles que

visam a criação de novos sistemas de bancos de dados orientados a desem-

penho, e naqueles que procuram melhorar a adaptabilidade dos sistemas

1Recursos são aqueles componentes de hardware e software que formam o sistema.

Uma arquitetura para auto-sintonia global de SGBDs usando agentes 12

atuais incluindo componentes de auto-sintonia [34]. O objetivo dessa pes-

quisa é criar um componente de auto-sintonia global baseado em agentes

que possa ser embutido dentro de um SGBD classi�cando-se, pois, dentro

da segunda vertente.

A principal contribuição desse trabalho é propor uma arquitetura de

auto-sintonia global baseada em agentes que atende aos principais requisitos

observados na literatura e enumerados aqui. Como contribuições adicionais

podemos mencionar a classi�cação e discussão de sistemas de auto-sintonia

locais e globais e a implementação de um protótipo para avaliação da

complexidade de desenvolvimento e e�cácia das idéias aqui propostas na

prática, utilizando o SGBD PostgreSQL.

Entre as vantagens que apresenta a introdução de agentes no projeto

e implementação dessas arquitetura está a facilidade de integração de novos

mecanismos de auto-sintonia. Estes podem ser acrescentados progressiva

e independentemente um do outro, sendo a sua inter-relação gerenciada

pelo sistema. Esta é uma grande diferença entre esse trabalho e propostas

anteriores, em que os sistemas de auto-sintonia têm sido sempre tratados

centralizadamente dentro do contexto do SGBD.

No próximo capítulo serão comentados brevemente alguns aspectos

relacionados com o tema de agentes de software e será apresentado um

panorama do problema da auto-sintonia em SGBDs, assim como algumas

abordagens de solução. No capítulo 3 são enumerados os requisitos que

devem ser satisfeitos por um sistema de auto-sintonia e discutidas as

possíveis arquiteturas para sua construção usando agentes. No capítulo 4

é detalhada a implementação de um protótipo do sistema proposto. O

capítulo 5 apresenta as conclusões dessa dissertação e possíveis extensões.

2

Auto-sintonia de sistemas de bancos de dados

Este capítulo apresenta os conceitos relacionados à auto-sintonia de

SGBDs abordadas nesta dissertação incluindo agentes de software e sintonia

de desempenho. Também discute os desa�os decorrentes do problema de

auto-sintonia e as abordagens propostas. Finalmente, as considerações

assumidas ao longo do trabalho e as motivações para a presente pesquisa

serão expostas.

Uma introdução aos termos relacionados com desempenho pode ser

consultada em [34], trabalho que contém um estado da arte em auto-sintonia

de SGBDs relacionais.

2.1Agentes

Embora o tema de agentes de software1 venha sendo estudado pela

área de Inteligência Arti�cial desde os anos 80 [48, 70] e pela área de Enge-

nharia de Software nos últimos anos [19, 33], ainda não existe um consenso

quanto às características que todo agente deve ter. Por enquanto, autono-

mia, reatividade, sociabilidade e pró-atividade são as mais aceitas [73]:

� Autonomia: capacidade de agir/reagir para atingir um objetivo sem a

intervenção de humanos, tendo algum controle sobre suas atitudes;

� Reatividade: a partir de percepções sobre o que ocorre no ambiente

possui a capacidade de responder a mudanças para que seus objetivos

sejam atingidos;

� Pró-atividade: agir para manter a possibilidade de atingir seus obje-

tivos, antecipando-se a mudanças no ambiente;

� Sociabilidade: capacidade de interagir com outros participantes do

ambiente.1Nesse trabalho serão chamados simplesmente de agentes


Os agentes podem ser classi�cados, entre outras formas, segundo a sua

característica de agência: fraca ou forte [73]. Agentes de agência fraca são

aqueles que possuem as características citadas acima. Os de agência forte,

também chamados agentes inteligentes, deverão possuir a mais a capacidade

de raciocínio (rationality), podendo ser atribuídas noções mentais como

conhecimento, intenção e compromisso.

No contexto de agência forte outro atributo importante é o apren-

dizado. O aprendizado é essencial quando o agente tem um conhecimento

incompleto do ambiente [48]. A idéia é aproveitar as experiências para me-

lhorar a habilidade do agente atuar no futuro. O agente aprende durante

sua interação com o ambiente e pela observação dos resultados do seu pró-

prio processo de tomada de decisões. Existe uma forte relação entre este

atributo e a autonomia: um sistema é autônomo na medida em que seu

comportamento está determinado por sua própria experiência [48].

Agentes são encontrados com freqüência formando uma organiza-

ção com outros agentes. Estas organizações são chamadas sistemas multi-

agentes (Multi-Agent Systems: MAS ) [73]. Um ponto crítico nos MAS é a

interação entre os agentes. Os propósitos dos agentes podem ser con�itantes

e devem, portanto, ser coordenados. A coordenação pode ser feita por um

agente coordenador dedicado ou por uma comunicação ponto a ponto, onde

os agentes interagem descentralizadamente. A cooperação é a coordenação

entre agentes não antagônicos enquanto a negociação é a coordenação entre

agentes competitivos ou "egoístas" [24]. Um MAS coerente é um sistema de

agentes que se comporta como uma unidade. O problema de como manter

a coerência do sistema sem um controle global explícito deve ser resolvido

através da coordenação, junto com a de�nição de "compromissos sociais"2,

de forma a resolver os con�itos entre os interesses locais e os objetivos da

sociedade. Existem várias soluções para esse problema, entre elas aquelas

baseadas em mecanismos de mercado [24].

O desenho de um MAS abrange não somente o desenho de cada

agente individual mas, também, os mecanismos de coordenação que lhes

permitem relacionar-se dentro da sociedade para atingir seus objetivos. As

características mais importantes destes sistemas são:

� cada agente tem informação incompleta e restrita das suas possibili-

dades;

� o controle do sistema é distribuído;

2compromissos de um agente com outro que permitem restringir o comportamentodos agentes dentro do sistema.


� os dados estão descentralizados;

� a computação é assíncrona.

A abordagem de um sistema multi-agentes se justi�ca nos casos em que

a tarefa pode ser melhor resolvida por uma sociedade de múltiplos agentes

que por um agente só. Dado que o uso de agentes pode introduzir uma

sobrecarga desnecessária nas aplicações que não precisam desse paradigma,

seu uso deve ser bem analisado em cada caso.

2.1.1Agentes em SGBDs

A questão da construção de SGBDs baseados em agentes foi levantada

em [40], onde são propostas as três arquiteturas para agentes em SGBDs

apresentadas na �gura 2.1.

Figura 2.1: Arquiteturas de integração de agentes em SGBDs [66].

Estas são:

1. Arquitetura em camadas: Permite implementar agentes sobre SGBDs

existentes sem ter praticamente que modi�car o SGBD objetivo. A

ação dos agentes é limitada pois devem acessar os componentes do

SGBD via as interfaces oferecidas.

2. Arquitetura Embutida: Os agentes são embutidos dentro de SGBDs

já construídos para aumentar e estender suas funcionalidades. Esta

arquitetura tem limites impostos pelas funcionalidades oferecidas pelo

SGBD.

3. Arquitetura Integrada: Os componentes do SGBD são implementados

como subsistemas de agentes. A integração dos agentes no sistema

aporta mais �exibilidade e controle que nas outras arquiteturas, ao

mesmo tempo que traz mais di�culdades de implementação.


Assim como os SGBDs baseados em agentes, os sistemas de bancos

de dados ativos conseguem reagir a mudanças de estado sem intervenção

humana [5]. Algumas vantagens podem ser citadas a favor da tecnologia de

agentes, como a quase ilimitada persistência das intenções, a possibilidade

de retornar o resultado das ações, a capacidade de controlar cenários

dinâmicos em tempo real e o fato de que algoritmos complexos de raciocínio

são mais facilmente implementados em arquiteturas de agentes. Estas razões

sugerem o uso de agentes em lugar de sistemas de bancos de dados ativos

para aplicações que exigem adaptabilidade, autonomia e inteligência como

a auto-sintonia de SGBDs.

2.2A arte da sintonia de desempenho

A sintonia de desempenho (performance tuning) consiste na realização

de ajustes em um sistema (seja um SGBD ou um sistema de computação

qualquer) para uma carga de trabalho especí�ca visando obter um melhor

desempenho das aplicações ao otimizar a utilização dos recursos computa-

cionais disponíveis.

O desempenho pode ser de�nido como a e�ciência com que um

sistema atinge seus objetivos. Os sistemas podem fornecer determinados

parâmetros de controle que permitam ajustar a alocação dos recursos e,

como conseqüência, mudar o desempenho. O desempenho de um sistema

pode ser caracterizado através da observação de três classes de métricas [7]:

1. Métricas de Con�guração: são características que não mudam ajus-

tando os parâmetros de controle, como a quantidade de memória e a

velocidade da CPU.

2. Medidas de Desempenho ou Métricas de Nível de Serviço: As medidas

mais usadas para avaliar o desempenho de um SGBD são a vazão

e o tempo de resposta. A vazão (throughput) é uma medida de

produtividade que corresponde à quantidade de trabalho executada

pelo sistema durante um dado período de tempo. O tempo de resposta

é o tempo de processamento das requisições submetidas ao sistema.

3. Métricas de carga de trabalho: designa todo o processamento de

requisições submetidas ao sistema pelo usuário durante um dado

intervalo de tempo. Em [64] é proposto um conjunto de parâmetros

para a caracterização da carga de trabalho em bancos de dados.


Estes são: a localidade de acesso ou de referência, o comprimento

das transações, a proporção de operações de escrita das transações, o

nível de multiprogramação e a taxa de chegada das consultas.

A satisfação do usuário com o desempenho do sistema é que de�ne o

�m do processo de sintonia.

Chamada às vezes de arte, a sintonia de SGBDs ainda é uma tarefa

que tem muito de empírico e requer, com freqüência, as habilidades e

imaginação de administradores experimentados [49]. A di�culdade que essa

tarefa apresenta tem causas técnicas e subjetivas. Entre as causas técnicas

podemos mencionar o grande número de ajustes diferentes que podem

resolver um dado problema de desempenho, as fortes inter-relações que

existem entre os recursos, assim como entre os recursos e a carga de trabalho,

e o escasso conhecimento que existe ainda sobre essas inter-relações [56].

Um exemplo da complexidade que as interferências entre as diferentes

cargas de trabalho acrescentam à sintonia é descrito em [66]. É comparada

a complexidade do problema do controle do nível de multiprogramação

(MultiProgramming Level - MPL) para uma carga homogênea e para uma

mistura de cargas, conforme mostrado na �gura 2.2. Aqui é notável a

in�uência da carga no valor ótimo do parâmetro, cuja determinação se torna

mais complexa na mistura de cargas heterogêneas.

Figura 2.2: Desempenho da transação em função do MPL limite [66].

No primeiro caso, pode-se notar na �gura que o valor ótimo para o

parâmetro MPL é 20, pois é com esse valor que o tempo médio de resposta

do sistema é menor para essa carga de trabalho. No casso da mistura de

cargas é mais difícil a determinação do MPL ótimo. A escolha do valor

ótimo de uma carga como valor para o parâmetro MPL otimiza o tempo de

resposta para essa carga, mas piora para as outras.


As causas subjetivas da complexidade da tarefa de sintonia se devem

fundamentalmente ao fato de que a tarefa habitual do SGBD é oferecer ser-

viços a seres humanos. Isso deriva, por exemplo, na di�culdade para de�nir

prioridades no processamento de consultas dado que muitas vezes os crité-

rios são basicamente empresariais, di�cilmente de�nidos automaticamente.

O fator subjetivo na tarefa de sintonia é um poderoso voto contra a

possibilidade da sua total automatização em sistemas de bancos de dados.

Dessa forma, a idéia de integrar componentes de auto-sintonia em SGBDs

é eliminar o máximo possível as tarefas rotineiras de modo que os DBAs

(DataBase Administrators) possam se concentrar na verdadeira gerência

dos dados.

O processo de sintonia depende fortemente do contexto da aplicação.

Este inclui o tipo de aplicação, a relevância da informação gerenciada e a

estabilidade do sistema. Aplicações de comércio eletrônico, por exemplo,

demandam respeitar limites nos tempos de resposta de forma a evitar a

desistência dos usuários.

A relevância da informação é determinante em cenários nos quais

decisões de sintonia podem melhorar notavelmente o desempenho do banco

colocando em risco, por outro lado, a integridade dos dados. Este é o

caso, por exemplo, da opção que permite desabilitar fsync (fsync-disabling)

no SGBD PostgreSQL, conforme descrito em [65]. Quando fsync está

habilitado, é o backend do PostgreSQL que decide quando serão salvos

(�ushed) os dados a disco. Por outro lado, com fsync desabilitado é o

sistema operacional que decide. As escritas em disco nesse caso serão menos

freqüentes aumentando o desempenho do sistema de banco de dados. Mas

poderá acontecer que dados já con�rmados (commited) que estiverem ainda

em memória sejam perdidos em caso de uma falha de hardware. O valor

pré-determinado de fsync é habilitado. Em ambientes onde as falhas de

hardware são improváveis e as informações não são críticas, desabilitar este

parâmetro é uma opção a se levar em conta.

A postura de tentar resolver os problemas de desempenho depois des-

tes terem se manifestado, também chamada de postura reativa, é cada vez

mais difícil de se manter por causa do aumento das exigências dos sistemas

atuais e das cargas a que estes são submetidos [55]. Vários trabalhos têm

discutido a necessidade de passar de posturas reativas a pró-ativas, que se

antecipem aos problemas de forma a tentar evitar que estes aconteçam. Em

[55] propõe-se uma metodologia chamada de Total Performance Manage-

ment - TPM em que, após concluído o processo de sintonia, se executa

uma etapa de detecção e alerta de problemas potenciais. Em [64] depois de


concluídas as etapas que são chamadas no trabalho de diagnóstico e terapia

(ou resolução de problemas) executa-se uma etapa de previsão de desempe-

nho que estima a evolução da carga e permite determinar quando o sistema

deverá ser ajustado novamente. A indústria de sistemas para gerência de sis-

temas de bancos de dados tem assumido em grande parte esta postura [34].

Por exemplo, a informação coletada pelas ferramentas da suíte de gerência

de desempenho da Veritas Software [63] é consolidada e armazenada em

um repositório chamado Performance DataWarehouse. Análises históricas

sobre os dados armazenados nesse repositório permitem antecipar alertas

ante problemas potenciais.

A complexidade que apresenta a tarefa de sintonia tem motivado o

desenvolvimento de várias ferramentas de ajuda ao DBA na tomada de

decisões de sintonia. Algumas delas, baseadas em Sistemas Especialistas

(Expert Systems), Raciocínio Baseado em Casos (Case Based Reasoning -

CBR) e Redes Neurais, são destacadas em [28]. O objetivo desses sistemas

é apenas sugerir ações: não inclui a execução dessas ações.

2.3Auto-Sintonia

Os sistemas com auto-sintonia devem ser capazes de escolher os valores

ótimos dos parâmetros de forma a satisfazer os requisitos de desempenho

previamente estabelecidos pelo administrador ou usuário do sistema. São

tarefas de um sistema com auto-sintonia executar tanto processos que

tenham por objetivo resolver problemas que prejudiquem ou que podem

prejudicar a perspectiva do cliente como processos que visem melhorar o

desempenho do sistema.

No caso particular de SGBDs, alguns administradores são contrários

à idéia da auto-sintonia, dado que consideram que a maioria dos problemas

desses sistemas se devem à implementação ine�ciente das aplicações3.

Certamente, um sistema de auto-sintonia pode não ser a melhor alternativa

em todos os casos. Entretanto, podemos identi�car algumas situações em

que o seu resultado pode ser vantajoso:

1. Dado que o desempenho do sistema depende intimamente da carga de

trabalho, assim que esta mudar o sistema pode precisar ser sintonizado

novamente. Por este motivo, a automatização do processo de sintonia

3The limits of self-tuning,http://www.computerworld.com/news/2002/story/0,11280,73890,00.html


é essencial se a freqüência com que a carga de trabalho do sistema

varia for alta [18].

2. Em instalações cujas dimensões não justi�quem o alto custo de um

DBA que gerencie a complexidade e requisitos de desempenho dos

sistemas atuais [2, 66].

3. Novos paradigmas como a computação ubíqua (Ubiquitous Compu-

ting) [71] procuram isolar o usuário das particularidades do sistema.

A auto-sintonia de SGBDs embutidos em dispositivos construídos se-

guindo esses paradigmas é uma necessidade.

Outro argumento contra a auto-sintonia é o fato de que a sua integra-

ção com o SGBD implica em uma carga adicional concorrendo pelos recursos

do sistema. Uma decisão errada pode piorar o problema de desempenho e

erros de programação ou concepção podem deixar um sistema, até então

considerado robusto, fora de uso. A qualidade da implementação do sistema

de auto-sintonia é crítica para o seu sucesso. Deve-se ter cuidado para não

prejudicar o desempenho do SGBD, assim como conseguir diagnosticar os

problemas mais signi�cativos de desempenho que o sistema possa sofrer. Os

requisitos que um sistema de auto-sintonia deve cumprir serão enumerados

na seção 3.1.

Nesse trabalho se considerará que o sistema oferece uma interface mí-

nima com o usuário. Na prática, no entanto, é desejável que o sistema de

auto-sintonia ofereça ao administrador a possibilidade de intervir no pro-

cesso de sintonia, monitorando-o ou decidindo quais ações serão executa-

das. Por este motivo, deveremos considerar como sistema com auto-sintonia

aquele que possua a capacidade de executar ações sem intervenção humana,

ainda quando essa possibilidade estiver disponível.

2.3.1Considerações

1. A sintonia envolve a otimização da utilização dos recursos pre-

existentes no sistema. Nesse trabalho não serão consideradas soluções

que impliquem acrescentar recursos de hardware.

2. Nesse trabalho será considerada como parte da atividade de sintonia

de desempenho a resolução de problemas de deterioração de desempe-

nho, bem como os processos que geram con�gurações iniciais ótimas

dos parâmetros do SGBD.


3. Apesar de estarem muito relacionados, o conceito de sintonia é dife-

rente da tarefa de planejamento de capacidade, que consiste em de-

terminar a con�guração de um sistema ainda inexistente de forma a

suportar as cargas de trabalho estimadas.

4. A sintonia �m a �m4 de um sistema requer a análise de todos os

seus componentes, ou seja, tanto o sistema de banco de dados como

o sistema operacional e a aplicação. A proposta de [55] é executar

a sintonia procurando o gargalo em cada sub-sistema. Em seguida,

estudar as interações entre eles e estreitar o espaço de busca voltando a

atenção para o sub-sistema suspeito. Para os efeitos dessa dissertação,

entretanto, não serão considerados casos que requeiram a sintonia da

aplicação ou do sistema operacional, devido à elevada complexidade

desse problema. A integração de todas as camadas da aplicação para

uma completa gerência dos sistemas também é tratada em [29].

5. Para a de�nição dos valores esperados das métricas de desempenho

pode-se assumir duas alternativas: uma é calcular o melhor valor

possível para cada parâmetro com base nos recursos disponíveis.

Outra é permitir ao administrador do sistema especi�car níveis de

serviço ou objetivos (Service Level Agreements - SLAs) que serão

então mapeados pelo sistema para valores de parâmetros de controle.

Nesse trabalho estaremos considerando somente a primeira opção, pois

entendemos que a mesma abrange os problemas mais importantes

relativos à auto-sintonia de sistemas de banco de dados, e não requer

a construção de interfaces com o usuário, uma tarefa que está fora do

escopo da dissertação.

2.3.2Abordagem global à auto-sintonia

Uma abordagem freqüente ao problema da auto-sintonia consiste em

usar algoritmos isolados, como os apresentados em [34]. Porém, interações

tanto entre os componentes do sistema como entre as cargas de trabalho

podem gerar deterioração do desempenho como conseqüência das próprias

ações de auto-sintonia. Por outro lado, um problema de contenção em

um recurso pode-se re�etir em outro e ser erroneamente interpretado pelo

mecanismo de auto-sintonia local que o controla.

4Aquela que abrange todos os subsistemas envolvidos na execução da aplicação


Isto leva à idéia de um sistema de sintonia global [8, 11, 42, 66]

diferente da idéia da sintonia como a combinação não coordenada de ajustes

especí�cos para problemas ou componentes determinados. As interações

entre os componentes podem fazer com que mudanças em um parâmetro

afetem outros e devem por isso ser consideradas.

Por exemplo: colocando-se todas as páginas de índices em memória,

melhora-se o desempenho de buscas indexadas. Igualmente, aumentando-

se os bu�ers mantêm-se por mais tempo os dados na memória principal,

o que diminui os acessos e a contenção de disco. Mas estas ações podem

deixar pouca memória disponível para ordenação ou hash e em função

disso, o otimizador de consultas poderia escolher planos de execução menos

e�cientes para determinadas consultas, comprometendo o desempenho do

sistema.

2.4Trabalhos relacionados

Trabalhos anteriores têm proposto a implementação de sistemas de

auto-sintonia global para sistemas de computação em geral e de bancos de

dados em particular [34]. Em [8] sugere-se um processo em que um agente

único com visão global do sistema executa as funções de análise dos dados

coletados pelos sensores e armazenados em um repositório comum. Como

resultado dessa análise são acionados mecanismos para efetuar ações de

controle.

Em [28] descreve-se a tecnologia dos ATS (Automated Tuning Sys-

tems), cuja operação coincide em essência com a proposta de [8]. Além dos

comentários sobre os desa�os técnicos apresentados pela construção desses

sistemas, esse trabalho propõe resolver o problema da integração dos ATSs

para garantir determinados níveis de desempenho �m-a-�m. Essa integra-

ção seria atingida através de um ATS coordenador capaz de balancear os

requisitos de cada um dos ATSs do nível inferior dada sua visão global do

problema, o que sugere a colaboração entre os ATSs.

Em [7] descreve-se a implementação de um sistema baseado em agentes

para a auto-sintonia de sistemas genéricos. Esta generalidade é obtida

através de um modelo do sistema controlado que pode ser reconstruído

assim que mudam as características do sistema controlado. Este modelo

permite mapear os valores esperados de níveis de serviço em parâmetros de

controle.


No domínio de aplicação de bancos de dados as propostas para a auto-

sintonia de sistemas podem ser classi�cadas em dois grupos: aquelas que

propõem sistemas auto-sintonizáveis por projeto e aquelas que objetivam

a integração de componentes de auto-sintonia em bancos de dados já

existentes [34]. Assim, a proposta descrita em [12] baseia-se na complexidade

dos sistemas de bancos de dados atuais para propor a construção de um novo

tipo de SGBD mais simples, baseado em componentes. Esta simplicidade

facilitaria a modelagem e os ajustes. Atualmente está sendo desenvolvido

um protótipo seguindo essa abordagem [23] mas ainda não constam na

bibliogra�a sistemas deste tipo já prontos.

Representante da segunda vertente há o sistema apresentado em [39],

chamado Quartermaster, para auto-sintonia global de SGBDs no âmbito

de um sistema de comércio eletrônico. A arquitetura do Quartermaster

segue a linha daquelas descritas em [8, 28]. Constitui-se de um grupo

de módulos que são: o Monitor, o Planejador e o Controlador, os quais

executam respectivamente as funções de monitoramento, diagnóstico e ação.

O Quartermaster possui também módulos de interação com o usuário.

Um repositório armazena os objetivos, as medições dos parâmetros de

desempenho, regras e características da carga de trabalho, entre outros.

Apesar da sua arquitetura lhe permitir executar ações independentes, o

Quartermaster ainda deixa boa parte das decisões a cargo do administrador.

O módulo do Planejador foi descrito em [9].

A partir da documentação do SGBD e o conhecimento dos especialis-

tas, são criados um modelo de recursos, um modelo de carga de trabalho,

regras de diagnóstico e �nalmente uma árvore de diagnóstico. O processo

de diagnóstico consiste em atravessar a árvore de diagnóstico. Ele produz

um conjunto de recursos cujo ajuste é uma possível solução do problema de

desempenho. A determinação do ajuste que oferecerá o maior desempenho

é feita por algoritmos de auto-sintonia. A diferença de outros trabalhos, o

diagnóstico leva em conta vários recursos do sistema a partir de um modelo

de recursos que contém informação sobre os recursos e as relações entre

eles. A partir desse modelo podem determinar-se quais serão os efeitos de

um ajuste sobre os outros recursos e quais são os recursos que podem ter

afetado o desempenho de um recurso dado.

Finalmente, em [11] aborda-se o tema da integração dos estudos

existentes em auto-sintonia local dentro do contexto da proposta de uma

arquitetura baseada em agentes para a auto-sintonia de índices. O modelo de

auto-sintonia global proposto inclui um repositório onde são armazenadas

as operações executadas pelo agente de forma a evitar a execução de ações


que no passado tivessem afetado o desempenho do sistema. O modelo

prevê também a comunicação dos agentes de forma a garantir uma ação

combinada em favor do sistema como um todo.

Todas estas propostas utilizam como mecanismo de controle o ciclo

de controle fechado ou de realimentação (feedback control loop). O ciclo

de realimentação permite controlar continuamente a saída do sistema em

virtude do desconhecimento da função que relaciona os parâmetros de

con�guração e carga de trabalho com o desempenho do sistema [45].

As etapas em que deve ser dividida a auto-sintonia, por outro lado,

variam ligeiramente de uma proposta para outra. Assim, em [28] considera-

se que os passos a executar durante o processo de auto-sintonia devem ser

detecção, diagnóstico, ação e avaliação. Por outro lado, em [8] é sugerido

que o processo seja formado pelas etapas de de�nição de expectativas,

monitoramento de desempenho, análise e ação. A proposta de [66] inclui

somente três etapas, que são observação, predição e reação, diferente de [11],

que identi�ca quatro etapas de um Processo de Auto-Sintonia Genérico:

1. Coleta de informações: Monitoramento da parte do sistema onde está

sendo realizado a auto-sintonia.

2. Avaliação do sistema: Avaliação do desempenho baseado nas métricas

relacionadas ao nível do sistema e detecção da necessidade de adap-

tações. A escolha da métrica é uma grande di�culdade dado que é

muito dependente do caso em questão e as possíveis alternativas são

ora numerosas ora muito complexas.

3. Enumeração de possíveis alterações: Listagem das possíveis altera-

ções a serem realizadas quando é detectado que um componente não

está respondendo adequadamente. É a etapa que gera a maior sobre-

carga no sistema. São elaboradas várias alternativas calculando seus

ganhos/custos. Trata-se de um processo geralmente bastante oneroso

ao sistema e nem sempre a alternativa escolhida será a ótima.

4. Realização das alterações: alteração dos componentes do SGBD me-

diante o mecanismo de auto-sintonia.

No ciclo descrito em [30] como parte da arquitetura de computação

autonômica são propostas quatro etapas que podem ser mapeadas dire-

tamente às etapas propostas em [11]. Estas são: monitoramento, análise,

planejamento e ação.

O sistema é controlado através dos sensores (que coletam métricas

de desempenho) e os efetuadores (que ajustam a alocação dos recursos).


A operação do ciclo de controle transcorre como segue: o monitor coleta,

�ltra e consolida a informação captada pelos sensores. O analisador então

executa algoritmos de correlação e modelagem para detectar ou predizer

problemas de sintonia. Posteriormente, na etapa de planejamento, elabora-

se um plano de ação objetivando atingir os níveis de desempenho esperados,

plano este que é executado durante a etapa de ação. As particularidades de

cada uma dessas etapas, assim como os desa�os que apresentam as suas

implementações, serão discutidos na seção 2.5.2.

2.4.1De�nição do problema da con�guração ótima

A tarefa de auto-sintonia pode ser caracterizada como a otimização da

utilização dos recursos presentes em um sistema para atingir um determi-

nado objetivo com intervenção mínima do ser humano. A con�guração de

recursos é modi�cada através de parâmetros de controle. Chamamos de so-

lução de um problema de sintonia de desempenho a escolha de um conjunto

desses parâmetros (não necessariamente a combinação que ofereça o melhor

desempenho, dado que existem limitações de tempo e consumo de recur-

sos) que aplicados ao sistema gerem os melhores valores de níveis de serviço

possíveis para uma carga de trabalho dada, ou valores que se aproximem a

estes.

Em trabalhos anteriores [9, 64] a possibilidade de solução deste pro-

blema usando técnicas de otimização tem sido descartada. Outras soluções,

como a geração de modelos matemáticos5 são difíceis de aplicar devido à

complexidade associada à geração do sistema de equações. Igualmente os

modelos analíticos usualmente não são considerados pelas di�culdades da

sua elaboração para um sistema tão complexo como é um SGBD.

Considerando o fato de que as métricas de nível de serviço não são

independentes [18](podem inclusive ser contraditórias, como é o caso da va-

zão e o tempo de resposta em algumas situações) e dado o grande número

de soluções possíveis (sendo que o espaço de busca corresponde a todos

os valores possíveis dos parâmetros de sintonia acessíveis do sistema), o

problema pode ser formulado como um problema de Otimização Combina-

tória Multi-Objetivo (Multi-Objective Combinatorial Optimization Problem

- MOCO [14]). A resolução do problema usando esta abordagem deve gerar

5Um modelo matemático é formado por um conjunto de equações que tentam modelaro comportamento dinâmico do sistema.


um grupo de soluções e�cientes ou Pareto-ótimas6, as quais devem ser pos-

teriormente avaliadas por um "juiz", que nesse caso seria o próprio sistema.

Como resultado desta avaliação seria escolhida a solução mais conveniente,

considerando-se o valor de cada métrica de nível de serviço na solução pon-

derado pela relevância da métrica para o sistema em particular. Acreditamos

que essa abordagem oferece uma alternativa para a execução do processo

de con�guração inicial dos parâmetros de sintonia do SGBD.

2.5Operação do sistema de auto-sintonia

Nessa seção descreveremos a operação do sistema de auto-sintonia.

O sistema executa dois tipos de processos diferentes: estes são con-

�guração e ajuste. A seguir descrevemos em detalhes ambos os tipos de

processos.

2.5.1Con�guração

Este processo consiste na determinação dos valores iniciais dos parâ-

metros de con�guração que otimizem o desempenho do sistema e o ajuste

dos parâmetros de controle até atingir esses valores. A operação é similar

à do Con�guration Advisor do DB2 [32], que oferece recomendações para

a con�guração destes sistema. Ele deve ser executado no início da opera-

ção do sistema de auto-sintonia e toda vez que o sistema observado tivesse

mudado de tal forma que se justi�quem mudanças radicais. É altamente

recomendável que um processo desse gênero seja executado o�-line ou em

horários de pouca atividade, pois os modelos podem incluir imprecisões que

prejudiquem o desempenho.

A determinação dos parâmetros em [32] se baseia na modelagem ana-

lítica do sistema combinando informação relacionada com características do

ambiente que são especi�cadas pelo usuário, as características do sistema e

o conhecimento de especialistas em sintonia do DB2. Os resultados experi-

mentais indicam que as soluções obtidas não melhoram aqueles obtidos por

especialistas em sintonia, mas ultrapassam de forma considerável o desem-

penho do sistema com os valores de con�guração pré-determinados.

6Não existe uma outra solução viável que melhore pelo menos um e não piore nenhumdos objetivos.


Após terminado o processo de con�guração e com o sistema já servindo

a cargas de trabalho reais, é possível iniciar o processo de auto-sintonia

(comentado a seguir) que objetiva ajustar parâmetros de controle do SGBD

de forma a melhorar o seu desempenho.

2.5.2Processo de auto-sintonia genérico

Nessa seção são analisados brevemente os desa�os para a implemen-

tação das distintas etapas do processo de auto-sintonia. Assumiremos aqui

como etapas do processo a observação, a análise, o planejamento e a ação.

Observação

O monitoramento ou observação é a primeira e mais importante etapa

do ciclo de controle [66]. Trata-se da captura de uma imagem do estado do

sistema em intervalos que dependem da dinâmica de cada parâmetro.

Vários problemas comprometem esta etapa:

� Existe um compromisso entre o fato de que a observação deve ser

pouco intrusiva para não interferir nos resultados nem sobrecarregar

o sistema e que a freqüência de execução deva ser su�cientemente alta

para garantir a acurácia da medição e a reação imediata em caso de

problemas de sintonia.

� A escolha das métricas que caracterizam o desempenho do sistema é

um dos problemas fundamentais a resolver nesta etapa [66]. Devem ser

preferivelmente independentes de outras variáveis como, por exemplo,

o tempo de observação.

� Normalmente as informações coletadas são armazenadas para poste-

rior análise em um repositório de histórico. Dependendo da freqüência

de amostragem, do tipo e da quantidade de métricas observadas, o vo-

lume deste repositório pode tornar-se consideravelmente grande.

A coleta de dados pode efetuar-se usando uma das seguintes técnicas:

� Por eventos: A informação se coleta quando acontecem determinados

eventos. Usualmente a instrumentação deste tipo de medição consiste

em inserir código em lugares especí�cos do programa controlado.

Quando esses eventos acontecem com freqüência, pode ser introduzida

uma grande sobrecarga no processo de medição. Dado que a freqüência


dos eventos não pode ser controlada, a sobrecarga da medição se torna

imprevisível, o que é uma das maiores desvantagens desse método.

� Por amostragem: Nesse modo, a informação é coletada em intervalos

prede�nidos especi�cados no inicio da sessão de monitoramento. A

sobrecarga nesse caso depende de dois fatores: número de variáveis

observadas e tamanho do intervalo de amostragem. Longos intervalos

de amostragem geram baixas sobrecargas, mas a diminuição das

amostras provoca por outro lado a redução da acurácia da medição.

Comparado com o modo de eventos, fornece uma observação menos

detalhada.

Devido ao fato de que os sensores usam os mesmos recursos que

estão medindo, dependendo do nível de sobrecarga introduzido, podem

ser obtidos dados errôneos. Detalhes de implementação podem provocar

também leituras errôneas. Em [46] se reportam problemas de precisão dos

dados causados pela inexatidão das ferramentas de linha de comandos do

sistema operacional, que levaram os desenvolvedores do sistema a coletar os

dados acessando diretamente o núcleo do sistema.

Os sistemas comerciais de gerência de desempenho oferecem soluções

interessantes ao problema do monitoramento. Por exemplo, o Veritas In-

depth para Oracle [63] coleta as informações diretamente da área de memó-

ria compartilhada (SGA). Estas informações são armazenadas em arquivos

locais que são carregados em intervalos regulares em um repositório (Per-

formance Warehouse) que pode estar situado em outro servidor. A idéia

deste repositório é comum entre os trabalhos que propõem sistemas de auto-

sintonia [11, 39] e entre as ferramentas de análise de desempenho [34], pois

fornece dados históricos que permitem analisar situações passadas.

Análise

Um sistema de auto-sintonia deve procurar continuamente a existência

de métricas cujos valores não satisfaçam as expectativas especi�cadas, indi-

cando problemas de desempenho. A detecção de problemas de desempenho

potenciais, que corresponde à abordagem pró-ativa, requer a implementação

de algoritmos que, baseados em análises do repositório de dados históricos,

consigam extrair informações que indiquem a necessidade da execução de

ações corretivas. A escolha da técnica depende da disponibilidade e exatidão

dos dados históricos nos quais se baseia a análise, o horizonte da predição

e dos padrões contidos nos dados [26]. Entre os padrões possíveis estão os


de tendência, cíclico, sazonal e estacionário. O padrão de tendência re�ete

uma função que tende a crescer ou a decrescer em função do tempo, en-

quanto o estacionário exibe uma média constante. Tanto o padrão sazonal

como o cíclico apresentam �utuações, a diferença entre um e outro está na

periodicidade dessas �utuações.

Idealmente a detecção pró-ativa seria su�ciente. No entanto, na prá-

tica é possível que alguns problemas sejam detectados somente depois de

manifestarem-se.

Fatores decisivos para a efetividade desta etapa são, entre outros:

� a de�nição do intervalo admissível para cada parâmetro -dependendo

dos limites, problemas podem não ser detectados ou, pelo contrário,

gerar falsos alarmes-;

� a técnica escolhida para executar a análise -comumente a análise de li-

mite. É muito importante que esta técnica seja capaz de detectar todos

os problemas a partir de determinada severidade, ou a con�abilidade

do sistema comprometeria a sua utilidade.

É possível que em um determinado SGBD o sistema de auto-sintonia

não consiga resolver um problema de desempenho dado por causa das

limitações de recursos ou por falta de mecanismos que permitam ajustar

a con�guração. Entretanto, a detecção destes problemas é crítica para o

sucesso do sistema.

Um problema a resolver nessa etapa é saber distinguir se as mudanças

na resposta do sistema se devem à mudanças no padrão de carga de trabalho

ou à reação do SGBD a ajustes de sintonia. Esse problema se torna ainda

mais crítico devido à demora da realimentação, pois dependendo do caso

em particular a reação do sistema pode demorar um tempo indeterminado

em manifestar-se. Esta é uma das causas pelas quais é preferível executar

os ajustes o�-line ou em horários de pouca carga de trabalho. No entanto,

modelos de carga de trabalho podem ajudar nesse sentido, conforme pro-

posto em [7]. Uma outra opção possível é utilizar SGBD teste. Nesse caso as

modi�cações seriam testadas em réplicas do SGBD operacional submetidas

à carga de trabalho real de forma a não afetar o trabalho do sistema.

Após a detecção de um problema de desempenho, providências deverão

ser tomadas para a sua resolução. Segundo [18], os métodos baseados

na remoção sucessiva de gargalos se demostraram úteis para melhorar o

desempenho. Isso sugere que, ainda que sejam detectados vários problemas

de desempenho de uma vez, a resolução deve ser seqüencial pois a reação

do sistema pode não eliminar os problemas restantes como também criar


novos problemas. Os métodos para detectar e resolver esses problemas serão

comentados a seguir.

Planejamento

Nessa etapa o problema é diagnosticado de forma a determinar suas

verdadeiras causas. Em seguida são enumeradas as ações que podem corrigir

o problema detectado.

O objetivo do algoritmo de diagnóstico é localizar a causa do problema

em tempo mínimo. Existem inúmeras publicações e produtos comerciais

relacionados com o diagnóstico de problemas de desempenho em sistemas

de computação em geral e de SGBDs em particular. Em [34] são estudadas

algumas ferramentas de gerência de desempenho de SGBDs. A respeito

do diagnóstico, estas ferramentas conseguem sugerir recomendações para

resolver problemas de desempenho baseadas em sistemas especialistas. De

novo nessa etapa é importante a utilização do repositório, pois nele é

mantido um registro de dados temporais que permitem correlacionar eventos

gerados por diferentes módulos do sistema para detectar a verdadeira causa

do problema. Em qualquer caso, o diagnóstico de desempenho em um SGBD

é uma atividade inerentemente global, por causa das interações já discutidas.

A grande quantidade de métricas usualmente disponíveis nos SGBDs

leva à sugestão de métodos que permitam estreitar o espaço de busca das

variáveis relacionadas com a verdadeira causa do problema de desempenho.

Em linha com esta abordagem é proposta em [36] uma hierarquia de

produtores e consumidores que representam os componentes do SGBD,

como mostra a �gura 2.3. Os recursos primários ocupam o nível mais baixo

da hierarquia como produtores e os processos ou usuários o mais alto, como

consumidores. No nível intermediário encontram-se os subsistemas do SGBD

que consomem recursos para servir aos consumidores do nível superior. Em

cada ponto da hierarquia são feitas amostragens para checar o estado do

sistema.

Esta representação facilita a compreensão das relações causa-efeito,

dado que os efeitos do problema de sintonia podem manifestar-se em um

componente diferente daquele que o está causando. Desta forma problemas

surgidos nas leituras das amostragens podem ser relacionados com as causas.

Enquanto um processo de sintonia nesta etapa retornaria a causa do

problema e, em alguns casos, possíveis soluções para resolvê-lo, a auto-

sintonia precisa determinar os ajustes que podem solucionar o problema de


Figura 2.3: Cadeia de Consumo em SGBDs [36]

desempenho, assim como os novos valores que deverão ser atribuídos aos

parâmetros de sintonia.

Qualquer que seja o método escolhido para a geração das possíveis so-

luções, após a enumeração de possíveis alterações deve haver uma avaliação

para quanti�car o desempenho que será obtido recon�gurando o sistema a

partir de cada uma das possíveis soluções com a carga de trabalho atual.

Testar as possíveis soluções diretamente sobre o sistema pode levar a insta-

bilidade dado que a reação não é totalmente conhecida. Nesse caso os testes

somente poderão ser executados em momentos de pouca carga de trabalho

ou durante o processo de instalação. Ou então efetuando os ajustes progres-

sivamente em intervalos pequenos como sugere o método de Ajuste Incre-

mental [25]. De outra forma, uma representação ou modelo do sistema será

necessária para poder avaliar o impacto das mudanças no sistema. Alguns

problemas que podem apresentar as soluções propostas são enumerados em

[64]:

� Relação custo-benefício inviável.

� Con�ito: ações contraditórias de�nidas para um mesmo recurso que

se anulariam mutuamente.

� Restrição: características do componente, carga ou ambiente em exe-

cução limitam a aplicação da ação (exemplo: limitações em tempo de


reação ou memória disponível).

Ação

A etapa de ação é a última do ciclo de auto-sintonia. Embora a lista de

ajustes já tenha sido de�nida na etapa anterior, algumas decisões deverão

ainda ser tomadas.

Tomemos por exemplo o algoritmo proposto em [66] para o controle

de carga orientado a con�itos de bloqueio. Nesse trabalho foi identi�cada

uma métrica para a detecção de problemas de bloqueio, denominada razão

de con�itos (con�ict ratio), que mede a razão entre o número total de

bloqueios obtidos e a quantidade deles possuídos por transações ativas. O

valor crítico da razão de con�itos em que o sistema começa a sofrer thrashing

de contenção de dados foi determinado experimentalmente (coincidindo com

a determinação teórica desenvolvida em [59]). Este valor está em torno de

1.3, quase independentemente da carga de trabalho. Esta independência da

carga, e o fato de ser um valor limite constante, são as características mais

importantes dessa métrica pois não é necessário qualquer ajuste. Por outro

lado, o caso do algoritmo para a execução das ações de controle é diferente.

Ele se divide em dois processos: um processo de controle de admissão de

novas transações e um de cancelamento de transações em execução. Várias

opções podem ser assumidas na implementação destes métodos. Assim, uma

solução ingênua pode ser colocar em uma �la todas as novas transações que

chegarem ao sistema durante o tempo em que a variável razão de con�ito

permanecer em valores maiores de 1.3. Porém, tal decisão pode afetar

desnecessariamente o desempenho do sistema no caso de reter transações

que não precisem dos objetos bloqueados que estão provocando contenção

de dados.

Outras abordagens para este problema requerem conhecimento dos

objetos que serão afetados durante o processamento da transação. Da mesma

forma, no processo de cancelamento existem vários critérios possíveis a

assumir na escolha das transações vítimas. Estas podem ser escolhidas por

número de bloqueios requisitados, por tempo de processamento, por custo,

entre outras, sendo que algumas decisões podem ser boas para alguns casos

e ruins para outros. Embora a métrica do problema seja independente da

carga, o processo de sintonia acaba não o sendo por causa da relação da

etapa de ação com a carga de trabalho.

Novos problemas de desempenho decorrentes da reação do sistema à

execução de ações de auto-sintonia deverão ser detectados pelos mecanismos


anteriormente discutidos, fechando-se assim o ciclo de realimentação. O

fato de que a concorrência de vários processos de auto-sintonia di�culta

esta detecção sugere a implementação de um mecanismo de escalonamento,

que execute em nível de sistema um processo de cada vez, sendo que

um processo de sintonia pode estar composto por uma ou várias ações.

Algumas alternativas podem ser avaliadas, como por exemplo, a introdução

de prioridades e o cancelamento de atividades que não sejam mais válidas

quando é chegado o momento da execução.

A implementação desses processos é complexa e precisa de uma

abstração que ofereça adaptabilidade e reatividade. Os agentes de software

possuem características como pró-atividade e aprendizado [7, 33, 73] que

podem ser úteis na implementação de sistemas de auto-sintonia. Estudos

de agentes de software formando parte de SGBDs para aumentar sua

�exibilidade e adaptabilidade foram realizados em [11, 40, 62].

2.5.3Agentes para auto-sintonia

A construção de sistemas de auto-sintonia usando agentes foi abordada

em [7, 11]. Em [11] foi usada a arquitetura proposta em [33], que apresenta

um framework para o projeto e implementação de agentes de software. A

arquitetura está organizada em camadas verticais e permite, com relativa

simplicidade, a construção de agentes com capacidades pró-ativa e reativa.

É possível mapear as etapas do processo de auto-sintonia proposto em [11]

às camadas deste modelo, como mostra a �gura 2.4. Por sua vez, essas

etapas podem ser mapeadas diretamente com as quatro etapas propostas

do processo de auto-sintonia nesse trabalho, que são observação, análise,

planejamento e ação.

A arquitetura apresentada tem duas passagens: ocorre um �uxo da

camada inferior à superior e outro em sentido contrário. A camada inferior

monitora o estado do ambiente e atualiza as crenças, que ativam um

procedimento na camada de raciocínio. Este procedimento pode gerar tanto

planos a serem executados na camada de Ação como mensagens a serem

preparadas e enviadas pela camada de Colaboração. As outras camadas

tratam os problemas da tradução de mensagens e mobilidade do agente. Já

no agente receptor o processo percorre o sentido contrário. Assim, a camada

superior recebe as mensagens que são repassadas à camada de Raciocínio.

Esta pode ou não atualizar as crenças e/ou executar modi�cações na camada


Figura 2.4: Etapas de um processo de auto-sintonia [11]

Sensor, assim como gerar novos planos. Nesta con�guração, a percepção e

a ação estarão envolvidas cada uma com uma camada no máximo.

Este trabalho se baseará nessa arquitetura de agentes. Outras arqui-

teturas podem ser revisadas em [73].

2.6Motivação da pesquisa

O foco desta dissertação está na sintonia global de SGBDs, dado que

existem situações em que ajustes independentes não são su�cientes para

garantir um bom desempenho. Acreditamos que a implementação de tais

sistemas é factível, mesmo que não existam ainda SGBDs comerciais com

auto-sintonia global [34]. O objetivo do trabalho é a automatização da tarefa

dentro do possível e não a substituição total dos DBAs, o que de qualquer

forma deve redundar em uma diminuição dos custos de manutenção dos

SGBDs e no aumento da sua disponibilidade.

Seguimos a linha de trabalho do nosso grupo de pesquisa cujo interesse

é a utilização de agentes de software para aumentar as funcionalidades dos

sistemas de bancos de dados. Este trabalho em particular está aprofundando

uma idéia colocada em [11] no contexto de uma proposta para um sistema de

auto-sintonia de índices baseado em agentes, em que se menciona a forma

em que o componente de auto-sintonia poderia inserir-se em um sistema

formado por outros agentes de auto-sintonia.

O objetivo dessa pesquisa é criar um componente de auto-sintonia

global baseado em agentes que possa ser embutido dentro de um SGBD.


Entra, portanto, dentro da classi�cação de sistemas de auto-sintonia por

adaptação (veja [34]).

2.7Conclusões

Nesse capítulo apresentamos alguns conceitos relacionados á nossa

pesquisa, como são os agentes de software, assim como as considerações que

serão assumidas ao longo do trabalho. Foi mostrado um panorama geral das

abordagens atuais para a realização de sintonia e auto-sintonia de SGBDs.

Finalizamos com as motivações que originaram o presente trabalho.

No próximo capítulo discutiremos possíveis abordagens para o pro-

blema da auto-sintonia de SGBDs usando agentes. Mostraremos os proble-

mas que devem ser resolvidos e, �nalmente, proporemos uma arquitetura

para a auto-sintonia global de sistemas de bancos de dados usando agentes.

3

Arquitetura

Neste capítulo serão sugeridos um conjunto de requisitos que devem

ser satisfeitos pelos sistemas de auto-sintonia e serão discutidas possíveis

arquiteturas para sua construção usando agentes.

3.1Requisitos

A meta fundamental do sistema de auto-sintonia global é garantir que

o SGBD controlado mantenha um bom desempenho. Para satisfazer esse

objetivo é proposto nesta dissertação que o sistema deva cumprir um grupo

de requisitos, a saber:

1. A correção na detecção e diagnóstico de problemas de desempenho

crítico1 que o SGBD possa sofrer. Nesses casos os problemas devem

ser corrigidos imediatamente se for possível (se não for possível o

administrador do sistema deverá ser noti�cado).

2. Não tornar o SGBD indisponível. É necessária uma cuidadosa imple-

mentação do sistema de forma a evitar que erros de programação ou

ações do sistema de auto-sintonia possam deixar o SGBD indisponível.

3. Não introduzir instabilidade no SGBD. Este requisito se aplica a ajus-

tes on-line e se refere a evitar oscilações e outros tipos de comporta-

mento errôneo que podem ser causados pelos ajustes.

4. Não alterar os serviços do SGBD. Por exemplo, o sistema de auto-

sintonia não pode fazer com que o SGBD comece a devolver dados

aproximados para aumentar o desempenho. Qualquer decisão desse

tipo cabe apenas ao administrador.

1situações em que esteja em risco a disponibilidade do SGBD ou em que o desempenhoseja inadmissível sob a ótica dos usuários


5. Garantir que a sobrecarga provocada pelo sistema de auto-sintonia

seja inferior ao benefício gerado.

Têm sido identi�cados também um grupo de requisitos desejáveis:

1. Ser pró-ativo. O sistema deverá ser capaz de detectar e corrigir situa-

ções que indiquem futuros problemas de deterioração de desempenho.

2. Requerer do administrador do sistema a mínima intervenção possível.

3. A interação com o administrador deve ser a alto nível, de forma que

ele não precisará dominar detalhes da arquitetura interna do SGBD

para interagir com o sistema de auto-sintonia.

4. Comportar-se melhor que a simples união de mecanismos de auto-

sintonia isolados.

Os trabalhos existentes em auto-sintonia global satisfazem parcial-

mente esses requisitos. Assim, a tendência à pró-atividade está presente

tanto nos sistemas comerciais [63, 72] como nos trabalhos acadêmicos [11,

55, 61, 64]. Por outro lado, os detalhes de implementação do sistema que

devem ser seguidos para manter a disponibilidade do SGBD não têm sido

muito comentados. O fato de que o administrador é que toma as decisões �-

nais afeta a correção imediata de problemas críticos. A intenção de requerer

do administrador do sistema uma intervenção mínima e a nível de objetivos

do negócio é também uma tendência atual [34]. Estudos sobre como limitar a

sobrecarga gerada pelo sistemas de auto-sintonia �caram como trabalhos fu-

turos em [8, 9], pelo que concluímos que não é ainda um problema resolvido.

Outro problema igualmente não resolvido identi�cado em [9] (relacionado

com o requisito 8) é como garantir que o processo de diagnóstico alcance

o desempenho ótimo do SGBD. O requisito de se comportar melhor que a

simples união de componentes isolados não é válido em trabalhos anteriores,

pois nenhuma das propostas revisadas trata o problema da combinação de

componentes de auto-sintonia dentro do SGBD.

Os requisitos propostos sugerem alguns princípios para a construção

de sistemas desse gênero, tanto no que se refere ao processo de sintonia

como à integração dos agentes com o sistema.

Dado que as interações no sistema fazem com que as reações às ações

de sintonia não sejam totalmente previsíveis o sistema de auto-sintonia pre-

cisa de um mecanismo que permita controlá-las. A prática tem demonstrado

a efetividade do ciclo de controle de realimentação como método de controle


do processo de auto-sintonia [18, 28, 66]. Combinado com políticas conserva-

doras de ajuste, esse método pode garantir a satisfação do requisito número

3.

A etapa de planejamento deverá conferir o custo da operação, de

forma que se ele for maior que o ganho a ação não deverá ser executada,

satisfazendo o requisito de baixa sobrecarga (requisito 5). Às ações podem

ser associados custos, de forma que será possível escolher a de menor custo

entre um grupo de ações candidatas. Nesse sentido também pode ser levada

em conta a idéia de priorizar as consultas mais importantes e controlar as

métricas seguindo uma hierarquia, como proposto em [8].

Para cumprir o requisito de manter a estabilidade do sistema, testes

on-line devem ser evitados exceto em momentos de pouca carga de trabalho.

Pode ser criado, para cada sistema, um modelo que descreva a resposta para

uma con�guração e uma carga de trabalho determinadas. Este modelo pode

ser gerado de várias formas. Uma delas é construí-lo com redes neurais

como proposto em [7], outra pode ser extraí-lo em forma de regras [9] a

partir dos dados coletados pelos sensores, armazenados no repositório de

desempenho como tuplas que relacionam grupos de valores dos parâmetros

de sintonia e as respectivas métricas de desempenho resultantes para cada

carga de trabalho. Inicialmente os dados podem ser gerados usando uma

carga padrão como TPC-C [58] e modi�cando os controles de sintonia para

obter a resposta do sistema para diferentes con�gurações.

A obtenção das métricas de desempenho deve minimizar o consumo

de recursos de sistema para não comprometer a sua correção nem afetar o

sistema observado.

Objetivando reagir ante manifestações de problemas de desempenho

(requisito 8), deverão coletar-se continuamente amostras dos parâmetros

que caracterizam o desempenho do sistema. Estas métricas devem ser

cuidadosamente escolhidas como discutido no capítulo anterior. Os dados

coletados devem ser checados periodicamente para detectar violações das

políticas de sintonia (veja a seção 2.5.2). A detecção de tais violações devem

gerar um processo para o diagnóstico do problema e ajuste de parâmetros de

controle. Esse processo deverá continuar até que sejam satisfeitas as políticas

de sintonia ou então que não seja possível executar ações que resolvam o

problema de desempenho. O sistema de auto-sintonia deve incluir, entre as

possíveis soluções dos problemas de falta de recursos, a opção de desligar-se

para liberar seus recursos em favor do SGBD (requisito 2).

As amostragens devem ser pouco intrusivas para não sobrecarregar o

sistema (requisito 5). Os dados coletados serão armazenados em repositó-


rios de desempenho a �m de permitir a detecção de padrões que indiquem

problemas que estão por surgir (requisito 1). Nesse repositório são também

mantidas outras informações, tais como as políticas ou objetivos de sinto-

nia. A de�nição destas políticas permite ao administrador de�nir as suas

necessidades em termos de políticas da empresa, afastando-o dos detalhes

do sistema (requisito 3).

A construção de um sistema global não se justi�ca se a simples

combinação de mecanismos isolados de auto-sintonia for mais bené�ca.

Nesse sentido, medidas deverão ser tomadas como, por exemplo, limitar

a sobrecarga causada pelos mecanismos de coordenação (requisito 4).

A seguir discutiremos à integração dos agentes com o sistema. Nesse

sentido, é preciso desenvolver uma arquitetura que faça com que as ações dos

agentes convirjam com os objetivos globais do sistema de auto-sintonia. Um

sistema coerente pode ser construído através de um controle global ou da

cooperação entre seus componentes(veja a seção 2.1). Essas duas abordagens

são discutidas nas seções 3.3 e 3.4.

3.2Propostas de Arquitetura

Uma abordagem para o desenvolvimento de uma arquitetura para a

construção de sistemas de auto-sintonia é a integração de módulos que im-

plementem resultados de estudos sobre auto-sintonia local, sendo que cada

módulo pode ser constituído por um ou mais agentes. No desenvolvimento

dessa arquitetura devem ser destacados vários detalhes importantes:

1. Nos sistemas comerciais existem usualmente uma grande quantidade

de parâmetros de ajuste. Por isso, não é uma boa solução armazenar

todas as medidas que descrevem a reação do sistema considerando

todos os parâmetros de ajuste para cada uma das cargas de trabalho

possíveis.

2. Existem estudos sobre auto-sintonia local para quase todos os compo-

nentes de um SGBD. Alguns deles têm sido testados em sistemas reais

e inclusive implementados em sistemas comerciais [34]. Esses estudos,

em geral, descrevem o processo de auto-sintonia de um determinado

aspecto, desde a detecção até o ajuste. Entretanto, eles fazem determi-

nadas considerações com respeito ao estado do SGBD [49] que podem

ser inválidas em determinado momento, ainda que se possa esperar

que essas situações não aconteçam na maioria dos casos.


3. A maior parte das propostas não leva em conta os outros componentes

do sistema, inclusive aqueles que podem causar um desvio similar nas

métricas de sintonia. Isto implica que a integração destas propostas

dentro do mesmo sistema pode ter efeitos inesperados. Por exemplo,

em [66] se descreve a situação em que uma carga mal balanceada

entre os discos provoca demoras em alguns acessos que podem fazer

com que aumente a duração de alguns bloqueios. Se a contenção

de dados chegar a um nível crítico, o mecanismo proposto nesse

trabalho A.2 reagiria detendo a admissão de novas transações no

sistema e cancelando algumas das transações em curso, causando a

sobrecarga da CPU por causa do processamento causado pelo reinício

das transações.

4. Conforme concluído em [16] nem sempre a combinação dos resultados

oferecidos pelos algoritmos de análise de um processo de auto-sintonia

é a melhor solução no nível global.

5. A complexidade de alguns processos de diagnóstico e ajuste justi�ca

sua execução separada do trabalho do sistema, em um processo

concorrente. Este é o caso da proposta em [50], na qual um processo

de coleta de consultas SQL submetidas deve ser executado em paralelo

a um processo de escalonamento de ações de criação e destruição

de índices e a outro de análise. Enquanto o processo de coleta é

executado por um agente dentro do sistema, os restantes executam

fora do sistema a �m de satisfazer o requisito de baixa sobrecarga

(requisito 5).

6. Os mecanismos que integram a etapa de ação de um componente

de auto-sintonia local podem ser úteis aos outros componentes do

sistema. É o caso do algoritmo de controle de admissão que forma

parte do mecanismo de controle de contenção de dados. Ele pode ser

usado por outro mecanismo que precise do controle do número de

transações concorrentes no sistema.

7. Conforme discutido na seção 2.5.2, o reconhecimento da causa da

deterioração de desempenho é facilitada se os processos de sintonia são

executados um de cada vez, separados por intervalos que dependem

do tempo de reação do sistema ao ajuste em particular, e do intervalo

de monitoramento.

Dessas constatações podemos concluir que pode resultar em benefício

a implementação de algumas das propostas de auto-sintonia local dentro


de um sistema de auto-sintonia global. Entretanto, a introdução dessas

propostas requer uma arquitetura que garanta o caráter social que devem ter

o diagnóstico e o escalonamento das ações a executar (veja a seção 2.5.2).

Essa é a motivação da nossa proposta de arquitetura para auto-sintonia

global.

Essa arquitetura consiste basicamente em um grupo de agentes que

controlam os diversos módulos do SGBD e em uma base de conhecimento

que armazena toda a informação relativa ao estado do SGBD e as ações

executadas pelos agentes, assim como as interações entre os componentes

do SGBD (regras, con�itos) e os objetivos dos usuários. Os acessos á base

de conhecimento podem ser executados através de um Agente de Histórico.

Outros agentes podem ser incorporados à infra-estrutura do sistema, como

será discutido nas seções seguintes. A combinação do trabalho dos agentes

permite não só coordenar o trabalho como também aproveitar os recursos

oferecidos por cada um deles, como seria o caso do módulo de coleta

de consultas proposto em [50] que seria útil para que o sistema tivesse

conhecimento da carga de trabalho submetida.

O relacionamento entre os agentes na arquitetura proposta dependerá

do grau de distribuição do controle do sistema. Desta forma podem ser

construídas versões decorrentes dessa magnitude que vão desde a abordagem

totalmente centralizada até a totalmente distribuída.

Em cada caso é importante para o sucesso de um sistema que siga

quaisquer destas abordagens, que os agentes que o compõem cumpram

determinados compromissos sociais (aqueles que estabelecem os agentes

entre si dentro da sociedade). Para os efeitos dessa proposta em particular,

consideramos que os agentes que integram o sistema devem cumprir os

seguintes compromissos:

� Os agentes são honestos. Não cabem no sistema atitudes como a

de ocultar informação, informar dados errôneos propositadamente ou

aceitar tarefas que não serão executadas.

� Os agentes formam parte de uma sociedade e não podem executar de

forma independente tarefas inerentemente sociais.

3.3Abordagem centralizada

A abordagem centralizada proposta é bem semelhante à forma como

é executado o processo de sintonia no mundo real. Ou seja, o administra-


dor recebe informações de problemas de desempenho no SGBD e efetua uma

análise para resolvê-los. Essa análise baseia-se nas métricas coletadas, na do-

cumentação do sistema, na experiência do administrador e, possivelmente,

em alguma ferramenta oferecida pelo sistema ou por terceiros. Com essas

informações o administrador determina as causas prováveis do problema

e começa a executar ajustes, enquanto observa a reação do sistema para

desfazê-los no caso de mostrarem-se negativos para o desempenho do sis-

tema. A abordagem centralizada apresentada na �gura 3.1 permite executar

esta metodologia substituindo o administrador por um agente de software.

Figura 3.1: Abordagem centralizada para auto-sintonia global

Nessa arquitetura o processo consiste em um agente que comanda a

execução de ações de sintonia quando recebe alguma noti�cação dos senso-

res de que alguma métrica não está respeitando os valores esperados. Nessa

abordagem os agentes que estão relacionados diretamente com os recursos

são meramente sensores e efetuadores, comprometendo seriamente sua au-

tonomia a tal ponto que estes podem ser substituídos por objetos. O agente

central é o único que domina a visão global do sistema e portanto é quem

pode determinar qual é a verdadeira causa do problema de desempenho,

dado que um sintoma pode ter diferentes causas. Isto implica que o único

agente do sistema com poder para comandar a execução de ações é o agente

coordenador, coincidindo com a proposta de [8]. Para efetuar as análises,

ele precisará dominar o signi�cado de cada variável, assim como particu-

laridades dos mecanismos disponíveis no sistema que permitam resolver o

problema.

Problemas presentes nessa arquitetura, como a di�culdade de expan-

são, a falta de autonomia dos agentes e a dependência do agente coordenador

nos levam a uma arquitetura onde o controle e os dados estejam mais dis-


tribuídos entre todos os agentes componentes do sistema, como veremos a

seguir.

3.4Abordagem distribuída

Na abordagem distribuída o controle (e o conhecimento) se encontram

distribuídos pelo sistema. Na �gura 3.1 apresenta-se uma proposta que segue

a abordagem distribuída para auto-sintonia global de SGBDs.

Figura 3.2: Arquitetura distribuída para auto-sintonia global

Essa arquitetura é formada por um agente analisador, agentes compo-

nentes e o agente de histórico que controla a base de conhecimento. Os agen-

tes componentes contêm mecanismos que permitem variar os parâmetros de

sintonia e os oferecem como serviços aos outros agentes. Nessa variante

as funções de análise se distribuem pelo sistema, de modo que os agentes

componentes tomam parte também na geração das soluções. A resolução

distribuída de um problema de desempenho é descrita a seguir:

1. Durante a etapa de monitoramento cada sensor coleta as métricas de

desempenho.

2. Os dados coletados são ora enviados ao agente de histórico, que oferece

um serviço de registro com esse propósito, ora mantidos pelo próprio

agente, sendo que no último caso algum mecanismo deverá existir

que permita aos outros agentes ter acesso a esses dados. O fato de

que existe uma grande quantidade dessas métricas indica que não é

possível trafegá-las livremente dentro do sistema.


3. Os dados coletados são comparados com as expectativas. Se for

detectado um problema de desempenho, um processo de sintonia deve

ser iniciado.

4. A etapa de planejamento objetiva a determinação da causa do pro-

blema e a elaboração de um plano de ações (ou intenção) que deve

resolvê-lo. As decisões do agente analisador tem a maior prioridade,

pois ele tem acesso às informações contidas na base de conhecimento

relativas a restrições e con�itos. Os agentes componentes relaciona-

dos com o problema podem elaborar propostas que podem ser eleitas

desde que não violem essas restrições.

5. As ações enumeradas no plano resultado são escalonadas para ser

executadas por agentes com as devidas capacidades. As solicitações de

execução de ações são feitas em forma de requisições por serviços. A

execução de cada tarefa está reservada ao agente que sugeriu a solução

selecionada para execução, mas este pode delegá-la a qualquer agente

que ofereça o serviço. Um dos protocolos mais usados para alocação

de tarefas é o Contract Net [73].

Esta metodologia pode ser melhor compreendida através de um exem-

plo. Durante a etapa de monitoramento um sensor coleta dados de vazão

média no sistema, que são enviados pelo agente para o repositório. No caso

em que o valor médio foi menor que o valor esperado para esta métrica,

uma mensagem de alarme é enviada ao sistema. O agente analisador envia

uma mensagem anunciando um problema de "vazão baixa", a partir da qual

os agentes relacionados com o problema reconhecem que irá começar uma

sessão de planejamento.

Cada agente convocado pela mensagem pode oferecer a sua solução

para o problema. Um agente implementado seguindo a proposta de [25] irá

diminuir o MPL assim que a vazão descer, e começará aumentá-lo quando a

queda da vazão parar. O agente encarregado do controle de páginas em

bu�er irá sugerir a troca de estratégia de substituição se for detectado

uma varredura seqüencial muito longa. Um agente de índices pode sugerir a

destruição de um índice que está causando um elevado nível de bloqueios. E

o agente analisador, segundo o modelo, irá sugerir a diminuição do MPL ou

detenção temporal da aceitação de novas transações. Nesse caso somente as

propostas de controle de MPL entram em con�ito. Considerando que não

tenham sido encontradas situações similares no histórico que provocassem

deterioração do desempenho, todas as propostas serão executadas exceto


aquela de controle de MPL que entra em con�ito com a proposta do agente

analisador. Estas ações serão escalonadas para execução seqüencial.

Quanto a qual será o grupo de agentes que receberá a mensagem de

convocação, a mensagem pode ser um broadcast a todos os agentes do

sistema multi-agentes. Nesse caso a vantagem é que não se precisa saber

de antemão a lista de agentes relacionados com cada problema, enquanto a

desvantagem é a sobrecarga desnecessária que representa no que diz respeito

às comunicações. Uma possibilidade mais atraente pode ser aproveitar o

processo de inscrição do agente na entrada no sistema multi-agentes, para

registrar também os problemas que está capacitado para resolver.

Os resultados obtidos por cada agente envolvido no problema podem

ser diferentes. O intercâmbio de resultados entre os agentes oferece todas as

soluções disponíveis que o sistema de agentes pode acionar para resolver um

determinado problema. Cada agente formula o resultado de acordo com o

seu próprio algoritmo e a sua visão do sistema. Embora essa solução implique

em um esforço inútil para os agentes cujas soluções não serão escolhidas,

o dinamismo que oferece introduz vantagens tais como os agentes poderem

entrar no sistema no meio da execução sem precisar de recon�guração e

experimentarem alternativas não previamente consideradas.

Os custos de sobrecarga que implica esta alternativa podem ser reduzi-

dos concentrando a negociação em um repositório comum como o oferecido

nas arquiteturas de blackboards. Um blackboard é um repositório comparti-

lhado que permite intercâmbios indiretos de informação entre fontes inde-

pendentes. Durante a resolução de um problema os especialistas trabalham

cooperativamente, acrescentando suas contribuições ao blackboard toda vez

que tem informação su�ciente para fazê-lo, em um processo que continua até

o problema ser resolvido [24]. Esta opção permite também que o agente não

precise conhecer a quem noti�car as decisões. Por outro lado, o blackboard

precisa de um elemento de coordenação que introduz novamente problemas

da arquitetura centralizada. No entanto, a vantagem é que ao pertencer à

infra-estrutura do sistema, este elemento não precisa ser alterado toda vez

que se precisa acrescentar um novo algoritmo, ao contrário do que acontece

na arquitetura centralizada. Outra vantagem está em que esses elementos

são padronizados e disponíveis, minimizando o esforço de programação e a

possibilidade de erros.

Outra possibilidade é utilizar o método de Criação-Destruição (Create-

Destruction). Segundo esse método, um grupo de agentes, cujas funções são

construtores ou destrutores, trabalham em um problema. Os construtores

incorporam novas soluções ao conjunto, enquanto os destrutores eliminam


soluções. A eliminação de soluções que não deveriam ter sido criadas deve

melhorar a qualidade da solução. Nesse caso o analisador seria basicamente

um destrutor, pois baseado nas conclusões extraídas da base de conheci-

mento pode determinar se alguma solução proposta pode dani�car o de-

sempenho.

A vantagem dessa proposta distribuída está no fato, já mencionado, de

que existem situações em que os mecanismos de auto-sintonia não oferecem a

melhor solução mas a experiência da sua utilização em sistemas comerciais

e os resultados de estudos podem mostrar sua e�cácia em boa parte das

situações. Entretanto, o processo de diagnóstico e planejamento precisa que

as decisões do agente analisador sejam sempre as mais prioritárias e que os

compromissos sociais colocados sejam cumpridos.

Uma abordagem que pode ser considerada intermediária entre a cen-

tralizada e a distribuída consiste em fazer com que o agente analisador

avalie as soluções extraídas da base de conhecimento e as propostas ofereci-

das pelos agentes. Esta variante não é totalmente distribuída e novamente

é sensível a falhas no agente analisador, mas permite um grau mais forte de

agência que a versão centralizada sem afetar a coerência do sistema além

de simpli�car o processo de negociação.

A abordagem distribuída supõe algumas vantagens sobre a centrali-

zada:

1. Maior capacidade de resposta dado que existe mais de um agente

atendendo as noti�cações e é possível a comunicação entre grupos de

agentes em separado.

2. Permite implementar métodos de sintonia distintos em componentes

separados, de forma que estes podem ser acrescentados e modi�cados

sem alterar o sistema. No caso da arquitetura centralizada o código do

componente mais sensível do sistema (o agente coordenador) deveria

ser modi�cado.

3. Permite o reuso dos resultados de estudos existentes sobre auto-

sintonia local. Este fato, além de aliviar o trabalho do agente central,

representa uma notável diminuição do esforço de programação do

sistema e facilita a sua escalabilidade.

4. Facilita a introdução progressiva de novas funções e o trabalho em

conjunto de distintos programadores.

5. Diminui a probabilidade de falhas do sistema.


6. Aumenta a facilidade na introdução de novos agentes, cujas propostas

são avaliadas assim que ocorre algum problema com os recursos

relacionados com o agente.

Por outro lado, podem ser citadas algumas desvantagens da aborda-

gem distribuída:

1. Maior complexidade.

2. Os agentes precisam ter conhecimento dos outros agentes.

3. O conhecimento no sistema está disperso. As ações dos agentes devem

ser coordenadas pois a solução depende sempre do contexto global que

envolve todas as variáveis observadas.

A forma em que a arquitetura proposta satisfaz os requisitos de auto-

sintonia colocados em 3.1 é mostrada na tabela 3.4

Requisito Resolvido ComentáriosCorreção na detecção e diagnós-tico de problemas de desempe-nho crítico

Não Não existe até o momento uma forma de comprovar que o sistemaescolhe a melhor solução.

Não tornar o SGBD indisponí-vel.

Não Esse aspecto depende da implementação

Não introduzir instabilidade noSGBD.

Sim É possível introduzir nas crenças do agente os limites para as modi�ca-ções do sistema. Da mesma forma a detecção de ciclos de modi�caçõesdeve ser codi�cada como parte do raciocínio do agente coordenadorna abordagem centralizada, ou do sistema na distribuída

Não alterar os serviços doSGBD.

Não Esse aspecto não pode ser resolvido pela infra-estrutura do sistema.Em arquiteturas de integração como a embutida ou a integrada oacesso às funções do SGBD somente pode ser limitado por este. Ficapelo implementador levar em conta esse tipo de limitações

Garantir que a sobrecarga pro-vocada pelo sistema de auto-sintonia seja inferior ao benefíciogerado

Sim No caso de serem detectadas pioras no desempenho decorrentes daexecução de ações de auto-sintonia, estas devem ser desfeitas pelopróprio sistema. Ações cujo custo ultrapasse um certo limite deverãoser adiadas o impedidas de serem executadas. Idealmente, um cálculode custo benefício poderia resolver este problema, se bem este nemsempre pode ser determinado previamente.

Ser pró-ativo Sim A introdução de agentes facilita a execução de algoritmos de prediçãoque detectem problemas potenciais e iniciem processos de resoluçãodestes. O aprendizado é uma característica importante nessa tarefa.

Requerer do administrador dosistema a mínima intervençãopossível

Sim Às soluções que impliquem interação com o administrador deve seralocado um custo alto

A interação com o administradordeve ser a alto nível

Sim Na base de conhecimento podem ser armazenados mapeamentos entreos níveis

Comportar-se melhor que a sim-ples união de mecanismos deauto-sintonia isolados

Sim A arquitetura pretende corrigir os problemas decorrentes das intera-ções entre os mecanismos de auto-sintonia local

Tabela 3.1: Satisfação dos requisitos propostos para um sistema de auto-sintonia global de SGBDs na arquitetura.


3.5Agentes na arquitetura






anteriores, em que os sistemas de auto-sintonia têm sido sempre tratados


A arquitetura oferece variantes para a integração do sistema de

auto-sintonia com o SGBD. No caso, dada a indisponibilidade de SGBDs

construídos seguindo a arquitetura integrada (veja a seção 2.1.1), as opções

se limitam às arquiteturas embutidas e em camadas. A arquitetura embutida

possibilita uma implementação mais e�ciente, tanto pela possibilidade de

aproveitar componentes do SGBD como por poder acessar diretamente as

funções e variáveis necessárias para efetuar o monitoramento e a execução

de ações. De outro lado, complica a implementação pois é necessário

entender o funcionamento interno do banco de dados e, possivelmente,

alterar algumas das suas estruturas. A arquitetura em camadas, por outro

lado, utiliza as interfaces que dispõe o sistema para uso público, em geral

bem documentadas e mais fáceis de utilizar. As desvantagens desta se

baseiam fundamentalmente em critérios de e�ciência.

Ambas as arquiteturas permitem integrar mecanismos de auto-sintonia

conhecidos, sendo que na abordagem centralizada seria preciso modi�car o

código do agente coordenador.

3.6Conclusões

Nesse capítulo foram apresentados os requisitos que deve satisfazer

um sistema para auto-sintonia de SGBDs. Duas abordagens de arquitetura

(centralizada e distribuída) foram propostas, e comentadas as vantagens e

desvantagens de cada uma, assim como detalhes da forma de operação.

Em seguida iremos descrever os detalhes da implementação do sistema.

O protótipo implementado foi baseado na arquitetura centralizada pois

a implementação da arquitetura distribuída de forma completa não seria

possível devido aos limites de tempo de desenvolvimento dessa dissertação.

4

Implementação

Nesse capítulo se descreve a implementação de um protótipo que im-

plementa a arquitetura centralizada proposta no capítulo 3. O protótipo

consiste de um sistema de auto-sintonia embutido em um SGBD relacional

baseado nessa arquitetura. A idéia é mostrar que é factível a implementa-

ção deste tipo de sistema, assim como testar a in�uência do MAS sobre o

desempenho do SGBD e pesquisar as di�culdades que apresenta a imple-

mentação.

Na próxima seção serão expostas questões relacionadas ao desenvol-

vimento do sistema de auto-sintonia. Finalmente será descrito um exemplo

de aplicação desse sistema embutido no SGBD PostgreSQL e uma avaliação

da factibilidade da implementação do protótipo, assim como as di�culdades

que esta tarefa apresenta.

4.1Infra-estrutura

O sistema de auto-sintonia foi projetado seguindo a arquitetura centra-

lizada descrita em 3.3. O sistema pode ser integrado com o SGBD seguindo a

arquitetura em camadas ou embutida. Esse sistema deve permitir a inclusão

de agentes componentes construídos seguindo um template oferecido pelo

sistema 1 de forma a minimizar o esforço de programação de novos agentes

componentes e a padronizar a interação entre eles. Os agentes podem tra-

balhar isoladamente (desde que não exista outro agente ativo no sistema)

ou em conjunto. Isto permite uma integração progressiva de mecanismos de

auto-sintonia no sistema de banco de dados. O template segue a arquitetura

proposta em [33], que também foi usada em [11, 40, 51] e é apresentada na

�gura 4.1.

1devido aos requisitos de e�ciência da aplicação, não foram usadas plataformas paraa implementação dos agentes


Figura 4.1: Framework para a construção de agentes [33]

Algumas desvantagens dessa arquitetura colocadas em [19] são que

alguns aspectos como a autonomia atravessam as diferentes camadas, e por

estar muito interrelacionadas, não é trivial remover ou acrescentar uma

camada. No entanto, ela foi escolhida para a implementação desse trabalho

devido a sua relativa simplicidade e o fato de que já existia uma versão

parcial disponível em C++ [51]. Nessa dissertação essa versão foi modi�cada

para incluir a camada de Colaboração e a gerência de concorrência.

A implementação está baseada em padrões de desenho orientado a

objetos como Facade e Singleton que podem ser consultados em [21].

4.1.1Gerência de concorrência

Um programa concorrente contêm dois ou mais processos que traba-

lham em conjunto para executar uma tarefa. Visando garantir um controle

contínuo da atividade do SGBD afetando no mínimo possível o seu funcio-

namento, todas as medições, assim como as ações tanto de sintonia como

de colaboração deverão ser executados por processos concorrentes.

Esses processos podem ser threads ou processos de aplicação. Enquanto

a criação de um processo de aplicação implica na duplicação do processo

pai junto com todo seu contexto, as threads são processos leves(lighweight)

que só precisam da criação de um novo contador de programa e pilha de

execução [57]. O mecanismo para escrever aplicações multithreaded em C foi

padronizado e criada a biblioteca Pthreads (POSIX API, standard 1003.1c-


1995 da IEEE), amplamente suportada.

A linguagem C++ não possui gerência intrínseca de concorrência.

As funções relacionadas estão contidas na biblioteca pthreads [57]. Para

encapsular o comportamento concorrente nesse trabalho foi criada uma

classe Thread que faz chamadas às funções desta biblioteca. As informações

no sistema são trafegadas entre os processos através de �las de mensagens

(Message Queues) [57], que encapsula por sua vez detalhes de controle de

concorrência.

4.1.2Implementação dos agentes

As camadas dos agentes foram implementadas usando o padrão Fa-

cade [21], de forma a isolar as camadas do agente. Esse isolamento foi, no

entanto, prejudicado pela ausência de re�exividade do C++. Assim, por

exemplo, na implementação original desenvolvida em Java [33] os planos

de execução são enviados à camada de ação como strings. As ações são

instanciadas a partir destas variáveis utilizando facilidades oferecidas pela

linguagem. Dado que o C++ não permite este tipo de operação, optamos

aqui por criar fábricas de objetos cuja referência é trafegada de uma camada

a outra segundo a classe a instanciar.

Nesse trabalho assume-se que todos os agentes utilizam uma ontologia

comum e não se consideram aspectos relativos à mobilidade. Por essa causa,

o template não inclui as camadas de Tradução e Mobilidade. As camadas

restantes serão descritas a seguir:

Camada Sensor

A camada Sensor está constituída pela interface ASensor e pela classe

SensoryFacade. A interface ASensor deve ser herdada pelas novas classes

sensor. O SensoryFacade é o ponto de entrada na camada e, como as outras

Façades, seu objetivo é manter o isolamento da camada.

O sensor executa em um processo independente do sistema, que é

iniciado assim que são inicializadas as estruturas do agente e iniciada a

execução da camada de Colaboração. Sua tarefa é a coleta de dados. Esta

pode ser efetuada por amostragem ou por eventos (noti�cação). Os dados

são repassados ao objeto crença subscrito como observador desse sensor,

através do padrão Observer [21].


Camada de Crença

A camada Crença é composta das classes ABelief e BeliefFacade.

ABelief é a interface das classes Crença dos novos agentes componentes. O

objeto Crença deve ser subscrito como observador de um ou vários sensores,

de forma a ser noti�cado em caso de mudanças. Eventos importantes devem

ser noti�cados por sua vez à camada de Raciocínio.

Camada Raciocínio

Na camada de Raciocínio, o objeto observador da crença avalia a

informação e pode gerar intenções que serão executadas pela camada de

ação. Essas intenções podem ser de colaboração ou de ação. As intenções de

ação contêm um plano com uma ou várias ações a executar, sendo que para

manter o isolamento entre as camadas, nessa implementação são repassadas

uma referência a uma fábrica do tipo de objeto indicado para executar a

ação e seus parâmetros.

Um exemplo para um caso que precise da mudança de estratégia de

substituição de páginas em bu�er é mostrado na �gura 4.2.

Figura 4.2: Processo executado pelas camadas de Crença, Raciocínio e Açãopara o controle da estratégia de substituição de páginas em bu�er.

Após ser noti�cado, o plano observador na camada de raciocínio

(bu�ReplStrategyPlan) avalia as crenças. Como conseqüência dessa avaliação

podem ser geradas intenções de ação e colaboração, que são transmitidas


à camada de ação. As intenções de ação indicam a execução de uma ou

várias ações listadas dentro do plano de ação (plan) que é passado como

parâmetro. Cada ação é de�nida por uma fábrica (BufRepStrategyFactory)

e um grupo de parâmetros para a instanciação da ação. Já na camada de

ação, uma intenção é criada que consulta o plano de ações e recebe as ações

instanciadas. Essas ações serão executadas pela intenção seqüencialmente

em um novo processo.

Por outro lado, a intenção de colaboração implica em uma chamada

ao método collaborate da camada de colaboração repassando os parâmetros

recebidos na camada de ação.

Além das classes ActionPlan, APlan e ReasoningFacade, a camada de

Raciocínio está integrada também pela classe ReasForwarder, que recebe as

mensagens transmitidas pela camada de Ação, e a classe InterpretPlan, que é

observadora de ReasForward e é executada para processar essas mensagens,

possivelmente invocando outros planos disponíveis no agente.

Camada Ação

A camada de Ação executa as intenções de ação e repassa para a ca-

mada de Colaboração as intenções de colaboração. As ações são executadas

seqüencialmente dentro de uma intenção, sendo que cada intenção é exe-

cutada em um processo separado. A camada está formada pelas interfaces

AAction e as classes ActionFacade, AIntention, Forwarder e ReactionInten-

tion. A classe Forwarder recebe as mensagens da camada de Colaboração

enviadas por outros agentes do sistema e as repassa para a camada de Ra-

ciocínio.

Camada Colaboração

Essa camada está constituída pelas classes CollabFacade, PostO�ce,

Acceptor, Connector eMessage. A classe PostO�ce é um Singleton: somente

existe um objeto PostO�ce no sistema. Ele é um depósito de mensagens,

de forma que os objetos Connector deixam as mensagens especi�cando o

destinatário e a prioridade, e o PostO�ce as coloca na �la de prioridade

correspondente a esse destinatário. O destino pode ser broadcast (todos os

agentes do sistema), um agente em particular ou um provedor de serviço.

Nesse último caso o destinatário será primeiro registrado como provedor do

serviço em particular no PostO�ce. O processo de envio de uma mensagem

é ilustrado na �gura 4.3.


Figura 4.3: Envio de uma mensagem

Como mostra a �gura, as mensagens enviadas à camada de Colabo-

ração são repassadas ao Connector, que as envia ao PostO�ce e retorna

o controle ao agente. O Connector também cria e retorna um objeto para

armazenar a resposta recebida no caso da camada de raciocínio esperar

resposta.

O envio das mensagens pode ser síncrono ou assíncrono. O envio

síncrono é utilizado quando um objeto precisa de uma informação para

continuar seu processamento. Nesse caso ele envia uma mensagem e �ca

bloqueado até a resposta chegar. Esta é enviada diretamente do Acceptor

ao objeto destino usando a referência contida no campo future.

No agente receptor, o Acceptor �ca bloqueado esperando por men-

sagens na �la até ser noti�cado de que pode retirar a sua mensagem. Ela

é repassada para a camada de ação, que a sua vez a transmite para a ca-

mada de Raciocínio, onde é analisada por um objeto da classe InterpretPlan

que está registrado como observador dessa camada. Esse objeto pode criar

planos que por sua vez gerem novas intenções de ação ou colaboração. Na

�gura 4.4 se mostra a seqüência de ações desde o PostO�ce até a camada

de Raciocínio durante o recebimento de uma mensagem.

A comunicação envolve as camadas:

1. transmissão: que descreve a forma em que a mensagem vai trafegar

pelo sistema;

2. sintaxe: de�ne o formato da informação;


Figura 4.4: Recebimento de uma mensagem (comunicação assíncrona)

3. semântica: que de�ne o tipo da mensagem e o seu conteúdo.

Estas três camadas são idealmente independentes, de forma que é

possível substituir uma sem afetar as outras.

A comunicação pode ser tanto ponto a ponto como broadcast. As

mensagens são encapsuladas para sua transmissão em objetos da classe

Message. O protocolo da camada de sintaxe de�ne os seguintes campos:

� MsgID

� SessionID

� Performative

� origem

� destino

� prioridade

� conteúdo

� future

O campo future guarda uma referência ao objeto ao que deverá ser

entregue a informação retornada no caso de uma comunicação síncrona.

Origem e destino são os identi�cadores únicos reservados a cada agente

durante o processo de registro no sistema. O campo Performative contém o

tipo de mensagem.


O conteúdo propriamente dito está estruturado como uma sucessão

de cadeias de caracteres separadas por espaços, em que a primeira cadeia é

o serviço requisitado no caso do tipo da mensagem (performative) ser um

REQUEST. O restante da mensagem pode ser organizado livremente desde

que a estrutura seja compartilhada por todos os agentes do sistema. Assim,

por exemplo, uma intenção de colaboração expressada da seguinte forma:

newintention(0,1,REQUEST,"record BuffRepStrategy MRU=true",false,0);

sendo que esse método está de�nido como:

void ActionFacade::newIntention(int ID, int prioridade,

Performative performative, char *message, bool resposta, int Destino)

signi�ca que o agente Bu�RepStrategy solicita ao agente de histórico, cuja

identi�cação não tem, o registro de uma ação como resultado da qual a

política de substituição de páginas em bu�er foi trocada para MRU. O

agente não espera resposta.

Um problema dessa implementação está na mistura entre as camadas

semântica e de sintaxe, pois é necessário "abrir"o conteúdo da mensagem

para saber o serviço requisitado e com isso, o destinatário da mensagem no

caso deste não estar especi�cado no campo destino. Uma solução pode ser

acrescentar um campo ao envelope da mensagem com o nome do serviço.

Essa mudança será efetuada em breve no sistema.

Na �gura 4.5 se mostra um processo de comunicação. Nele estão

envolvidos um processo do SGBD e dois agentes. Note que as requisições

entre os agentes são trafegadas na forma de serviços. Aqui é possível perceber

que um dos agentes possui somente as camadas de Crença, Raciocínio e

Colaboração, como pode ser o caso do Agente Coordenador na Arquitetura

Centralizada. Esse agente não precisaria da camada Sensor porque as noções

que ele tem sobre o ambiente vem todas da camada de colaboração. A

camada de ação não é necessária porque as ações a executar são requisições

de serviços a outros agentes do sistema que serão enviadas através da

camada de colaboração. No caso, o trabalho do agente consiste em decidir

sobre a base das informações recebidas dos outros agentes quais devem ser

as ações a tomar e mandar a executá-las na forma de requisições de serviço.

Um exemplo de requisição de serviço poderia ser uma mensagem do agente

de Bu�RepStrategy ao agente de histórico pedindo para que seja armazenado

o dado "MRU=true".

O tráfego de informação entre os processos pode obrigar ao uso de

estruturas protegidas.


Figura 4.5: Interações no sistema de auto-sintonia

Sistema de Agentes

A entrada no Sistema de Agentes é feita através do cadastro de cada

agente na lista mantida no objeto AgentSystem, que é único no sistema. Ao

mesmo tempo é inicializada a camada de Colaboração do agente e o agente

se registra no PostO�ce. A execução de tarefas no sistema de auto-sintonia é

orientada a serviços. Esses serviços são especi�cados durante a con�guração

do agente e registrados no PostO�ce para disponibilizá-los para os outros

agentes do sistema. A saída acontece com o cancelamento do cadastro do

agente com o AgentSystem.

4.1.3Validação da gerência de concorrência

A função da sincronização é restringir o grupo de possíveis �uxos de

execução a aqueles que são desejáveis. Nessa implementação a sincronização

entre os processos do PostgreSQL e os sensores do agente é garantida pelas

�las de mensagens. As �las de mensagens permitem implementar esperas por

condição e não precisam do uso de semáforos para garantir acesso exclusivo.

As ações do agente consistiram em escritas em variáveis compartilhadas

protegidas por semáforos.

A correção de um programa concorrente implica na satisfação das

propriedades segurança(safety) e vitalidade(liveness) [4], que podem ser


de�nidas como que nada "ruim"vai a acontecer durante a execução e que em

algum momento algo de "bom"vai a acontecer, respectivamente. Para o tipo

de aplicação que está sendo discutida aqui o termo "em algum momento"não

é su�ciente pois algumas decisões deverão ser tomadas em tempo real.

Por esse motivo consideraremos que o sistema satisfaz a propriedade de

vitalidade se o tempo em que ocorre "algo de bom"está dentro do admissível

segundo o domínio da aplicação.

Dado que todas as comunicações serão efetuadas mediante �las de

mensagens, o programa não deve entrar em um estado no qual um ou mais

processos estejam em uma zona mutuamente crítica.

Outro requerimento para considerar o programa seguro é que esteja

livre de deadlock. O deadlock acontece quando dois ou mais processos espe-

ram por uma condição que nunca vai acontecer. As condições necessárias e

su�cientes para a ocorrência de deadlock são [4]:

� necessidade de que os processos envolvidos precisem compartilhar

recursos que devam ser usados em exclusão mutua;

� que os processos mantenham os recursos já adquiridos enquanto

esperam por outros;

� ausência do controle do sistema sobre a liberação dos recursos;

� existe uma cadeia circular de requisições e aquisições.

A política adotada é usar o recurso e liberá-lo imediatamente, isso

implica que não existem possibilidades de deadlock no sistema.

O livelock é o estado no qual o processo não executa mais do que

instruções inúteis. O livelock é uma violação da vitalidade. Uma situação

em que o processo pode entrar em livelock é na espera por condição. Se

a condição nunca acontece o processo vai esperar inutilmente. Novamente,

situações de livelock podem ser codi�cadas como parte da programação

dos agentes. Todas as operações de colaboração que impliquem espera

devem incluir timeouts, protegendo-se de erros que possam eventualmente

acontecer. Seguidas essas regras nosso sistema deverá ser um sistema seguro.

A inanição (starvation) é outra violação de vitalidade. Nessa situação

o sistema consegue progredir, mas tem algum processo que não consegue

acesso aos recursos porque sempre perde na concorrência, por exemplo, por

ser de menor prioridade. Há dois candidatos potenciais a gerar situações

de inanição que são as mensagens armazenadas nas �las do PostO�ce e o

escalonador de ações. Ações pouco prioritárias não serão jamais executa-

das se tiver sempre ações mais prioritárias esperando, da mesma forma que


as mensagens menos prioritárias não conseguirão sair da �la enquanto tiver

mensagens de maior prioridade. Isso pode ser resolvido de duas formas: uma

é codi�car o escalonador seguindo princípios de justiça (fairness), garan-

tindo que cada processo será eleito em algum momento, com independência

da sua prioridade. A outra solução é assumir que as ações mais prioritárias

são aquelas que devem ser executadas em tempo real, enquanto as menos

prioritárias não têm restrições de tempo. Nesse caso o fato das mensagens

menos prioritárias �carem na �la não constitui um problema, desde que as

prioridades sejam cuidadosamente alocadas.

4.2Exemplo de aplicação

Para veri�car a arquitetura proposta na prática o sistema proposto

neste trabalho foi embutido dentro de um SGBD. Uma di�culdade que

enfrentamos foi a escolha desse SGBD, que deveria expor tanto as variáveis

a medir como os parâmetros ou funções de controle. Os SGBDs comerciais

publicam um grupo de APIs que permitem o acesso às funções do sistema.

Entretanto, não permitem modi�car seu código. Outro problema é o fato

de que já existe um grupo de funções de auto-sintonia implementada

nesses sistemas comerciais que poderia afetar os resultados dos testes. Por

último está a motivação deste trabalho ter sido conduzido em colaboração

com outro [50] que seria aproveitado aqui que precisava de funções não

publicamente disponíveis em sistemas comerciais.

Por essas razões foi escolhido um sistema de código aberto. Os sistemas

analisados foram o MySQL e o PostgreSQL. O MySQL é um SGBD

relacional de código aberto disponível em [43]. O PostgreSQL [47] é um

sistema de gerência de bancos de dados objeto-relacional também de código

aberto disponível nas plataformas Unix.

Para o desenvolvimento do trabalho seria necessário previamente im-

plementar funções e criar novas variáveis dentro do SGBD que permitissem

observar determinadas métricas e ajustar parâmetros de controle. O MySQL

demostrou não ser uma boa escolha para este tipo de trabalho devido à falta

de documentação e a desorganização do código. No PostgreSQL, por outro

lado, são notáveis a limpeza e organização do código, assim como a abun-

dância de documentação. Esses aspectos foram determinantes na escolha

desse sistema para a nossa implementação.


4.3Ambiente de desenvolvimento

A linguagem escolhida para a implementação desse trabalho foi C++.

A razão dessa escolha se deve ao fato do PostgreSQL estar escrito nessa

linguagem. O compilador de linha usado foi o gcc versão 3.2.2. A depuração

foi uma das tarefas mais difíceis deste trabalho devido às di�culdades

inerentes à depuração de código concorrente. Esta foi feita usando gdb [20]

e checkpoints manuais.

A ferramenta de modelagem UML usada foi o Together 6.0 para

Windows [60]. Essa é uma plataforma implementada na linguagem Java

que permite modelar e documentar sistemas orientados a objetos. Usando a

ferramenta é possível tanto a geração de código na linguagem C++ ou Java

a partir dos diagramas UML como efetuar o processo inverso.

A plataforma foi um Athlon de 1.6GHz com 128Mb de RAM sob o

sistema operacional Linux versão 8.0.

4.3.1Interação com o SGBD

O código do PostgreSQL foi modi�cado de forma a incluir um parâ-

metro na linha de comandos para iniciar o sistema de auto-sintonia (arquivo

postmaster/postmaster.c). No caso de ser habilitada a opção são instancia-

dos os agentes e incluídos dentro do sistema de agentes.

O sistema de auto-sintonia foi implementado de forma a não intervir

na atividade do SGBD. Assim, no caso do sistema de auto-sintonia estar

desligado o SGBD seguirá funcionando. Os agentes estão embutidos [40]

dentro do SGBD, consumindo recursos deste ainda quando executam em

processos separados.

O motivo para não ter escolhido uma arquitetura integrada é o fato

de não existir um sistema de banco de dados relacional baseado em agen-

tes disponível para esta implementação. A arquitetura em camadas permite

não requer modi�cações no sistema de banco de dados, mas depende das

interfaces que este ofereça para observar e agir sobre o sistema controlado.

Por outro lado, os agentes embutidos tem acesso a todos os componentes

do banco, porém a sua construção se complica pelo fato de precisar com-

preender o funcionamento interno do sistema. Outras desvantagens contra a

arquitetura embutida estão no fato de que somente pode ser implementada

em SGBDs de código aberto, assim como em aspectos relacionados com a

interação com o SGBD como é o caso do modelo de concorrência. Uma van-


tagem fundamental dessa arquitetura é que permite uma implementação

mais otimizada que a versão em camadas. Diferentemente da arquitetura

integrada, na arquitetura embutida pode-se utilizar o sistema ainda sem

ativar os agentes.

O tema da inclusão de threads na implementação do PostgreSQL tem

sido bastante levantada em listas públicas de discussão. No entanto, a equipe

de desenvolvimento do PostgreSQL mantém a posição de que o isolamento

que os processos oferecem garante uma segurança e uma portabilidade

difíceis de alcançar com threads, além de que critérios de e�ciência são muito

dependentes da implementação particular de cada sistema operacional.

Dessa forma, o PostgreSQL segue o esquema de um servidor concorrente que

cria um processo toda vez recebe uma nova conexão. A comunicação entre

os processos se efetua através de sinais, os dados são compartilhados usando

uma estrutura chamada de Memória Compartilhada (Shared Memory) [57]

e a sincronização através de semáforos.

A interação entre o PostgreSQL e o sistema de auto-sintonia se

desenvolve através de uma interface (postgresInterface.cpp). Ela contém

as funções que chamam os métodos de criação e destruição do sistema de

agentes, assim como as funções que executam ações sobre o SGBD e aquelas

invocadas por este para noti�car um evento.

Ao ser iniciado o PostgreSQL com a opção -t, o postmaster faz um

chamado à função ags_create da interface. Essa função cria os agentes, os

inclui no sistema de agentes e inicializa as estruturas de comunicação entre

o PostgreSQL e os agentes.

A detecção de eventos internos se efetua através de checkpoints ou

software probes, que são instruções que se inserem no código de um programa

para coletar e armazenar dados ou chamar a uma rotina de medição [18]. A

interferência produzida pode ser intolerável se for introduzido em porções

críticas do programa medido, ou se tempo de interferência for considerável.

Levando em conta este problema, a política assumida é fazer com que o

processo PostgreSQL somente precise colocar a informação e retornar pois

o sensor correspondente está executando em outro processo concorrente.

O sistema de auto-sintonia implementado usa como repositórios de

informação arquivos de texto simples. A informação contida nesses arquivos

deve ser analisada para detectar violações das expectativas de desempenho

e veri�car a validade de uma ação que tenha sido executada antes em um

contexto similar.

Com o objetivo de comprovar a factibilidade da implementação, assim

como avaliar as di�culdades que esta apresenta, foram implementados


dois mecanismos de auto-sintonia referentes aos problemas de escolha da

estratégia de substituição de páginas em memória (veja a seção A.1) e

ao de thrashing e contenção de dados(veja a seção A.2). Os detalhes da

implementação desses mecanismos se expõem a seguir.

4.3.2Estratégia de substituição de páginas em memória

Foi acrescentada ao PostgreSQL uma função que implementa o método

MRU de substituição de páginas em bu�er (veja o anexo A.1). Esta

função está disponível livremente na Internet, mas ainda não foi inclusa na

distribuição o�cial do PostgreSQL. A diferença da estratégia LRU, a MRU

coloca as páginas no extremo MRU da �la, de forma que serão as primeiras

candidatas a substituição. Isso faz sentido em casos em que a informação será

usada somente uma vez, como pode ser o caso das varreduras seqüenciais,

e pretende preservar a informação útil armazenada no bu�er.

Ao detectar a geração de um plano que inclui varreduras seqüenciais,

o sensor é noti�cado pelo processo PostgreSQL correspondente. O agente

pode então avaliar a execução de uma ação consistente na troca da estratégia

de substituição de páginas utilizando uma função incluída no PostgreSQL

com esse propósito.

4.3.3Thrashing de contenção de dados

A variável razão de con�itos é a razão entre o número total de

bloqueios no sistema e quantos deles são possuídos por transações ativas.

O registro desses valores é feito introduzindo checkpoints nos pontos de

con�rmação de bloqueios no arquivo lock.c do PostgreSQL que consistem

em chamadas à função ags_notify_lock() da interface para noti�car esses

valores.

O �nal de cada transação também é noti�cado. Esse evento supõe a

ativação do mecanismo de controle de admissão, que pode liberar transações

da �la dependendo do valor da razão de con�itos (veja a seção A.2).

Finalmente, a �gura 4.6 mostra o processo executado pelo sistema

após um alarme indicando perigo de thrashing de contenção de dados no

PostgreSQL.

Ao receber um dado do PostgreSQL, o agente de controle de MPL

calcula o valor atual da razão de con�itos. Esse valor é enviado ao agente de


Figura 4.6: Atividade do sistema em um evento de violação de razão decon�itos

histórico para ser armazenado no repositório centralizado e também avaliado

para detectar se existe perigo de thrashing de contenção de dados. Em caso

de violação, o agente Coordenador é noti�cado. Ele inicia um processo de

análise do estado do sistema objetivando diagnosticar as causas reais dos

problemas e assim evitar situações como a comentada na seção 3.2, em

que a reação do mecanismo de auto-sintonia a uma causa aparente piora

mais ainda o desempenho do sistema. Posteriormente as possíveis soluções

ao problema são enumeradas e avaliadas com a informação disponível sobre

ações executadas. As ações �nalmente escolhidas são repassadas aos agentes

correspondentes na forma de requisições de serviço, cujo objetivo é agir sobre

o PostgreSQL para resolver a situação.

4.4Aspectos de implementação

O desenvolvimento do trabalho consistiu na implementação em C++

do framework de agentes discutido anteriormente (veja 4.1) e nas adaptações

necessárias para embutir agentes instanciados a partir desse framework em

um SGBD real, no caso no PostgreSQL. Para esse trabalho aproveitamos

duas versões implementadas por pessoas do nosso grupo em C++ [40, 51].

Ambas implementações foram construídas pensando em um único agente.

Partindo desse código, da documentação e o código original em Java

disponível em [33], foi criada para essa dissertação uma versão que inclui a

gerência de concorrência e a camada de colaboração.

A implementação em geral apresentou a di�culdade já discutida da


falta de suporte a concorrência em C++. O uso deMessage Queues facilitou

a implementação pois evitou a necessidade de utilizar semáforos para

garantir o acesso exclusivo e por permitir implementar facilmente esperas

por condição. Assim como em [33], grande parte da nossa implementação

está baseada em padrões de projeto. A implementação da camada de

colaboração foi di�cultada pois em [33] a colaboração centralizada não está

muito documentada e a implementação distribuída dessa camada não é

completa. Para essa dissertação concluímos que a complexidade da variante

distribuída não era necessária. A versão centralizada foi implementada

seguindo a sugestão de usar o padrão Mediator [33], que é a base do

PostO�ce. Além de suportar o envio de mensagens assíncronas, inclui

também o trafego síncrono de mensagens devido às necessidades do agente

central, que não deveria �car esperando inde�nidamente por consultas

necessárias para a tomada de decisões. Com esse objetivo foi acrescentado

na mensagem o campo future, que contém uma referência à estrutura onde

será armazenado o dado retornado. Essa referência é devolvida ao objeto

que espera a resposta, o qual �cará esperando o dado para continuar o

processamento.

Já construída a estrutura básica dos agentes basta estender as clas-

ses Sensor, Belief, Reasoning e Action (na realidade somente aquelas que o

agente precise) para instanciar cada agente que formará parte do sistema.

Para comprovar a comunicação entre os agentes e a sua inserção no SGBD,

em nosso protótipo foram instanciados um agente de histórico, um agente de

Controle de Carga, um outro agente para o controle de política de substitui-

ção de páginas no bu�er e um agente central. Dado que os algoritmos usados

por esses agentes in�uem na e�cácia do sistema, eles devem ser melhorados

para obter bons resultados.

A inserção do sistema de agentes no PostgreSQL representou um

grande desa�o. O PostgreSQL é um sistema robusto e complexo que precisou

ser estudado a fundo devido à escolha de embutir o sistema de agentes

dentro do SGBD. Diversas veri�cações são feitas pelo PostgreSQL durante

a execução dos processos, de forma que o sistema deveria inserir-se da forma

mais transparente possível para não gerar inconsistências. No protótipo os

agentes executam em threads diferentes dentro do processo do postmaster.

Uma solução melhor seria colocar o sistema de agentes dentro de um

processo separado, de forma a garantir o isolamento do SGBD no caso de

erros no sistema de agentes, facilitando também a depuração. No entanto,

essa não é uma tarefa fácil, pois é preciso reproduzir o procedimento (não

documentado) que o PostgreSQL executa a cada vez que um novo processo


é criado. Essa solução foi implementada posteriormente em [52].

4.5Conclusões

A implementação por um lado mostrou a viabilidade da inserção

de um sistema de agentes construído seguindo a arquitetura centralizada

dentro de um SGBD real, assim como as di�culdades que isto implica. A

problemática da integração do sistema de agentes com o SGBD usando

uma arquitetura embutida fez aumentar consideravelmente a complexidade

da implementação, impossibilitando no caso a apresentação de resultados

quantitativos.

As di�culdades fundamentais enfrentadas durante a implementação

foram:

� Integração com o PostgreSQL.

� Depuração em ambiente concorrente

� Gerência de concorrência.

� Implementação do framework de agentes sob as limitações do C++.

5

Conclusões e Contribuições

Neste capítulo se comentam brevemente os resultados obtidos, des-

crevendo as conclusões e principais contribuições, assim como as possíveis

extensões e os trabalhos futuros.

5.1Resumo

No presente trabalho foi feito um estudo do problema da auto-sintonia

global de SGBDs, assim como os trabalhos relacionados a esse tema. Tam-

bém foram discutidas algumas possíveis abordagens. As vantagens da im-

plementação de sistemas de auto-sintonia usando agentes foram colocadas

e propostas duas arquiteturas para a implementação de sistemas de auto-

sintonia usando agentes. Essas arquiteturas propõem aproveitar as caracte-

rísticas dos agentes para construir sistemas auto-adaptáveis. Os mecanismos

de auto-sintonia locais podem ser integrados ao SGBD como agentes que

colaboram para garantir o desempenho do SGBD como um todo. Para ava-

liar as arquiteturas propostas foi implementado e estudado um sistema de

auto-sintonia embutido em um SGBD PostgreSQL.

5.2Principais contribuições

Consideramos que as principais contribuições do trabalho são:

1. Uma arquitetura para auto-sintonia global baseada em agentes.

2. A enumeração dos requisitos que devem possuir os sistemas de auto-

sintonia global.

3. A abordagem usando agentes, que assim como facilita a introdução

de inteligência no sistema, oferece uma grande �exibilidade na mo-

di�cação dos mecanismos que governam cada etapa do processo de


auto-sintonia. Isto sugere a vantagem dessa abordagem para a pes-

quisa e implementação de protótipos.

4. Uma proposta que permite a integração paulatina e relativamente

simples de novos mecanismos de auto-sintonia local, ao mesmo tempo

que trata o problema de sintonia do SGBD como um todo.

5. A implementação de um protótipo para a avaliação da e�cácia e

complexidade da implantação da arquitetura centralizada em um

SGBD real.






anteriores, em que os sistemas de auto-sintonia tem sido sempre tratados


5.3Conclusões

A auto-sintonia é uma necessidade em um número crescente de con-

textos. Mesmo quando a decisão �nal ainda deva ser tomada por um admi-

nistrador, os sistemas devem possuir capacidade de se auto-adaptar ao seu

ambiente de forma a não precisar dos administradores em tarefas rotineiras.

Os SGBDs atuais não oferecem infra-estruturas para auto-sintonia global,

apesar de que a sua estrutura monolítica faz com que as interações entre

componentes e cargas de trabalho sejam imprevisíveis, di�cultando a tarefa

de auto-sintonia que sempre tem que lidar com uma dose de incerteza.

A construção de novos tipos de SGBDs desenhados desde o inicio

visando obter um bom desempenho parece ser a solução a esse problema,

e já existem trabalhos que seguem essa vertente [12, 23, 41]. Entretanto,

iniciativas que integrem auto-sintonia global em sistemas já existentes

podem ser aplicadas.

Este trabalho propõe uma abordagem inicial à implementação desses

sistemas usando agentes de software. Os agentes podem embutir nos siste-

mas em que são integrados características que lhes são próprias, como é o

caso da sua adaptabilidade, desejáveis nesse tipo de aplicação.

Concluímos nesse trabalho que a arquitetura proposta é capaz de

acrescentar adaptabilidade aos sistemas ante mudanças do ambiente. O uso


de agentes introduz �exibilidade na implementação. O sistema de auto-

sintonia representa uma carga para o sistema observado, mas ainda assim

resulta em benefícios. O sistema cumpre com os requisitos para os quais foi

projetado.

5.4Trabalhos futuros

Enquanto acreditamos que é possível estender a implementação atual

do sistema para incluir a criação tanto de threads como de processos de

aplicação, até o momento nossa implementação inclui somente a gerência

de threads. A inclusão de processos de aplicação deve ser valorada como

trabalho futuro.

Acreditamos que a incerteza provocada pelas inter-relações existentes

no sistema possam ser contornadas com uma mistura entre a realimentação

do ciclo de controle e um forte componente probabilístico no raciocínio.

As estratégias de negociação dos agentes devem continuar a ser

exploradas. O sistema ganharia em autonomia se os agentes, provavelmente

baseados em noções de utilidade, considerassem a obtenção de con�gurações

ótimas do sistema como m todo como um bene�cio para os seus próprios

interesses em lugar de manter a coerência global sujeitos a compromissos

sociais.

Os estudos sobre o processo de con�guração do sistema devem ser

aprofundados.

O problema identi�cado em [9] de como garantir que o processo de

diagnóstico vai alcançar o desempenho ótimo do SGBD ainda está por ser

resolvido.

Ficam também por estudar as diferentes alternativas de construção e

gerência da base de conhecimento.

Por último, acreditamos que a arquitetura apresentada é válida não

somente para SGBDs mas também para sistemas que precisem da alocação

de recursos em geral. Aplicar a arquitetura proposta em sistemas similares

pode ser um trabalho interessante.

Bibliogra�a

[1] ANDREWS, G.. Foundations of Multithreaded Parallel and

Distributed Programming. Addison-Wesley, 2000.

[2] BERNSTEIN, P.; BRODIE, M.; CERI, S.; DEWITT, D.; FRANKLIN,

M.; GARCIA-MOLINA, H.; GRAY, J.; HELD, J.; HELLERSTEIN, J.;

JAGADISH, H.; LESK, M.; MAIER, D.; NAUGHTON, J.; PIRAHESH,

H.; STONEBRAKER, M. ; ULLMAN, J.. The Asilomar report on

database research. ACM SIGMOD Record, 27(4):74�80, 1998.

[3] BROWN, K.; CAREY, M. ; LIVNY, M.. Managing memory to meet

multiclass workload response time goals. Em: PROCEEDINGS OF

THE INTERNATIONAL CONFERENCE ON VERY LARGE DATABASES

(VLDB), 1993.

[4] BURNS, A.; DAVIES, G.. Concurrent Programming. Addison-Wesley,

1993.

[5] BAILEY, J.; GEORGEFF, M.; KEMP, D.; KINNY, D. ; RAMAMOHA-

NARAO, K.. Active databases and agent systems - a compari-

son. Em: PROCEEDINGS OF THE INTERNATIONAL WORKSHOP ON

RULES IN DATABASE SYSTEMS, LECTURE NOTES IN COMPUTER

SCIENCE 985, p. 342�356. Springer, 1995.

[6] BERRY, R. F.; HELLERSTEIN, J. L.. A �exible and scalable appro-

ach to navigating measurement data in performance manage-

ment applications. Em: PROCEEDINGS OF THE IEEE INTERNATI-

ONAL WORKSHOP ON SYSTEMS MANAGEMENT (SMW), p. 92�103,

1996.

[7] BIGUS, J. P.; HELLERSTEIN, J. L.; JAYRAM, T. S. ; SQUILLANTE,

M. S.. Auto tune: A generic agent for automated perfor-

mance tuning. Em: PROCEEDINGS OF THE INTERNATIONAL CON-

FERENCE AND EXHIBITION ON THE PRACTICAL APPLICATION OF


INTELLIGENT AGENTS AND MULTI-AGENT SYSTEMS (PAAM), p.

33�52, 2000.

[8] BARRERA III, J. S.. Self-tuning systems software. Em: PROCEE-

DINGS OF THE WORKSHOP ON WORKSTATION OPERATING SYS-

TEMS, IEEE COMPUTER SOCIETY, p. 194�197, 1993.

[9] BENOIT, D.. Automatic Diagnosis of Performance Problems in

Database Management Systems. PhD thesis, School of Computing,

Queen's University, 2003.

[10] CHAUDHURI, S.; GUPTA, A. ; NARASAYYA, V.. Compressing sql

workloads. Em: PROCEEDINGS OF THE ACM SIGMOD INTERNA-

TIONAL CONFERENCE ON MANAGEMENT OF DATA, p. 488 � 499,

2002.

[11] COSTA, R. L. C.; LIFSCHITZ, S.. Index self-tuning with agent-

based databases. Em: PROCEEDINGS OF THE LATIN-AMERICAN

CONFERENCE ON INFORMATICS (CLEI), p. 76, Abstracts Proceedings;

12 pp. CD�ROM Proceedings, 2002.

[12] CHAUDHURI, S.; WEIKUM, G.. Rethinking database system archi-

tecture: Towards a self-tuning risc-style database system. Em:

PROCEEDINGS OF THE INTERNATIONAL CONFERENCE ON VERY

LARGE DATABASES (VLDB), p. 1�10, 2000.

[13] DIAO, Y.; HELLERSTEIN, J. L.; PAREKH, S. ; BIGUS, J. P.. Managing

web server performance with autotune agents. IBM SYSTEMS

JOURNAL, 42(1):136 � 149, 2003.

[14] EHRGOTT, M.; GANDIBLEUX, X.. An Annotated Bibliography of

Multi-objective Combinatorial Optimization. Technical Report

62/2000, Universitat Kaiserslautern, 2000.

[15] ELMASRI, R.; NAVATHE, S.. Fundamentals of Database Systems.

Benjamin-Cummings, 1994.

[16] FEITELSON, D. G.; NAAMAN, M.. Self-tuning systems. IEEE

Software, 16(2):52�60, 1999.

[17] FRANK, M.; OMIECINSKI, E. ; NAVATHE, S.. Adaptive and Auto-

mated Index Selection in RDBMS. Em: PROCEEDINGS OF THE

INTERNATIONAL CONFERENCE ON EXTENDING DATABASE TECH-

NOLOGY (EDBT), p. 277�292, 1992.


[18] FERRARI, D.. Computer Systems Performance Evaluation.

Prentice Hall, 1978.

[19] GARCIA, A.; CHAVEZ, C.; SILVA, V. ; LUCENA, C.. Developing

Multi-Agent Software: an Aspect-Based Approach and a

Pattern-Based Approach. Technical report, PUC-RIO, November

2001. MCC40/01.

[20] GDB: The GNU Project Debugger.

http://www.gnu.org/software/gdb/gdb.html, acessado em 5/03/2004.

[21] GAMMA, E.; HELM, R.; JOHNSON, R. ; VLISSIDES, J.. Padrões de

projeto: soluções reutilizáveis de software orientado a objetos.

Porto Alegre: Bookman, 2000.

[22] GREY, J.. The Benchmark Handbook. Morgan Kaufmann Publishers,

Inc., second edição, 1998.

[23] HARIZOPOULOS, S.; AILAMAKI, A.. A case for staged database

systems. Em: PROCEEDINGS OF THE BIENNIAL CONFERENCE ON

INNOVATIVE DATA SYSTEMS RESEARCH (CIDR), 2003.

[24] HUHNS, M.; STEPHENS, L.. Multiagent systems and societies of

agents. Em Weiss [70], capítulo 2, p. 79�120.

[25] HEISS, H.; WAGNER, R.. Adaptive load control in transaction

processing systems. Em: PROCEEDINGS OF THE INTERNATIONAL

CONFERENCE ON VERY LARGE DATABASES (VLDB), p. 47�54, 1991.

[26] HARVEY, A.. Time series models. MIT Press, second edição, 1993.

[27] HELLERSTEIN, J. L.. A comparison of techniques for diagnosing

performance problems in information systems. Em: PROCE-

EDINGS OF THE SIGMETRICS CONFERENCE ON MEASUREMENT

AND MODELING OF COMPUTER SYSTEMS, p. 278�279. ACM, 1994.

[28] HELLERSTEIN, J. L.. Automated tuning systems: Beyond deci-

sion support. Em: PROCEEDINGS OF THE COMPUTER MEASURE-

MENT GROUP, p. 277�292, 1997.

[29] HORN, P.. Autonomic computing: IBM's perspec-

tive on the state of information technology, 2001.

http://www.research.ibm.com/autonomic/manifesto, acessado em

11/01/2004.


[30] IBM and Autonomic Computing, 2003. http://www-

306.ibm.com/autonomic/pdfs/ACwpFinal.pdf, acessado em 11/01/2004.

[31] JAIN, R. K.. The Art of Computer Systems Performance

Analysis. John Wiley & Sons, 1991.

[32] KWAN, E.; LIGHTSTONE, S.; SCHIEFER, B.; STORM, A. ; WU, L.. Au-

tomatic database con�guration for DB2 universal database:

Compressing years of performance expertise into seconds of

execution. Em: PROCEEDINGS OF THE CONFERENCE ON DATA-

BASE SYSTEMS FOR BUSINESS, TECHNOLOGY AND WEB (BTW

2003), 2003.

[33] KENDALL, E.; MURALI KRISHNA, P.; C.V., P. ; SURESH, C.. A

framework for agent systems, capítulo 6, p. 113�154. John Wiley &

Sons, 1999.

[34] LIFSCHITZ, S.; MILANÉS, A. ; SALLES, M. V.. Estado da arte em

auto-sintonia de sgbd relacionais. Preprint, 2004.

[35] LAVENDER, R. G.; SCHMIDT, D. C.. Active object: an object beha-

vioral pattern for concurrent programming. Em: Vlissides, J.;

Coplien, J. ; Kerth, N., editors, PATTERN LANGUAGES OF PROGRAM

DESIGN 2, capítulo 30, p. 483��499. Addison�Wesley, 1996.

[36] LERNER, A.. Troubleshooting, capítulo 7. Em SB03 [49], 2003.

[37] MENASCE, D.; ALMEIDA, V.. Capacity Planning for Web Perfor-

mance: Metrics, Models, and Methods. Prentice Hall, 1998.

[38] MENASCÉ, D. A.; BARBARÁ, D. ; DODGE, R.. Preserving QoS of E-

commerce Sites Through Self-Tuning: A Performance Model

Approach. Em: PROCEEDINGS OF THE ACM CONFERENCE ON

ELECTRONIC COMMERCE (ACM EC), p. 224 � 234. ACM Press, 2001.

[39] MARTIN, P.; POWLEY, W.; LI, H. ; ROMANUFA, K.. Managing

database server performance to meet QoS requirements in

electronic commerce systems. International Journal on Digital

Libraries, 3(4):316�324, 2002.

[40] MACÊDO, J. A. F.. Um estudo de SGBDs baseados em agentes.

Master's thesis, Departamento de Informática, Pontifícia Universidade

Católica do Rio de Janeiro (PUC-Rio), 2000.


[41] MCCANN, J. A.. The database machine: Old story, new slant?

Em: PROCEEDINGS OF THE BIENNIAL CONFERENCE ON INNOVA-

TIVE DATA SYSTEMS RESEARCH (CIDR), 2003.

[42] MOHAN, C.. Interactions between query optimizations and con-

currency control. Em: PROCEEDINGS OF THE INTERNATIONAL

WORKSHOP ON RESEARCH ISSUES ON DATA ENGINEERING: TRAN-

SACTION AND QUERY PROCESSING (RIDE-TQP), p. 26�35, 1992.

[43] MySQL. http://www.mysql.com, acessado em 11/01/2004.

[44] NIEMIEC, R.; BROWN, B. ; TREZZO, J.. Oracle 9i Performance

Tuning: dicas e técnicas. Campus, 2003.

[45] OGATA, K.. Modern Control Engineering. Prentice Hall, 3rd edição,

1997.

[46] Patrol(r) knowledge module (tm) for unix v8.3 - features and

faqs. http://www.softwareinnovations.co.uk/downloads/patrol/9066.pdf,

acessado em 11/01/2004.

[47] PostgreSQL. http://www.postgresql.com, acessado em 11/01/2004.

[48] RUSSELL, S. J.; NORVIG, P.. Arti�cial Intelligence: A Modern

Approach. Prentice Hall, 2nd edição, 1995.

[49] SHASHA, D.; BONNET, P.. Database Tuning: Principles, Experi-

ments and Troubleshooting Techniques. Morgan Kaufmann, 2003.

[50] SALLES, M. V.. Uma arquitetura baseada em agentes para a

resolução do problema de auto-sintonia de índices em sgbds

relacionais. Documento apresentado na defesa de proposta de Disser-

tação, Departamento de Informática, Pontifícia Universidade Católica do

Rio de Janeiro (PUC-Rio), 2003.

[51] SALLES, M. V.. Agente de auto-sintonia de Índices baseado em

diferenças. Projeto Final de Programação, Departamento de Informática,

Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio), 2003.

[52] SALLES, M. V.. Criação autônoma de Índices em bancos de

dados. Master's thesis, Departamento de Informática, Pontifícia Univer-

sidade Católica do Rio de Janeiro (PUC-Rio), 2004.

[53] SANDHOLM, T.. Distributed rational decision making. Em Weiss

[70], capítulo 5, p. 201�258.


[54] SEVCIK, K. C.. Database system performance prediction using

an analytical model (invited paper). Em: PROCEEDINGS OF


(VLDB), p. 182�198. IEEE Computer Society, 1981.

[55] SHALLAHAMER, C.. Total performance management. Oracle

Magazine, 69(2), 1995.

[56] SHASHA, D.. Tuning databases for high performance. ACM

Computing Surveys, 28(1):113�115, March 1996.

[57] STEVENS, R.. Unix Network Programming, volume 2. Prentice

Hall, 2 edição, 1999. Interprocess Communications.

[58] Transaction processing council. http://www.tpc.org, acessado em

11/02/2004.

[59] THOMASIAN, A.. Two-phase locking performance and its th-

rashing behavior. ACM Transactions in Database Systems, 18(4):579�

625, 1993.

[60] Together. http://www.togethersoft.com, acessado em 11/02/2004.

[61] VILALTA, R.; APTE, C.; HELLERSTEIN, J.; MA, S. ; WEISS, S.. Pre-

dictive algorithms in the management of computer systems.

IBM Systems Journal, special issue in Arti�cial Intelligence, 41(3):461�474,

2002.

[62] VAN DEN AKKER, J.; SIEBES, A.. Enriching active databases with

agent technology. Em: PROCEEDINGS OF THE INTERNATIONAL

WORKSHOP ON COOPERATIVE INFORMATION AGENTS, p. 116�125,

1997.

[63] Veritas software corporation.

http://www.veritas.com, acessado em 11/01/2004.

[64] VICARI, S.. Proposta de um sistema de regras de sintonia de

performance para aplicações de bancos de dados. Master's thesis,

Universidade Federal do Rio Grande do Sul, July 1998.

[65] WORSLEY, J.; DRAKE, J.. Practical PostgreSQL. O'Reilly &

Associates, 2002.


[66] WEIKUM, G.; HASSE, C.; MÖNKEBERG, A. ; ZABBACK, P.. The

comfort automatic tuning project. Information Systems, 19(5):381�

423, 1994.

[67] WEISS, S. M.; INDURKHYA, N.. Predictive Data Mining: A

Practical Guide. Morgan Kaufmann Publishers, 1998.

[68] WEIKUM, G.; MÖNKEBERG, A.; HASSE, C. ; ZABBACK, P.. Self-

tuning database technology and information services: from

wishful thinking to viable engineering. Em: PROCEEDINGS OF


(VLDB), p. 20�31, 2002.

[69] VON WANGENHEIM, C. G.; VON WANGENHEIM, A.. Raciocínio

Baseado em Casos. Editora Manole Ltda., 2003.

[70] Weiss, G., editor. Multiagent Systems: A modern Approach to

Distributed Arti�cial Intelligence. The MIT Press, Cambridge, MA,

USA, 1999.

[71] WEISER, M.. Some computer science issues in ubiquitous

computing. Communications of the ACM, 36(7):75�84, 2003. Special

issue on Computer Augmented Environments.

[72] WISETH, K.. Oracle database 10g, the world's �rst self-

managing, grid-ready database arrives. Oracle Magazine, p. 28�37,

September 2003.

[73] WOOLDRIDGE, M.. Intelligent agents. Em Weiss [70], capítulo 1, p.

27�78.

A

Anexo

Apresentamos aqui um grupo de algoritmos para controle de sintonia

que foram usados durante a implementação deste trabalho para comprovar as

interações entre os agentes.

A.1Substituição de páginas em cache

As operações sobre os dados são realizadas em memória principal. Dado

que seu custo usualmente impede manter o banco de dados em memória RAM,

são utilizadas técnicas que gerenciam a disponibilidade das páginas de memória,

assim como a integridade e persistência dos dados. A página é a unidade

básica de transferência de dados entre memória principal e disco. O propósito

fundamental do gerente de bu�er é manter endereçáveis as páginas em memória

principal e coordenar a escrita das páginas a disco com outros gerentes.

O número de acessos a disco deve ser minimizado. O gerente de bu�er

administra um segmento em memória virtual que está particionado em frag-

mentos de igual tamanho chamados de frames, que podem conter exatamente

uma página.

O bu�er de dados está implementado como uma �la, como é mostrado

na �gura A.1. Essa �la se organiza de forma que em um extremo se colocam

as páginas mais recentemente usadas que vão avançando na �la no sentido

LRU (Least Recently Used - Menos Recentemente Usadas) na medida em que

aumenta o tempo sem serem atualizadas. Quando são atualizadas se colocam no

extremo MRU (Most Recently Used - Mais Recentemente Usadas) novamente.

A estratégia LRU consiste em que a página substituída é aquela do extremo

LRU, que é então colocada no extremo MRU da �la. Já a estratégia MRU

substitui a página no extremo MRU.

Uma requisição de página ao gerente de bu�er é seguida dos seguintes

passos:


Figura A.1: A estratégia LRU toma uma página limpa do extremo LRU dacache

� Checar se a página solicitada está no bu�er. Se for encontrada é devolvido

o endereço do frame. Esse caso é chamado de cache hit.

� Caso contrário a página deve ser trazida do disco e colocada no bu�er.

Por esse motivo se procura primeiramente algum frame que não contenha

uma página válida.

� Se não existem frames com páginas não válidas, segue a determinação da

página que será retirada. A escolha depende da estratégia de substituição

de páginas implementada. Por exemplo, de seguir uma estratégia MRU

será selecionada a página mais recentemente utilizada (a que está no

extremo MRU da �la). Já utilizando uma estratégia LRU, a escolhida

será a página menos recentemente utilizada(extremo LRU).

� Se a página a retirar estiver marcada como dirty (modi�cada), deverá ser

escrita em seu bloco do disco.

� O bloco que contém a página solicitada é copiado no frame eleito.

� O endereço do frame é devolvido.

LRU é usada comumente para páginas que serão usadas mais de uma vez

ou que precisam ser atualizadas. Já o MRU é usado para páginas que serão lidas

somente uma vez, como longas varreduras de tabelas únicas.

A política de substituição de páginas de PostgreSQL é LRU. Aplicando

essa política se obtém bons resultados para determinados padrões de acesso

ao banco de dados, como aqueles que implicam atualizações freqüentes e alta

localidade de dados 1. No caso de operações como longas varreduras seqüenciais,

1Localidade é a tendência de dados recentemente usados de serem novamente referen-ciados por operações posteriores.


entretanto, não deve ser usada essa estratégia, pois a cache seria esvaziada de

informação útil. Nesses casos, MRU torna-se uma boa escolha.

A.2Nível de Multiprogramação

O Nível de Multiprogramação (MultiProgramming Level - MPL) é o

parâmetro que controla o número máximo de processos concorrentes que podem

ser atendidos pelo sistema. O MPL pode in�uir de forma inversa na vazão e no

tempo de resposta, sendo que até um certo limite o aumento do MPL aumenta

a vazão mas diminui o tempo de resposta por causa da contenção de recursos

requisitados por vários processos simultaneamente. A determinação de seu valor

ótimo é um processo complexo por causa da dependência que tem com a carga

de trabalho, como mostrado na �gura 2.2.

Em sistemas de processamento de transações que executam concorrente-

mente, pode ocorrer um problema de sobrecarga em que excessivos con�itos de

bloqueio provoquem que o tempo de resposta de uma grande parte das transa-

ções aumente drasticamente, a vazão caia e o sistema deva ser reiniciado. Este

problema é chamado de thrashing de contenção de dados. Conforme [18, 66],

o thrashing pode ser evitado através do controle do MPL.

Em [49] se sugere basear a escolha do nível de multiprogramação no

método de ajustes incrementais [25], dado que lamentavelmente os sistemas

de banco de dados não possuem o algoritmo proposto em [66] que não pode

ser usado de outra forma porque requer monitoramento contínuo. A proposta

de [66] propõe um método chamado controle de carga orientado a con�itos.

Nele se procura o controle automático e dinâmico do nível de bloqueios através

da observação de uma métrica chamada de "razão de con�ito"(con�ict ratio)

que se calcula como a razão entre o total de bloqueios existentes no sistema

e o total que pertencem a transações ativas, re�etindo o grau de contenção

de dados presente no sistema. A razão de con�ito tem um valor crítico quase

constante com independência da carga bem de�nido tanto experimental como

analiticamente em torno de 1.3 [59, 66]. Caso esta métrica alcance seu valor

crítico, existem grandes probabilidades de thrashing e devem ser tomadas

ações de sintonia. Estas podem ser o controle de admissão e o controle de

cancelamento. O princípio de trabalho do controle de carga orientado a con�itos

é mostrado na �gura A.2.

O controle de admissão determina se uma nova transação deve ser

processada ou se deve esperar em �la na entrada do sistema. O algoritmo para

o controle de admissão proposto em [66] é o seguinte:


Figura A.2: O princípio de trabalho do controle de carga orientado a con�itos[66].

upon a BOT request for transaction T:

if conflict ratio < critical conflict ratio

then admit T

else put T in the transaction queue

fi

upon the EOT of transaction T:

update conflict ratio

if conflict ratio < critical conflict ratio then

foreach transaction Tqueued in the transaction queue do

if (Tqueued will be started the first time) or

Tqueued has been a deadlock victim or cancelation

victim before and all transactions that Tqueued was

waiting for in its previous execution have been

succesfully completed)

then admit Tqueued

fi

od

fi


Note que o algoritmo é executado ao ser requisitado um inicio de

transação (BOT - Begin Of Transaction) e ao terminar uma transação. Uma

nova transação será admitida no sistema se o valor da razão de con�itos não

ultrapassar o nível crítico. Caso contrário a transação é colocada na �la. Ao

terminar de executar uma transação é checado o estado da razão de con�itos.

Se o valor da variável estiver dentro do intervalo admissível, uma heurística

é executada para liberar transações da �la. Esta prioriza transações novas e

aquelas que foram canceladas e já podem ser completadas.

Uma melhora ao algoritmo pode consistir na determinação dos locks

que cada nova transação vai solicitar, de forma que não sejam colocadas na

�la aquelas cujas requisições não estão relacionadas com o problema presente

de thrashing. Da mesma forma podem ser escolhidas as transações a serem

liberadas da �la quando o valor da razão de con�ito sair da região crítica.

Isso implica, por outro lado, na necessidade de algoritmos para controlar

a possibilidade de deadlocks entre as transações que �cam na �la. Nessa

dissertação não foi usada uma implementação aprimorada deste controle pois

não se trata de um objetivo fundamental da pesquisa e também devido as

limitações de tempo para desenvolvimento.

Dado que as transações que estão sendo executadas pelo sistema podem

continuar a solicitar novos bloqueios, o controle de admissão é complementado

com o controle de cancelamento. O controle de cancelamento pode abortar tran-

sações que presentemente estão no sistema, colocando-as na �la de transações

até serem reiniciadas posteriormente pelo mecanismo de controle de admissão.

O algoritmo para o controle de cancelamento proposto é apresentado a seguir:

Upon a lock wait of transaction T:

update conflict ratio

while conflict ratio >= critical conflict ratio do

among the transactions that are blocked and block

other transactions

determine the transaction Tvictime with the smallest product

number of locks held * number of previous restarts

(with the transaction with the highest product being exempt)

abort Tvictim and put it in the transaction queue

if no elegible transaction found then exit loop fi

od

O algoritmo mostrado cancela a transação com o menor produto número

de bloqueios possuídos*número de prévios reinícios. A idéia por trás a heurística


para a escolha da vítima de cancelamento está em um compromisso entre a

minimização de esforço perdido e a tentativa de evitar starvation. A transação

cancelada é colocada na �la de transações até ser readmitida no sistema pelo

controle de admissão.

anolan yamilé milanés barrientos uma arquitetura para auto ...postgresql/conteudo/... · 3.2...

Documents