RAM ou disco? Otimização de servidores Apache, Postfix, Oracle/MySQL e Samba

Transcrição

1 Otimização de servidores Apache,, Oracle/MySQL e Samba Os 44 mandamentos do servidor A homepage da empresa está conectada ao Slashdot desde as 11:20h; a nova massa de s deve sair e o banco de dados tem que retornar os dados solicitados em tempo recorde. Este artigo mostra quais técnicas o servidor pode utilizar para vencer a sobrecarga. por Badran Farwati, Peer Heinlein, Ralf Hildebrandt, Charly Kühnast e Volker Lendecke CAPA Benjamin Earwicker e Esther Groen - A otimização de servidores é uma questão de sobrevivência. A partir de uma determinada carga de uso, sua eficiência despenca. Se mais solicitações forem feitas, aumentando ainda mais a pressão sobre ele, todo o sistema também quebra. Mas é possível evitar a queda de um serviço crítico da empresa. A melhor solução nem sempre é empregar hardwares mais rápidos. Uma otimização da configuração do sistema do servidor, assim como dos serviços que rodam nele, pode fazer milagres. Cinco profissionais contam o que os administradores de sistema devem fazer para manter o fluxo de dados em seus servidores web, de , de banco de dados ou Samba. Independentemente do tipo de servidor, há algumas regras que todo administrador de sistemas deveria observar. Ralf Spenneberg, autor e docente na área de Administração de Sistemas Linux, conta que, para um desempenho otimizado, deve-se levar em consideração o seguinte: Fique atento às combinações! Para cada serviço há ao menos um fator que define o desempenho: CPU, E/S ou uso da memória. Por isso faz sentido dividir os serviços, que também tenham o mesmo fator determinante de desempenho, de tal maneira que dois serviços não rodem na mesma máquina (figura 1). Na maioria das vezes, o gargalo do desempenho do servidor de s localiza-se no disco rígido ou na latência de rede. Caso um antivírus não exija tempo adicional do processador, a CPU de um servidor responsável pela entrega de mensagens tem tempo suficiente para realizar outras tarefas. Seja observador! Somente com uma observação precisa e duradoura podese determinar quais são os fatores determinantes de performance, e quais as faixas normais de uso de CPU, E/S e memória. Os comandos de diagnóstico vmstat e sar analisam o fluxo de disco; top, htop, uptime e sar ajudam a supervisionar a CPU; ps, top e sar são úteis na determinação do uso de memória. Situações de carga total levam esses valores além dos normais. Uma supervisão através de SNMP (por exemplo, por meio do Zabbix [1] ou do Nagios) avisa, além disso, sobre catástrofes eminentes. Se forem localizadas áreas vulneráveis, registros supérfluos devem ser desativados. Partições de swap são um perigo para o administrador de sistemas. Muitos servidores permitem determinar o limite para o número máximo de instâncias rodando num mesmo momento. Como a manipulação de memória através da swap torna extremamente demorados outros acessos ao disco, cada vez mais processos esperam pelo cumprimento de suas ordens de E/S, o que leva a um ciclo horrendo de consumo progressivo de swap. Todos os serviços juntos não devem produzir um número de instâncias superior ao armazenável na memória física do disco da máquina servidor. ou disco? Não se deve deixar a memória do servidor ociosa! Em diversos servidores ela também fica menor: vale a pena carregar apenas módulos necessá- CPU E/S CPU E/S Serviço 1 Serviço 2 Serviço 1 Serviço 2 Figura 1: Elefante no buraco da agulha: diferentes solicitações de dois serviços referentes a tempo de CPU, memória e E/S provavelmente usam melhor a capacidade total do servidor quando executados como solicitações concorrentes. 29

2 CAPA Ações gerais Memória física Processo rios, o que também é válido para a recompilação de pacotes. Com isso, reduz-se o espaço ocupado na. Normalmente o Apache carrega vários módulos desnecessários na configuração padrão. No, em algumas circunstâncias, não faz sentido gerar binários sem suporte a MySQL, TLS ou LDAP. O espaço de memória ocupado pelo CDB é muito menor que o do Berkeley DB. As partições de dados, sistema e log devem ficar claramente separadas! Partições distintas permitem escolher o melhor sistema de arquivos para cada tarefa (por exemplo Ext3 para a de sistema e XFS para a partição de dados). Discos próprios ou sistemas RAID evitam que a cabeça de leitura do disco em acessos concorrentes se movimente exageradamente, o que degrada o desempenho. Use um sistema de log! Sem um log do sistema, nenhum dado para análise ou busca de erros pode ser disponibilizado. Um - diante do nome do arquivo de log em /etc/syslog.conf ativa a escrita assíncrona dos arquivos de log e diminui a carga no sistema de arquivos. Armazenagem segura Deve-se sempre proteger a configuração atual de alterações! Pequenas alterações podem deteriorar inesperadamente o desempenho do servidor. Até o motivo ser encontrado, perde-se um tempo precioso. Por isso, o administrador de sistemas deve utilizar um controle de versões Memória Espaço de Swap física Processo Processamento Processamento Figura 2: Um cenário de queda clássico: o número de processos para a carga sobe tanto que a máquina começa a usar a memória virtual, que cresce ainda mais por causa da diminuição da capacidade de carga. Na pior hipótese, o final da história é um sem memória disponível. para arquivos de configuração, ou ao menos fazer um backup das alterações. Assim ele pode reagir rapidamente quando os clientes começarem a reclamar de uma repentina queda de velocidade. Tudo que não sofrer alterações deve ficar no cache! O cache auxilia em muitas situações: proxies reversos (Squid, por exemplo) diante de sistemas CMS reduzem a carga sobre o banco de dados. Servidores DNS com caching (por exemplo Dns-Cache e Bind) economizam solicitações DNS desnecessárias em analisadores de log e servidores de . O cache integrado ao antivírus Amavisd New evita a repetição de análise do mesmo conteúdo. Perguntar ao porteiro Visitas indesejadas devem ser dispensadas o quanto antes. Quem não se aproxima do servidor também não consegue gerar qualquer problema. Um firewall, um controle de acesso com verificações smtpd_*_checks no excluem hóspedes indesejados antes que estes exijam minimamente do sistema. O Anvill Server no [2] limita, além disso, o número de s que o servidor manipula por unidade de tempo, mantendo as filas em tamanhos que ele consiga processar sem prejudicar seu desempenho. O Cband [3] se encarrega de realizar uma limitação inteligente da largura de banda no servidor web Apache. Bata sem fazer barulho! Port-knocking é uma ótima forma de poupar recursos, pois mantém o firewall completamente fechado e, no entanto, permite o login a usuários confiáveis [4]. Até mesmo senhas de uso único (one-time passwords) e a mudança das portas de serviços como SSH fazem bem à segurança, e além disso evitam que visitas indesejadas danifiquem a máquina. Servidor web Se o endereço de uma página Web estiver publicado em um local muito visitado, não deve demorar muito para que sua visitação aumente consideravelmente. Charly Kühnast, o administrador de sistemas responsável pelos firewalls e DMZs em um datacenter do Baixo Reno, aconselha: Escolha o módulo de multiprocessamento correto! O MPM prefork fornece uma série de processos idênticos do Apache, e é indicado para máquinas com até dois processadores. Quanto mais CPUs um servidor web possuir, melhor será optar pelo MPM worker, que trabalha com várias threads por processo. Use o cache com responsabilidade! O Apache oferece os módulos mod_disk_cache e mod_mem_cache, que são mecanismos para armazenar em cache os conteúdos chamados com freqüência. Quem possuir bastante deve optar pelo mod_mem_cache [5]. Peso a bordo Livre-se do peso morto! O mecanismo HTaccess é incontestavelmente útil, mas também um destruidor de desempenho. Então, livre-se dele se você não o utilizar: AllowOverride None economiza o lento processamento do arquivo.htaccess. Elimine mais peso ainda: o administrador também deve tirar do caminho links simbólicos (Options -followsymlinks) e todos os módulos desnecessários. A melhor solução é compilar o Apache estaticamente com tudo de que precisamos, e não carregar absolutamente nenhum módulo no tempo de execução. Abdique dos lookups! Lookups de nomes de máquina são terríveis para o desempenho, mesmo no caso de servidores de nome velozes. HostnameLookups off elimina esse entrave. Quem precisar urgentemente da informação pode executar os lookups mais tarde na avaliação dos logs com uma ferramenta como o Webalizer. Cuide de seus clientes e não os deixe esperar. A diretiva MaxClients tem papel central no desempenho. Se ela receber um número baixo demais, nem todos os clientes serão atendidos em tempo real. Se for muito alta, os clientes aguardarão tempo demasiado na fila de espera TCP. O valor correto só pode ser encontrado através de testes de carga. Desista de logfiles desnecessários! A atividade de registrar ações custa tempo. Um arquivo de log que ninguém mais usa já é desnecessário. Se o log é armazenado em discos externos, é desejável que seja um SAN 30

3 bem veloz, pois NFS geralmente é demasiadamente ineficiente. Use o Sendfile. Sendfile é uma chamada de sistema que delega ao kernel o envio de arquivos por soquetes de rede. Isso economiza memória (evita buffers de leitura) e além disso é mais rápido. O Apache utiliza a Sendfile quando se ativa EnableSendfiles. Preste atenção ao MMAP! O suporte a MMAP através do módulo mod_mmap_static permite ao Apache acessar um arquivo como um campo de memória integrado, o que melhora o desempenho. Não abuse do monitoramento de seu servidor! A auto-supervisão do Apache (opção SetHandler server-status...) é útil para testes e depuração. Depois de terminados os testes, ela deve ser desativada. Servidor de Quando o servidor de ameaça ter um colapso devido à carga, devem ser estabelecidas prioridades claras: primeiramente, é importante que o sistema permaneça estável e trabalhe efetivamente mesmo sob forte exigência. Então a velocidade de processamento deve estar no centro dos interesses. Peer Heinlein, instrutor da LPI e autor de artigos sobre Código Aberto, dá as dicas práticas: Limite o número de instâncias. O valor padrão no arquivo master.cf do define como 100 o número máximo de instâncias. Dependendo da versão e recursos compilados, uma instância pode custar 3 MB de, de modo que, em servidores com pouca memória, há a ameaça de uma falta de memória, e com isso uma queda do sistema. Mesmo programas anti-spam e antivírus requerem grandes quantidades de memória quando muitas instâncias rodam paralelamente. Muitas instâncias paralelas em um sistema sobrecarregado fazem com que elas se atrapalhem mutuamente, e terminam por levar a uma forte deterioração do fluxo de dados (figura 2). Use um disco para auxiliar o filtro de spam. Filtros de spam ou vírus como o Amavisd New e o Spamassassin geralmente criam um gargalo no servidor de s: eles causam uma grande carga sobre a CPU e E/S, e assim definem todo o fluxo do sistema. É interessante, nesse caso, remover o arquivo /var/spool/amavis/tmp para um disco (figura 3). Devido à alta performance, o servidor passa a tolerar aproximadamente 14 em vez das sete instâncias sugeridas como máximo do filtro de spam. Evitar caminhos confusos Faça cache das solicitações DNS! Todos os servidores de necessitam de DNS e precisam administrar incontáveis interrogações: quem são os servidores MX de um domínio? Existe algum domínio de envio? Há algum cliente em uma lista RBL? Um servidor DNS inserido em /etc/ resolv.conf, que se localize na própria rede e que armazene solicitações, economiza valiosos milisegundos em grandes volumes de acesso. Não desvie do caminho! O procedimento mais comum envia s do para o filtro de spam ou vírus. Estes, por sua vez, devolvem os s para o. Se forem adicionadas mais aplicações, seguemse mais ciclos como esse. O melhor é não enviar os s dos filtros de spam ou vírus de volta para o, mas passá-los diretamente para a próxima aplicação. Se estiver definido claramente que se trata apenas de tráfego de sendo transferido, a última aplicação do fluxo pode mandar os s diretamente para um servidor de , em vez de retorná-los para o. Checar competências Você só deve agir se tiver competência! Quem recebe s e não consegue organizá-los ou repassá-los acaba jogando seus recursos com as duas mãos pela janela. O emprego de local_recipient_maps e relay_recipient_maps é uma solução, pois o recebe s apenas para contas que existem realmente. Isso evita carga desnecessária vinda de spammers que estão apenas testando endereços. Com endereços de remetentes ocorre algo semelhante: caso o domínio especificado não exista, dificilmente se trata de um desejado. De qualquer forma, é impossível respondê-lo. A opção reject_unknown_sender_domain realiza Disco Disco Spamassasin Spamassasin Figura 3: Solução lucrativa: como aplicações como filtros de spam ou antivírus no servidor de s necessitam de muitos acessos de arquivo, em muitos casos vale a pena investir em um disco para o diretório atual dos softwares de filtro que rodam no servidor. uma requisição DNS para esclarecer isso antes que o servidor receba o . Utilize apenas arquivos locais como tabelas Lookup do! A administração de usuários ou domínios no MySQL e no LDAP pode parecer muito confortável porém, as requisições do podem causar um efeito bastante negativo. Uma tabela Lookup no formato hash ou, melhor ainda, btree, é sensivelmente mais rápida. Vale a pena criar um script que escreva em meia hora os dados de usuários atualizados da tabela MySQL ou LDAP em um arquivo local. Domestique os clientes inconvenientes com a limitação de espaço! Se um único cliente estiver sobrecarregando o servidor de , ou se ocorrer um ataque, a limitação de espaço, através do parâmetro smtpd_client_connection_rate_limit, evita que o restante do tráfego de s seja afetado. Até mesmo um firewall pode limitar o número máximo de conexões, e com isso evitar que o retorno de clientes abra centenas de conexões. Não se detenha com s problemáticos. Se o tráfego de s ficar congestionado, também pode ser porque o está gastando mal os recursos com muitas mensagens que não puderam ser enviadas. O parâmetro maximum_backoff_time determina o maior tempo que o deve esperar para tentar reenviar o . Um aumento desse valor oferece mais tempo para uma primeira busca possivelmente bemsucedida, em vez de desperdiçá-lo com repetidas tentativas subseqüentes aparentemente sem resultado. Como opção, o parâmetro fallback_relay oferece a possibilidade de mover esses s problemáticos 31

4 CAPA Ações gerais para outra máquina, que então realiza o trabalho sujo pelo servidor de verdade. Servidor de banco de dados Qual é a causa quando o banco de dados entrega conjuntos de dados de maneira hesitante e a CPU praticamente não está ocupada? Além da qualidade de cada consulta SQL, o design do banco de dados e a configuração do servidor também contribuem de forma importante para o desempenho de um banco de dados. Badran Farwati, há sete anos administrador de bancos de dados, programador e atualmente sênior da Oracle na Biblioteca Nacional Austríaca, esclarece como aumentar o desempenho de um servidor de banco de dados: Escolha o índice correto! Um dos elementos mais importantes de um banco de dados são seus índices: tempos de resposta do servidor dependem decisivamente de sua qualidade. Um índice B*TREE (o tipo padrão em muitos bancos de dados) deve ser empregado quando a coluna indexada puder aceitar muitos valores diferentes. A árvore de busca desse tipo de índice cresce mais devagar. Para colunas que recebem poucos valores diferentes (por exemplo, grupos de produtos), E/S Tabela Parser Data Local Parser Tabela E/S Data Local Figura 4: Desde a versão 5.1, o MySQL também suporta tabelas particionadas que poupam o parser, no caso de perguntas que se referem a uma ou poucas colunas, de ler a tabela por completo. Isso preserva os recursos do computador. aconselha-se em vez disso um índice do tipo bitmap para Oracle, ou um tipo correspondente em outros bancos de dados. Para tabelas de poucas linhas, um TABLE ACCESS (FULL) (no MySQL um FULL TABLE SCAN) é mais rápido que o acesso pelo índice. Caso muitas perguntas utilizem uma função como UPPER(coluna xyz)), um índice do resultado dessa função se encarrega de melhorar o desempenho. Pressupõe-se que o sistema de banco de dados empregado suporte índices baseados em funções [6]. Apague índices desnecessários! O Oracle Optimizer não utiliza índices desnecessários em comandos. Independentemente de eles utilizarem ou não comandos SQL, o sistema SQL carrega em uma tabela todos os índices definidos. Evite índices fragmentados! Índices B-TREE fragmentam com o tempo através de atualizações ou inserções em uma tabela, o que torna as perguntas consideravelmente mais lentas. O grau de fragmentação pode ser verificado no Oracle com a instrução ANALYSE INDEX Index-name VALIDATE STRUCTURE. Com ALTER INDEX Index-name REBUILD ONLINE, o índice pode ser reconstruído. No MySQL, ANALYSE TABLE e OPTMIZE TABLE reconstroem um índice fragmentado. A expressão correta Otimize os comandos SQL. O SQL é uma linguagem flexível. Na maioria das vezes, diversos caminhos levam ao mesmo objetivo. Freqüentemente, as aplicações se diferenciam no uso que fazem de seus recursos de E/S. EXPLAIN PLAN no Oracle, ou EXPLAIN, no MySQL, ajudam na otimização. Esses comandos esclarecem como os sistemas SQL constróem as perguntas, quais índices ela utiliza e quantos resultados intermediários o banco de dados produz. A partir do MySQL 5.1, está disponível o EXPLAIN PARTITIONS, para análise do comportamento de tempo de execução de tabelas particionadas [7]. Use de maneira correta o soft parsing disponibilizado por seu banco de dados. O sistema do banco de dados processa consultas SQL literalmente, ou seja, em palavras. Mesmo entre perguntas idênticas, que se diferenciam apenas em um único literal (por exemplo SELECT... WHERE x= e SELECT... WHERE x=200...), o sistema não produz nenhum anexo. Ela deposita uma cópia de cada pergunta na memória compartilhada. Se as perguntas diferentes por apenas um literal se repetirem uma centena de vezes, o banco de dados irá depositá-las cem vezes na memória (Hard Parse). Isso leva a uma fragmentação da memória. Um aumento da ajuda apenas de maneira limitada. Se, no entanto, a pergunta na cláusula WHERE utilizar, em vez de um literal, um termo variável (comando BIND SQL), o sistema depositará as consultas SQL com esse termo na, e não as modificará mais em uma nova chamada (Soft Parse). Dividir e conquistar Limite o tamanho de suas tabelas! Tabelas com milhões de conjuntos de dados levam a um alto uso de recursos de E/S. Uma possibilidade de reduzir essa necessidade é desmembrar tabelas grandes em vários blocos. Desde o Oracle 8 e o MySQL 5.1, é possível particionar tabelas. Em comandos SQL que se referem apenas a determinadas colunas na cláusula WHERE, o parser deve fazer uma busca apenas nas partições relevantes (figura 4). O particionamento ajuda especialmente em trabalhos em lote que atualizem partes de uma tabela. Diferentes tipos de uso de bancos de dados levam a diferentes demandas de recursos da máquina: Decision Support Systems (DSS, [8]) são sistemas de pesquisa e busca, que normalmente executam repetidos SELECT e, com isso, processos de ordenação conjuntos, porém quase nenhuma ação de inserção, atualização ou exclusão. Um Online Transaction Processing System (OLTP, [9]), como por exemplo um sistema de catálogo on-line, ou um sistema de gerenciamento de conteúdo, serve normalmente a centenas de usuários ao mesmo tempo, que também modificam os dados. Com isso, as tabelas de índice também se alteram rapidamente. A escolha correta do índice, portanto, é decisiva para o desempenho. Caso um servidor de banco de dados sirva ambos os cenários de uso, deve-se optar, de acordo com o uso principal, por uma prioridade de CPU adequada aos diferentes tipos de uso. No Oracle isso é feito mais facilmente com o Resource Manager [10]. 32

5 Use conexões persistentes e o servidor compartilhado! A formação recorrente de conexões não persistentes custa recursos. Por outro lado, o Oracle, em servidores dedicados, inicia um processo para cada conexão, e o mantém na memória quando o usuário não acessa o banco de dados. Por isso a Oracle oferece uma solução para servidores compartilhados que mantém o número de processos baixo, administrando conexões e consultas em um grande pool. Isso preserva os recursos, especialmente em sistemas OLTP. Atente às tarefas em lote! Elas devem rodar exclusivamente em horas sem acesso durante a noite. Controle o número de conexões! O mais eficaz é separar servidores de aplicação e Web do servidor de banco de dados. Em todo caso, o número máximo de processos de ambos os lados deve ser bem definido: se o número máximo de processos no servidor web for maior que o do banco de dados, isso pode levar a uma inundação de conexões ao banco de dados, que será incapaz de reagir ao número excessivo de processos. As diretivas do Apache MaxClients, KeepAlive, MaxSpareServer e MaxRequestsPerChild devem ser ajustadas às configurações do Oracle; os parâmetros SESSION e PROCESS, e a decisão sobre o uso do servidor compartilhado, têm influência no número máximo de conexões possíveis. No MyS- QL, isso é definido por max_connections e max_user_connections. Samba Quando o servidor Samba apenas envia dados timidamente, a abertura e o salvamento de arquivos tornam-se um teste de paciência, e provocam assim um efeito sobre a produtividade de toda a empresa. Volker Lendecke, participante da equipe do Samba e co-fundador do Service Network GmbH, explica como tirar essa pedra do caminho. Não altere a configuração do seu servidor Samba! A configuração padrão do Samba já possui as configurações para oferecer o melhor desempenho possível aos clientes Windows. Caso ocorram problemas de desempenho, deve-se primeiro eliminar todas as configurações que não sejam extremamente necessárias no arquivo de configuração smb.conf, e então fazer a reinstalação passo a passo. Seja generoso com a! Dois a 3 MB de memória real por usuário ativo são o mínimo para o bom desempenho de um servidor Samba. Cada bit a mais pode ser utilizado pelo sistema para fins de cache de alto desempenho. Teste sua rede! Quando a transferência de arquivos por Samba estiver lenta, aconselha-se um contra-teste com FTP. Esse protocolo simples, que transfere apenas seqüências de dados puros, mostra a taxa de transferência máxima possível através da rede. Ajudante útil Ative as travas oportunistas (Oplocks)! Um Opportunistic Lock não serve para reservar determinados arquivos exclusivamente para um usuário. Ele permite ao cliente armazenar no cache o conteúdo do arquivo. Dessa forma, o servidor assegura a um cliente que ninguém mais acesse aquele arquivo ao mesmo tempo. Assim que um segundo usuário o abrir, o servidor avisará o cliente, fechando em seguida o Oplock (figura 5). Logo após, o cliente envia o acesso de escrita para o servidor, o que na prática economiza muita largura de banda de rede. Inicie o Winbind! Sem Winbind, o daemon Samba é obrigado a construir uma nova conexão própria para cada novo usuário, o que inclusive aumenta desnecessariamente a carga em aproximadamente 40 a 60 pacotes IP. O Winbind diminui isso para três pacotes, mantendo uma conexão com o controlador de domínios permanentemente aberta. Não diferencie letras maiúsculas e minúsculas! Como o Windows não diferencia letras maiúsculas e minúsculas em nomes de arquivos, mas o Unix sim, o Samba precisa, quando o Windows quer depositar um arquivo test.txt, confirmar que o arquivo Test.txt não existe. Em diretórios com algumas milhares de entradas, essa varredura utiliza muitos recursos. Por isso, se possível, diretórios administrados com Samba devem conter apenas poucos arquivos. Caso não seja possível, faz sentido desativar a varredura com case sensitive = yes, preserve case = no e default case = lower. Com isso, o Samba mostrará todos os nomes de arquivo com letras minúsculas. Servidor Cliente Servidor Cliente Dados Ajuste imediato Alteração local Figura 5: No acesso de escrita a um arquivo, as travas operacionais (Operative Locks) tornam a sincronização entre clientes e servidor supérflua, caso apenas um usuário esteja acessando o arquivo. Se outro usuário o acessar, o servidor cancela a trava e o cliente envia de volta o arquivo alterado. Consciência tranqüila São 7:30 da noite: os tempos de resposta do servidor web nas páginas referidas no Slashdot permanecem sob controle. A massa de s chegou a seus destinatários e o banco de dados avaliou as consultas eficientemente. Como os servidores foram otimizados conforme as regras, é hora de o estressado administrador de sistemas ir para casa com a consciência tranqüila. Mais Informações [1] Zabbix: Ampla competência: Linux Magazine 24, pg 66, outubro de [2] Anvil Server: [3] Cband: [4] Batida secreta: Port Knocking: Linux Magazine 26, pg. 48 [5] Módulo Apache mod_mem_cache: docs/2.0/mod/mod_cache.html [6] Índices baseados em funções com Oracle: 8i/FunctionBasedIndexes.php [7] EXPLAIN PARTITIONS no MySQL 5.1: refman/5.1/en/explain.html [8] Decision Support Systems (Wikipédia): Sistema_de_suporte_à_decisão [9] Online Transaction Processing (Wikipédia): Online_transaction_processing [10] Oracle Resource Manager: oramag/oracle/04-nov/o64tuning.html Ajuste somente se necessário Alteração local 33