Arquivo

Archive for the ‘Geral’ Category

Blocos de Dados: tamanho é documento?

A tecnologia da informação está cada vez mais ligada ao nosso cotidiano, seja em casa, no carro, ou no trabalho nós convivemos o tempo inteiro com dispositivos tecnológicos. Quanto maior é a nossa dependência de tecnologia, mais informação é gerada e mais espaço é utilizado para guardar as informações relevantes (ou não). No meio corporativo onde a demanda por espaço é bem maior e geralmente são informações que tem que estar disponíveis sempre que necessário, da maneira mais performática possível.

Com o crescimento acelerado de banco de dados e a adoção cada vez maior de sistemas virtualizados, os blobs (arquivos binários) gerados hoje em dia estão cada vez mais volumosos. Se antes uma imagem iso de pouco mais de 700MB era uma coisa enorme, hoje em dia em algumas empresas encontramos blobs de 1TB ou mais, geralmente blobs que ocupam uma LUN ou um Pool de LUNs inteiro apenas para sí, muitas vezes resultando em um desempenho sofrível principalmente no caso de bancos de dados quando precisam fazer algum tipo de “data scan” ou de arquivos que são tratados de forma sequencial e precisam serem lidos do inicio até o fim. O mesmo senário se repete para o contrário: arquivos pequenos demais que resultam em uma grande quantidade de informação, talvez esse senário seja pior, pois por gerar um maior número de IOPS, fazem uso do hardware muitas vezes de forma extrema, porém nada otimizada. Se você está sofrendo com algo parecido com isso, esse artigo é pra você!

De forma alguma venho através deste artigo dizer que X é certo e Y é errado, mesmo porque cada ambiente  tem suas regras de negócios, particularidades, limitações e etc. Venho aqui discutir sobre como otimizar esses dados a partir de ajustes em níveis mais baixos, como por exemplo a “blocagem” do seu sistema de arquivos e/ou o stripesize de seu RAID.

Blocos de Dados

Os blocos, também chamados de INODE (no caso de sistemas baseados em UNIX) ou CLUSTER (no caso de sistemas baseados em Windows) são a maneira que o sistema de arquivos armazena e gerenciam os blobs gravados no disco (que pode ser realmente um disco ou qualquer outro dispositivo de bloco como LUN, RAID, etc).  Por exemplo, se seu sistema de arquivos usa blocos com o tamanho de 14KB, os arquivos serão quebrados em unidades de 14KB de tamanho, o que quer dizer, que para cada leitura, de um arquivo, o disco terá que ler X blocos de 14KB por Y vezes.  Nesse senário hipotético um arquivo de 1MB (1024KB) seria dividido em aproximadamente 74 partes de 14KB, o que significa que a cabeça de leitura do disco seria reposicionada 74 vezes durante a leitura deste único arquivo. Esse senário “hipotético” é tão comum quanto você não imagina, pois na maioria das vezes, os administradores de sistema não se preocupam muito com a blocagem a ser utilizada no sistema de arquivos como fator de desempenho final.

Também podem existir casos extremos em que se usam uma blocagem grande para escrever arquivos pequenos, o que incide no espaço final que ficará disponível, pois os blocos tem tamanhos fixos e uma vez alocados para uma determinado arquivo, não serão utilizados para gravar outro arquivo, mesmo que exista espaço de sobra. Por exemplo: o sistema de arquivos foi formatado para blocos de 1MB, se você cria varios arquivos de 500KB, essa formatação é ineficiente, pois para cada arquivo de 500KB, estão sendo gerados blocos de 1MB, o que significa que metade do espaço disponível está sendo desperdiçado.

Não existe uma matemática exata da relação tamanho de arquivos X blocos, o que vale é o bom senso durante a escolha do tamanho dos blocos a depender do tipo e tamanho de arquivos que serão armazenados nesse disco.

Cíclos de CPU

A operação de leitura de cada bloco consiste em várias etapas que vão desde a localização deste bloco no disco pois os dados geralmente não são sequenciais e são passíveis de fragmentação, reposicionamento de cabeça de agulha e etc.

Quando se lê um arquivo de 1MB em um sistema de arquivos utilizando blocos de 14KB, você estará utilizando aproximadamente 75 ciclos de CPU e o mesmo número de I/O para realizar tal leitura. Cada ciclo de CPU é independente e faz com que aquele “core” fique ocupado e indisponível para outras chamadas até que o ciclo se complete ou seja interrompido (no caso de ciclos preemptivos).  É importante também observar a quantidade de IOPS (I/O Per Second) suportados pelo dispositivo de blocos, pois se chegar no máximo em apenas uma leitura, o desempenho do equipamento estará comprometido para outras operações, principalmente se for um storage que geralmente é compartilhado com outras aplicações e máquinas.

Ao utilizar blocos maiores, você estará diminuindo a quantidade necessária de ciclos de CPU e IOPS e aumentando o uso de banda disponível.  Num senário bastante realista os storages funcionam com fibras a velocidades de 8Gbit, o que resulta em uma largura de banda bastante generosa para acesso a dados, e ao se utilizar blocos maiores, você conseguirá aumentar seu desempenho utilizando esta banda disponível sem precisar sacrificar o processamento de seu hardware.

Vale salientar que…

Para um sistema operacional, é mais fácil gerenciar grandes arquivos do que pequenos arquivos. Já experimentou comparar a cópia de uma arquivo de 1GB e vários arquivos pequenos que resultam em 1GB? A cópia do único arquivo é muito mais rápida, pois o S.O. já tem indexado a localização dos blocos desse arquivo de maneira a antecipar a leitura no disco por exemplo, porém tal operação irá incidir em um maior consumo de banda no disco e memória RAM, enquanto que quando precisamos copiar varios arquivos, o S.O. precisa recorrer ao seu índice saber a localização dos blocos de cada arquivo que irá copiar, reposicionar as agulhas do disco, e então começar a operação de cópia. O mesmo vale para leitura.

Porém, no caso de uma varredura de dados, comum em SGDBs, a quebra dos arquivos grandes em arquivos médios, poderá facilitar tal operação. Pois apesar de otimizar o uso da banda quando precisar realizar um full table scan por exemplo, o mesmo terá de fazer em um blob grande, e em uma única operação, enquanto que utilizando vários arquivos, mesmo num full table scan, o SGDB se beneficiará do paralelismo entre os cores, podendo varrer vários arquivos correspondentes ao dados procurados de uma só vez.

Conclusão

Esse tipo de tuning deve levar em conta o ambiente, o tipo de dados e a proposta de performance que vai se querer extrair do mesmo. No caso de um file server talvez não compense utilizar blocos grandes, pois o número de arquivos menores poderá não compensar e acabar aumentando o gasto de espaço de forma desnecessária, mas no caso de grandes bancos de dados e de discos de máquinas virtuais, por exemplo, deverá sim ser levado em conta o tamanho dos blocos do sistema de arquivos. Atualmente os sistemas já projetados para virtualização vem preparados por padrão para grandes arquivos, como é o caso do VMFS, sistema de arquivos utilizados pelo VMware, que vem com uma blocagem padrão superior ao que é utilizado normalmente em sistemas operacionais comuns. Em resumo: quanto menor o bloco, maior economia de espaço, porém maior será o uso de ciclos de CPU e menor será a otimização no acesso aos dados, quanto maior o bloco, maior será o uso do espaço em disco, inclusive a chance de desperdício de espaço é maior também, porém no caso de acesso aos dados,  é necessário um número menor de ciclos de CPU resultando em maior performance e aproveitamento de banda e memória RAM disponíveis.

E você, o que acha? Me envia um email para ramongadelha@gmail.com e/ou deixa teu comentário logo abaixo deste artigo!

Anúncios

Zimbra: importando e exportando contatos via linha de comando.

Para quem não conhece, o Zimbra é uma das suítes de colaboração mais utilizadas do mundo e concorre diretamente com grandes players como Microsoft Exchange, por exemplo.

O Zimbra fornece uma cli (command line interface) bem completa, tudo o que você faz via interface web, você poderá fazer por sua CLI, na verdade, para administradores avançados, a CLI lhe da mais liberade e recursos do que a sua interface de gerência na web.

Uma das dores de cabeças muito comuns quando se vai migrar servidores de e-mail, são as listas de contatos de cada usuário, no caso do Zimbra, ele permite que cada usuário, crie sua lista de contatos. Recentemente encontrei-me em um cenário bem interessante: migração entre versões diferentes do Zimbra para máquinas diferentes. Os e-mails, eu migrei sem problemas via imapsync, mas, e os contatos? Pesquisando, descobri uma maneira bem simples.

Exportando os contatos:

Para exportar os contatos de uma conta, você deverá executar:

# zmmailbox -z -m conta@dominio.tld gru /Contacts > arquivo.csv

No meu caso, como eram muitas contas, eu fiz um pequeno loop a partir de uma lista de contas que eu obtive através do utilitário zmprov:

# zmprov -l gaa | while read conta; do zmmailbox -z -m $conta gru /Contacts > /tmp/contatos/$conta.csv; done

Esse comando irá exportar todos os contatos de todas as contas para o diretório /tmp/contatos com o arquivo seguindo o padrão conta@dominio.csv. Simples, não!?

Ok, tenho todos os contatos, o que devo fazer? Simples, copie todos esses csv para a máquina de destino, e siga as instruções a seguir.

Importando os contatos:

Esse passo é mais moleza do que empurrar bêbado em ladeira. Na máquina onde os contatos serão importados, faça um loop com a lista de contas já cadastradas via zmprov, e execute o comando de importação, apontando para o csv. Simples:

# zmprov -l gaa | while read conta ; do zmmailbox -z -m $conta pru /Contacts /caminho/para/$conta.csv ; done

Aguarde alguns minutos, e pronto! 🙂

Synergy: Controlando um desktop e um netbook utilizando o mesmo teclado e mouse.

março 13, 2011 2 comentários

Um belo dia, eu tive de usar um Desktop e um Netbook ao mesmo tempo para fazer um trabalho e o fato de ter de ficar mudando do teclado e mouse do desktop pra o minusculo teclado e touchpad do netbook estava me deixando bem estressado, além de me tornar menos produtivo.

Procurei uma solução que fosse rápida e simples e acabei topando com o Synergy, o mesmo está disponível para Ubuntu 10.10, distribuição que uso tanto no Desktop quanto no Netbook. O conceito é simples, você está com o mouse na tela do desktop, então o mouse e teclado ficam dedicados a ele, então você vai até a extremidade do monitor, e o mouse some do seu desktop e aparece no netbook, tornando então o teclado e mouse dedicado ao netbook e vice-versa.

O Synergy trabalha na arquitetura cliente-servidor, não há “requerimentos” sobre qual deverá ser o servidor, você decide, vamos aos pre-requisitos:

  • Os dois computadores deve ter o Synergy instalado e um arquivo de configuração devidamente criado onde será o servidor (usei /etc/synergy,conf);
  • As duas máquinas deverão se enchercar por nomes e não por IPs, cada “screen” tem o nome de uma máquina.

Para começarmos, deveremos instalar o Synergy nas duas máquinas, isso é possível através do comando:

# apt-get install synergy

Configurando o Servidor

Crie um arquivo de configuração, no caso usei /etc/synergy.conf para manter os padrões.

section: screens
desktop:
netbook:
end

section: links
desktop:
right = netbook
netbook:
left = desktop
end

Onde você ver desktop, substitua pelo nome da sua maquina na rede, onde tem netbook, faça o mesmo. Ambas as máquinas devem ser visiveis entre sí através dos nomes, caso não tenha um servidor DNS, defina os nomes no /etc/hosts de ambas as máquinas.

Após feito, é hora de iniciarmos a instância do servidor, para tal:

# synergys -f –config /etc/synergy.conf

Este comando deverá iniciar o daemon, e torná-lo disponível para o client.

Conectando-se no servidor e iniciando o compartilhamento

No lado do client, assumindo que o desktop é o servidor, digite:

# synergyc -f  desktop

O client deverá conectar-se ao servidor, feito isso, já temos mouse e teclado compartilhados. Além do mais, o synergy possui o “plus” de compartilhar também as áreas de transferências das duas máquinas, ou seja, você pode copiar em uma máquina e colar n’outra!

Categorias:Geral, Tecnologia