Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

Guia de Gerenciamento de Energia

Red Hat Enterprise Linux 6

(Beta) Gerenciando consumo de energia no Red Hat Enterprise Linux 6

Edição 0.2

Logo

Red Hat Inc.

Don Domingo

Red Hat Serviços de Conteúdo de Engenharia

Rüdiger Landmann

Red Hat Serviços de Conteúdo de Engenharia

Resumo

Este documento explica como gerenciar o consumo de energia nos sistemas Red Hat Enterprise Linux 6 de forma efetiva. As seguintes seções apresentam técnicas diferenciadas para diminuir o consumo de energia (para ambos servidor e laptop), e como cada técnica afeta o desempenho geral de seu sistema. Por favor, observe: O documento ainda está sob desenvolvimento, está sujeito à grande mudança e é fornecido aqui como uma pré-visualização. O conteúdo e instruções contidas nele não devem ser consideradas completas, e devem ser usadas com cuidado.

Capítulo 1. Visão Geral

O gerenciamento de energia tem sido um de nossos pontos de foco para aprimoramento para o Red Hat Enterprise Linux 6. De uma perspectiva mais ampla, o gerenciamento de energia é somente um dos problemas para o green IT (TI verde) que estende adiante e inclui problemas como materiais recicláveis, produção de sistemas ecológicos, e design adequado e planejamento de sistemas ecológicos. Neste documento, fornecemos diretrizes e informações sobre o gerenciamento de energia de seus sistemas com um Red Hat Enterprise Linux 6.

1.1. Importância do Gerenciamento de Energia

No centro do gerenciamento de energia você entende como otimizar de forma efetiva o consumo de energia de cada componente de sistema. Isto leva a estudos de tarefas diferentes que seu sistema realiza e configurar cada componente para assegurar que seu desempenho é correto para o trabalho.
O maior motivador para o gerenciamento de energia é:
  • reduzindo consumo de energia em geral para economizar energia
O uso correto do gerenciamento de energia em:
  • redução de aquecimento para servidores e centrais de computadores
  • custos secundários reduzidos, incluindo refrigeramento, espaço, cabos, geradores, e uninterruptible power supplies (UPS).
  • tempo de vida de bateria estendido para laptops.
  • resultado de dióxido de carbono mais baixo
  • atendendo às regulamentações do governo ou requerimentos legais a respeito do Green IT, por exemplo Energy Star
  • atendendo às regras da empresa para novos sistemas
Como via de regra, a diminuição do consumo de energia de um componente específico (ou de um sistema como um todo) irá diminuir o aquecimento e naturalidade. Como tal, você deve estudar a fundo e testar a diminuição do desempenho aceita por qualquer configuração que você fizer, especialmente para sistemas de missão crítica.
Ao estudar as tarefas diferentes que seu sistema realiza, e ao configurar cada componente para certificar-se que seu desempenho é o suficiente para o trabalho, você pode economizar energia, gerar menos aquecimento e otimizar a vida da bateria para laptops. Muitos dos princípios para a análise e ajuste de um sistema em relação ao consumo de energia são semelhantes àqueles do ajuste de desempenho. Até um certo ponto, o gerenciamento de energia e ajuste de desempenho são soluções opostas para a configuração do sistema, pois os sistemas são geralmente otimizados quanto ao desempenho ou quanto à energia. Este manual descreve as ferramentas que a Red Hat fornece e as técnicas que desenvolveram para ajudá-lo neste processo.
O Red Hat Enterprise Linux 6 já vem com uma quantia de recursos de gerenciamento de energia que são ativados por padrão. Eles foram todos escolhidos seletivamente para não impactar o desempenho de um servidor comum ou uso de desktop. No entanto, para uso muito específico onde máxima entrada, meor latência ou desempenho de CPU mais alto é crucial, pode ser necessário realizar uma revisão destes padrões.
Para decidir se você deve otimizar suas máquinas usando técnicas descritas neste documento, pergunte-se:
P: Eu preciso otimizar?
P: Quanto eu preciso otimizar?
P: A otimização irá reduzir o desempenho do sistema até um ponto aceitável?
P: O tempo e recursos gastos na otimização do sistema compensam o ganho alcançado?
P:
Eu preciso otimizar?
R:
A importância da otimização de energia depende se sua empresa possui diretrizes que precisam ser seguidas ou se existem algumas regras que você precisa seguir.
P:
Quanto eu preciso otimizar?
R:
Muitas das técnicas que apresentamos não requerem que você passe por todo o processo de auditoria e análise de sua máquina em detalhes, mas ao invéz disso oferece um conjunto de otimizações gerais que geralmente melhoram o uso de energia.
P:
A otimização irá reduzir o desempenho do sistema até um ponto aceitável?
R:
A maioria das técnicas descrita neste documento influencia o desempenho de seu sistema de maneira notável. Se você escolher implementar o gerenciamento de energia além de padrões já existentes no Red Hat Enterprise Linux 6, você deve monitorar o desempenho do sistema após a otimização de energia e decidir se a perda de desempenho é aceitável.
P:
O tempo e recursos gastos na otimização do sistema compensam o ganho alcançado?
R:
A otimização de um sistema único manualmente seguido de um processo inteiro geralmente não compensa, considerando que o tempo de custo gastos ao fazê-lo é maior do que o benefício que geralmente obteria durante toda uma vida de uma máquina única. Por um outro lado, se você por exemplo colocar 10000 sistemas de desktops em seu escritório, todos usando a mesma configuração, então ao criar uma configuração otimizada e aplicá-la à todas as 10000 máquinas pode ser uma boa idéia.
As seções a seguir irão explicar como os benefícios de desempenho de hardware óptimo beneficia seu sistema em relação ao consumo de energia.

1.2. Básicos do Gerenciamento de Energia

O gerenciamento de energia efetivo é construído sob os seguintes princípios:
Uma CPU ociosa deve somente ser ativada quando necessário

O kernel Red Hat Enterprise Linux 5 usado em um timer periódico para cada CPU. Este timer evita que a CPU se torne realmente ociosa, pois ele requer que a CPU processe cada evento de timer (o qual aconteceria a cada milisegundos, dependendo da configuração), não importando se o processo estava rodando ou não. Uma grande parte do gerenciamento de energia efetivo envolve a redução da frequência na qual as ativações de CPU são realizadas.

Por causa disso, o kernel do Linux no Red Hat Enterprise Linux 6 elimina o timer de periódico: como um resultado, o estado ocioso de uma CPU agora é tickless. Isto evita que a CPU consuma energia desnecessária quado estiver ociosa. No entanto, os benefícios deste recurso podem estar em offset se seu sistema possuir aplicativos que criam eventos de timer desnecessários. Os eventos de poll (como os de verificações para as mudanças de volume, movimento de mouse, entre outros) são exemplos de tais eventos.
Red Hat Enterprise Linux 6 inclui ferramentas com o qual você pode identificar aplicativos de auditoria com base no uso de suas CPUs. Consulte o Capítulo 2, Ferramentas de Gerenciamento de Energia e análise para maiores detalhes.
Hardware e dispositivos que não estiverem sendo usados devem ser desativados completamente.

Este é especialmente verdadeiro para dispositivos que possuem partes que movem ( por exemplo, discos rígidos). Além disso, alguns aplicativos podem deixar um dispositivo sem uso mas ativado "aberto" quando isto acontecer, o kernel assume que o dispositivo está em uso, o qual pode evitar que o dispositivo vá para estado de economia de energia.

Atividade baixa deve traduzir para baixa voltagem

Na maioria dos casos, no entanto, isto depende do hardware moderno e configuração do BIOS correta. Componentes de sistema mais antigos, geralmente não possuem suporte para alguns dos novos recursos que podemos agora suportar no Red Hat Enterprise Linux 6.Certifique-se de que está usando o firmware oficial mais recente para seus sistemas e que nas seções de gerenciamento de energia ou configuração de dispositivo do BIOS, os recursos de gerenciamento de energia estejam habilitados. Alguns recursos a checar incluem:

  • SpeedStep
  • PowerNow!
  • Cool'n'Quiet
  • ACPI (C state)
  • Smart
Se seu hardware possui suporte para estes recursos e eles estão habilitados no BIOS, o Red Hat Enterprise Linux 6 irá usá-los por padrão.
Formatos diferentes de estados de CPU e seus efeitos.

CPUs modernas juntas com Advanced Configuration and Power Interface (ACPI) fornecem estados de energia diferentes. Os três estados diferentes são:

  • Espera (C-states)
  • Frequência (P-states)
  • Resultado de aquecimento (T-states or "thermal states")
Uma CPU rodando no estado de espera mais baixo consome o mínimo de quantidade de watts, mas ele também leva muito mais tempo para ativar do estado quando necessário. Em casos raros, isto também pode levar à CPU ter que ser ativada imediatamente, todas as vezes que acaba de entrar no estado de espera. Esta situação resulta em uma CPU efetivamente permanentemente ocupada e perde um pouco da economia de energia em potencial se outro estado houver sido usado.
Uma máquina desligada usa o mínimo de quantidade de energia.

O mais óbvio que isto possa parecer, uma das melhores maneiras de economizar energia é desligando os sistemas. Por exemplo, sua empresa pode desenvolver uma cultura corporativa focada em consciência "green IT" (TI verde) com regras de desligar máquinas durante o intervalo do almoço ou quando você for pra casa. Você também poderá consolidar diversos servidores físicos em um servidor maior e virtualizá-los usando a tecnologia de virtualização que enviamos junto com o Red Hat Enterprise Linux 6.

Capítulo 2. Ferramentas de Gerenciamento de Energia e análise

2.1. Visão geral de auditoria e análise

A auditoria do manual detalhado, e ajuste de um sistema único é geralmente uma exceção, pois o tempo e custo gasto para realizar isto, sobrepõe os benefícios ganhos destas últimas peças de ajuste de sistema. No entanto, ao realizar estas tarefas uma vez para um grande número de sistemas quase idênticos onde você pode reusar as mesmas configurações para todos os sistemas, pode ser muito útil. Por exemplo, considere a implementação de diversos sistemas de desktop, ou um cluster de HPC onde as máquinas são quase idênticas. Outra razão para fazer a auditoria e análise é fornecer uma base para comparação contra o qual você consegue identificar regressões ou mudanças no comportamento do sistema no futuro. Os resultados desta análise podem ser muito úteis em casos onde o hardware, BIOS, ou atualizações de software acontecem regularmente e você queira evitar qualquer surpresas a respeito de consumo de energia. Geralmente, uma auditoria completa e análise lhe dará uma idéia muito melhor do que está realmente acontecendo em um sistema específico.
A auditoria e análise de um sistema a respeito do consumo de energia é relativamente difícil, até mesmo com os sistemas mais modernos disponíveis. A maioria dos sistemas não fornecem os meios necessários para medir o uso de energia via software. Porém, existem exceções: O console de gerenciamento do ILO dos sistemas de servidor Hewlett Packard possuem um módulo de gerenciamento de energia que você pode acessar através da Web. A IBM fornece uma solução semelhante em seu módulo de gerenciamento de energia BladeCenter. Em alguns sistemas Dell, o assistente de IT oferece monitoramento de energia também. Outros fornecedores podem oferecer capacidades semelhantes para suas plataformas de servidores, mas não existe soluções únicas disponíveis que sejam suportadas por todos os fornecedores. Se seu sistema não possuir nenhum mecanismo embutido para medir o consumo de energia, existem outras opções. Você pode instalar um fornecimento de energia especial em seu sistema que ofereça informações de consumo de energia por USB. O Gigabyte Odin GT 550 W PC power supply é um exemplo deste, e o software para ler estes valores sob o Linux pode ser encontrado externamente em http://mgmt.sth.sze.hu/~andras/dev/gopsu/. As a last resort, some external watt meters like the Watts up? PRO possui uma conexão de USB.
Medidas diretas de consumo de energia é geralmente necessário somente para aumentar a economia o máximo possível. Felizmente, existem outros meios disponíveis para medir se as mudanças foram efetivadas ou como o sistema está se comportando. Este capítulo descreve as ferramentas necessárias.

2.2. PowerTOP

A introdução do kernel do tickeless no Red Hat Enterprise Linux 6 (consulte Seção 3.4, “Kernel sem Tick”) permite que a CPU insira o estado ocioso mais frequêntemente, reduzindo o consumo de energia e aumentando o gerenciamento de energia. A nova ferramenta PowerTOP identifica componentes específicos do kernel e aplicativos do userspace que frequentemente ativam a CPU. O PowerTOP foi usado no desenvolvimento para desenvolver as auditorias descritas em Seção 3.11, “Otimizações em Espaço de Usuário” que ajustam muitos aplicativos neste lançamento, reduzindo ativamento de CPU desnecessário pelo fator de dez.
Instale PowerTOP com o comando:
yum install powertop
Execute PowerTOP com o comando:
powertop
Observe que você precisará executar o PowerTOP com privilégios do usuário root para permitir que o aplicativo faça qualquer coisa.
Quando ele é executado, o PowerTOP reune estatísticas do sistema e apresenta-lh com uma lista de componentes que estão enviando ativamentos para a CPU mais frequentemente. O PowerTOP também dá sugestões de ajuste de sistema para consumo de energia mais baixo. Estas sugestões aparecem no final da tela, e especificam uma chave que você deve pressionar para aceitar as sugestões do PowerTOP. As atualizações do PowerTOP são efetuadas periodicamente, e outras sugestões aparecem em Figura 2.1, “PowerTOP em Operação”, observe as sugestões para aumentar o tempo de gravação de retorno suja do VM, and the key (W) para pressionar para aceitar as sugestões.
Quando ele é executado, o PowerTOP reune estatísticas de sistemas e lhe apresenta diversas listas importantes de informações. No topo existe uma lista do tamanho que os seus núcleos de CPU têm sido em cada estado C e P disponíveis. Quanto mais tempo a CPU ficar em uma estatística C ou P, melhor (C4 sendo mais alta do que C3) e é um bom indicador de como o sistema está bem ajustado de acordo com o uso da CPU. Seu objetivo deve ser a residência de 90% ou mais em estado C ou P mais alto enquanto o sistema estiver em ocioso.
A segunda parte da imformação é um sumário dos ativamentos atuais por segundo da máquina. O número de ativamento por segundo lhe fornece uma boa idéia de como os serviços estão ou os dispositivos e driver do kernel estão se desempenhando a respeito do uso de energia em seu sistema. Quanto mais ativamento por segundo você tiver, mais energia é consumida, portanto o mais baixo é melhor aqui.
Depois, o PowerTOP fornece uma estimativa do uso de energia atual do sistema, caso esteja disponível. Aguarde o PowerTOP relatar estes números em laptops enquanto eles estão em modo de bateria.
Qualquer estimativa disponível de uso de energia é seguido de uma lista detalhada de componentes que enviam ativamentos para a CPU mais frequentemente. No topo da lista se encontram os componentes que você deve investigar mais de perto, para otimizar seu sistema para reduzir o uso de energia. Se eles forem os componentes do kernel, (indicado pelo nome do componente sendo listado em <>) então os ativamentos serão associados geralmente ao driver específico que causa isto. O ajuste de drivers geralmente requer mudanças de kernel, que vão além do escopo deste documento. No entanto, os processos da área de usuário que enviam ativamentos, são gerenciados com maior facilidade. Primeiro, identifique se este serviço ou aplicativo deve ser executado neste sistema. Caso não deva, simplesmente desative-o. Para desligar um serviço permanentemente, execute:
chkconfig servicename off
Se você precisar de mais detalhes sobre o que o componente realmente faz, execute:
ps -awux | grep componentname 
strace -p processid
Se o rastro parece que se repetirá, então provavelmente você encontrou um loop ocupado. Para reparar isto, você precisaria de uma mudança de código neste componente, o qual vai além do escopo deste documento.
Quando ele é executado, o PowerTOP reune estatísticas do sistema e apresenta uma lista de componentes que estão enviando ativamentos para a CPU mais frequentemente. O PowerTOP também dá sugestões de ajuste de sistema para consumo de energia mais baixo. Estas sugestões aparecem no final da tela, e especificam uma chave que você deve pressionar para aceitar as sugestões do PowerTOP. As atualizações do PowerTOP são efetuadas periodicamente, e outras sugestões aparecem em Figura 2.1, “PowerTOP em Operação”, observe as sugestões para aumentar o tempo de gravação de retorno suja do VM, and the key (W) para pressionar para aceitar as sugestões. Estas mudanças serão ativadas somente na próxima reinicialização. Para ajudá-lo a efetivar de forma permanente estas mudanças, o PowerTOP exibe o comando exato que ele executa para realziar esta otimização. Adicione o comando ao seu arquivo /etc/rc.local com seu editor de texto preferido para que tome efeito todas as vezes que seu computador iniciar.
PowerTOP em Operação

Figura 2.1. PowerTOP em Operação

O website Less Watts publica uma lista de aplicativos que o PowerTOP identificou como mantendo as CPUs ativas. Consulte http://www.lesswatts.org/projects/powertop/known.php.

2.3. Diskdevstat e netdevstat

As ferramentas Diskdevstat e netdevstat são SystemTap que coletam informações detalhadas sobre a atividade do disco e atividade de rede de todos os aplicativos rodando em um sistema. Estas ferramentas foram inspiradas por PowerTOP, o que exibe o número de ativamentos de CPU por cada aplicativo por segundo (consulte o Seção 2.2, “PowerTOP”). As estatísticas que estas ferramentas coletam, permitem que você identifique aplicativos que desperdiçam a energia com muitas operações de E/S pequenas, ao invés de menos operações maiores. Outras ferramentas de monitoramento que medem somente velocidades de transferência, não ajudam a identificar este tipo de uso.
Instalar estas ferramentas com o SystemTap com o comando:
yum install systemtap tuned-utils kernel-debuginfo
Rodar estas ferramentas com o comando:
diskdevstat
ou o comando:
netdevstat
Ambos comandos podem tomar três parâmetros, como se segue:
diskdevstat update_interval total_duration display_histogram
netdevstat update_interval total_duration display_histogram
update_interval
O tempo em segundos entre atualizações da exibição. Padrão 5
total_duration
O tempo em segundos para a execução total. Padrão: 86400 (1 dia)
display_histogram
Sinalização se o histograma para todos os dados colecionados no final da execução.
O resultado se assemelha ao de PowerTOP. Aqui segue um resultado de amostra de uma execução de diskdevstat mais longa em um sistema Fedora 10 executando um KDE 4.2:
  PID   UID DEV     WRITE_CNT WRITE_MIN WRITE_MAX WRITE_AVG    READ_CNT  READ_MIN  READ_MAX  READ_AVG COMMAND        
 2789  2903 sda1          854     0.000   120.000    39.836           0     0.000     0.000     0.000 plasma            
15494     0 sda1            0     0.000     0.000     0.000         758     0.000     0.012     0.000 0logwatch         
15520     0 sda1            0     0.000     0.000     0.000         140     0.000     0.009     0.000 perl              
15549     0 sda1            0     0.000     0.000     0.000         140     0.000     0.009     0.000 perl              
15585     0 sda1            0     0.000     0.000     0.000         108     0.001     0.002     0.000 perl              
 2573     0 sda1           63     0.033  3600.015   515.226           0     0.000     0.000     0.000 auditd            
15429     0 sda1            0     0.000     0.000     0.000          62     0.009     0.009     0.000 crond             
15379     0 sda1            0     0.000     0.000     0.000          62     0.008     0.008     0.000 crond             
15473     0 sda1            0     0.000     0.000     0.000          62     0.008     0.008     0.000 crond             
15415     0 sda1            0     0.000     0.000     0.000          62     0.008     0.008     0.000 crond             
15433     0 sda1            0     0.000     0.000     0.000          62     0.008     0.008     0.000 crond             
15425     0 sda1            0     0.000     0.000     0.000          62     0.007     0.007     0.000 crond             
15375     0 sda1            0     0.000     0.000     0.000          62     0.008     0.008     0.000 crond             
15477     0 sda1            0     0.000     0.000     0.000          62     0.007     0.007     0.000 crond             
15469     0 sda1            0     0.000     0.000     0.000          62     0.007     0.007     0.000 crond             
15419     0 sda1            0     0.000     0.000     0.000          62     0.008     0.008     0.000 crond             
15481     0 sda1            0     0.000     0.000     0.000          61     0.000     0.001     0.000 crond             
15355     0 sda1            0     0.000     0.000     0.000          37     0.000     0.014     0.001 laptop_mode       
 2153     0 sda1           26     0.003  3600.029  1290.730           0     0.000     0.000     0.000 rsyslogd          
15575     0 sda1            0     0.000     0.000     0.000          16     0.000     0.000     0.000 cat               
15581     0 sda1            0     0.000     0.000     0.000          12     0.001     0.002     0.000 perl              
15582     0 sda1            0     0.000     0.000     0.000          12     0.001     0.002     0.000 perl              
15579     0 sda1            0     0.000     0.000     0.000          12     0.000     0.001     0.000 perl              
15580     0 sda1            0     0.000     0.000     0.000          12     0.001     0.001     0.000 perl              
15354     0 sda1            0     0.000     0.000     0.000          12     0.000     0.170     0.014 sh                
15584     0 sda1            0     0.000     0.000     0.000          12     0.001     0.002     0.000 perl              
15548     0 sda1            0     0.000     0.000     0.000          12     0.001     0.014     0.001 perl              
15577     0 sda1            0     0.000     0.000     0.000          12     0.001     0.003     0.000 perl              
15519     0 sda1            0     0.000     0.000     0.000          12     0.001     0.005     0.000 perl              
15578     0 sda1            0     0.000     0.000     0.000          12     0.001     0.001     0.000 perl              
15583     0 sda1            0     0.000     0.000     0.000          12     0.001     0.001     0.000 perl              
15547     0 sda1            0     0.000     0.000     0.000          11     0.000     0.002     0.000 perl              
15576     0 sda1            0     0.000     0.000     0.000          11     0.001     0.001     0.000 perl              
15518     0 sda1            0     0.000     0.000     0.000          11     0.000     0.001     0.000 perl              
15354     0 sda1            0     0.000     0.000     0.000          10     0.053     0.053     0.005 lm_lid.sh
As colunas são:
PID
O ID do processo do aplicativo
UID
o ID de usuário sob o qual o aplicativo está em execução
DEV
o dispositivo no qual a E/S aconteceu
WRITE_CNT
o número total de operações de gravação
WRITE_MIN
o tempo mínimo tomado para 2 gravações consecutivas (em segundos)
WRITE_MAX
o tempo mais longo gasto para duas gravações consecutivas (em segundos)
WRITE_AVG
a média de tempo gasta para duas gravações consecutivas (em segundos)
READ_CNT
o número total de operações de leitura
READ_MIN
o tempo mais curto gasto para duas leituras consecutivas (em segundos)
READ_MAX
o tempo mais long gasto para duas leituras consecutivas (em segundos)
READ_AVG
a média de tempo gasta para duas leituras consecutivas (em segundos)
COMMAND
o nome do processo
neste exemplo, três aplicativos bastante óbvios se sobresaem:
  PID   UID DEV     WRITE_CNT WRITE_MIN WRITE_MAX WRITE_AVG    READ_CNT  READ_MIN  READ_MAX  READ_AVG COMMAND
 2789  2903 sda1          854     0.000   120.000    39.836           0     0.000     0.000     0.000 plasma
 2573     0 sda1           63     0.033  3600.015   515.226           0     0.000     0.000     0.000 auditd
 2153     0 sda1           26     0.003  3600.029  1290.730           0     0.000     0.000     0.000 rsyslogd
Estes três aplicativos possuem um WRITE_CNT maior do que 0, o que significa que eles realizam alguma forma de gravação durante a medida. Destes, o plasma era o ofendedor pior pela principal razão: ele realizava a maior parte das operações de gravação, e é claro, a média de tempo entre gravações era a mais baixa. O Plasma seria então o melhor candidado a investigar se você estivesse preocupado com os aplicativos de energia ineficiente.
Use os comandos strace e ltrace para examinar aplicativos mais de perto, rastreando todas as chamadas de sistema de ID de processo existentes. Neste exemplo, você pode executar:
strace -p 2789
Neste exemplo, o resultado de strace continha um modelo repetitivo a cada 45 segundos que abria o arquivo cache do ícone KDE do usuário para gravação seguido de um fechamento imediato do arquivo novamente. Isto levava à uma gravação física necessária para o disco rígico, pois o metadado do arquivo (principalmente, o tempo de modificação) tinha sido mudado. O reparo final era para evitar aquelas chamadas desnecessárias quando não ocorria nenhuma atualização nos ícones.

2.4. Kit de Ferramenta de Vida da Bateria

O Red Hat Enterprise Linux 6 apresenta o Battery Life Tool Kit (BLTK), um conjunto de tests que simula e analiza a o tempo de vida da bateria e desempenho. O BLTK consegue isto realizando conjuntos de tarefas que estimulam grupos de usuários específicos, tal como um desenvolvedor ou funcionário de escritório e relatando resultados. Embora tenha sido desenvolvido especialmente para testar o desempenho do notebook, o BLTK também pode relatar o desempenho de computadores desktop quando iniciar com a opção -a.
O BLTK permite que você gere cargas de trabalho muito reproduzíveis, que são comparáveis ao uso real de uma máquina. Por exemplo, a carga de trabalho office escreve um texto, corrige, e faz a mesma coisa para uma planilha. Ao rodar um BLTK combinado com um PowerTOP ou qualquer uma das outras ferramentas de análises que você testa se as otimizações que você realizou possuem um efeito quando uma máquina está em uso ao invés de somente em modo ocioso. Como você pode rodar exatamente a mesma carga de trabalho diversas vezes para configurações diferentes, você pode comparar resultados para configurações diferentes.
Instalar BLTK com o comando:
yum install bltk
Executar BLTK com o comando:
bltk workload options
Por exemplo, para executar a carga de trabalho de idle por 120 segundos:
bltk -I -T 120
A carga de trabalho disponível por padrão é:
-I, --idle
sistema está ocioso, para usar como uma base para comparação com outras cargas de trabalho.
-R, --reader
simula documentos de leitura (por padrão com o Firefox)
-P, --player
simula visualizar arquivos de multimídia a partir de um CD ou DVD (por padrão com o mplayer)
-O, --office
simula a edição de documentos com o conjunto OpenOffice.org
Outras opções permitem que você especifique:
-a, --ac-ignore
ignore se a energia AC estiver disponível (necessário para o uso de desktop)
-T number_of_seconds, --time number_of_seconds
o tempo (em segundos) sob o qual o teste é rodado; use esta opção com a carga de trabalho idle
-F filename, --file filename
especifica um arquivo a ser usado por uma carga de trabalho específica, por exemplo, um arquivo para a carga de trabalho player para tocar ao invés de acessar o drive de CD ou DVD.
-W application, --prog application
especifica um aplicativo a ser usado por uma carga de trabalho específica, por exemplo, um browser ao invés de um Firefox para a carga de trabalho do reader
BLTK suporta várias opções mais especializadas. Para detalhes, consulte as páginas man bltk
BLTK grava os resultados que ele gera em um diretório especificado no arquivo de configuração /etc/bltk.conf por padrão, ~/.bltk/workload.results.number/. Por exemplo, o diretório ~/.bltk/reader.results.002/ mantém os resultados do terceiro teste com a carga de trabalho reader (o primeiro teste não é numerado). Os resultados estão espalhados por diversos arquivos texto. Para condensionar estes resultados em um formato que seja fácil de ler, rode:
bltk_report path_to_results_directory
Os resultados agora aparecem em um arquivo texto chamado Report no diretório de resultados. Para visualizar os resultados em um emulador de terminal, use a opção -o:
bltk_report -o path_to_results_directory

2.5. Tuned e ktune

O Tuned é um daemon que monitora o uso de componentes de sistema e ajusta dinamicamente as configurações de sistema baseadas na informação de monitoramento. O ajuste dinâmico significa a forma que diversos componentes de sistema são usados de forma diferentes durante o tempo ativo para qualquer sistema. Por exemplo, o hard drive é usado de forma pesada durante a inicialização e login, mas é raramente usado mais tarde quando um usuário provavelmente estiver trabalhando com aplicativos como o OpenOffice ou clientes de email. Como forma semelhante, os dispositivos da CPU e rede são usados de forma diferentes em momentos diferentes. O Tuned monitora a atividade deste componentes e reage à mudanças em suas formas de uso.
Como exemplo prático, considere uma estação de trabalho de um escritório comum. Na maior parte do tempo, a interface de rede Ethernet estará inativa. Somente alguns emails serão recebidos ou enviados ou algumas páginas da Web podem ser carregadas. Para estes tipos de cargas, a interface de rede não precisa rodar em velocidade total o tempo todo, como é por padrão. O Tuned possui um plugin de monitoramento e ajuste para dispositivos de rede que podem detectar baixa atividade e depois diminuir automaticamente a velocidade da interface, geralmente resultando em menos uso de energia. Se a atividade na interface aumentar drasticamente por um longo período de tempo, por exemplo porque uma imagem de DVD está sendo baixada ou um email recebido com anexos grandes, o tuned irá detectar isto e ajustar a velocidade de interface para o máximo, para oferecer melhor desempenho enquanto o nível de atividade está tão alto. Este princípio é usado para os outros plugins para a CPU e discos rígidos também.
Dispositivos de rede não são configurados para se comportarem desta maneira por padrão, pois a mudança de velocidade pode levar um tempo para ser efetivado e portanto impacta a experiência do usuário diretamente e visivelmente. Considerações semelhantes se aplicam à CPU e plugins de ajuste de hard drive. Quando um hard drive for girado para baixo, pode levar alguns segundos para que volte para cima o que resulta na falta observada de resposta do sistema durante o período. As consequências da latência para o plugin da CPU é a menor possível, mas ainda é ao menos mensurável, embora quase não notável por um usuário.
Junto com o tuned agora também oferecemos o ktune. Ktune foi introduzido no Red Hat Enterprise Linux 5.3 como uma framework e serviço para otimizar o desempenho de uma máquina para casos de uso específicos. Desde então, o ktune tem sido aprimorado até o ponto que nós agora o usamos como parte estática de nossa framework de ajuste geral. É usado principalmente em perfis diferentes pré-definidos descritos em Seção 2.5.2, “Tuned-adm”.
Instalar o pacote tuned e seus scripts associados systemtap com o comando:
yum install tuned
Instalando o pacote tuned você também instala um arquivo de configuração de amostra em /etc/tuned.conf e ativa o perfil de padrão.
Iniciar tuned executando o:
service tuned start
Para iniciar tuned todas as vezes que a máquina inicializa, execute:
chkconfig tuned on
O próprio Tuned possui opções adicionais que você pode usar quando rodar automaticamente. As opções disponíveis são:
-d, --daemon
iniciar tuned como um daemon ao invés de permanente.
-c, --conffile
use o arquivo de configuração com o nome e caminho especificado, por exemplo, --conffile=/etc/tuned2.conf. O padrão é /etc/tuned.conf.
-D, --debug
use o nível mais alto de loggin

2.5.1. O arquivo tuned.conf

O arquivo tuned.conf contém configurações do tuned. Por padrão, está localizado em /etc/tuned.conf, mas você pode especificar um nome diferente e local iniciando o tuned com a opção --conffile.
O arquivo config deve sermpre conter uma seção [main] que define os parâmetros gerais para tuned. O arquivo então contém uma seção para cada plugin.
A seção [main] contém as seguintes opções:
interval
o intervalo no qual o tuned deve monitorar e ajustar o sistema, em segundos. O valor padrão é 10.
verbose
especifica se o resultado deve ser verbosidade. O valor padrão é False.
logging
especifica a prioridade mínima a ser autenticada. Em order decrescente, valores aceitáveis são: critical, error, warning, info, e debug. O valor padrão é info.
logging_disable
especifica prioridade máxima de mensagens a serem autenticadas; qualquer mensagem com esta prioridade ou menor, não será autenticada. Em ordem decrescente, os valores aceitáveis são: critical, error, warning, info, e debug. O valor notset desabilita esta opção.
Cada plugin possui sua própria seção, especificada com o nome do plugin nos colchetes; por exemplo: [CPUTuning]. Cada plugin possui suas próprias opções, mas o seguinte se aplica à todos os plugins:
enabled
especifica se o plugin está ativao ou não. O valor padrão é True.
verbose
especifica se o resultado deve ser verbosidade. Se não for ajustado para este plugin, o valor é herdado de [main].
logging
especifica a prioridade mínima de mensagens a serem autenticadas. Se não for ajustado para este plugin, o valor é herdado de [main].
Um arquivo de configuração de amostra segue:
[main]
interval=10
pidfile=/var/run/tuned.pid
logging=info
logging_disable=notset

# Disk monitoring section

[DiskMonitor]
enabled=True
logging=debug

# Disk tuning section

[DiskTuning]
enabled=True
hdparm=False
alpm=False
logging=debug

# Net monitoring section

[NetMonitor]
enabled=True
logging=debug

# Net tuning section

[NetTuning]
enabled=True
logging=debug

# CPU monitoring section

[CPUMonitor]
# Enabled or disable the plugin. Default is True. Any other value
# disables it.
enabled=True

# CPU tuning section

[CPUTuning]
# Enabled or disable the plugin. Default is True. Any other value
# disables it.
enabled=True

2.5.2. Tuned-adm

Ás vezes, uma auditoria detalhada e análise de um sistema, pode ser consumir muito de seu tempo e pode não compensar os watts extras que você terá que economizar para fazê-lo. Antes, a única alternativa era simplesmente usar o padrão. Por tanto, o Red Hat Enterprise Linux 6 inclui perfil separado para casos de uso específico como alternativa entre aqueles dois extremos, juntos com a ferramenta tuned-adm que permite que você mude entre estes perfis facilmente na linha de comando. O Red Hat Enterprise Linux 6 inclui diversos perfis pré-definidos para casos de uso comum que você pode simplesmente selecionar e ativar com o comando tuned-adm, mas você mesmo também pode criar, modificar ou remover perfis.
Para listar todos os perfis disponíveis e identificar o perfil ativo atual, execute:
tuned-adm list
Para exibir somente o perfil ativo atual, execute:
tuned-adm active
Para mudar para um perfil disponível, execute:
tuned-adm profile profile_name
por exemplo:
tuned-adm profile server-powersave
Para desabilitar todos os ajustes:
tuned-adm off
Quando você iniciar a instalação do tuned, o perfil default será ativado. O Red Hat Enterprise Linux 6 também inclui os seguintes perfis pré-definidos:
padrão
o perfil de economia de energia padrão. Ele causa meno impacto na economia energia de perfis disponíveis e somente habilita a CPU e plugin de disco do tuned.
desktop-powersave
o perfil de economia de energia direcionado por sistemas de desktop. Habilita a economia de energia ALPM para adaptadores de host SATA (consulte o Seção 3.6, “Aggressive Link Power Management (Gerenciamento de Energia de Conexão Agressiva)”) assim como a CPU, Ethernet, e plugins de disco de tuned.
server-powersave
o perfil de economia de energia direcionado ao sistema de servidor. Habilita a economia de energia ALPM para adaptadores de host SATA, desabilita poll de CD-ROM através do HAL (consulte a página man do hal-disable-polling ) e ativa os plugins de CPU e disco do tuned.
laptop-ac-powersave
um perfil de economia de energia de médio impacto direcionado à laptops rodando em AC. Habilita a economia de energia do ALPM para adaptadores de host SATA, economia de energia do WiFi, como também a CPU, Ethernet e plugin de disco do tuned.
laptop-battery-powersave
Um perfil de economia de energia de alto impacto em laptops funcionando a bateria. Ele ativa todos os mecanismos de economia de energia desde perfis anteriores e também habilita o agendador de economia de energia de núcleos múltiplos para sistemas de ativamento baixo e certifica-se de que o governador ondemand está ativo e que o AC97 de economia de energia audio está habilitado. Você pode usar este perfil para economizar o máximo de quantia de energia de qualquer tipo de sistema, e não somente de laptops rodando em energia de bateria. O benefício desde perfil é um impacto notável no desempenho, especialmente latência do disco e rede E/S.
throughput-performance
um perfil de servidor para ajuste de desempenho total típico. Ele desabilita o tuned e os mecanismos de economia de energia do ktune, habilita a configuração do sysctl que aprimora o desempenho total de seu disco e rede de E/S, e muda para o agendador de deadline.
latency-performance
um perfil de servidor para um ajuste de desempenho de latência típica. Ele desabilita o tuned e ktuneas máquinas de economia de energia e habilita as configurações do sysctl, a qual melhora o desempenho de latência de sua E/S de rede.
Todos os perfis são armazenados em subdiretórios separados sob o /etc/tune-profiles. Portanto o /etc/tune-profiles/desktop-powersave contém todos os arquivos necessários e configurações para este perfil. Cada um destes diretórios contém até quatro arquivos:
tuned.conf
a configuração para o serviço tuned a ser ativado para este perfil.
sysctl.ktune
A configuração do sysctl usado por ktune. O formato é idêntico ao arquivo /etc/sysconfig/sysctl (consulte o sysctl e páginas man do sysctl.conf).
ktune.sysconfig
o arquivo de configuração do ktune, geralmente /etc/sysconfig/ktune.
ktune.sh
um script de shell estilo init usado pelo serviço ktune que pode rodar comandos específicos durante a inicialização do sistema para ajustar o sistema.
A forma mais fácil de iniciar um novo perfil é copiando um já existente. O perfil laptop-battery-powersave irá conter um conjunto rico de ajustes e é portanto um ponto de início bastante útil. Simplesmente copie todo o diretório para o nome do novo perfil como este:
cp -a /etc/tune-profiles/laptop-battery-powersave/ /etc/tune-profiles/myprofile
Modifique qualquer um dos arquivos no perfil novo para coincidir com seus requerimentos pessoais. Por exemplo, se você deseja a detenção de mudanças de CD você pode desabilitar esta otimização retirando o comentário na linha apropriada no script do ktune.sh:
# Disable HAL polling of CDROMS
# for i in /dev/scd*; do hal-disable-polling --device $i; done > /dev/null 2>&1

2.6. DeviceKit-power e devkit-power

No Red Hat Enterprise Linux 6 o DeviceKit-power entende que as funções de gerenciamento de energia que foram parte do HAL e de algumas das funções que foram parte do GNOME Power Manager em versões anteriores do Red Hat Enterprise Linux (consulte também o Seção 2.7, “GNOME Power Manager”). O DeviceKit-power fornece um daemon, um API e um conjunto de ferramentas de linha de comando. Cada fonte de energia no sistema é representada como um dispositivo, seja ele um dispositivo físico ou não. Por exemplo, uma bateria de laptop e uma fonte de energia a cabo são representadas como dispositivos.
Você pode acessar as ferramentas da linha de comando com o comando devkit-power e as seguintes opções:
--enumerate, -e
exibe um caminho do objeto para cada dispositivo de energia no sistema, por exemplo:
/org/freedesktop/DeviceKit/power/devices/line_power_AC
/org/freedesktop/UPower/DeviceKit/power/battery_BAT0
--dump, -d
exibe os parâmetros para todos os dispositivos de energia no sistema.
--wakeups, -w
exibe o ativamento da CPU no sistema.
--monitor, -m
monitora o sistema para mudanças nos dispositivos de energia, por exemplo, a conexão e disconexão de uma fonte de energia a cabo ou desconexão de uma bateria. Pressione Ctrl+C para parar o monitoramento do sistema.
--monitor-detail
monitora o sistema para mudanças nos dispositivos de energia, por exemplo, a conexão e desconexão de uma fonte de energia a cabo, ou desconexão de uma bateria. A opção --monitor-detail apresenta mais detalhes do que a opção --monitor. Pressione Ctrl+C para parar o monitoramento do sistema.
--show-info object_path, -i object_path
exibe todas as informações disponíveis para um caminho do objeto específico. Por exemplo, para obter informações sobre uma bateria em seu sistema representada pelo caminho do objeto /org/freedesktop/UPower/DeviceKit/power/battery_BAT0, execute:
devkit-power -i /org/freedesktop/UPower/DeviceKit/power/battery_BAT0

2.7. GNOME Power Manager

GNOME Power Manager é um daemon que foi instalado como parte do desktop GNOME. A maioria da funcionalidade do gerenciamento de energia que o GNOME Power Manager fornecia nas versões anteriores do Red Hat Enterprise Linux, se tornou parte do DeviceKit-power no Red Hat Enterprise Linux 6 (consulte o Seção 2.6, “DeviceKit-power e devkit-power”. Entretanto, o GNOME Power Manager mantém-se linha de frente para esta função. Através de um applet na bandeja do sistema, GNOME Power Manager o notifica sobre as mudanças em no status de energia do seu sistema, por exemplo, uma mudança de bateria para fornecimento de energia AC. Ele também reporta o status da bateria, e avisa-o quando a energia da bateria estiver baixa.
GNOME Power Manager também permite que você configure algumas configurações de gerenciamento de energia básica. Para acessar estas configurações, clique em GNOME Power Manager na bandeja do sistema, e depois clique em Preferências
A tela Power Management Preferences contém três abas:
  • Com energia a cabo
  • Com energia de bateria
  • Geral
Use as abas de Com energia a cabo e Com Energia de Bateria para especificar quanto tempo deve levar para que a exibição seja desligaada em um sistema inativo, quanto tempo dev levar para que um sistema inativo entre em modo de espera, e se o sistema deve girar os discos rígidos quando não estiver em uso. A aba Com Energia de Bateria também permite que você estabeleça o brilho da exibição e escolha um comportamento para um sistema com bateria extremamente baixa. Por exemplo, por padrão, o GNOME Power Manager hiberna um sistema quando seu nível de bateria alcança um nível extremamente baixo. Use a aba Geral para definir comportamentos para o botão de energia (físico) e suspender o botão em seu sistema, e para especificar as circunstâncias sob a qual o ícone do GNOME Power Manager deva aparecer na bandeja do sistema.e

2.8. Outras razões para auditoria

Red Hat Enterprise Linux 6 fornece algumas outras ferramentas com o qual realiza auditoria e análise de sistema. A maioria deles pode ser usado como fontes suplementares de informações caso deseje verificar o que você já descobriu ou caso precise de mais informações detalhadas em certas partes. Muitas destas ferramentas são usadas para realizar ajuste também. Estas incluem:
vmstat
O vmstat lhe fornece informações detalhadas sobre o processo, memória, paginação, bloco E/S, obstáculos e atividade de CPU. Use isto para observar de perto o que a visão geral do sistema faz e onde fica ocupado.
iostat
iostat é semelhante ao vmstat, mas somente para E/S nos dispositivos de bloco. Ele também fornece resultado de verbosidade e estatística.
blktrace
blktraceé um programa de rastreamento de E/S de bloco detalhado. Ele quebra as informações em blocos individuais associados aos aplicativos. É muito útil se usado com diskdevstat.

Capítulo 3. Infraestrutura do Núcleo e Mecânica

3.1. Estados Ociosos de CPU

As CPUs com a arquitetura x86, suporta diversos estados cujas partes da CPU são desativadas ou executam em configuração de desempenho mais baixo. Estes estados, conhecidos como C-states, permitem que os sistemas economizem energia desativando parcialmente as CPUs que não estiverem sendo usadas. Os C-states são numerados a partir do C0 para cima, com números mais algos representando uma diminuição no funcionamento da CPU e maior economia de energia. Os C-States de um número específico são semelhantes em todos os processadores, embora os detalhes exatos de um conjunto de recursos específicos de um estado possa variar entre as famílias de processadores. O siginificado de C-State 0-3 é definido como a seguir:
C0
o estado em execução ou em operação. Neste estado, a CPU está funcionando e não fica em ocioso em nenhum momento.
C1, Halt
um estado onde o processador não está executando nenhuma instrução mas geralmente não se encontra em um estado de energia baixo. A CPU pode continuar processando com praticamente nenhum atraso. Todos os processadores que oferecem o C-States precisam suportar este estado. Os processadores Pentium 4 suportam um estado C1 aprimorado chamado C1E que na verdade é um estado para consumo de energia mais baixo.
C2, Stop-Clock
um estado onde o relógio é congelado para este procesador, mas mantém o estado completo para seus registradores e caches, portanto depois que o relógio reinicia ele pode iniciar a processar imediatamente. Este é um estado opcional.
C3, Espera
um estado onde o processador realmente fica em modo de espera e não precisa manter seu cache atualizado. Acordar deste estado demora um pouco mais do que o C2 por esta razão. Este também é um estado opcional.
As CPUs Intel recentes com a microarquitetura "Nehalem" apresentam um novo C-State, C6, o qual pode reduzir a zero o fornecimento de voltagem de uma CPU, mas geralmente reduz o consumo de energia entre 80% a 90%. O kernel em Red Hat Enterprise Linux 6 inclui otimizações para este novo C-State.

3.2. Usando os Governadores CPUfreq

Uma das formas mais efetivas de reduzir o consumo de energia e aquecer resultado em seu sistema, é usando o CPUfreq. O CPUfreq, também conhecido como escalamento de velocidade de CPU, permite que a velocidade do relógio do processador seja ajustada imediatamente. Isto permite que o sistema rode em uma velocidade de relógio reduzida para economizar energia. As regras para mudar as frequências, para mais rápido ou mais devagar, e quando as frequências mudam, são definidas pelo governador da CPUfreq.
O governador define as características de energia da CPU do sistema, o qual por sua vez afeta o desempenho da CPU. Cada governador possui seu próprio e único comportamento, propósito e adequação em relação à carga de trabalho. Esta seção descreve como escolher e configurar um governador de CPUfreq, as características de cada governador, e para qual o tipo de carga de trabalho cada governador está adequado.
A maior preocupação no gerenciamento de energia é:
  • Redução de aquecimento para servidores
  • Extendendo a vida da bateria para laptops
Como via de regra, a diminuição do consumo de energia de um componente específico (ou de um sistema como um todo) levará ao aquecimento e naturalmente ao desempenho. Como tal, você deve estudar profundamente e testar a diminuição do desempenho exata para qualquer configuração realizada, especialmente para sistemas de missão crítica.
As seções a seguir explicam como o desempenho de hardware optimal beneficia seu sistema em relação ao consumo de energia.

3.2.1. Tipos de CPUfreq Governor

Esta seção lista e descreve os tipos diferentes de governadores de CPUfreq disponíveis no Red Hat Enterprise Linux 6.
cpufreq_performance

O governador de Desempenho força a CPU a usar a frequência de relógio mais alta possível. Esta frequencia ajustará estaticamente, e não mudará. Como tal, este governador em particular não oferece nenhum benefício de economia de energia. Funciona somente por algumas horas de carga de trabalho e mesmo assim somente durante as horas que a CPU estiver raramente (ou nunca) em ocioso.

cpufreq_powersave

Por contraste, o governador do Powersave força a CPU a usar a frequência de relógio mais baixa possível. Esta frequencia será ajustada estaticamente, e não mudará. Como tal, este governador específico oferece economia máxima de energia, mas ao cuso de menor desempenho de CPU

O termo "powersave" pode enganar as vezes, pois originalmente uma CPU lenta em carga total consome mais energia do que uma CPU rápida que não é carregada. Como tal, embora possa ser aconselhável ajustar a CPU para usar o governador Powersave durante horários de atividades baixa, qualquer carga alta inesperada durante estas horas pode causar um consumo de mais energia.
O governador Powersave é mais um "limitador de velocidade" para a CPU do que um "economizador de energia". É mais útil em sistemas e ambientes onde o super-aquecimento pode ser um problema.
cpufreq_ondemand

O governador Ondemand é um governador dinâmico que permite que a CPU alcance a frequência máxima de relógio quando a carga do sistema for alta, e também uma frequência mínima de relógio quando o sistema estiver ocioso. Embora isto permita que o sistema ajuste o consumo de energia de acordo com o requisitado, quanto à carga do sistema, ele faz isto ao cuso de latência entre a mudança de frequência. Como tal, a latência pode ativar qualquer benefício de economia de desempenho/energia pelo governador Ondemand se o sistema mudar entre ocioso e cargas de trabalho pesadas com muita frequência.

Para a maioria dos sistemas, o governador Ondemand pode fornecer um melhor comprometimento entre a emissão de aquecimento, consumo de energia, desempenho, e gerenciabilidade. Quando o sistema está somente ocupado durante algumas horas específicas do dia, o governador Ondemand irá mudar automaticamente entre a frequência máxima e mínima, dependendo da carga sem qualquer intervenção futura.
cpufreq_userspace

O governador Userspace permite que programas do userspace (ou qualquer processo que estiver rodando como root) ajuste a frequência. Este governador é geralmente usado junto com o daemon cpuspeed. Entre todos os governadores, o Userspace é o mais padronizável, e dependendo de como ele é configurado, ele pode oferecer o melhor equilíbrio entre o desempenho e consumo para seu sistema.

cpufreq_conservative

Como o governador Ondemand, o governador Conservativo também ajusta a frequência do relógio de acordo com o uso (como o governador Ondemand). No entanto, enquanto o governador Ondemand o faz de forma mais agressiva, (ou seja, do máximo para o mínimo e de volta ao máximo), o governador Conservative muda entre as frequências mais gradualmente.

Isto significa que o governador Conservative irá ajustar uma frequência de relógio que está destinada a suprir para a carga, ao invés de simplesmente escolher entre o máximo e mínimo. Embora isto possa fornecer muita economia no consumo de energia, ele o faz em uma latência ainda maior do que o governador Ondemand.

Nota

Você pode habilitar um governador usando os trabalhos cron. Isto permite que você ajuste automaticamente governadores específicos durante horas específicas do dia. Como tal, você pode especificar um governador de baixa frequência durante horas ociosas (por exemplo após horário comercial) e retornar para um governador de alta frequência em horários de carga de trabalho pesada.
Para instruções sobre como ativar um governador específico, consulte o Procedimento 3.2, “Habilitando um Governador de CPUfreq” in Seção 3.2.2, “Configuração do CPUfreq”.

3.2.2. Configuração do CPUfreq

Antes de selecionar e configurar o governador do CPUfreq, você precisa adicionar o driver CPUfreq adequado primeiro.

Procedimento 3.1. Como adicionar um Driver CPUfreq

  1. Use o seguinte comando para visualizar quais drivers do CPUfreq estão disponíveis para seu sistema:
    ls /lib/modules/[kernel version]/kernel/arch/[architecture]/kernel/cpu/cpufreq/
  2. Use o modprobe para adicionar o driver CPUfreq adequado.
    modprobe [CPUfreq driver]
    Ao usar o comando acima, tenha a certeza de remover o sufixo do nome de arquivo .ko.

    Importante

    Ao escolher um driver CPUfreq, sempre escolha o acpi-cpufreq ao invés do p4-clockmod. Pois apesar do uso do driver p4-clockmod reduzkir a frequência do relógio de uma CPU, ele não reduz a voltagem. Por outro lado, o acpi-cpufreq, reduz a voltagem com a frequência do relógio da CPU, permitindo menos consumo de energia e aquecimento de resultado para cada redução de unidade sendo realizada.
  3. Depois que o CPUfreq estiver instalado, você pode visualizar qual governador o sistema está usando atualmente:
    cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
Você também pode visualizar quais governadores estão disponíveis para uso para um CPU específico usando:
cat /sys/devices/system/cpu/[cpu ID]/cpufreq/scaling_available_governors
Alguns governadores de CPUfreq podem não estar disponíveis para que você utilize. Neste caso, use o comando modprobe para adicionar os módulos de kernel necessários, os quais habilitam o governador de CPUfreq específico que você deseja usar. Estes módulos de kernel estão disponíveis no /lib/modules/[kernel version]/kernel/drivers/cpufreq/.

Procedimento 3.2. Habilitando um Governador de CPUfreq

  1. Se um governador específico não estiver listado como disponível para sua CPU, use o modprobepara habilitar o governador que você deseja usar. Por exemplo, se o governador ondemand não estiver disponível para sua CPU, use o seguinte comando:
    modprobe cpufreq_ondemand
  2. Depois que um governador for listado como disponível para sua CPU, você pode habilitá-lo usando:
    echo [governor] > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

3.2.3. Ajustando Política e Velocidade do CPUfreq

Depois que você escolheu um governador do CPUfreq adequado, você pode ajustar a velocidade de cada CPU usando os tunables encontrados em /sys/devices/system/cpu/[cpu ID]/cpufreq/. Estes tunables são:
  • cpuinfo_min_freq — Mostra a frequência de operação mínima disponível da CPU (em KHz).
  • cpuinfo_max_freq — Mostra a frequência operacional máxima disponível da CPU (em KHz)
  • scaling_driver — Mostra qual o driver da CPUfreq é usada para ajustar a frequência nesta CPU.
  • scaling_available_governors — Mostra os governadores da CPUfreq disponíveis neste kernel. Se você quiser usar um governador do CPUfreq que não esteja listado neste arquivo, consulte o Procedimento 3.2, “Habilitando um Governador de CPUfreq” in Seção 3.2.2, “Configuração do CPUfreq” para obter instruções sobre como fazer isto.
  • scaling_governor — Mostra que o governador da CPU freq está em uso. Para usar um governador diferente, simplesmente use echo [governor]> /sys/devices/system/cpu/[cpu ID]/cpufreq/scaling_governor (consulte Procedimento 3.2, “Habilitando um Governador de CPUfreq” em Seção 3.2.2, “Configuração do CPUfreq” para obter mais informações.)
  • cpuinfo_cur_freq — Mostra a velocidade atual da CPU (em KHz).
  • scaling_available_frequencies — Lista frequencias disponíveis para a CPU em KHz.
  • scaling_min_freq e scaling_max_freq — Ajusta a política de policy limits da CPU, em KHz.

    Importante

    Ao ajustar os limites de políticas, você deve ajustar o scaling_max_freq antes scaling_min_freq.
  • affected_cpus — Lista CPUs que requerem software de coordenação de frequência.
  • scaling_setspeed — Usado para modificar a velocidade do relógio da CPU, em KHZ. Você pode ajustar uma velocidade dentro dos limites de política da CPU (como scaling_min_freq e scaling_max_freq).
Para visualizar o valor atual de cada ajustável, use o comando cat [tunable]. Por exemplo, para visualizar a velocidade atual de cpu0 (em KHZ), use:
cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq.
Para mudar o valor de cada ajustável, use echo [value]> /sys/devices/system/cpu/[cpu ID]/cpufreq/[tunable]. por exemplo, para ajustar a velocidade mínima de relógio da cpu0 para 360 KHZ, use:
echo 360000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq

3.3. Suspender e Resumir

Quando um sistema é suspenso, o kernel chama em drivers para armazenar seus estados e depois descarregá-los. Quando o sistema é fechado, ele recarrega estes drivers, o qual tenta reprogramar seus dispositivos. A habilidade dos drivers de concluir esta tarefa determina se o sistema pode ser resumido com sucesso.
Os drivers de vídeo são particularmente problemáticos neste campo, pois as especificações do Interface de Energia e Configuração Avançada (ACPI) não requer que o firmware de sistema seja capaz de reprogramar o hardware do vídeo. Portanto, a menos que os drivers de vídeo sejam capazes de programar o hardware de um estado inicializado completamente, eles podem evitar que o sistema resuma.
O Red Hat Enterprise Linux 6 inclui maior suporte para novos chipsets de gráficos, o qual certifica que a suspensão e resumo irão funcionar em números maiores de plataformas. Especialmente, suporte para NVIDIA chipsets foram altamente aprimorados; especialmente as séries GeForce 8800

3.4. Kernel sem Tick

Anteriormente, o kernel do Linux interrompia periodicamente cada CPU em um sistema em uma frequência pré-determinada, 100 Hz, 250 Hz ou 1000 Hz, dependendo da plataforma. O kernel pesquisava a CPU sobre os processos que estava executando, e usava os resultados para a contabilidade do processo e carregamento de balanceamento. Conhecido como o timer tick, o kernel realizava esta interrupção não importando o estado de energia da CPU. Portanto, até uma CPU ociosa estava respondendo a até 1000 destas requisições a cada segundo. Em sistemas que a economia de energia implementada mede o estado ocioso das CPUs, o timer tick evitou que a CPU ficasse ociosa por muito tempo para que o sistema se beneficiasse desta economia de energia.
O kernel em Red Hat Enterprise Linux 6 executa o tickless: ou seja, ele substitui as interrupções de timer antigo periódico pelas interrupções sob demanda. Assim, as CPUs ociosas podem ficar em seu estado até a próxima tarefa entrar em fila para processamento, e as CPUs que inserirem estados de energia podem ficar nestes estados mais tempo.

3.5. Active-State Power Management (Gerenciamento de Energia de Estado Ativo)

Active-State Power Management (ASPM) economiza energia no subsistema Peripheral Component Interconnect Express (PCI Express or PCIe) configurando um estado de energia para os links PCIe quando os dispositivos ao qual eles se conectam não estiverem sendo usados. O ASPM controla o estado de energia nos dois lados do link, e economiza energia no link até mesmo quando o dispositivo no final do link estiver em um estado totalmente ligado.
Quando o ASPM estiver habilitado, a latência do dispositivo aumenta porcausa o tempo requerido para a transição do link entre estados de energia diferentes. O ASPM possui três políticas para determinar os estados de energia:
padrão
ajusta os estados do link do PCle de acordo com os padrões especificados pelo firmware no sistema (por exemplo, BIOS). Este é o estado padrão para ASPM.
powersave
ajusta o ASPM para economizar energia onde for possível, não importando o custo de desempenho.
desempenho
desabilita o ASPM para permitir que os links do PCle operem com o máximo de desempenho.
As políticas do ASPM são configuradas em /sys/module/pcie_aspm/parameters/policy, mas também podem ser especificadas durante a inicialização com o parâmetro do kernel pcie_aspm onde o pcie_aspm=off desabilita o ASPM pcie_aspm=force habilita o ASPM, até mesmo em dispositivos que não suportam o ASPM.

Atenção

Se pcie_aspm=force estiver ativado, o hardware que não suporta o ASPM pode fazer com que sistemas parem de responder. Antes de configurar o pcie_aspm=force, certifique-se que o hardware do PCle no sistema suporta o ASPM.

3.6. Aggressive Link Power Management (Gerenciamento de Energia de Conexão Agressiva)

Aggressive Link Power Management (ALPM) é uma técnica de economia de energia que ajuda o disco a economizar energia configurando a conexão do SATA no disco para uma configuração de baixa energia durante os horários ociosos (ou seja, quando não houver Entrada/Saída). O ALPM ajusta automaticamente a conexão SATA de volta para o estado de energia ativa, depois que as requisições de Entrada/Saída são enfileiradas nesta conexão.
A economia de energia apresentada pelo ALPM vem a custo de latência de disco. Como tal, deve ser usado somente se você espera que o sistema fique longo tempo em E/S ociosa.
O ALPM está disponível somente nos controladores SATA que usam o Advanced Host Controller Interface (AHCI). Para mais informações sobre o AHCI, consulte http://www.intel.com/technology/serialata/ahci.htm.
Quando disponível, o ALPM é ativado por padrão. O ALPM possui três modos:
min_power

Este modo configura a conexão com seu estado de energia mais baixo (SLUMBER) quando não há E/S no disco. Este modo é útil para as horas que se espera ter um longo período de tempo em ocioso.

medium_power

Este modo configura a conexã para o segundo estado de energia mais baixo (PARTIAL) quando não houver E/S no disco. Este modo é designado para permitir transações na conexão de estados de energia ( por exemplo durante as horas de E/S pesadas intermitentes e ociosa) com impacto tão pequeno no desempenho quanto for possível.

O modo medium_power permite a conexão de transição entre PARTIAL e totalmente com energia (ou seja "ACTIVE"), dependendo da carga. Observe que não é possível transitar um link diretamente de PARTIAL para SLUMBER e retornar. Neste caso, ambos estados de energia não podem transitar para outro sem transitarem através do estado ACTIVE primeiro.
max_performance

O ALPM está desativado, o link não insere nenhum estado de baixa energia quando não houver E/S no disco.

Para avalizar se os adaptadores do host SATA suportam o ALPM você pode verificar se o arquivo /sys/class/scsi_host/host*/link_power_management_policy existe. Para modificar as configurações simplesmente grave os valores descritos nesta seção nestes arquivos ou exiba os arquivos para checar a configuração atual.

Importante

Ao configurar o ALPM para min_power ou medium_power irá desabilitar automaticamente o recurso "Hot Plug".

3.7. Otimização de Acesso de Drive Relatime

O POSIX padrão requer que os sistemas operacionais mantenham o metadados de sistema de arquivo que gravam quando cada arquivo foi acessado. Este carimbo de data e hora é chamado de atime, e mantê-lo requer uma série constante de operações de gravações para armazenamento. Estas gravações mantém os dispositivos de armazenamento e seus links ocupados e ligados. Como alguns aplicativos fazem uso dos dados atime, esta atividade do dispositivo de armazenamento gasta energia. A gravação do armazenamento ocorreria mesmo se o arquivo não fosse lido pelo armazenamento, mas pelo cache. Durante algum tempo, o kernel do Linux suportou uma opção noatime para mount e não gravaria os dados do atime em sistemas de arquivo montados com esta opção. No entanto, desligar este recurso seria problemático pois alguns aplicativos contam com os dados do atime e falharão caso não esteja disponível.
O kernel usado no Red Hat Enterprise Linux 6 suporta outra alternativa, relatime. Relatime mantém dados do atime , mas não para cada vez que um arquivo é acessado. Com esta opção habilitada, os dados do atime são gravados no disco somente se um arquivo foi modificado desde que os dados do atime tenham sido atualizados (mtime), ou se o arquivo foi acessado pela última vez mais de um certo período de tempo atrás (por padrão, um dia).
Por padrão, todos os sistemas de arquivos são montados agora com o relatime habilitado. Para omitir este recurso em todo o sistema, use o parâmetro de inicialização default_relatime=0. Se relatime estiver ativado em um sistema por padrão, você pode omití-lo de qualquer sistema de arquivo específico montando aquele sistema de arquivo com a opção norelatime. Finalmente, para variar o período de tempo padrão antes do qual o sistema irá atualizar dados do atime de arquivo, use o parâmetro de inicialização relatime_interval= especificando o período em segundos. O valor padrão é 86400.

3.8. Planejamento de Energia

O Red Hat Enterprise Linux 6 suporta os recursos do planejamento de energia encontrado em hardwares recentes, tal como as tecnologias HP Dynamic Power Capping (DPC), e Intel Node Manager (NM). O Planejamento de Energia permite que os administradores limitem o consumo de energia por servidores, mas ele também permite que os gerentes planejem centros de dados de forma mais eficiente, pois o risco de sobrecarga no fornecimento de energia é muito diminuido. Os gerenciadores podem colocar mais servidores dentro de um local físico e ter certeza de que se o consumo de energia do servidor aumentar, a demanda de energia durante a carga pesada não excederá a energia disponível.
HP Dynamic Power Capping

O Dynamic Power Capping é um recurso disponível ao selecionar os servidores ProLiant e BladeSystem que permitem que os administradores de sistema planejem o consumo de energia de um servidor ou um grupo de servidores. O 'cap' ou planejamento, é um limite definitivo que o servidor não irá exceder, não importando sua carga de trabalho atual. Neste ponto, um processador de gerenciamento ajusta a CPU P-states e controle de fluxo do relógio para limitar a energia consumida.

Dynamic Power Capping (Planejamento de Energia Dinâmico) modifica o comportamento da CPU independentemente do sistema operacional, no entanto, o firmware do integrated Lights-Out 2 (iLO2) da HP, permite que os sistemas operacionais acessem o processador de gerenciamento e portanto aplicativos no espaço do usuário podem pesquisar o processador de gerenciamento. O kernel usado em Red Hat Enterprise Linux 6 inclui um driver para HP iLO e iLO2 firmware, o qual permite programas pesquisarem os processadores de gerenciamento em /dev/hpilo/dXccbN. O kernel também inclui uma extensão da interface hwmon sysfs para suportar o planejamento de energia, e um driver hwmon para medidores de energia ACPI 4.0 que usam a interface sysfs. Juntos estes recursos permitem que o sistema operacional e ferramentas de espaço de usuário leiam o valor configurado para o plano de energia, junto como o uso de energia atual do sistema.
Para maiores detalhes sobre o HP Dynamic Power Capping, consulte HP Power Capping and HP Dynamic Power Capping for ProLiant Servers, disponível em http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01549455/c01549455.pdf
Gerenciador de Nó Intel

O Gerenciador de Nó impõe um plano de energia em sistemas, usando o processador P-states e T-states para limitar o desempenho da CPU e portanto o consumo de energia. Ao ajustar a política de gerenciamento de energia, os adminstradores podem configurar os sistemas para consumir menos energia nas vezes que as cargas de sistema forem baixas, por exemplo, a noite ou aos finais de semana.

O gerenciador de Nó da Intel ajusta o desempenho da CPU usando o Operating System-directed configuration and Power Management (OSPM) através do Advanced Configuration and Power Interface padrão. Quando o Gerenciador de Nó da Intel notificar o driver OSPM das mudanças para T-states, o driver faz mudanças correspondentes para o processador P-states. Da mesma forma, quando o Gerenciador de Nó da Intel notifica o driver do OSPM de mudanças para o P-states, o driver muda o T-states. Estas mudanças acontecem automaticamente e não requerem inserção futura de sistema operacional. Os administradores configuram e monitoram o Gerenciador de Nó da Intel com o software Intel Data Center Manager (DCM).
Para maiores detalhes sobre o Gerenciador de Nó da Intel, consulte o Node Manager — A Dynamic Approach To Managing Power In The Data Center, disponível em http://communities.intel.com/docs/DOC-4766

3.9. Gerenciamento de Energia de Gráficos Aprimorado

Red Hat Enterprise Linux 6 economiza energia em gráficos e exibe dispositivos eliminando diversas fontes de consumo desnecessário.
LVDS reclocking

Sinalização de diferencial de baixa voltagem (LVDS) é um sistema para carregar sinais eletrônicos sob fio de cobre. Um aplicativo bastante importante do sistema é transmitir informações de pixel para telas de exibição de cristal líquido (LCD) em computadores notebook. Todas as exibições possuem uma taxa de atualização - a taxa na qual eles recebem dados novos de controlador de gráfico e redefine a imagem na tela. Geralmente, a tela recebe dados novos sessenta vezes por segundo (uma frequência de 60 Hz). Quando uma tela e controlador de gráfico são ligados por LVDS, o sistema de LVDS usa a energia em todos os ciclos de atualização. Quando estiver ocioso, a taxa de atualização de muitas telas de LCD podem cair para 30 Hz sem qualquer efeito notável (diferente de monitores tubo de raio catodo (CRT), onde uma diminuição da taxa de atualização produz um estado característico). O driver para adaptadores de gráficos Intel embutidos no kernel usados em Red Hat Enterprise Linux 6 realiza este downclocking automaticamente, e economiza por volta de 0.5 W quando a tela está em ociosa.

Habilitando a auto atualização de memória

Memória de acesso aleatório de dinâmica síncrona (SDRAM) - como usado para memória de vídeo em adaptadores de gráficos, é recarregado mil vezes por segundo para que as celulas de memória individuais retenham os dados que estão armazenados neles. Fora a função principal de gerenciamento de dados como ele flui para dentro e para fora da memória, o controlador de memória é geralmente responsável por iniciar estes ciclos de atualização. No entanto, SDRAM também possui uma baixa energia de modo auto atualização. Neste modo, a memória usa um timer interno para gerar seus próprios ciclos de atualização, o qual permite que o sistema feche o controlador de memória sem colocar os dados em risco, atualmente mantidos na memória. O kernel usado no Red Hat Enterprise Linux 6 pode disparar a atualização automática de memória nos adaptadores de gráficos da Intel quando estiverem em ociosos, o qual economizará por volta de 0.8 W.

Redução de GPU clock

As Unidades de processamento gráfico típica ou GPUs, contém relógios internos que governam diversas partes de seu circuito interno. O kernel usado no Red Hat Enterprise Linux 6 pode reduzir a frequência de alguns dos relógios internos na Intel e ATI GPUs. Reduzir o número de ciclos que os componentes GPU realizam em um dado momento, economiza a energia que eles teria consumido nos ciclos que eles não tiveram que funcionar. O kernel automaticamente reduz a velocidade destes relógios quando o GPU estiver ocioso, e aumenta quando a atividade do GPU aumentar. Reduzir os ciclos de relógio do GPU pode economizar até 5 W.

Baixa de energia do GPU

Os gráficos da Intel e ATI no Red Hat Enterprise Linux 6 podem detectar quando não houver monitor anexado à um adaptador e portanto fechar o GPU completamente. Este recurso é importante especialmente para servidores que não possuem monitores anexados à eles regularmente.

3.10. RFKill

Muitos sistemas de computadores contém transmissores de rádio, incluindo Wi-Fi, Bluetooth, e 3G. Estes dispositivos consomem energia, a qual é desperdiçada quando o dispositivo não está em uso.
O RFKill é um subsistema no kernel do Linux que fornece uma interface através do qual os transmissores de rádio em um sistema de computador podem ser pesquisados, ativados, desativados. Quando os transmissores são desativados, eles podem ser colocados em um estado onde o software pode reativá-los ( um soft block) ou onde o software não pode reativá-los (um hard block).
O RFKill core fornece uma interface de programação de aplicativo (API) para subsistema. Os drivers do kernel que foram designados para suportar o RFkill usam este registro do API com o kernel, e inclui métodos para ativar e desativar o dispositivo. Além disso, o RFKill core fornece notificações que os aplicativos de usuários podem interpretar de formas para aplicativos de usuários pesquisarem os estados de transmissores.
O RFKill interface está localizado em /dev/rfkill, o qual contém o estado atual de todos os trasmissores de rádio no sistema. Cada dispositivo possui seu estado de RFKill registrado em sysfs. Além disso, o RFKill emite o uevents para cada mudança de estado em um dispositivo do RFKill ativado.
O Rfkill é uma ferramenta de linha de comando com a qual você pode pesquisar e mudar os dispositivos ativados do RFKill no sistema. Para obter a ferramenta, instale o pacote rfkill.
Use o comando rfkill list para obter uma lista de dispositivos, cada uma possui um index numberassociado à ele, iniciando como 0. Você pode usar este número de índice para informar o rfkill para bloquear ou desbloquear um dispositivo, por exemplo:
rfkill block 0
bloqueia o primeiro dispositivo habilitado do RFKill no sistema.
Você também pode usar o rfkill para bloquear certas categorias de dispositivos ou todos os dispositivos habilitados do RFKill. Por exemplo:
rfkill block wifi
bloqueia todos os dispositivos do Wi-Fi no sistema. Para bloquear todos os dispositivos habilitados do RFKill, execute:
rfkill block all
Para desbloquear os dispositivos, execute o rfkill unblock ao invés do rfkill block. Para obter uma lista completa de categoria de dispositivos que o rfkill consegue bloquear, execute rfkill help

3.11. Otimizações em Espaço de Usuário

Ao reduzir a quantidade de trabalho realizado pelo hardware de sistema é fundamental economizar energia. Portanto, embora mudanças descritas em Capítulo 3, Infraestrutura do Núcleo e Mecânica permitam que o sistema opere em diversos estados de consumo de energia reduzido, os aplicativos no espaço de usuário que requer trabalho desnecessário do hardware do sistema, evita que o hardware insira estes estados. Durante o desenvolvimento do Red Hat Enterprise Linux 6, as audições foram tomadas nas seguintes áreas para reduzir demandas desnecessárias nos hardware:
Despertar reduzido

O Red Hat Enterprise Linux 6 usa um tickless kernel (consulte Seção 3.4, “Kernel sem Tick”), que permite que as CPUs a ficarem em estados ociosos mais profundos. No entanto, o timer tick não é a única fonte de ativamento de CPU excessivo e chamadas de função dos aplicativos também podem evitar que a CPU entre ou fique em estados ociosos.As chamadas de função desnecessárias foram reduzidas em mais de 50 aplicativos.

Armazenamento reduzido e rede IO

Entrada e saída (ES) para dispositivos de armazenamento e interfaces de rede forçam dispositivos a consumir energia. Nos dispositivos de armazenamento e rede que apresentam estados de energia reduzidos quando ociosos (por exemplo, ALPM ou ASPM), este trânsito pode evitar que o dispositivo ensira ou fique em estado ocioso, e pode evitar que os discos rígidos girem pra baixo quando não estiverem em uso. As demandas excessivas e desnecessárias no armazenamento foram minimizadas em diversos aplicativos. Especialmente aquelas demandas qeu evitam o disco rígido de girar para baixo.

Auditoria Initscript

Os serviços iniciam automaticamente, quer requerido ou não, possuem um grande potencial de recursos de sistema de disperdício. Os serviços deveriam ficar como padrão em "off" ou "on demand" sempre que possível. Por exemplo, o serviço BlueZ que ativa o suporte do Bluetooth, antes rodava automaticamente quando o sistema inicializava, mesmo quando o Bluetooth não estava presente. O initscript do BlueZ agora verifica se o hardware do Bluetooth está presente no sistema antes de iniciar o serviço.

Capítulo 4. Casos de Uso

Este capítulo descreve dois tipos de caso de uso para ilustrar a análise e métodos de configuração descritos em outros locais neste guia. O primeiro exemplo consiste de servidores típicos e o segundo é um laptop comum.

4.1. Exemplo - Servidor

Um modelo típico de servidor atual, vem com praticamente todos os recursos de hardware necessários suportados no Red Hat Enterprise Linux 6. A primeira coisa a se levar em consideração é o tipo de carga de trabalho para o qual o servidor será usado. Baseado nessas informações, você pode decidir quais componentes podem ser otimizados para a economia de energia.
Seja qual for o tipo do servidor, o desempenho gráfico geralmente não é necessário. Portanto, a economia de energia pode ficar ligada.
Webserver

O servidor da Web precisa de rede e disco de E/S. Dependendo da velocidade de conexão externa 100 Mbit/s pode ser o suficiente. Se a máquina serve basicamente páginas estáticas, o desempenho da CPU pode não ser muito importante. As escolhas de gerenciamento de energia podem incluir:

  • nenhum disco ou plugins de rede para tuned.
  • ALPM ligado
  • governador do ondemand ligado.
  • placa de rede limitada à 100 Mbit/s.
Servidor computado

Um servidor computado precisa principalmente de uma CPU. As escolhas de gerenciamento de energia podem incluir:

  • dependendo do trabalho e onde o armazenamento de dados acontece, o disco e plugin de rede para tuned; ou para sistemas em modo batch, ativa totalmente o tuned;.
  • dependendo do uso, talvez o governador do performance
Mailserver

O servidor de correio precisa basicamente de disco de E/S e CPU. As escolhas de gerenciamento de energia podem incluir:

  • governador do ondemand ligado, pois as últimas porcentagens de desempenho da CPU não são importantes.
  • nenhum disco ou plugins de rede para tuned.
  • velocidade de rede não deve ser limitada, pois o correio é geralmente interno e pode portanto se beneficiar de um link 1 Gbit/s or 10 Gbit/s.
Fileserver

Os requerimentos do servidor de arquivo são semelhantes aos do servidor de correio, mas dependendo do protocolo usado, pode requerer mais desempenho de CPU. Geralmente, os servidores baseados em Samba requerem mais CPU do que a NFS e a NFS geralmente requer mais do que o iSCSI. Mesmo assim, você deve conseguir usar o governador ondemand

Directory server

Um servidor de diretório geralmente possui menos requerimentos para disco de E/S, especialmente se equipado com RAM suficiente. A latência de rede é importante embora a rede de E/S seja menor. Você deve considerar o ajuste da rede de latência com velocidade de link menor, mas teste-a com cuidado para sua rede privada.

4.2. Exemplo — Laptop

Outro local muito comum onde o gerenciamento e economia de energia podem fazer uma grande diferença é nos laptops. Como os laptops, devido ao seu design, utilizam muito menos energia do que as estações de trabalho ou servidores, o esforço para economizar é muito menor do que em outras máquinas. No entanto, quando estiver em modo de bateria, qualquer economia pode ajudar a ganhar mais alguns poucos minutos de vida de bateria de um laptop. Embora esta seção foque em laptops em modo de bateria, você ainda pode utilizar um pouco ou todo o ajuste enquanto estiver rodando em energia a cabo também.
Economia para componentes únicos geralmente fazem uma diferença muito maior em laptops do que em estações de trabalho. Por exemplo, uma interface de rede 1 Gbit/s rodando em 100 Mbits/s economiza cerca de 3–4 watts. Para um servidor comum com consumo total de energia de cerca de 400 watts, esta economia é de aproximadamente 1 %. Em um laptop com consumo de energia total de cerca de 40 watts, a economia de energia somente neste componente é de 10 % no total.
Otimizações de economia de energia específica em um laptop típico são:
  • Configure o BIOS do sistema para desabilitar todos os hardwares que você não vá usar. Por exemplo, portas paralelas ou seriais, leitores de cartão, webcams, WiFi, e Bluetooth, nomeando somente alguns possíveis candidatos.
  • Ajuste a exibição para ambientes mais escuros onde você não precisa de iluminação total para ler a tela de maneira confortável. Use o System+PreferencesPower Management no desktop GNOME, Kickoff Application Launcher+Computer+System Settings+AdvancedPower Management no dpeskto KDE; ou gnome-power-manager o xbacklight na linha de comando; ou as chaves de função do seu laptop.
  • Use o perfil de laptop-battery-powersave de tuned-adm para habilitar todo um conjunto de mecanismos de economia de energia. Observe que o desempenho e latência para o disco rígido e interface de rede são impactados.
Além disso ( ou como forma alternativa) você pode realizar diversos pequenos ajustes em diversas configurações de sistemas :
  • use o governador do ondemand (ativado pelo padrão em Red Hat Enterprise Linux 6)
  • habilite o modo do laptop (parte do perfil do laptop-battery-powersave):
    echo 5 > /proc/sys/vm/laptop_mode
  • aumenta tempo de fluxo de tempo para o disco (parte do perfil do laptop-battery-powersave):
    echo 1500 > /proc/sys/vm/dirty_writeback_centisecs
  • desabilitar o nmi watchdog (parte do perfil laptop-battery-powersave):
    echo 0 > /proc/sys/kernel/nmi_watchdog
  • habilitar a economia de energia do audio AC97 (habilitado por padrão no Red Hat Enterprise Linux 6):
    echo Y > /sys/module/snd_ac97_codec/parameters/power_save
  • habilita economia de energia de núcleos múltiplos (parte do perfil laptop-battery-powersave):
    echo Y > /sys/module/snd_ac97_codec/parameters/power_save
  • habilita o USB auto-suspend:
    for i in /sys/bus/usb/devices/*/power/autosuspend; do echo 1 > $i; done
    Observe que o USB auto-suspend não funciona corretamente com todos os dispositivos USB.
  • habilita a configuração de energia mínima para ALPM (parte do perfil laptop-battery-powersave):
    echo min_power > /sys/class/scsi_host/host*/link_power_management_policy
  • monta o sistema de arquivo usando o relatime (padrão em Red Hat Enterprise Linux 6):
    mount -o remount,relatime mountpoint
  • ativa o modo de economia de energia para discos rígidos ( parte do perfil laptop-battery-powersave):
    hdparm -B 1 -S 200 /dev/sd*
  • desabilita o polling do CD-ROM (parte do perfil laptop-battery-powersave):
    hal-disable-polling --device /dev/scd*
  • reduz brilho de tela para 50 ou menos, por exemplo:
    xbacklight -set 50
  • ativa o DPMS para tela ociosa:
    xset +dpms; xset dpms 0 0 300
  • reduz os níveis de energia de Wi-Fi (parte do perfil laptop-battery-powersave):
    for i in /sys/bus/pci/devices/*/power_level ; do echo 5 > $i ; done
  • desativar o Wi-Fi:
    echo 1 > /sys/bus/pci/devices/*/rf_kill
  • limita rede a fio para 100 Mbit/s (parte do perfil laptop-battery-powersave ):
    ethtool -s eth0 advertise 0x0F

Apêndice A. Dicas para Desenvolvedores

Todo livro texto de programação bom cobre os problemas com alocação de memória e o desempenho de funções específicas. A medida que você desenvolve seu software, tome consciência dos problemas que podem aumentar o consumo de energia nos sistemas no qual o software executa. Embora estas configurações não afetam toda linha de código, você pode otimizar seu código em áreas que são funis frequentes para desempenho.
Algumas técnicas que são problemáticas são:
  • usando opções:
  • ativamentos de CPU desnecessárias e o uso ineficiente do mesmo. Se você precisa realizar um ativamento, faça tudo de uma só vez (vá direto para modo ocioso) e o mais rápido possível.
  • usasndo o [f]sync() sem necessidade.
  • polling ativo desnecessário ou uso de timeouts regulares e curtos. (Reativar para eventos).
  • o uso ineficiente do ativamento (wake-ups)
  • acesso ineficiente ao disco. Use buffers grandes para evitar acesso ao disco frequente. Grave um bloco grande por vez.
  • Uso ineficiente de timers. Timers de grupo nos aplicativos (ou até nos sistemas) se possível.
  • E/S excessiva, consumo de energia, ou uso de memória (incluindo vazamento de memória)
  • realizando computação desnecessária.
As seções a seguir examinam algumas destas áreas em detalhes.

A.1. Usando Opções

acredita-se que o uso de opções faz com que os aplicativos tenham um melhor e mais rápido desempenho, mas isto não é verdadeiro para todos os casos.
Python

Python usa o Global Lock Interpreter[1], portanto o uso de opções é lucrável somente para operações de E/S maiores. Unladen-swallow [2] é uma implementação mais rápida do Python com o qual você deve ser capaz de otimizar seu código.

Perl

As opções do Perl foram criadas primeiramente para aplicativos que são executados em sistemas sem divisão (tal como sistemas com sistemas operacionais de 32-bits Windows). Nas opções do Perl, os dados são copiados para cada opção (Copiar na Gravação). Os dados não não compartilhados por padrão pois os usuários deveria ser capazes de definir o nível de dados compartilhados. Para compartilhamento de dados, o módulo threads::shared deve ser incluído. No entanto, os dados não devem ser só copiados (Copiar na Gravação), mas o módulo também cria variáveis ligadas para os dados, o qual leva ainda mais tempo e é mais lento. [3]

C

As opções C compartilham da mesma memória, cada opção possui sua própria pilha e o kernel não precisa criar novos descritores de arquivo e alocar espaço de memória novo. O C podem realmente usar o suporte para mais CPUs por opções. Portanto, para maximizar o desempenho de suas opções, use uma linguagem de baixo nível como o C ou C++. Se você usar uma linguage de script, considere utilizar um C binding. Use donos de perfis para identificar o pouco desempenho de partes de seu código.[4]

A.2. Wake-ups

Muitos aplicativos copiam arquivos de configuração para mudanças. Em diversos casos, o scan é realizado em intervalos fixos, por exemplo, a cada minuto. Isto pode ser um problema, pois força um disco a acordar de giros. A melhor solução é encontrar um bom intervalo, um bom mecanismo de verificação ou verificar mudanças com o inotify e reagir a eventos. O inotify pode verificar uam variedades de mudanças em um arquivo ou em um diretório.
Por exemplo:
int fd;
fd = inotify_init();
int wd;
/* checking modification of a file - writing into */
wd = inotify_add_watch(fd, "./myConfig", IN_MODIFY);
if (wd < 0) {
  inotify_cant_be_used();
  switching_back_to_previous_checking();
}
...
fd_set rdfs;
struct timeval tv;
int retval;
FD_ZERO(&rdfs);
FD_SET(0, &rdfs);

tv.tv_sec = 5;
value = select(1, &rdfs, NULL, NULL, &tv);
if (value == -1)
  perror(select);
else {
  do_some_stuff();
}
...
A vantagem desta saída é a variedade de verificações que você pode realizar.
A principal limitação é que somente um número limitado de relógios estão disponíveis no sistema. O número pode ser obtido através de /proc/sys/fs/inotify/max_user_watches e embora ele possa ser modificado, isto não é recomendado. Além disso, no caso de falhas do inotoify, o código precisa retornar à um método de verificação diferente, o qual geralmente significa muitas ocorrências de #if #define no código fonte.
Para mais informações sobre o inotify, consulte a página man do inotify

A.3. Fsync

Fsyncé conhecido como uma operação de E/S cara, mas isto não é totalmente verdadeiro. Por exemplo, consulte o artigo Theodore Ts'o's Don't fear the fsync! [5] e a discussão que o acompanha.
O Firefox costumava a chamar a biblioteca dosqlite todas as vezes que o usuário clicava em um link para ir para uma nova página. O Sqlite chamado de fsync e por causa das configurações de sistema do arquivo (principalmente o ext3 com modo de dados ordenados), existia uma longa latência quando nada acontecia. Isto podia levar um longo tempo (até 30 segundos) se outro processo era copiado em um arquivo grande ao mesmo tempo.
No entanto, em outros casos, onde o fsync não era usado, os problemas cresciam com a mudança do sistema de arquivo ext4. O Ext3 era ajustado para modo de dados ordenados, o qual enviava a memória a cada poucos segundos e salvava-as em um disco. Mas com um ext4 e laptop_mode, o intervalo entre salvamentos era maior e dados podiam ser perdidos quando o sistema não esperava desligamentos. Agora o ext4 foi reparado, mas nós ainda consideramos o design de nossos aplicativos com cuidado, e usamos o fsync de acordo como o adequado.
O exemplo simples a seguir de leitura e gravação em um arquivo de configuração mostra como um backup de um arquivo pode ser realizado ou como dados podem ser perdidos:
/* open and read configuration file e.g. ~/.kde/myconfig */
fd = open("./kde/myconfig", O_WRONLY|O_TRUNC|O_CREAT);
read(myconfig);
...
write(fd, bufferOfNewData, sizeof(bufferOfNewData));
close(fd);
Uma melhor solução seria:
open("/.kde/myconfig", O_WRONLY|O_TRUNC|O_CREAT);
read(myconfig);
...
fd = open("/.kde/myconfig.suffix", O_WRONLY|O_TRUNC|O_CREAT);
write(fd, bufferOfNewData, sizeof(bufferOfNewData));
fsync; /* paranoia - optional */
...
close(fd);
rename("/.kde/myconfig", "/.kde/myconfig~"); /* paranoia - optional */
rename("/.kde/myconfig.suffix", "/.kde/myconfig");

Apêndice B. Histórico de Revisão

Histórico de Revisões
Revisão 0.2-23.4002013-10-31Rüdiger Landmann
Rebuild with publican 4.0.0
Revisão 0.2-232012-07-18Anthony Towns
Rebuild for Publican 3.0
Revisão 0.2-19Tue Jul 20 2010Rüdiger Landmann
Foi adicionada uma seção para DeviceKit-Power — BZ#548242
Foi adicionada uma seção para GNOME Power Manager — BZ#548243
Revisão 0.2-18Fri Jul 16 2010Rüdiger Landmann
reescrever uma frase no capítulo "Importance"
Revisão 0.2-17Thu Jul 8 2010Rüdiger Landmann
corrigir mais erros de digitação
Revisão 0.2-16Thu Jul 8 2010Rüdiger Landmann
corrigir comandos do yum — BZ#611745
correção sobre o relato do Tuned - RT3#67837
corrigir diversos erros de digitação - BZ#611428
traduzir USV e UPS
Revisão 0.2-15Wed Jun 30 2010Rüdiger Landmann
Incorporar feedback de desenvolvedor — BZ#608908
Remova referências às opções -D e -G para BLTK — BZ#593665
Revisão 0.2-14Tue Mar 15 2010Rüdiger Landmann
Pequena limpeza
Revisão 0.2-13Mon Mar 15 2010Rüdiger Landmann
Descrever a ferramenta BLTK
Revisão 0.2-12Mon Mar 15 2010Rüdiger Landmann
Descrever a ferramenta PowerTOP
Revisão 0.2-11Mon Mar 15 2010Rüdiger Landmann
Descrever a ferramenta tuned
Revisão 0.2-10Mon Mar 15 2010Rüdiger Landmann
Descrever auditorias realizadas em User Space
Revisão 0.2-9Mon Mar 15 2010Rüdiger Landmann
Reestruturar as partes/capítulos/seções
Revisão 0.2-8Mon Mar 15 2010Rüdiger Landmann
Observe suporte de C6 para Nehalem CPUs
Revisão 0.2-7Sun Mar 14 2010Rüdiger Landmann
Observe melhor suporte para suspensão e resumo
Revisão 0.2-6Sun Mar 14 2010Rüdiger Landmann
Documeno do kernel Tickless
Revisão 0.2-5Sun Mar 14 2010Rüdiger Landmann
Documento ASPM
Revisão 0.2-4Sat Mar 13 2010Rüdiger Landmann
Documento relatime
Revisão 0.2-3Sat Mar 13 2010Rüdiger Landmann
Documento power capping
Revisão 0.2-2Tue Mar 9 2010Rüdiger Landmann
Documento aprimorado do gerenciamento de energia de gráficos
Revisão 0.2-1Mon Mar 8 2010Rüdiger Landmann
Documento RFKill
Revisão 0.2-0Thu Dec 17 2009Rüdiger Landmann
Adicionar tabela de conteúdo para guia expandido e marcar como 'rascunho'
Revisão 0.1-0Tue Sep 23 2008Don Domingo
atualizado para construir um Publican 0.36
sob o cabeçalho do produto Whitepapers agora

Nota Legal

Copyright © 2010 Red Hat Inc..
This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.