Neste artigo, saiba como:
- Medir o desempenho do Samba
- Otimizar o uso de memória do Samba
- Melhorar as velocidades de transferência de arquivos em um ambiente de Bloco de Mensagens do Servidor/Sistema de Arquivos da Internet Comum
Este artigo ajuda a preparar para o Objetivo 315.3 no Tópico 315 do exame Mixed Environment Specialty (302) do Linux Professional Institute (LPI). O objetivo tem peso 1.
Para aproveitar ao máximo os artigos desta série, é necessário ter um conhecimento avançado de Linux e um sistema Linux funcional, no qual seja possível praticar os comandos mencionados neste artigo. Você também deve ter um bom entendimento de rede TCP/IP.
Antes de poder melhorar algo, você deve ser capaz de medi-lo de forma confiável. Meça algo, faça mudanças, meça novamente e compare os resultados. No caso do Samba, é necessário medir:
- Tempo de resposta e rendimento e um cliente sob condições do servidor inativo
- Tempo de resposta e rendimento de um cliente sob um determinado carregamento do servidor
- Características do servidor sob um determinado carregamento
- Capacidade máxima do servidor em termos de clientes ou rendimento
Medir tempos de resposta fornece uma ideia do que um cliente típico esperaria sob as condições de teste. Para que isso funcione, seus casos de teste devem se aproximar do carregamento real do cliente. Por exemplo, ver com qual velocidade é possível solicitar repetidamente o mesmo arquivo não é o mesmo que copiar um diretório que contém uma combinação de arquivos pequenos e grandes.
Medir as características do servidor sob um determinado carregamento fornece alguma ideia de quanto espaço você tem para crescer. Se, sob carregamento, seu servidor estiver com dificuldade para manter o ritmo, então, você sabe que não há muita capacidade além do carregamento de teste. As mesmas técnicas são usadas para medir o carregamento de um servidor de produção e extrapolar a capacidade.
Por fim, os chamados "testes de tortura", em que você coloca tudo que pode em um servidor e vê quando ele trava, fornecem informações interessantes, mas não são tão úteis quanto os outros tipos de testes. Se o objetivo for provar que seu servidor pode manipular um determinado carregamento, então, esse tipo de teste será útil. Esses testes são frequentemente mais úteis para medir as características de nível inferior, como a capacidade máxima de E/S do disco de um servidor.
Samba é um servidor de rede, portanto, é importante simular de forma razoável a rede que está sendo usada. Se seus clientes estiverem 50 milissegundos de distância do servidor, os efeitos da latência da rede serão mais pronunciados do que com clientes locais. Essas informações direcionam suas prioridades de ajuste conforme necessário.
Você poderia comprar um dispositivo um tanto quanto caro que simule o tráfego do cliente e obtém medidas de desempenho precisas. E se você estiver publicando referências ou desenvolvendo o hardware de servidor, um dispositivo desse tipo pode ser uma boa opção. No entanto, se estiver interessado em ajustar seu próprio servidor e enfrentar as restrições usuais de tempo e dinheiro, provavelmente não está procurando uma ferramenta cara que precisará aprender como usar.
Como um exemplo, o primeiro teste avalia desempenho de leitura aleatório fazendo download de um grande número de arquivos com o cliente de linha de comando do Samba. A principal preocupação é: "com qual velocidade esse diretório pode ser transferido por download?"
Como qualquer utilitário UNIX® bem comportado, a ferramenta smbclient pode ler sua lista de instruções a partir da entrada padrão.
O fragmento a seguir mostra uma série de comandos para fazer download do conteúdo de um diretório:
prompt recurse mget smbtest |
O comando prompt impede que o cliente peça confirmação de downloads e
recurse indica que você deseja descer nos diretórios quando fizer download de diversos arquivos.
Por fim, mget smbtest instrui o cliente a iniciar o download do diretório smbtest. Preencha esse diretório com algumas centenas de megabytes de arquivos de teste e terá tudo que precisa para testar o desempenho.
Para executar o teste, conecte à seu compartilhamento com
smbclient e redirecione entrada padrão para seu arquivo.
A Listagem 1 mostra como fazer isso.
Listagem 1. Executando o teste
$ time smbclient '\\192.168.1.1\test' password < instructions Domain=[BOB] OS=[Unix] Server=[Samba 3.5.8-75.fc13] getting file \smbtest\file2 of size 524288000 as file2 (5323.2 kb/s) (average 5323.2 kb/s) getting file \smbtest\file1 of size 139460608 as file1 (5275.3 kb/s) (average 5313.0 kb/s) real 2m2.289s user 0m0.509s sys 0m4.580s |
O comando na Listagem 1 começa com o comando time
, que cronometra quanto tempo o comando especificado no restante dos argumentos leva para executar.
O comando em si é
smbclient e os argumentos dele são o nome do compartilhamento e a senha do usuário.
É possível incluir os argumentos típicos, como
-U para passar um nome de usuário alternativo se seu ambiente o requerer.
Por fim, < instructions redireciona a entrada padrão de
smbclient para o arquivo chamado
instructions, que contém as instruções do primeiro fragmento de código.
O resultado desse comando é uma cópia de vários arquivos em lote cronometrada.
O resultado do comando é uma lista dos arquivos transferidos, juntamente com uma taxa média de transferência por arquivo.
A saída de time é incluída no fim, mostrando que copiar aproximadamente 664 MB de arquivos levou 2 minutos e 2,289 segundos no total.
Essa agora é a referência.
Se você fizer qualquer mudança e o teste levar mais de 2 minutos e 2 segundos, então, está piorando as coisas com suas mudanças.
Se quiser testar apenas parâmetros do Samba e desconsiderar os efeitos do disco local e armazenamento em cache, é possível executar o teste diversas vezes e pegar a última medida. Fazer isso assegura que o sistema operacional armazena em cache o máximo possível e minimiza o acesso ao disco. À medida que você testa suas mudanças, certifique-se de que haja uma quantia de memória livre no servidor semelhante; caso contrário, as diferenças na quantia de dados armazenados em cache podem alterar os resultados de seu experimento.
Visualizando o status do Samba
Observar as informações de CPU, memória, disco e rede do servidor fornece algumas boas informações sobre o funcionamento do servidor em si, mas não fornece nenhum contexto para o que o aplicativo está fazendo.
O Samba vem com um utilitário útil chamado
smbstatus que mostra as conexões atuais e a atividade do arquivo; também é bom para ajuste de desempenho e resolução de problemas.
Listagem 2 mostra o comando smbstatus na ação.
Listagem 2. O comando smbstatus
$ smbstatus lp_load_ex: refreshing parameters Initialising global parameters params.c:pm_process() - Processing configuration file "/etc/samba/smb.conf" Processing section "[global]" Processing section "[homes]" Processing section "[printers]" Processing section "[extdrive]" Samba version 3.5.8-75.fc13 PID Username Group Machine ------------------------------------------------------------------- 17456 fred fred macbookpro-d0cd (::ffff:192.168.1.167) Service pid machine Connected at ------------------------------------------------------- fred 17456 macbookpro-d0cd Mon Jul 18 07:36:46 2011 extdrive 17456 macbookpro-d0cd Mon Jul 18 07:36:46 2011 Locked files: Pid Uid DenyMode Access R/W Oplock SharePath Name Time ---------------------------------------------------------------------------------- 17456 505 DENY_NONE 0x100081 RDONLY NONE /home/fred . 17456 505 DENY_NONE 0x100081 RDONLY NONE /home/fred Documents |
A Listagem 2 mostra a atividade atual do servidor Samba. Um usuário, fred, está conectado e tem dois compartilhamentos montados (fred e extdrive). Há também dois diretórios bloqueados.
O Samba é um daemon que principalmente envia e recebe pacotes pela rede. Diversos parâmetros alteram como os pacotes são enviados e como o Samba interage com o sistema operacional subjacente; esses parâmetros podem ter um efeito drástico no desempenho.
Muitos daemons fornecem o melhor nível possível de serviço a todos e não discriminam entre clientes. Se o serviço estiver sobrecarregado, todos obtêm o mesmo serviço ruim. Compare isso a uma rede telefônica: se ocorrer congestionamento, as pessoas não podem fazer novas chamadas, mas as chamadas existentes continuam como se nada estivesse errado. Se você limitar de forma artificial determinadas opções no Samba, é possível evitar chegar a uma situação de falta de recursos.
O parâmetro max connections limita o número de conexões que pode haver com um servidor Samba específico.
Cada conexão consome recursos de memória e CPU, portanto, é possível sobrecarregar um servidor tendo muitas conexões.
Por padrão, conexões ilimitadas são permitidas.
Se precisar limitar um servidor ocupado, é possível especificar um limite rígido com
max connections.
O parâmetro max smbd processes controla o número máximo de processos que podem ser executados.
Esse parâmetro é semelhante a
max connections , mas controla o número de processos resultantes das conexões.
Quando mais efetuar log com log level, mais recursos do servidor são gastos gravando logs no disco.
Manter esse valor em 1 ou 2 limita a quantia de logs gravados no disco e economiza mais recursos para atender clientes.
Configurando opções de soquete
Quando um aplicativo pede ao sistema operacional para abrir uma conexão de rede, o aplicativo também pode pedir que o sistema operacional trate os pacotes de uma determinada maneira usando opções de soquete. As opções de soquete podem ativar ou desativar ajustes de desempenho da rede, configurar bits de qualidade de serviço específicos nos pacotes ou configurar opções no nível de kernel no soquete.
O comando socket options pode controlar os bits de
tipo de serviço (TOS) nos pacotes. Os bits TOS informam os roteadores ao longo do caminho como o tráfego deve ser tratado.
Se os roteadores forem configurados para respeitarem esses bits, o tráfego pode ser manipulado da maneira solicitada pelo aplicativo.
A palavra-chave IPTOS_LOWDELAY é mais apropriada para redes de pouco atraso, como as LANs, enquanto que
IPTOS_THROUGHPUT é para links de WAN com latência mais alta.
Sua rede pode ser configurada de forma diferente, portanto, é possível que o uso das opções possa ter o efeito oposto.
A opção TCP_NODELAY desativa o algoritmo de Nagle (consulte
Recursos para um link para informações adicionais), que é mais apropriado para protocolos chatty, a um custo de mais pacotes sendo enviados.
Você tem firewalls ou outros dispositivos que mantêm o estado em sua rede, você pode estar interessado na opção
SO_KEEPALIVE , que ativa keep-alives de TCP. Esses pacotes periódicos mantêm a conexão aberta e mantêm o estado atualizado dentro dos firewalls. Caso contrário, o firewall descartará os pacotes e levará mais tempo para o cliente perceber que precisa reconectar ao servidor.
Apesar de brincar com diferentes configurações e tentar obter configurações ideais poder ser divertido, alguns itens fora da configuração do Samba podem realmente atrapalhar o desempenho. Em qualquer momento que o servidor estiver fazendo algo diferente de ler dados do disco e enviá-los para um cliente ou de receber tráfego recebido da rede e gravá-lo no disco, você estará fazendo a operação levar mais tempo.
Se um pacote for perdido na transmissão, o kernel precisa observar que o pacote sumiu e solicitar uma retransmissão.
Esse processo pode tornar uma conversa rápida lenta, principalmente se os dois lados forem separados por alta latência.
Uma fonte comum de perda de pacote é configurações incompatíveis entre o comutador e o servidor.
A negociação automática falha em ser ativada com uma correspondência correta ou um lado é configurado estaticamente e o outro lado ainda está realizando a negociação automática.
Essa discrepância resulta em erros em ambos os lados.
É possível procurar esses erros com o comando
netstat :
# netstat -d -i 2 Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg eth1 1500 0 5258404 0 0 0 3024340 0 0 0 BMRU eth1 1500 0 5258409 0 0 0 3024341 0 0 0 BMRU eth1 1500 0 5258411 0 0 0 3024342 0 0 0 BMRU |
Esse código mostra o comando netstat de diversos propósitos procurando erros de interface a cada 2 segundos com os parâmetros
-d -i 2 .
A cada 2 segundos, o status das interfaces disponíveis é mostrado.
No exemplo acima, as colunas
RX-OK e TX-OK
mostram que pacotes estão fluindo para dentro e para fora. Os erros, descartes e saturações são todos 0 em ambas as direções, o que mostra que não ocorreu nenhuma perda de pacote.
Se você vir erros, determine qual velocidade/duplex está sendo usada com
mii-tool ou mii-diag. Listagem 3 mostra como verificar as configurações da rede.
Listagem 3. Verificando as configurações de rede
# mii-tool eth1: negotiated 100baseTx-FD, link ok # mii-diag eth1 Basic registers of MII PHY #24: 3000 782d 0040 6177 05e1 41e1 0003 0000. The autonegotiated capability is 01e0. The autonegotiated media type is 100baseTx-FD. Basic mode control register 0x3000: Auto-negotiation enabled. You have link beat, and everything is working OK. Your link partner advertised 41e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT. End of basic transceiver information. |
A Listagem 3 começa com o comando mii-tool para fornecer um resumo curto das interfaces ativas.
Os resultados mostram que a interface negociou em 100/Cheio. mii-diag
mostra informações mais detalhadas e pode ser mais adequado para enviar para sua equipe de rede se precisar escalar o problema.
O comando
mii-tool pode ser usado para corrigir a velocidade e o duplex, apesar d na prática ser melhor ter a negociação automática do link.
Em "Aprenda Linux, 302 (Ambientes Mistos): Arquivos de banco de dados Trivial", você aprendeu sobre os arquivos de banco de dados
(TDBs) triviais que o Samba usa para manter o estado. Se houver algo de errado com esses bancos de dados, seu servidor precisará executar algum trabalho, como buscas desnecessárias no disco, ou deixará de armazenar em cache informações de serviços remotos.
Felizmente, é possível verificar os arquivos TDB para corrupção e corrigi-los se houver um problema.
É possível excluir os arquivos TDB temporários após encerrar o Samba e eles serão recriados na inicialização.
Para outros, certifique-se de executar um backup e, em seguida, verifique os arquivos com
tdbbackup -v.
Às vezes, o cliente pode ser a causa do desempenho lento. O cliente pode ter problemas de duplex, pode ter malware ou algum outro problema pode estar ocorrendo. Usar um cliente consistente para seu teste pode ajudar a eliminar o servidor como uma fonte em potencial da lentidão.
Este foi o artigo final da série do exame LPIC 302. Revise suas anotações e faça o exame! Boa sorte!
Aprender
- A man page smb.conf tem mais exemplos e descrições dos comandos mostrados neste artigo.
-
Configuring a Samba
cluster permite manipular mais carregamento e reduzir os efeitos de um falha do servidor.
- Dr. Gunther da Performance Dynamics publicou livros sobre análise e ajuste de desempenho.
Você pode estar familiarizado com seu método PDQ de análise do exame LPIC 301.
-
Nagle's
algorithm pode ter um efeito profundo na velocidade da rede.
- No site do programa LPIC você encontra objetivos detalhados, listas de tarefas e amostras de perguntas referentes aos três níveis da certificação em administração de sistemas Linux do LPI. Especificamente, veja os objetivos detalhados do LPI-302.
- Revise toda a série de preparação para o exame LPI no developerWorks, para saber mais sobre os fundamentos do Linux e se preparar para a certificação de administrador de sistemas, com base nos objetivos do exame LPI anteriores a abril de 2009.
- Na zona Linux do developerWorks, encontre vários artigos de instruções e tutoriais, bem como downloads, fóruns de discussão e muitos outros recursos para desenvolvedores e administradores Linux.
- Fique por dentro dos eventos técnicos e webcasts do developerWorks com foco em uma variedade de produtos IBM e tópicos do segmento de mercado de TI.
- Participe de um briefing ao vivo e gratuito
do developerWorks para se atualizar rapidamente sobre produtos e ferramentas da IBM, bem como tendências do segmento de mercado de TI.
- Acompanhe as demos on demand do developerWorks , que abrangem desde demos de instalação e configuração de produtos para iniciantes até funcionalidades avançadas para desenvolvedores experientes.
- Siga o DeveloperWorks no Twitter, ou inscreva-se em um feed de tweets sobre o Linux no developerWorks.
Obter produtos e tecnologias
- Se estiver procurando
open-source performance testing tools, consulte esta lista da opensourcetesting.org.
-
Wireshark é a melhor ferramenta de análise de pacote por aí; use-a para verificar os pacotes que seu servidor está enviando e recebendo.
- A diretiva IOzone filesystem benchmark ajuda a determinar a velocidade de seu armazenamento.
- Faça download de uma avaliação de 30 dias do
IBM Rational Performance Tester para ajudá-lo a identificar gargalos no desempenho do sistema.
-
Avalie os produtos IBM da maneira que for melhor para você: faça download da versão de teste de um produto, avalie um produto on-line, use-o em um ambiente de nuvem ou passe algumas horas na SOA Sandbox aprendendo a implementar Arquitetura Orientada a Serviços de modo eficiente.
Discutir
- Participe da comunidade do developerWorks. Entre em contato com outros usuários do developerWorks e explore os blogs, fóruns, grupos e wikis voltados para desenvolvedores.

Sean Walberg trabalha com Linux e UNIX desde 1994 em ambientes acadêmicos, corporativos e de provedores de serviço de Internet. Escreveu muito sobre administração de sistemas nos últimos anos. É possível entrar em contato com ele pelo e-mail sean@ertw.com.