VIR

TUA

LIZA

ÇÃ

O34 – RTI – SET 2012

O artigo avalia asobrecarga relativa dosistema operacionalquando são usadasmáquinas virtuais emaplicações comintensas operações deentrada/saída. Osresultados indicamque o OS pode custaraté 60% mais emtermos de energiaconsumida e que umaúnica instância demáquina virtual custa150% em desempenhoe 180% em consumode energia poroperação.

Consumo de energiade sistemasoperacionais

Shoaib Akram, Manolis Marazakis e Angelos Bilas,da Foundation for Research and Technology - Hellas (FORTH) e

Institute of Computer Science (ICS), Grécia

A quantidade de dados geradosna sociedade moderna está

crescendo rapidamente. Váriasprojeções estimam que, por volta de2020, o mundo produzirá 35zetabytes de dados [10]. Paragerenciar e processar esse imensovolume de informações, surgiu oconceito de aplicações centradasem dados [12]. Os data centers jáconsomem uma significativaquantidade de energia e com a taxade crescimento anual de cerca de14%, o seu consumo total deenergia, nos EUA, será de 300 bilhõesde kWh. Por essa razão, há umacrescente pressão para melhorar aeficiência das modernas aplicaçõescentradas em dados.

Muitas aplicações centradas emdados usam de forma intensiva osistema operacional (OS) paraacesso à rede e armazenamento.Para muitas aplicações, acontribuição do OS para o tempode execução total é comparável oumaior que o tempo útil do usuário,ou seja, o tempo que uma aplicaçãogasta na execução do código noespaço do usuário. Particularmentecom relação às aplicações centradasem dados, todo o trabalho realizadopelo OS visa o fornecimento detradução do nome, recuperação egerenciamento de buffer e dedispositivo. Não está relacionadoaos dados reais, em si, mas ao

processo de mudar os dados de umarmazenamento permanente para osbuffers da aplicação.

Além disso, hoje as VMs - máquinasvirtuais são normalmente usadaspara permitir que múltiplasaplicações rodem no mesmoservidor. A melhoria do uso doservidor requer a execução demúltiplas aplicações e, para fins deisolamento, elas em geral rodamdentro de VMs separadas. Issointroduz sobrecargas adicionais parao desempenho de E/S.

Neste artigo, estamos interessadosem compreender a relativa sobrecargado OS e das VMs sobre oprocessamento de aplicações comintensidade de E/S. Usamosaplicações e conjuntos de dadostípicos de cargas de trabalhoimplantadas nos atuais data centers.Rodamos as cargas de trabalho usandoum OS commodity e medimos suasobrecarga sozinho. Usamos ummodelo simples para traduzir adivisão do tempo de execução emciclos e a energia gasta por E/S(cpio e eio). Em seguida, rodamosas cargas de trabalho usando umVMM - monitor de máquina virtualpopular e medimos a sobrecargaadicional. Também relatamos aredução do custo de energia por E/Squando se usam múltiplas VMspara rodar instâncias independentesda mesma carga de trabalho.

35 – RTI – SET 2012

Rodamos cada carga de trabalhousando parâmetros de configuraçãoe conjuntos de dados que resultamnuma grande quantidade de E/S.Primeiro rodamos cada carga detrabalho sobre a distribuição doOS commodity, com o mais recentekernel Linux, e medimos a divisãodo tempo de execução. Relatamosa sobrecarga do componente dosistema sozinho, em comparaçãocom o tempo de execução totalgasto para fins de processamento.Mostramos que, embora baixa emcomparação com o componente dousuário, a sobrecarga docomponente do sistema cresce como número de núcleos. Finalmente,examinamos como as sobrecargasaumentam observando cpio e eioem um número crescente denúcleos.

Em comparação com a energiaconsumida pelo componente dousuário de uma única instância decarga de trabalho, observamos que:• Os servidores que usamsubsistemas dearmazenamentobaseados em disco,além dos lentos temposde resposta, também sãoenergeticamenteineficientes em E/S deprocessamento. Emparticular, com as atuaispilhas do sistema, osservidores que usamsubsistemas dearmazenamentobaseados em discogastam até seis vezes

mais energia por operação de E/S. Adiferença é reduzida de seis vezespara apenas 58%, se o consumo deenergia ociosa nos servidores forigual a zero.• Em média, o tempo de execuçãodo componente do sistema custa60%, em termos de consumo deenergia, por operação de E/S.• A virtualização custa até 150% emtermos de ciclos gastos poroperação de E/S, para um conjuntode aplicações centradas em dados.Da mesma forma, com o acréscimodos custos da camada VM há, emmédia, uma sobrecarga de 180%,em termos da energia consumidapor operação de E/S.• A camada OS, como é atualmente,não funciona bem com o aumentodo número de núcleos. Em média,para oito cargas de trabalhocentradas em dados, há umaumento de 12, 24 e 92 vezes nosciclos do sistema por operação deE/S, em comparação com os ciclosdo sistema com um núcleo.

Metodologia

Nosso principalobjetivo, neste artigo, équantificar sobrecargasintroduzidas pelascamadas de sistema. Emparticular, estamosinteressados na camadaOS e na camada VM. Asmétricas do nível deaplicações, portanto, nãosão úteis para a análisedos componentesindividuais das

complexas pilhas de software de hojeem dia. Assim, propomos o uso deciclos por operação de E/S (cpio)como métrica para quantificar assobrecargas no nível de sistemas.Calculamos o cpio rodando aaplicação e medindo a divisão dotempo de execução consistindo deusuário, sistema, tempo ocioso etempo de espera de E/S (iowait). Aseguir, discutimos brevemente o quecada componente do tempo deexecução significa.

O tempo do usuário refere-se aotempo que uma aplicação leva paraexecutar o código no espaço dousuário. Quando uma aplicaçãosolicita serviços pelo OS, o tempogasto é classificado como tempo dosistema. O tempo que uma aplicaçãoleva esperando que uma operação deE/S pendente seja completada échamado de tempo de espera de E/S(iowait). Finalmente, quando umprocessador não tem qualquertrabalho a realizar, o tempo é contadocomo tempo ocioso.

Fig. 1 - Porcentagem de tempo de execução (eixo Y) gasto como tempo de sistema,ocioso e iowait em SSDs e com discos

Fig. 2 - Consumo de energia por 1 milhão de E/S (emio) com discos e SSDs

36 – RTI – SET 2012VIRTUALIZAÇÃO

Também observamos o número deoperações de E/S de 512 bytes queuma aplicação realiza durante otempo de execução. Trata-se de umtamanho típico do setor em muitosdispositivos de armazenamento. Otamanho real da operação de E/S, doponto de vista do kernel, é diferentee, normalmente, da ordem dekilobytes. Supomos que a totalidadedo volume de dados de leitura/escritadurante o tempo de execução consistede muitos chunks de 512 bytes.

Em seguida, calculamos o cpiodividindo os ciclos do usuário maisos ciclos do sistema consumidos

durante o tempo de execução pelonúmero de operações de E/S. Nãorodamos as cargas de trabalho até ofim, mas o bastante para capturar ocomportamento representativo. Emparticular, fizemos medições duranteas quais a aplicação gera o throughputtípico se houver permissão de rodarpor períodos mais longos.

Um importante benefício do cpiocomo métrica do nível de sistema é afacilidade de traduzir para energia poroperação de E/S. Usamos ummétodo simples para calcular aenergia gasta por operação de E/S.Nosso modelo deriva-se de resultados

relatados na literaturarecente [9, 20, 18]. Emparticular, medimos autilização da CPU e, emseguida, o pico deenergia e a potênciaociosa típicos de nossasmáquinas de servidor,para calcular a energiapor operação de E/S.Não incluímos a energiaconsumida por dispositivosde armazenamento.Relatamos os resultadossupondo não haver energiaociosa, o que é típico dosservidores implantados

nos dispositivos de armazenamentodos data centers atuais [20].

Usamos a seguinte equação paracalcular a energia por E/S (eio) emjoules:

eio = {P * (1 * cpio + 1P * cpioi)}/(N * F)

onde:• P: potência de pico do servidor (menoso subsistema de armazenamento);• cpio: ciclos por E/S;• IP: fração da potência de pico quandoa máquina está em estado ocioso;• N: número de núcleos; e• F: frequência de cada núcleo.

Fig. 3 - Sobrecarga da camada de sistema com discos e SSDs

38 – RTI – SET 2012VIRTUALIZAÇÃO

Mostramos os resultados doconsumo de energia necessário e odesempenho (e processamento) de1 milhão de operações de E/S (emio).

Uma pilha de software podeparecer ter eficiência de cpio ou deeio, ao fazer inúmeras e pequenasoperações de E/S. Por exemplo,aplicações que realizam um grandenúmero de operações de metadadosao longo da execução podem parecerter um baixo cpio, embora asoperações E/S de metadados sejam,normalmente, ‘induzidas’ e nãoestritamente necessárias para o

processamento de um conjunto dedados específico. Assim, aoobservarmos o cpio e o eio, o seumero valor absoluto não é adequadopara julgar a qualidade de uma pilhaou plataforma.

Em nosso trabalho, primeirocomparamos o emio de doisservidores com diferentes subsistemasde armazenamento. Em seguida,calculamos o emio sem a camadaOS. Depois, rodamos as cargas detrabalho dentro de uma VM emostramos o aumento de emio. Emseguida, usamos a consolidação doservidor com duas VMs. Finalmente,usamos o componente de cpio dosistema para avaliar a escalabilidadedas atuais pilhas OS. Medimos osciclos do sistema por E/S para 1, 4, 8

e 16 núcleos e fazemos uma projeçãousando um modelo linear de 1000núcleos.

Aplicações

Discutimos os parâmetros deconfiguração, o modo de operação eos conjuntos de dados usados nasaplicações. A tabela I apresenta umresumo das cargas de trabalho usadaspelas aplicações. Em alguns casos,usamos múltiplas instâncias damesma aplicação para formar umacarga de trabalho que utilize melhor

os recursos do servidor e dearmazenamento. A seguir, discutiremosbrevemente cada aplicação.

O checkpointing é feito emaplicações de computação de altodesempenho (HPC - highperformance computing) para arecuperação de possíveis falhas.Usamos IOR [16], que simula váriospadrões de checkpointing queaparecem no domínio HPC. Devidoà camada MPI, o IOR tem um tempode usuário moderado e os E/S in-flightemitidos por vários processos MPIsimultâneos induzem um tempo deiowait significativo, devido àcontenção de recursos E/S.

A indexação de arquivos é feita,principalmente, como trabalho deback-end em data centers e instalações

de hospedagem da web. UsamosPsearchy [15, 5] como aplicação deindexação de arquivo. Rodamos oPsearchy usando múltiplos processos,em que o processo aach escolhearquivos de uma fila compartilhadade nomes de arquivos. Uma tabelahash é mantida por cada processopara armazenar índices BDB namemória. As tabelas hash sãoliberadas para os dispositivos dearmazenamento uma vez alcançado otamanho certo. Modificamos oPsearchy original para usar leiturasem bloco em vez de leituras por

caracteres para melhorar o throughputde E/S.

Há um aumento do tempo desistema do Psearchy na indexação degrandes arquivos. Ao contrário, naindexação de pequenos arquivos háum aumento do tempo do usuário.Uma complexa estrutura de diretórioresulta num aumento do tempo dosistema.

A deduplicação é uma técnica decompressão usada em farms dearmazenamento e data centers.Usamos o kernel Dedup do conjuntode referência PARSEC [4]. O núcleoDedup kernel tem cinco estágios,sendo o primeiro e o último paraexecução de E/S. Os três estágiosintermediários usam, cada um, umaassociação de threads. Observamos

Tab. I - Cargas de trabalho para avaliação

AplicaçãoAplicaçãoAplicaçãoAplicaçãoAplicação DescriçãoDescriçãoDescriçãoDescriçãoDescrição ParâmetrosParâmetrosParâmetrosParâmetrosParâmetros TTTTTamanho do conjunto de dados (Gb)amanho do conjunto de dados (Gb)amanho do conjunto de dados (Gb)amanho do conjunto de dados (Gb)amanho do conjunto de dados (Gb)IOR Checkpointing de aplicação Processos = 128; Tamanho de arquivo = 2 Gb; 128

Modo E/S = MPLIO; Offsetting dentro do arquivo = sequencialPsearchy Indexação de arquivo Hierarquia de diretório = horizontal; Tamanho de documento = 10 Mb 100

Processos = 32; Tamanho de tabela hash = 128 MbDedup Compressão de arquivo Dedup: Tamanho de arquivo = 1 Gb; Instâncias = 10; threads por estágio = 32 10Metis Biblioteca Mapreduce para máquina de Aplicação: contagem de palavras; Instâncias = 5; Tamanho de arquivo = 1 Gb; 20

núcleo único e múltiplos núcleos threads de mapa = 8; threads de redução = 8BDB Key-value Store (baseado em Java) Threads = 128; Campos por registro = 10; 30

Tamanho de campo = 1 kbH B a s e Armazenamento NoSQL Threads = 128; Campos por registro = 10; 30

Tamanho de campo = 1 kbTPC-E Carga de trabalho OLTP (corretor da bolsa) Clientes ativos = 200 000; dias de comércio = 7; Terminais = 128; 155

innodb-thread concorrentes = 8; innodb-arquivo-io-threads = 4BLAST Busca de similaridade de sequência Instâncias = 16; Threads por instância = 16; Tarefa=blastn; Questionário por instância = 16; 20

Bancos de dados de nucleotídeo pré-formatado de NCBI (refseq-genomic, env-nt, nt);Alinhamentos = 128; sequências meta = 5000

40 – RTI – SET 2012VIRTUALIZAÇÃO

que o pico de utilização da memóriado Dedup é muito alto para arquivosgrandes, pois as filas entre os estágiosficam muito grandes. Para eliminar asfilas rapidamente, é necessário umelevado número de threads nosestágios intermediários. A utilizaçãode memória não é um problemaquando se trata de pequenosarquivos, porque há menos estadosintermediários a serem mantidos. ODedup é inteiramente dominado pelotempo do usuário.

O Madrepuce é um modelo deprogramação cada vez mais usadopara o desenvolvimento de aplicaçõescentradas em dados. Usamos uma

biblioteca de programaçãoMadrepuce para nós únicos, chamadaMetis, que é parte do conjunto dereferência Mosbench [5]. A Metismapeia o arquivo de entrada namemória e atribui uma parte doarquivo para cada um dos threads demapa. Usamos o Metis para contarpalavras em um arquivo. Uma únicainstância do Metis não gera muita E/Se é em grande parte dominada pelotempo do usuário. Rodamosmúltiplas instâncias de Metis eatribuímos um arquivo diferente paracada instância.

Os armazenamentos de dadosNoSQL estão ficando populares para

servir dados de uma forma escalável.O HBase é um sistema de serviço dedados que faz parte da estruturaHadoop. Usamos a estrutura YCSB [6]do Yahoo para testar o HBase.Primeiro, construímos um banco dedados usando o gerador de cargaYCSB (usando uma carga de trabalhoque executa apenas operações deinserção). Em seguida, rodamos umacarga de trabalho que executa 70%das operações de leitura e 30% deoperações de atualização. Reservamos3 Gb de memória física para amáquina virtual Java (JVM). OHBase tem um tempo ocioso alto,embora haja uma igual quantidade de

tempo de usuário e desistema.

O armazenamento dedados key-value (paracada valor há uma chavecorrespondente)continua sendo umaescolha popular paraservir dados em datacenters. O BDB é umabiblioteca que suporta aconstrução de dispositivosde armazenamento dedados com base empares key-value(chave-valor).Fig. 4 - cpio (esquerda) e emio (direita) com e sem virtualização em SSDs

42 – RTIVIRTUALIZAÇÃO

A metodologia de avaliação deBDB é similar àquela que usamospara HBase. Uma vez que o BDB éum dispositivo de armazenamento dedados embutido, os clientes YCSB eo código BDB compartilham o mesmoespaço de endereço de processamento.Portanto, reservamos 6 Gb de memóriafísica para a JVM. Configuramos oYCSB para usar 3 Gb para os clientesYCSB e 3 Gb para BDB. O BDB édominado por tempo de usuário, mashá um considerável tempo de sistema.

O processamento de transaçõeson-line (OLTP - online transactionprocessing) é uma importante classe decargas de trabalho para data centers.Usamos TPC-E para avaliar umacarga de trabalho OLTP. O TPC-Emodela as transações que acontecemnuma corretora de ações. Rodamos oTPC-E usando o sistema de bancode dados MySQL e especificamos osparâmetros de tempo de execuçãoque resultam em alta concorrência.Observamos que usar o servidor debanco de dados MySQL resulta emalto tempo ocioso para TPC-C eTPC-E, seja devido à nãoescalabilidade para múltiplos núcleosou ociosidade devido à sincronizaçãoentre um grande número de threads.

A genômica comparativa mobilizauma enorme quantidade de dadosgenômicos graças aos avanços datecnologia de sequenciamento.Usamos BLAST [2] para busca desimilaridade de sequêncianucleotídeo-nucleotídeo. Rodamosmúltiplas instâncias de BLAST, cadaqual executando um conjuntodiferente de consultas em bancos dedados separados. Usamos sequênciasde consultas aleatórias de 5 kB, que éum caso comum em pesquisas dehomologias proteoma/genoma. OBLAST é intensivo quanto a E/S e otempo de execução é dominado pelotempo do usuário.

Plataformas de avaliaçãoe o impacto dossubsistemas dearmazenamento

Caracterizamos o comportamentodas cargas de trabalho na tabela I

usando um servidor baseado emdisco e um baseado em SSD – solidstate drive. Nossa principal finalidadeem usar dois servidores diferentes éobservar como a divisão da execuçãode cargas de trabalho é efetuada pelohardware de armazenamento. Osprincipais recursos das duasmáquinas que usamos para aavaliação estão na tabela II.

Para testes com virtualização,usamos a infraestrutura devirtualização para kernel Linux(KVM). Notamos que a KVM requerque pelo menos um núcleo e atédois núcleos sejam reservados paraque a KVM destinada a cargas detrabalho rode de forma adequada.Realizamos testes de virtualizaçãousando apenas oito processadores(lógicos) e 8 Gb de DRAM. Portanto,deixamos oito processadores lógicospara KVM e 4 Gb de DRAM para okernel (núcleo) de hospedagem.Quando executamos duas VMs,alocamos quatro processadoreslógicos e 4 Gb de DRAM para cadainstância de VM. Da mesma forma,dividimos nosso subsistema dearmazenamento em SSDs para doisdispositivos RAID 0, cada qual com12 SSDs, e atribuímos um para cadadas duas instâncias de VM.

Primeiro, observamos que, emmédia, o tempo do sistema comdisco físico é de apenas 2% dotempo de execução total, emcomparação com os 26% em SSDS.

Entretanto, o resultado mais sutil éque os ciclos gastos por I/O (cpio) e,em particular, os ciclos do sistemapor E/S, são quase os mesmos nasduas máquinas. Portanto, a eficiênciada pilha do sistema, ou seja, ascamadas OS e outras abaixo daaplicação do usuário, ainda érelevante para ambas as máquinas.No entanto, para compreender assobrecargas introduzidas peloacréscimo da camada VM, relatamosos resultados usando SSDs. Etambém, realizamos os testes deescalabilidade e relatamos osresultados de SSDs. Em essência, astendências da escalabilidade sãomais fáceis de identificar e projetarquando a E/S não é o gargalo.

44 – RTI – SET 2012VIRTUALIZAÇÃO

A estimativa da potência dosservidores de faixa média, hoje, é decerca de 400 W, valor que usamospara nossos cálculos de energia.Como o cpio é bastanteindependente de um servidorparticular, a potência específica queusamos para calcular eio (e emio)não é importante para a comparaçãodas várias camadas do sistema.

A figura 1 mostra a divisão dotempo de execução em termos de

tempo do usuário, do sistema, ociosoe iowait. Como esperado, a máquinacom subsistema de armazenamentobaseado em disco tem um alto tempoiowait. Em média, o tempo iowaitcom disco é 42% do tempo deexecução total, comparado com os10% em SSDs. Entretanto, notamosque o tempo ocioso também é altona máquina baseada em disco. Emmédia, a porcentagem de tempo ociosoé de 30% com disco, comparados

com apenas 7% em SSDs. Isso éporque, normalmente, nas aplicaçõesde hoje, há threads cuja principal tarefaé executar E/S e distribuir trabalhoou fornecer dados a um grande númerode threads que executam a principalfuncionalidade da aplicação. Se osubsistema E/S é lento, os threads queexecutam E/S têm menos trabalho adistribuir a outros threads e, portanto,todo o sistema é ineficiente ou hámais tempo ocioso.

Fig. 5 - Aumento em ciclos do sistema por operação E/S a partir de 1 até muitos núcleos

45 – RTI – SET 2012

Essa observação é de particularinteresse para infraestruturascentradas em dados, uma vez que nosservidores de hoje os períodos detempo ocioso e iowait consomem até70% do pico de energia. Com isso, ossubsistemas baseados em disco nãoapenas terão um tempo de respostamais lento, mas também ineficienteno processamento de E/S, em termosde energia. A figura 2 mostra o emiode ambas as máquinas. Mostramos oemio de ambas as máquinas,supondo uma potência ociosa (IP -idle power) de 0% e 70% do pico depotência. Primeiro, notamos que, emmédia, com IP = 0, o emio comdisco é 58% maior do que o deSSDs. Entretanto, com IP = 0,7, oemio com disco é seis vezes o deSSDs. Concluímos que os servidoresde hoje em dia, em que a IP estámais próxima de 0,7, são ineficientesem termos de energia para operaraplicações com o uso de subsistemas

de armazenamento com baixothroughput. No entanto, uma vez quea potência ociosa seja reduzida paraaproximadamente 0% do pico, adiferença em termos de ineficiênciaenergética será bastante reduzida.

Com o uso de disco, os ciclos detempo ocioso e iowait têm um custosignificativo em termos de consumode energia. Em média, uma IP de 0,7comparada a 0 resulta em umaumento de 4x em emio com disco.Nesse trabalho, fizemos um esforçopara executar todas as cargas detrabalho com o máximo desimultaneidade, para maximizar autilização do servidor. Em certoscasos, em que a interferência e acontenção não significam umproblema, rodamos múltiplasinstâncias da mesma aplicação.Portanto, os ciclos ociosos das cargasde trabalho avaliadas nesse trabalhosão um comportamento da aplicação.À parte os ciclos ociosos excessivos

com disco, esse comportamento temimplicações também para a máquinade SSDs. Por exemplo, tanto oHBase quanto BDB não utilizamintegralmente os recursos do servidorem SSDs e com disco e, portanto, háuma notável diferença entre o emiocom IP de 0 e com IP de 0,7.

Quantificação desobrecarga de váriascamadas

Aqui comparamos o emio docomponente usuário sozinho, o deusuário e do componente sistemajuntos, o da mesma aplicaçãorodando dentro de uma VM e o deduas instâncias da mesma aplicaçãorodando em duas VMs separadas.Todos os resultados são mostradospara uma IP de 0,7.

Primeiro, a figura 3 compara o emiocom e sem sobrecarga de sistema paracargas de trabalho com tempo de

46 – RTIVIRTUALIZAÇÃO

sistema significativo (10% ou mais,em SSDs). Notamos que, com disco,não há qualquer diferença de emiocom ou sem sobrecarga de sistema.Isso é porque o tempo de execução édominado pelo tempo ocioso ou poriowait. Entretanto, em SSDs, aintrodução da camada de sistemaresulta em um aumento de 60% doemio (em média, cinco aplicações).A sobrecarga máxima é do Psearchy(250%). Note-se que o Psearchy éuma aplicação simples, mas acabapor consumir uma grande quantidadede energia, principalmente paraacessar os arquivos para a construçãode índices. Embora não seja realistasupor que as sobrecargas no nível desistema serão completamente

eliminadas, o trabalho mostra a faixaem que as pilhas modernas poderiamser melhoradas quanto à eficiênciaenergética.

A seguir, discutimos e comparamosos resultados com a virtualização. Afigura 4 mostra a sobrecarga que sedeve à virtualização, tanto em termosde cpio quanto de emio. Na figura,mostramos os resultados com umainstância de carga de trabalho semvirtualização, com a mesma carga detrabalho rodando dentro de uma VM ecom duas instâncias de carga detrabalho cada qual em uma VM separada.

Em termos de desempenho, vemosque, em média, o cpio aumenta em150%. Note-se que três cargas detrabalho que incluem Dedup, Metis eBDB têm baixa sobrecarga de até30%, devido à virtualização, emcomparação com outras cargas detrabalho. Note-se que a porcentagemdo tempo do sistema em relação aotempo de execução total, com as trêscargas de trabalho, é de 0,6%, 7,2% e

10%, respectivamente. Há umapossibilidade de que essas aplicaçõesoperem em grande parte a partir doscaches mantidos pela aplicação oupelo OS de hospedeiros. Nas demaiscargas de trabalho, a sobrecargadevida à virtualização é de até 300%.

Na maioria das cargas de trabalho,há alguma redução da sobrecarga davirtualização, quando se usam duasVMs para rodar duas instâncias damesma carga de trabalho. Emparticular, para IOR e BLAST, há umaredução de 16% e 25% em cpio,quando duas instâncias de VM sãorodadas, em comparação com aexecução de uma instância de VM.Entretanto, observamos que paraDedup e BDB, a sobrecarga devido à

execução de duas VMs é realmenteaumentada. Em particular, paraDedup, há um aumento de 200% dasobrecarga de VM com duas VMs,em comparação com os 28% desobrecarga com uma VM.

Finalmente, notamos umatendência semelhante em termos dassobrecargas de energia davirtualização. Em média, em todas ascargas de trabalho, a virtualizaçãoresulta num aumento de consumo deenergia de 180%. A sobrecarga éparticularmente adversa em duasimportantes cargas de trabalho dosdata centers de hoje, incluindoHBase e TPC-E. Nas duas cargas detrabalho, a sobrecarga é de 350% e400%, respectivamente.

Escalabilidade da camada OS

Idealmente, com o crescentenúmero de núcleos, a aplicação deveexecutar, proporcionalmente, mais E/S,assim resultando em cpio constante.

Tab. II - Resumo de parâmetros da máquina

DISKS SSDs2 Intel Xeon E5620 (núcleo quádruplo) 2 Intel Xeon E5405 (núcleo quádruplo)

Sem Hyper-threading 2 hardware thread por núcleo8 Gb RAM; 1 controlador de armazenamento 12 Gb RAM; 4 controladores de armazenamento

XFS sobre hardware RAID 0 (8 discos) XFS sobre software RAID 0 (24 SSDs)Throughput de armazenamento = 1 Gbit/s Throughput de armazenamento = 6 Gbit/s

Distribuição CentOS; 2.6.18 kernel Distribuição CentOS; 2.6.32 kernel

47 – RTI – SET 2012

Entretanto, observamos que isso nãoé verdade com as pilhas dos sistemasatuais. Nesse trabalho, estamosprincipalmente interessados nocomponente sistema de cpio.Mostramos o aumento dos ciclos dosistema por operação de E/S com onúmero de núcleos na figura 5.

Mostramos os valores medidoscom 1, 4, 8 e 16 núcleos. Em seguida,projetamos os resultados para até1000 núcleos, usando um modelolinear. Apresentamos o aumento deciclos do sistema normalizado paraos ciclos medidos com um núcleo.

Os ciclos de sistema aumentamem todas as aplicações mostradas nafigura 5. As mesmas aplicaçõesexecutadas com um processador demuitos núcleos, com 1024 núcleos,gastarão, em média 90 vezes maisciclos de sistema por operação E/S.Isso indica que a atual camada desistema é ineficiente e sãonecessárias melhorias para otimizaras aplicações que usam intensamentea camada de sistema. Notamos que,em particular nas cargas de trabalhoOLTP mais recentes, o aumento deciclos do sistema com o aumento donúmero de núcleos é dramático. OTPC-E depende bastante dosserviços OS, gastando até 36% deseu tempo de execução no OS com16 núcleos.

Os ciclos de sistema consumidospor uma aplicação traduzem-sediretamente em sobrecargas deenergia. Portanto, a nãoescalabilidade da camada OS temimplicações adversas para o consumode energia em data centers.

Trabalho correlato

O interesse em pesquisar questõesrelativas à ineficiência de pilhas desoftware em aplicações centradas emdados está crescendo. [17] discutetendências na construção de aplicaçõesde data centers a partir de componentesexistentes, que levam a grandesineficiências. Trabalhos recentes apontamque as ineficiências da pilha de softwaretêm impacto sobre a eficiênciaenergética de infraestruturas de datacenters [3, 14].

48 – RTI – SET 2012VIRTUALIZAÇÃO

A metodologia dominante, até omomento, do lado da redução deenergia, tem sido para construirmodelos de potência fazendo primeiromedições de um subconjunto doespaço de projeto. Usando essaabordagem, há uma forte evidência em[9] e [20] de uma relação direta entreo consumo de energia em grupos querodam típicas cargas de trabalhocentradas em dados e a utilização daCPU e o uso da memória física. Asmedições em [9] sugerem ainda que aCPU e a memória física são as quemais contribuem para a potência. Asatuais técnicas de modelagem sãobasante discutidas em [19, 18, 8].

O programa ENERGY Star daAgência de Proteção Ambiental dosEUA estima os requisitos deinfraestrutura e o consumo de energiade data centers em 2020, com base nocrescimento do mercado [1]. Elestambém sugerem otimizações queprovavelmente reduzirão os orçamentosenergéticos, reduzindo a potência deservidores usados em data centers.

Há trabalhos mais antigos sobre aanálise de desempenho das modernascamadas de sistema operacional. Maisrecentemente, [5] identificou muitosgargalos no kernel Linux quando muitosnúcleos são utilizados. Descreve-se uma

análise de escalabilidade similar paramuitos domínios importantes deaplicação em [7, 21]. Finalmente, hátrabalhos recentes sobre a redução desobrecargas devido à adição da camadade virtualização em cargas de trabalhocom grande intensidade de E/S. Osautores em [13] propõem o Split-X, queotimiza os cruzamentos de OS hóspede-hospedeiros, enquanto [11] propõe ELIpara a otimização e interrupção de viasob as máquinas virtuais.

Conclusões

Neste artigo, usamos um conjuntode aplicações com intensidade de usode E/S para quantificar a sobrecargado OS e das máquinas virtuais aoexecutarem E/S relativas aoprocessamento de aplicações. O OSpode resultar em um aumento de60% do consumo de energia. Oacréscimo de máquinas virtuaisresulta numa sobrecarga energéticaadicional, por operação E/S, de150%. Finalmente, observando umcrescente número de núcleos,verificamos que a sobrecarga por E/S,no OS, aumenta em 90 vezes, aofazermos a projeção para 1000núcleos, usando um modelo linearsimples.

[1] U. E. P. Agency. Report to congresson server and data center energyefficiency. www.energystar.gov.[2] S. Altschul, W. Gish, W. Miller, E.Myers e D. Lipman: Basic localalignment search tool. Journal ofMolecular Biology, 215:403–410, 1990.[3] E. Anderson e J. Tucek: Efficiencymatters! SIGOPS Oper. Syst. Rev.,44(1):40–45, 2010.[4] C. Bienia, S. Kumar, J. P. Singh eK. Li: The parsec benchmark suite:characterization and architecturalimplications. 17th International Conferenceon Parallel Architectures andCompilation Techniques, EUA. 2008.[5] S. Boyd-Wickizer, A. T.Clements, Y. Mao, A. Pesterev,

REFERÊNCIAS

Agradecimentos

Os autores agradecem àComunidade Europeia, sob o 7th

Framework Programs e IOLANES(FP7-ICT-248615), HiPEAC2(FP7-ICT-217068) e SCALUS(FP7-PEOPLE-ITN-2008-238808).O autor Angelos Bilas também daUniversidade de Creta, Grécia.

49 – RTI – SET 2012

M. F. Kaashoek, R. Morris e N. Zeldovich: An analysis of linux scalability to many cores. 9th USENIX Conference on OperatingSystems Design and Implementation, OSDI’10. EUA. 2010.[6] B. F. Cooper, A. Silberstein, E. Tam, R. Ramakrishnan e R. Sears. Benchmarking cloud serving systems with ycsb. 1st ACMsymposium on Cloud computing, SoCC ’10. EUA, 2010.[7] Y. Cui, Y. Chen e Y. Shi: Scaling oltp applications on commodity multi-core platforms. Performance Analysis of Systems Software(ISPASS), 2010 IEEE International Symposium.[8] D. Economou, S. Rivoire e C. Kozyrakis: Full-system power analysis and modeling for server environments. Workshop on ModelingBenchmarking and Simulation. MOBS, 2006.[9] X. Fan, W.-D. Weber e L. A. Barroso: Power provisioning for a warehouse-sized computer. ISCA ’07: 34th Annual InternationalSymposium on Computer Architecture. EUA, 2007.[10] J.F. Gantz, D. Reinsel, C. Chute, W. Schlichting, J. Mcarthur, S. Minton, I. Xheneti, A. Toncheva e A. Manfrediz: IDC - TheExpanding Digital Universe: A Forecast of Worldwide Information Growth Through 2010.[11] A. Gordon, N. Amit, N. Har’El, M. Ben-Yehuda, A. Landau, D. Tsafrir e A. Schuster. Eli: Bare-metal performance for i/ovirtualization. 2012.[12] R. Joshi. Data-Centric Architecture: A Model for the Era of Big Data.[13] A. Landau, M. Ben-Yehuda e A. Gordon: Splitx: split guest/hypervisor execution on multi-core. 3rd conference on I/Ovirtualization, WIOV’11. EUA, 2011.[14] J. Leverich e C. Kozyrakis: On the energy (in)efficiency of hadoop clusters. SIGOPS Oper. Syst. Rev., 44(1):61–65, 2010.[15] J. Li, B. T. Loo, J. M. Hellerstein e M. F. Kaashoek et al.: On the feasibility of peer-to-peer web indexing and search. IPTPS.03. 2003.[16] llnl.gov: ASC Sequoia Benchmark Codes. https://asc.llnl.gov.[17] N. Mitchell: The big pileup. In Performance Analysis of Systems Software (ISPASS), 2010 IEEE International Symposium on.[18] S. Rivoire, P. Ranganathan e C. Kozyrakis: A comparison of high-level full-system power models. HotPower’08: Conference onPower aware computing and systems, EUA, 2008.[19] S. Rivoire, P. Ranganathan e C. Kozyrakis: A comparison of high-level full-system power models. HotPower’08: Power awarecomputing and systems. EUA, 2008.[20] A. Vasan, A. Sivasubramaniam, V. Shimpi, T. Sivabalan e R. Subbiah: Worth their watts? - an empirical study of datacenter servers. 2010.[21] B. Veal e A. Foong: Performance scalability of a multi-core web server. 3rd ACM/IEEE Symposium on Architecture fornetworkingand communications systems, ANCS ’07, EUA, 2007.

REFERÊNCIAS