Microsoft SQL Server

O SQL Server é um sistema de gestão de bases de dados relacionais cuja função principal é armazenar e retornar dados de acordo com os pedidos efectuados ao sistema. Tem todas as carac- terísticas associadas às bases de dados relacionais, no entanto tem um conjunto de especificidades que embora não estando no âmbito deste projecto importa destacar, a linguagem utilizada para ob- ter dados que é o T-SQL, uma variante do SQL clássico. É disponibilizada também uma interface para configuração, gestão e administração de todos os componentes associados ao SQL Server. Esta ferramenta é o SQL Server Management Studio e a Figura2.10representa a interface dessa ferramenta.

A importância desta tecnologia no âmbito deste projecto prende-se com o facto de os servi- dores e as bases de dados a monitorizar utilizarem esta tecnologia, para além disto a ferramenta a desenvolver terá grande parte da sua estrutura também nesta tecnologia.

Figura 2.11: Nagios Interface

2.6.2 Nagios

O Nagios é um software de monitorização de infraestruturas e é actualmente utilizado na Farfetch.

O Nagios assenta num paradigma reactivo e tem por base um sistema de alarmística. São configurados pesquisas sobre as infraestruturas monitorizadas que são executadas em intervalos de tempo definidos no processo de configuração. Quando os resultados das pesquisas ultrapassam os limites definidos, são enviados alertas e as equipas de suporte respondem a esses alertas. Existem diferentes níveis de alarmística em que cada um tem um valor limite associado para ser possível atacar problemas com mais tempo de antecedência. No entanto é uma ferramenta de monitorização que não permite análise sobre os dados acumulados tendo apenas a função de alertar em caso de problema.

Uma das suas vantagens é o facto de ser altamente configurável, no entanto, o objectivo da ferramenta é completamente distinto do que se pretende desenvolver no âmbito desta dissertação.

2.6.3 New Relic

O New Relic é uma ferramenta de monitorização. A sua tecnologia é disponibilizada no mo- delo software como serviço e monitoriza aplicações Web e Mobile em tempo real. Os dados são apresentados na plataforma da empresa e permite aos utilizadores a utilização de plugins para monitorizar diferentes aspectos das suas aplicações.

O New Relic permite monitorizar um conjunto variado de métricas de acordo com a configu- ração definida pelo utilizador, permite ainda um nível de detalhe bastante elevado sendo possível seguir todos os passos efectuados por um pedido à base de dados, desde a aplicação até à base de dados. Outra funcionalidade interessante é o facto de armazenar os dados recolhidos e ser possível analisar dados históricos, no entanto não fornece nenhum mecanismo de comparação re- lativamente a métricas de bases de dados que permita comparar performance entre intervalos de tempo distintos.

Existe uma funcionalidade particularmente interessante, que surge da possibilidade de ligar a recolha de informação às mais variadas fontes, em que é disponibilizada a informação do dia e hora em que foi instalada uma nova versão de uma aplicação, alterações à sua base de dados incluídas. Esta informação permite analisar a performance antes da alteração e após a alteração o que é uma grande mais valia para o processo de análise de performance. No entanto, o facto de não disponibilizar modos de comparação mais desenvolvidos torna esta análise um processo moroso e repetitivo.

A Figura2.12é ilustrativa da interface da plataforma do New Relic.

2.7

Resumo e Conclusões

Após a leitura deste capítulo espera-se que sejam claros os conceitos que constituem a base do trabalho desenvolvido, desde os paradigmas de monitorização, técnica de processamento da baselineaté aos possíveis impactos de uma ferramenta como a que foi desenvolvida. Foram ainda descritas ferramentas disponíveis para o desenvolvimento do projecto bem como ferramentas de monitorização disponíveis no mercado.

No próximo capítulo será abordada a arquitectura definida para a ferramenta desenvolvida, bem como a estrutura interna responsável pela recolha das métricas. Serão também apresentadas as métricas recolhidas pela ferramenta.

Arquitectura

Este capítulo descreve detalhadamente o problema a abordar, a arquitectura da solução imple- mentada, nomeadamente a interacção entre componentes e o fluxo de dados entre esses mesmos componentes. São ainda descritos os indicadores de performance recolhidos e o seu significado.

3.1

Definição do Problema

O problema em análise neste trabalho é a performance de bases de dados, nomeadamente a performance de bases de dados relacionais, neste caso específico das bases da dados da Farfetch mas pode ser aplicado a qualquer base de dados desde que siga o modelo relacional, com as res- pectivas adaptações ao modelo de negócio que estiver a ser analisado e à tecnologia das respectivas bases de dados.

Pretende-se identificar as métricas que melhor representem a performance associada a uma base de dados relacional, por forma a monitorizar a performance de uma instância SQL Server e das bases de dados existentes nela.

No caso especifico serão analisadas as bases da dados da Farfetch que suportam tanto as equi- pas de desenvolvimento como o negócio da empresa. Iremos analisar bases de dados que suportam uma plataforma de venda electrónica com milhões de utilizadores.

É importante perceber o tipo de negócio para perceber por completo o problema, nomeada- mente, existem padrões de actividade associados ao modelo de negócio da empresa que afectam directamente a performance das bases de dados. Esses mesmos padrões de actividade são indica- dores das métricas que têm de ser analisadas, por exemplo um aumento do número de utilizadores leva a um aumento do número de vendas, posteriormente as operações sobre a base de dados para tornar persistentes os dados relativos a essas mesmas vendas podem não estar optimizados e em elevado número provocarem um impacto negativo na performance.

O problema que este estudo se propõe a resolver é então a identificação das métricas que melhor representem a performance de uma base de dados associada a um modelo de negócio.

Requisitos funcionais:

• Como utilizador quero poder escolher os servidores a monitorizar.

• Como utilizador quero escolher o servidor cujas métricas serão apresentadas.

• Como utilizador quero poder escolher um intervalo específico de tempo e observar apenas valores relativos a esse intervalo.

• Como utilizador quero poder comparar valores de métricas entre dois intervalos de tempo. • Como utilizador quero poder escolher uma base de dados específica para análise.

• Como utilizador quero que as métricas me sejam apresentadas num formato de fácil análise. • Como utilizador quero que me sejam apresentadas métricas relativas ao estado de saúde do

servidor.

• Como utilizador quero ter acesso a métricas específicas por base de dados. Requisitos não funcionais:

• O sitema deve ser centralizado.

• O sitema deve ser capaz de monitorizar em paralelo múltiplos servidores. • O sistema deve ser instalado de forma automática.

• O sistema deve funcionar de forma automática.

• O sistema deve permitir adicionar novos servidores para monitorização a qualquer mo- mento.

• O sistema deve provocar o mínimo possível de impacto nos servidores monitorizados. • O sistema deve efectuar o processamento e a apresentação dos relatórios de forma eficaz e

rápida, para que a experiência de utilização seja positiva.

• O sistema deve ser o menos intrusivo possível nos servidores monitorizados.

Estando o problema definido, as próximas secções deste capítulo vão descrever a arquitectura pensada para a solução.

3.2

Arquitectura

Esta secção descreve a arquitectura da solução encontrada para o problema descrito anterior- mente. Será apresentado um diagrama de componentes UML representativo da arquitectura e uma descrição de cada componente da solução desenvolvida.

A figura3.1representa a arquitectura pensada para a solução de um ponto de vista global. São então três os componentes da solução pensada. Monitoring Server é o ponto central do sistema desenvolvido, é aqui que são armazenados os dados recolhidos que mais tarde fornecem os dados ao modelo de visualização e a estrutura de recolha de dados está também implementada neste servidor. É também aqui que é realizada toda a lógica de tratamento dos valores recolhidos e processamento de dados. Por uma questão de aproveitamento de recursos no caso do trabalho desenvolvido o Report Server, onde está alojado o modelo de visualização dos dados, encontra-se também no Monitoring Server, idealmente estaria num servidor separado.

Monitored Servers representa o conjunto de todos os servidores cujas bases de dados irão ser monitorizadas, contêm uma parte da estrutura de recolha de dados, dado que para a recolha de algumas métricas foi necessário efectuar a recolha localmente por questões de performance e impacto nos servidores.

O componente final é o Web Browser que será o modo de utilização da ferramenta.

Esta é a arquitectura que foi planeada e implementada, irão agora ser descritos em detalhe as métricas monitorizadas bem como cada componente da arquitectura.

3.3

Métricas Monitorizadas

Esta secção descreve as métricas escolhidas para monitorização, a informação que as mesmas representam e o porquê da sua escolha.

O conjunto de métricas monitorizadas pela solução desenvolvida divide-se em dois grandes grupos: métricas de análise do estado de saúde do servidor e métricas específicas associadas às bases de dados. Apesar do âmbito deste trabalho ser indicadores de performance de bases de dados foi tomada a decisão de monitorizar também o estado de saúde do servidor como um todo, por forma a oferecer ao utilizador uma visão global da instância onde se encontram as bases de dados uma vez que o somatório das performances das bases de dados individuais reflecte-se directamente na performance global da instância. Por este motivo são recolhidas as seguintes métricas de análise do estado da instância:

• CPU Usage — esta métrica representa a utilização do processador na máquina, nomea- damente a utilização por parte do SQL Server e a utilização por parte de todos os outros processos que corram na máquina. Valores elevados de utilização de processador por parte do SQL Server podem indicar que estão a ser executadas operações que causam elevado impacto, execução de tarefas internas de sistema em conjunto com a carga normal do servi- dor ou compilação e re-compilação excessiva de planos de execução de pesquisas de acordo com [Mic16b] e [Dav]

• Wait Statistics — como descrito em [KS14] este conjunto de métricas representam uma parte fundamental da análise de performance de um servidor SQL porque servem como ponto de partida para a análise de performance. Permitem identificar possíveis estrangulamentos e bloqueios entre processos. São apresentados os tipos de espera com maior valor acumulado no período de tempo em análise, sendo aprentados os tipos de espera, o valor acumulado desse tipo de espera bem como o valor médio por identificação. É ainda apresentado o valor percentual da métrica em relação a todas as esperas registadas no intervalo de tempo definido.

• Active Sessions — esta métrica retorna o número de sessões activas na instância monitori- zada. Como descrito em [DF10] a informação relativa a sessões é obtida através da ligação entre duas vistas de sistema, nomeadamente sys.dm_exec_connections e sys.dm_exec_sessions. Em conjunto estas vistas fornecem informação sobre o que está a ocorrer na instância, a pri- meira vista fornece informação centrada na rede enquanto que a segunda tem o seu escopo ao nível do servidor. Um ponto a ter em conta é o facto de uma conexão ao servidor poder gerar várias sessões dentro do mesmo.

• Active Sessions Cpu — através da monitorização desta métrica obtemos dados relativos à utilização de tempo de processador por parte das sessões activas no servidor, sendo possível perceber a carga de trabalho que está a ser gerada pelas ligações externas ao servidor. Estes dados estão disponíveis, como descrito em [DF10] na vista de sistema sys.dm_exec_sessions. • Active Sessions Memory — esta métrica representa a memória utilizada por todos os pedidos

associados a uma sessão. Os valores estão disponíveis na vista de sistema sys.dm_exec_sessions e através de um somatório é possível perceber os consumos em termos de memória provo- cado pelas ligações externas ao servidor. Tal como descrito em [DF10] os valores presentes nesta vista são actualizados quando um pedido associado a uma sessão é terminado, po- dendo dessa forma não representar exactamente o valor actual mas fornecer uma imagem da actividade realizada no servidor com alguns segundos de atraso.

• Active Sessions Reads, Writes and Logical Reads — este conjunto de dados representa o impacto provocado pelas sessões em termos de leituras e escritas. Apresenta dados relati- vos a Logical Reads que representa o número de leituras realizadas sobre a cache, Reads e Writesque representam operações de leitura e escrita realizadas directamente sobre o disco. Os valores permitem perceber os valores de I/O presente no sistema, através destes valores podem ser tiradas considerações relativamente a possiveis problemas de performance. Um exemplo será, valores elevados de Logical I/O, que podem explicar uma quebra de perfor- mance na execução de operações, uma vez que o SQL Server pode ser forçado a libertar memória para efectuar as operações. Tendo em conta que os planos de execução são guar- dados em memória, uma eventual eliminação força o servidor a compilar novos planos de execução, o que provoca impacto nos tempos de execução. Os valores para estas métricas são obtidos através da vista de sistema sys.dm_exec_sessions.

lhor performance. Só faz sentido a análise a estas duas métricas se a mesma for realizada em conjunto, uma vez que é através do rácio entre os dois valores que alguma conclusão pode ser retirada. O valor do rácio entre estas duas métricas deve ser idealmente superior ou muito próximo de 1. Quando não o é pode indicar problemas de memória uma vez que o SQL Ser- vernão consegue obter a memória que necessita. Convém também verificar o valor da opção Maximum server memorypois se o mesmo for baixo pode ser a causa do problema. Os valo- res para estas métricas são retirados da vista de sistema sys.dm_os_performance_counters. • Cache Hit Ratio — esta métrica fornece informação relativa à performance em termos de

memória. O seu valor representa o rácio entre o número de páginas encontradas em memória em relação ao número total de pedidos como descrito em [Pet14b]. Se o valor for de 1 todas as páginas são encontradas em memória, quando o valor é inferior significa que alguns pedidos tiveram que obter os dados directamente do disco, o que em si é um processo muito mais demorado e custoso em termos de performance.

• Memory Grants Pending — esta métrica, tal como o nome indica, representa o número de processos que estão à espera que lhes seja concedida memória para realizarem o seu trabalho. Tal como descrito em [Pet14c] o valor desta métrica deverá ser constantemente zero, no entanto, se o mesmo não se verificar podem ser tomadas medidas adicionais para perceber o problema. A vista de sistema sys.dm_query_memory_grants, de acordo com [Mic16c], oferece informação relativamente às operações que requisitaram memória e estão de momento à espera ou que já receberam a memória desejada, permitindo assim navegar um nível extra na tentativa de perceber o problema.

• Lazy Writes/sec — esta métrica envolve o conceito de Database Checkpoints. De acordo com [Mic16a], é um ponto no tempo em que as páginas alteradas em memória bem como informação relativa ao transaction log, são escritas de memória para disco, criando um ponto de retorno em caso de problemas na instância. Lazy Writes/sec é definido segundo [Micg] como o número de vezes por segundo que o SQL Server realoca dirty pages de memória para disco. Isto significa que entre dois Database Checkpoints o Lazy Writer vai libertando páginas em memória para evitar a necessidade constante de Checkpoints. Este processo consiste em escrever para disco as páginas que sofreram alterações e marcá-las como livres em memória.

• Page Life Expectancy — de acordo com [Pet14b] esta métrica representa o período de tempo, em segundos, que uma página permanece no buffer de dados. O valor normal apre- sentado como referência, 300 segundos, é um valor afastado da realidade atual, já que em

termos de hardware hoje em dia os valores médios são bastante mais elevados. No entanto a Page Life Expectancyé um valor completamente dependente das caracteristicas do sistema em monitorização, por isso mesmo não é possível definir um valor global de comparação para este valor.

• Page Lookups/sec — esta métrica tal como definida em [Micg], representa o número de pedidos por segundo que encontram a informação pretendida em memória. A informação fornecida torna-se relevante em correlação com valores de outras métricas, nomeadamente se este valor for bastante inferior ao Page Reads/sec pode indicar que a informação que se encontra em memória não é a mais adequada em relação às pesquisas efectuadas sobre a instância, o que pode indicar um problema na rotação das páginas em memória, daí que analisar em conjunto com Lazy Writes/sec possa ajudar a perceber se a rotação das páginas está a ser realizada correctamente.

• Page Reads/sec — tal como definida em [Micg], os valores desta métrica representam o número de leituras efectuadas directamente sobre o disco por segundo, relativo a todas as bases de dados presentes no servidor. O valor desta métrica é indicativo da quantidade de actividade existente no servidor e tal, como para a métrica Page Lookups/sec, tem de ser analisada em conjunto com outros valores. Tendo em conta que Physical I/O tem um custo superior ao Logical I/O, esta é uma métrica que deve ser constantemente inferior aos valores apresentados pela métrica Page Lookups/sec.

• Page Writes/sec — esta métrica representa o número de páginas escritas em disco por se- gundo, de acordo com [Micg]. Este valor é proveniente da inserção de novos dados no sistema que são persistidos nas bases de dados e é importante acompanhar este valor uma vez que representa uma parte importante das operações de I/O que são efectuadas sobre o sistema.

• Transactions/sec — esta métrica representa o número de transações efectuadas por segundo no servidor. Como descrito em [Micl], uma transação é um conjunto de operações tratadas como uma única unidade de trabalho e são utilizadas para garantir a integridade dos dados enquanto são efectuadas alterações sobre eles. Esta métrica é um indicador do nível de actividade do servidor.

• Batch Requests/sec — como definido em [Mich], esta métrica representa o número de pe- didos recebidos por segundo. A importância da monitorização desta métrica prende-se com o facto de ser um indicador da actividade global do servidor, bem como um indicador da velocidade a que o SQL Server está a processar os pedidos de utilizadores. Esta métrica é o principal indicador do nível de actividade de um servidor, sendo afectada por várias variá- veis, como I/O e número de utilizadores entre outras, o que indica que é um excelente ponto de partida para identificação de possíveis problemas de performance num servidor, uma vez que uma flutuação deste valor implica uma alteração em uma das variáveis que o afectam.

e guardado em memória um plano de execução. Um aumento nos valores registados desta métrica pode indicar problemas de memória, uma vez que os planos estão a ser removidos para dar lugar a outros dados.

• SQL Re-compilations — esta métrica representa o número de re-compilações por segundo e tem por base o mesmo conceito da métrica SQL Compilations, os valores associados a esta métrica devem ser baixos, uma vez que são indicativos da re-compilação de planos já existentes e que por algum motivo deixam de poder ser utilizados pelo query optimizer. Esta métrica é recolhida da vista de sistema sys.dm_os_performance_counters.

• Deadlocks — tal como é definido em [Mica] um deadlock acontece quando duas tarefas dis- tintas se bloqueiam mutuamente. O que acontece é que uma tarefa adquire um bloqueio num recurso enquanto que a segunda tarefa adquire um bloqueio num outro recurso, entretanto a primeira tarefa tenta obter um bloqueio no recurso que esta bloqueado pela segunda tarefa,