Red Hat Training
A Red Hat training course is available for Red Hat Enterprise Linux
Guia de Ajuste de Desempenho
Otimizando rendimento de subsistema no Red Hat Enterprise Linux 6
Edição 4.0
Red Hat Peritos do Assunto em Pauta
Editado por
Don Domingo
Editado por
Laura Bailey
Resumo
Capítulo 1. Visão Geral
- Recursos
- Cada capítulo de subsistema descreve recursos de desempenho únicos (ou implementados de forma diferente) do Red Hat Enterprise Linux 6. Estes capítulos discutem as atualizações do Red Hat Enterprise Linux 6 que aprimoraram o desempenho de subsistemas específicos ao longo do Red Hat Enterprise Linux 5.
- Análise
- O livro também enumera os indicadores de desempenho para cada subsistema específico. Valores típicos para estes indicadores são descritos no contexto de serviços específicos, ajudando-o a entender seu significado na produção de sistemas do mundo real.Além disso, o Guia de Ajuste de Desempenho também mostra formas diferentes de recuperar os dados de desempenho (ou seja, perfil) para um subsistema. Note que algumas das ferramentas de perfil demonstradas aqui são documentadas em outros locais em mais detalhes.
- Configuração
- Talvez a informação mais importante neste livro seja as instruções sobre como ajustar o desempenho de um subsistema específico no Red Hat Enterprise Linux 6. O Guia de Ajuste de Desempenho explica como ajustar de forma fina um subsistema do Red Hat Enterprise Linux 6 para serviços específicos.
1.1. Público Alvo
- Analistas de Sistema/Negócios
- Este livro enumera e explica os recursos de desempenho do Red Hat Enterprise Linux 6 a um nível elevado, fornecendo informações suficientes sobre como os subsistemas para executar cargas de trabalho específicas (tanto por padrão e quando otimizado). O nível de detalhamento utilizado na descrição dos recursos de desempenho do Red Hat Enterprise Linux 6 ajuda clientes em potencial e engenheiros de vendas a entenderem a adequação desta plataforma na prestação de serviços intensivos em recursos a um nível aceitável.O Guia de Ajuste de Desempenho também fornece links para documentação mais detalhada em cada recurso onde seja possível. Neste nível de detalhes, os leitores podem entender estes recursos de desempenho suficientes para formar uma estratégia de alto nível ao implementar e otimizar o Red Hat Enterprise Linux 6. Isto permite que leitores desenvolvam e avaliem as propostas de infraestrutura.Este nível de recurso focado de documentação é adequado para leitores com um alto nível de conhecimento do subsistema Linux e redes de nível corporativo.
- Administrador de Sistemas
- Os procedimentos enumerados neste livro são adequados aos administradores de sistema com o nível de qualificações RHCE [1] ( ou equivalente, ou seja, de 3 à 5 anos de experiência na implantação e gerenciamento do Linux). O Guia de Ajuste de Desempenho foca em prover o máximo de detalhes possível sobre os efeitos de cada configuração, ou seja, descrevendo qualquer compensação de desempenho que possa ocorrer.A qualificação subjacente no ajuste de desempenho não depende de como analisar e ajustar um subsistema. Ao invés disso, um administrador de sistema adepto ao ajuste de desempenho, sabe como balancear e otimizar um sistema Red Hat Enterprise Linux 6 system para propósitos específicos. Isto também significa saber quais penalidades de ajuste e compensações são aceitáveis para implementar uma configuração criada para aumentar um desempenho de subsistema específico.
1.2. Escalabilidade Horizontal
1.2.1. Computação Paralela
1.3. Sistemas Distribuídos
- Comunicação
- Escalabilidade horizontal requer muitas tarefas a serem executadas simultaneamente (em paralelo). Como tal, estas tarefas devem ter comunicação de interprocesso para coordenar seu trabalho. Além disso, uma plataforma com escalabilidade horizontal deve ser capaz de compartilhar tarefas entre vários sistemas.
- Armazenamento
- Armazenamento via discos locais não é suficiente para enfrentar as exigências de escalabilidade horizontal. Será necessária alguma forma de armazenagem compartilhada ou distribuída, uma com uma camada de abstração que permite que a capacidade de um único volume de armazenamento cresça de forma integrada com a adição de um novo hardware de armazenamento.
- Gerenciamento
- O dever mais importante na computação distribuída é a camada de gestão. Esta camada de gerenciamento coordena todos os componentes de software e hardware, gestão eficiente de comunicação, armazenamento e uso de recursos compartilhados.
1.3.1. Comunicação
- Hardware
- Software
A forma mais comum de comunicação entre computadores é sob Ethernet. Hoje, Gigabit Ethernet (GbE) é fornecido por padrão nos sistemas, e a maioria dos servidores incluem 2-4 portas Gigabit Ethernet. GbE fornece boa largura de banda e latência. Esta é a base da maioria dos sistemas distribuídos em uso nos dias de hoje. Mesmo quando os sistemas incluem hardware de rede mais rápida, ainda é comum o uso de GbE para uma interface de gerenciamento dedicado.
Ten Gigabit Ethernet (10GbE) está crescendo rapidamente na aceitação para servidores de alto nível e até mesmo servidores de nível médio. 10GbE fornece dez vezes a largura de banda de GbE. Uma de suas principais vantagens é com processadores multi-core modernos, onde se restabelece o equilíbrio entre comunicação e computação. Você pode comparar um sistema de núcleo único com GbE com um sistema de oito núcleos usando 10GbE. Usado desta forma, o 10GBE é especialmente valioso para manter o desempenho geral do sistema e evitar afunilamento de comunicação.
Infiniband oferece um desempenho ainda mais alto do que 10GbE.Além das conexões de rede TCP/IP e UDP utilizadas com o Ethernet, o Infiniband também suporta comunicação de memória compartilhada. Isto permite que o Infiniband funcione entre sistemas via acesso de memória direto remoto (RDMA).
RDMA over Ethernet (RoCE) implements Infiniband-style communications (including RDMA) over a 10GbE infrastructure. Given the cost improvements associated with the growing volume of 10GbE products, it is reasonable to expect wider usage of RDMA and RoCE in a wide range of systems and applications.
1.3.2. Armazenamento
- Dados de armazenamento de sistemas múltiplos em um único local
- uma unidade de armazenamento (ex.: um volume) composto por equipamentos de armazenamento múltiplos.
O Network File System (NFS) permite que múltiplos servidores ou usuários montem e utilizem a mesma instância de armazenamento remoto via TCP ou UDP. O NFS é geralmente utilizado para manter dados compartilhados por diversos aplicativos. É também conveniente para armazenamento em massa com uma grande quantidade de dados.
Rede de Área de Armazenamento (SANs) usa o Canal de Fibra ou o protocolo ou iSCSI para fornecer acesso remoto para armazenamento. A infraestrutura do Canal de Fibra, (tal como o adaptadores do bus do host Canal de Fibra, interruptores e matrizes de armazenamento) combina com o alto desempenho, largura de banda alta e enorme armazenamento. O SANs separa o armazenamento do processamento, provando flexibilidade considerável na criação do sistema.
- Controlando acesso ao armazenamento
- Gerenciamento de grande quantidade de dados
- Sistemas de Provisionamento
- Fazendo um backup e replicando dados
- Tirando snapshots
- Suportando failover de sistema
- Garantindo a integridade de dados
- Migrando dados
O sistema de arquivo da Red Hat Global File System 2 (GFS2) fornece vários recursos especializados. A função básica do GFS2 é fornecer um único sistema de arquivos, incluindo o concorrente de leitura / gravação de acesso, compartilhados entre vários membros de um cluster. Isto significa que cada membro do cluster vê exatamente os mesmos dados "no disco" no sistema de arquivos GFS2.
1.3.3. Redes Convergidas
With FCoE, standard fibre channel commands and data packets are transported over a 10GbE physical infrastructure via a single converged network adapter (CNA). Standard TCP/IP ethernet traffic and fibre channel storage operations can be transported via the same link. FCoE uses one physical network interface card (and one cable) for multiple logical network/storage connections.
- Número reduzido de conexões
- FCoE reduz o número de conexões de rede a um servidor pela metade. Você ainda pode optar por fazer várias conexões para o desempenho ou a disponibilidade, no entanto, uma única conexão fornece armazenamento e conectividade de rede. Isso é especialmente útil para os servidores de caixa de pizza e servidores blade, já que ambos têm um espaço muito limitado para os componentes.
- Custo mais baixo
- Reduzir número de conexões, imediatamente, significa número reduzido de cabos, interruptores e outros equipamentos de rede. A história da Ethernet também apresenta grandes economias de escala, o custo das redes cai drasticamente quando o número de dispositivos no mercado vai de milhões a bilhões, como foi visto na queda do preço de 100Mb Ethernet e dispositivos Gigabit Ethernet.Da mesma forma, o 10GbE também se torna mais barato a medida que os negócios se adaptam ao seu uso. Como o hardware CNA, ele é integrado em um único chip, o uso espalhado também aumentará seu volume no mercado, o qual resultará em baixa de preço de forma significativa ao longo do tempo.
Internet SCSI (iSCSI) é outro tipo de protocolo de rede convergida; é uma alternativa para o FCoE. Como o canal de fibra, o canal iSCSI fornece armazenamento de nível de bloco sob a rede. No entanto, o iSCSI não fornece um ambiente de gerenciamento completo. A principal vantagem do iSCSI sob o FCoE é que o iSCSI fornece muito da capacidade e flexibilidade do canal de fibra, mas com um custo menor.
Capítulo 2. Recursos de Desempenho do Red Hat Enterprise Linux 6
2.1. Suporte de 64-bit
- Huge pages e transparent huge pages
- Melhorias de Acesso de Memória Não Uniforme
A implementação do huge pages no Red Hat Enterprise Linux 6 permite que o sistema gerencie o uso de memória de forma eficiente em diferentes cargas de trabalho de memória. Huge pages usa de forma dinâmica as páginas de 2 MB comparado ao tamanho de página padrão de 4 KB, permitindo aplicativos escalar bem a partir do processamento de gigabytes e até terabytes de memória.
Muitos dos novos sistemas suportam agora Non-Uniform Memory Access (NUMA). NUMA simplifica o desenho e criação de hardware para sistemas de grande porte, no entanto, ele também adiciona uma camada de complexidade para o desenvolvimento de aplicativos. Por exemplo, NUMA implementa a memória local e remota, onde a memória remota pode levar muito mais tempo para acessar a memória local. Este recurso (entre outros) possuem muitas implicações de desempenho que os sistemas operacionais de impacto, aplicativos e configurações do sistema devem ser implantados.
2.2. Ticket Spinlocks
2.3. Estrutura da Lista Dinâmica
2.4. Tickless Kernel
2.5. Grupos de Controle
- Uma lista de tarefas atribuídas ao cgroup
- Recursos alocados a estas tarefas
- CPUsets
- Memória
- E/S
- Rede (largura de banda)
2.6. Melhorias de Armazenamento de Sistema de Arquivo
Ext4 é o sistema de arquivos padrão para o Red Hat Enterprise Linux 6. É a quarta versão da geração da família de sistema de arquivos EXT, apoiando um tamanho máximo teórico do sistema de arquivos de 1 exabyte, e tamanho máximo de arquivo único de 16TB. Red Hat Enterprise Linux 6 suporta um tamanho máximo de arquivo do sistema de 16TB, e um único tamanho máximo de 16TB. Além de uma capacidade de armazenamento muito maior, ext4 também inclui várias novas funcionalidades, tais como:
- Metadados baseados em Extensão
- Alocação atrasada
- Diário do check-summing
XFS é um sistema de arquivo de 64 bits robusto e maduro que suporta arquivos grandes e sistemas de arquivos em um único host. Este sistema de arquivos foi originalmente desenvolvido pela SGI, e tem uma histórico longo de execução em servidores extremamente grandes e diretrizes de armazenamento. As características XFS incluem:
- Alocação atrasada
- Inodes alocados de forma dinâmica
- Índice B-tree para escalabilidade de gerenciamento de espaço livre.
- Defragmentação online e crescente sistema de arquivo
- Algorítimos de leitura avançada de metadados sofisticados
BIOS tradicional suporta um tamanho máximo do disco de 2.2TB. Os sistemas Red Hat Enterprise Linux 6 que utilizam o BIOS podem suportar discos maiores que 2.2TB usando uma nova estrutura de disco chamado Partition Table global(GPT). GPT só pode ser utilizado para discos de dados, ele não pode ser utilizada em unidades de inicialização com o BIOS e, portanto, os discos de inicialização podem ser de tamanho máximo de 2.2TB. A BIOS foi criado originalmente para o IBM PC, enquanto BIOS evoluiu consideravelmente para se adaptar ao hardware moderno, o Unified Extensible Firmware Interface (UEFI) foi projetado para suportar hardwares novos e emergentes.
Importante
Importante
Capítulo 3. Monitorando e Analisando Desempenho de Sistema
3.1. O Sistema de Arquivos Proc
proc
"sistema de arquivos" é um diretório que contém uma hierarquia de arquivos que representam o estado atual do kernel do Linux. Ele permite que aplicativos e usuários acessem a visualização do kernel do sistema.
proc
diretório também contém informações sobre o hardware do sistema, e todos os processos em execução. A maioria destes arquivos são somente leitura, mas alguns arquivos (principalmente aqueles em /proc/sys
) podem ser manipulados por usuários e aplicações para comunicar as alterações de configuração com o kernel.
proc
, consulte o Deployment Guide, disponível a partir do http://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/.
3.2. GNOME e Monitores de Sistema KDE
O GNOME System Monitor exibe informações de sistema básicas e permite que você monitore processos de sistema e uso de sistema de arquivo ou recurso. Abra-o com o comando gnome-system-monitor
no Terminal, ou clique em menu de Applications e selecione System Tools > System Monitor.
- Sistema
- Exibe informações básicas sobre o hardware e software do computador
- Processos
- Mostra processos ativos, e as relações entre os processos, bem como informações detalhadas sobre cada processo. Ele também permite que você filtre os processos apresentados, e executar determinadas ações nesses processos (iniciar, parar, matar, alterar a prioridade, etc.)
- Recursos
- Exibe o uso de tempo de CPU atual, uso de memória e de espaço swap e uso de rede.
- Sistema de Arquivo
- Lista todos os sistemas de arquivo montados junto com informações básicas sobre cada um, tal como tipo de sistema de arquivo, ponto de montagem e uso de memória.
O KDE System Guard permite que você monitore a carga de sistema atual e processos que estejam em execução. Ele também deixa-o realizar ações e processos. Abra-o com o comando ksysguard
no Terminal,ou clique em Kickoff Application Launcher and select Applications > System > System Monitor.
- Tabela de Processo
- Exibe uma lista de todos os processos em execução, em ordem alfabética por padrão. Você também pode classificar os processos por uma série de outras propriedades, incluindo o uso total da CPU, uso da memória física ou compartilhado, proprietário e prioridade. Você também pode filtrar os resultados visíveis, procurar processos específicos, ou realizar determinadas ações em um processo.
- Carga de Sistema
- Exibe gráficos históricos de uso de CPU, memória e uso do espaço de troca e uso da rede. Passe o mouse sobre os gráficos para uma análise detalhada e as chaves de gráficos.
3.3. Ferramentas de Monitoramento de Linha de Comando Embutida
top
A ferramenta top fornece uma visão dinâmica em tempo real dos processos em um sistema em execução. Ela pode exibir uma variedade de informações, incluindo um resumo do sistema e as tarefas sendo gerenciadas pelo kernel do Linux. Ela também tem uma capacidade limitada para manipular processos. Tanto a sua operação quanto as informações que ela exibe são altamente configuráveis e quaisquer detalhes de configuração podem ser feitos para persistir nas reiinicializações.
man top
.
ps
A ferramenta ps tira um snapshot de um grupo seleto de processos ativos. Por padrão, este grupo é limitado a processos de usuários atuais e associados com o mesmo terminal.
man ps
.
vmstat
Os resultados do vmstat (Virtual Memory Statistics) reporta instantaneamente sobre os processos do seu sistema, memória e paginação, E/S de bloco e atividade de CPU.
man vmstat
.
sar
O sar (System Activity Reporter) coleta e reporta informações sobre as atividades de sistema de hoje. O resultado padrão cobre o uso da CPU de hoje em dez minutos de intervalo a partir do início do dia:
12:00:01 AM CPU %user %nice %system %iowait %steal %idle 12:10:01 AM all 0.10 0.00 0.15 2.96 0.00 96.79 12:20:01 AM all 0.09 0.00 0.13 3.16 0.00 96.61 12:30:01 AM all 0.09 0.00 0.14 2.11 0.00 97.66 ...
man sar
.
3.4. Tuned e ktune
default
- O perfil de economia de energia padrão. Este é o perfil de economia de energia mais básico. Ele permite somente plugins de disco e CPU. Note que este não é o mesmo que desligar o tuned-adm, onde ambos tuned e ktune estão desabilitados.
latency-performance
- Um perfil de servidor para um ajuste de desempenho de latência típica. Ele desabilita os mecanismos de economia de energia do tuned e ktune. O modo
cpuspeed
muda paraperformance
. O elevador de E/S foi modificado paradeadline
para cada dispositivo. para a qualidade do gerenciamento de energia do serviço, o requerimentocpu_dma_latency
de valor0
é registrado. throughput-performance
- Um perfil de servidor para ajuste de desempenho de rendimento típico. Este perfil é recomendado se o sistema não tiver o armazenamento de classe corporativa. É o mesmo que
latency-performance
, exceto:kernel.sched_min_granularity_ns
(granularidade preempção mínima de agendador) é ajustado para10
milisegundos.kernel.sched_wakeup_granularity_ns
(granularidade de ativação de agendador) é ajustado para15
milisegundos,vm.dirty_ratio
(índice de máquina virtual suja) é definido para 40%, e- transparent huge page são habilitadas.
enterprise-storage
- Este perfil foi recomendado para configurações de servidores de tamanho corporativo com armazenamento de classe corporativo, incluindo proteção e gerenciamento de cache de controlador com backup de bateria de um cache em disco. É o mesmo que o perfil
throughput-performance
, com uma adição: sistemas de arquivo são re-montadas com obarrier=0
. virtual-guest
- Este perfil é recomendado para configurações de servidor de tamanho corporativo com armazenamento de classe corporativa, incluindo proteção e gerenciamento de cache de controlador com backup de bateria de um cache em disco. É o mesmo que o perfil
desempenho de rendimento
, exceto:- O valor
readahead
é ajustado para4x
, e - sistemas de arquivo não root/boot são montados com o
barrier=0
.
virtual-host
- Baseado no perfil
enterprise-storage
, ovirtual-host
também deminui a troca de memória virtual e habilita um write-back mais agressivo de páginas sujas. Este perfil está disponível no Red Hat Enterprise Linux 6.3 e posteriores, e é o perfil recomendado para os hosts de virtualização, incluindo ambos KVM e hosts Red Hat Enterprise Virtualization.
3.5. Perfis de Aplicativo
3.5.1. SystemTap
3.5.2. OProfile
- As amostras de controle de desempenho podem não ser precisas - porque o processador pode executar instruções fora de ordem, uma amostra pode ser gravada a partir de uma instrução próxima, ao invéz da instrução que gerou a interrupção.
- Como o OProfile é todo o sistema e espera que os processos iniciem e parem várias vezes, amostras de várias execuções são autorizadas a acumular. Isso significa que você pode precisar limpar os dados da amostra de execuções anteriores.
- Ele se concentra na identificação de problemas com os processos de CPU-limitados e, portanto, não identifica os processos que estão inativos enquanto esperam em bloqueios para outros eventos.
/usr/share/doc/oprofile-<version>
.
3.5.3. Valgrind
man valgrind
quando o pacote valgrind for instalado. Documentação extra pode também ser encontrada em:
/usr/share/doc/valgrind-<version>/valgrind_manual.pdf
/usr/share/doc/valgrind-<version>/html/index.html
3.5.4. Perf
perf stat
- Este comando fornece estatísticas globais para eventos de desempenho comuns, incluindo instruções executadas e ciclos de relógio consumidos. Você pode usar a opção de sinalizadores para reunir estatísticas de eventos além dos eventos de medição padrão. A partir do Red Hat Enterprise Linux 6.4, é possível usar
perf status
para filtrar monitoramento baseado em um ou mais grupos de controle especificados (cgroups). Para mais informações, leia a página do manual:man perf-stat
. perf record
- This command records performance data into a file which can be later analyzed using
perf report
. For further details, read the man page:man perf-record
. perf report
- This command reads the performance data from a file and analyzes the recorded data. For further details, read the man page:
man perf-report
. perf list
- This command lists the events available on a particular machine. These events will vary based on the performance monitoring hardware and the software configuration of the system. For further information, read the man page:
man perf-list
. perf top
- This command performs a similar function to the top tool. It generates and displays a performance counter profile in realtime. For further information, read the man page:
man perf-top
.
3.6. Red Hat Enterprise MRG
- Parâmetros BIOS relacionados ao gerenciamento de energia, detecção de erros e interrupções de gerenciamento de sistema;
- configurações de rede, tais como união de interrupção e o uso do TCP;
- atividade de agendamento nos sistemas de arquivo de agendamento;
- autenticação de sistema;
- se a interrupção e processos de usuário são manuseados por uma CPU específica ou uma classe de CPUs;
- se o espaço swap é utilizado; e
- como lidar com exceções sem memória
Capítulo 4. CPU
Topologia
Threads
Interrupções
4.1. Topologia da CPU
4.1.1. CPU e a Topologia NUMA
- Barramentos em série
- Topologias NUMA
- Qual a topologia do sistema?
- Onde o aplicativo está executando atualmente?
- Onde está o banco de memória mais próximo?
4.1.2. Ajustando Desempenho de CPU
- Uma CPU (qualquer um dos 0-3) apresenta o endereço de memória para o controlador da memória local.
- O controlador de memória define o acesso ao endereço de memória.
- A CPU executa a leitura ou gravação de operações naquele endereço de memória.
Figura 4.1. Acesso Remoto e Local de Memória em topologia NUMA
- Uma CPU (qualquer um dos 0-3) apresenta o endereço de memória remota ao controlador da memória local.
- A requisição da CPU para o endereço de memória remota é passado para um controlador de memória remota, local para o nó que contém o endereço de memória.
- O controlador de memória remota define o acesso ao endereço de memória remota.
- A CPU executa a leitura ou gravação de operações naquele endereço de memória remota.
- a topologia do sistema (como os seus componentes estão conectados),
- o núcleo no qual o aplicativo é executado, e
- a localização do banco de memória mais próximo.
4.1.2.1. Configuração, Afinidade da CPU com o taskset
0x00000001
representa o processador 0, e o 0x00000003
representa processadores 0 e 1.
# taskset -p mask pid
# taskset mask -- program
-c
opção para fornecer uma lista delimitada por vírgulas de processadores separados, ou uma variedade de processadores, assim:
# taskset -c 0,5,7-9 -- myprogram
taskset
.
4.1.2.2. Controlling NUMA Policy with numactl
numactl
executa processos com um agendamento específico ou política de colocação de memória. A política selecionado está definido para o processo e todos os seus filhos. numactl
pode também definir uma política persistente de segmentos de memória compartilhada ou arquivos e definir a afinidade da CPU e afinidade de memória de um processo. Ele usa o / sys
sistema de arquivos para determinar a topologia do sistema.
/ sys
sistema de arquivos contém informações sobre como CPUs, memória e dispositivos periféricos são conectados via NUMA interconexões. Especificamente, o / sys / devices /system/cpu
contém informações sobre como CPUs de um sistema estão ligados um ao outro. O / sys / devices / system / node
contém informações sobre os nós NUMA no sistema, e as distâncias relativas entre os nós.
--show
- Mostrar as definições de política NUMA do processo atual. Este parâmetro não necessita de outros parâmetros, e pode ser usado assim:
numactl - espetáculo
. --hardware
- Exibe um inventário de nós disponíveis no sistema
--membind
- Alocar memória somente de nós específicos. Quando esta configuração estiver em uso, a alocação falhará se a memória nesses nós for insuficiente. A utilização para este parâmetro é
numactl - membind = nós programa
, onde nós é a lista de nós que você deseja alocar a memória programa é o programa cujos requisitos de memória devem ser alocados a partir desse nó. Números de nó podem ser dados como uma lista delimitada por vírgulas, um intervalo, ou uma combinação dos dois. Mais detalhes estão disponíveis na página do manual numactl :man numactl
. --cpunodebind
- Só executar um comando (e seus processos filhos) em CPUs que pertencem ao nó especificado (s). Uso para este parâmetro é
numactl - cpunodebind = nós programa
, onde nós é a lista de nós a cuja CPUs o programa especificado ( programa ) deve estar vinculado. Números nó pode ser dada como uma lista delimitado por vírgulas, um intervalo, ou uma combinação dos dois. Mais detalhes estão disponíveis no numactl página man:man numactl
. --physcpubind
- Somente execute um comando (e seus processos filho) em CPUs especificadas. O uso para este parâmetro é
numactl --physcpubind=cpu program
, onde cpu é uma lista separada por vírgulas de números de CPU físicos como exibido nos campos do processador do/proc/cpuinfo
, e program é o programaque deve executar somente naqueles CPUs. Os CPUs podem também ser especificados dependendo docpuset
atual. Consulte a página man do numactl para obter mais informações:man numactl
. --localalloc
- Especifica se a memória deve sempre ser alocada no nó atual.
--preferred
- Sempre que possível, a memória é alocada no nó especificado. Se a memória não pode ser alocada no nó especificado, recorrerá a outros nós. Esta opção aceita apenas um único número de nó, assim: nó
numactl - preferred =
. Consulte a página do manual numactl para mais informações:man numactl
.
man numa (3)
.
4.1.3. numastat
Importante
numastat
, sem nenhuma opção ou parâmetro) mantém a compatibilidade severa com as versões anteriores da ferramenta, note que as opções ou parâmetros fornecidos à este comando, muda significantemente o conteúdo de resultado e seu formato.
numastat
exibe como muitas páginas de memória estão ocupadas pelas seguintes categorias de evento para cada nó.
numa_miss
e valores numa_foreign
.
Categorias de Rastreamento Padrão
- numa_hit
- O número de tentativas de alocações neste nós que foram bem sucedidas.
- numa_miss
- O número de tentativas de alocações em outro nó que foram alocadas neste nó porcausa da baixa memória no nó pretendido. Cada evento
numa_miss
possui um eventonuma_foreign
correspondente em outro nó. - numa_foreign
- O número de alocações pretendidas inicialmente para este nó que foram alocadas à outro nó. Cada evento
numa_foreign
possui um eventonuma_miss
correspondente em outro nó. - interleave_hit
- O número de tentativas de alocações de políticas de intercalação neste nó que foram bem sucedidas.
- local_node
- O número de vezes que um processo neste nó alocou memória com sucesso neste nó.
- other_node
- O número de vezes que um processo em outro nó alocou memória neste nó.
-c
- Horizontalmente condensa a tabela da informação exibida. Isso é útil em sistemas com um elevado número de nós NUMA, mas a largura da coluna e do espaçamento entre colunas são um tanto imprevisíveis. Quando esta opção é utilizada, a quantidade de memória é arredondado para o próximo megabyte.
-m
- Exibe as informações de uso de memória em todo o sistema baseado por nó, semelhante à informação encontrada em
/proc/meminfo
. -n
- Exibe a mesma informação que o comando original
numastat
(numa_hit, numa_miss, numa_foreign, interleave_hit, local_node, e other_node), com um formato atualizado, utilizando megabytes como unidade de medida. -p pattern
- Exibe informações por nó para o modelo específico. Se o valor para o modelo é composto de dígitos, o numastat entende que seja um identificador de processo numérico. Caso contrário, o numastat procura por linhas de comando do processo para um modelo em específico.Os argumentos de linha de comando inseridos após o valor da opção
-p
devem ser modelos adicionais para o qual filtrar. Modelos adicionais expandem, ao em vez de estreitarem o filtro. -s
- Filtra os dados exibidos em ordem descendente para que os maiores consumidores de memória (de acordo com a coluna
total
) são listados primeiro.Opcionalmente, você pode especificar o node, e a tabela será filtrada de acordo com a coluna do node.Ao utilizar esta opção, o valor do nodedeve seguir a opção-s
imediatamente, como demonstrado aqui:numastat -s2
Não inclui o espaço em branco entre a opção e seu valor. -v
- Exibe mais informações de verbosidade. De modo que as informações do processo para processos múltiplos exibirão informações detalhadas para cada processo.
-V
- Exibe as informações da versão numastat.
-z
- Omite a faixa da tabela e colunas com valores zero de informações exibidas. Note que alguns valores quase zero que são arredondados para zero para exibir propósitos, não serão omitidos do resultado exibido.
4.1.4. NUMA Daemon de Gerenciamento de Afinidade (numad)
/proc
para monitorar recursos de sistemas disponíveis por nó. O daemon então tenta colocar processos significativos em nós do NUMA que possuam memória alinhada suficientes e recursos de CPU para o desempenho adequado do NUMA. Limites atuais para o gerenciamento do processo são de ao menos 50% de uma CPU e de ao menos 300 MB de memória. O numad tenta manter um nível de uso de recurso e rebalancear alocações quando necessárias, movendo processos entre nós de NUMA.
-w
para o aconselhamento de pré-colocação: man numad
.
4.1.4.1. Benefícios do numad
4.1.4.2. Modos de operação
Nota
- como um serviço
- como um executável
4.1.4.2.1. Utilizando o numad como um serviço
# service numad start
# chkconfig numad on
4.1.4.2.2. Usando o numadcomo um executável
# numad
/var/log/numad.log
.
# numad -S 0 -p pid
-p pid
- Adiciona o pid especificado à uma lista de inclusão explícita. O processo especificado não será gerenciado até que ele atenda ao limite de significância do processo do numad.
-S mode
- O parâmetro do
-S
especifica o tipo de escaneamento do processo. Configurá-lo para0
como demonstrado, limita o gerenciamento do numad para processos explicitamente incluídos.
# numad -i 0
man numad
.
4.2. Agendamento da CPU
- Políticas em Tempo Real (Realtime)
- SCHED_FIFO
- SCHED_RR
- Políticas Normais
- SCHED_OTHER
- SCHED_BATCH
- SCHED_IDLE
4.2.1. Políticas de agendamento em Tempo Real (Realtime)
SCHED_FIFO
- Esta política também é mencionada como agendamento de prioridade estática, pois ela define uma prioridade fixa (entre 1 e 99) para cada thread. O agendador copia uma lista de threads SCHED_FIFO para o thread de maior prioridade que esteja pronto para ser executado. Esta thread é executada até que seja bloqueada, ou tenha admitido preempção por um thread de prioridade maior que esteja pronto para ser executado.Até mesmo a thread em tempo real com a prioridade mais baixa será agendada antes do que qualquer thread com uma política não-tempo real; Se somente existir threads em tempo real, o valor de prioridade
SCHED_FIFO
não importará. SCHED_RR
- Uma variante de repetição alternada (round-robin) da política
SCHED_FIFO
. As threads doSCHED_RR
também recebem uma prioridade fixa entre 1 e 99. No entanto, as threads com a mesma prioridade são agendadas em estilo repetição alternada dentro de um certo quantum, ou fração de tempo. A chamada do sistemasched_rr_get_interval(2)
retorna o valor de fração de tempo, mas a duração da fração de tempo não pode ser estabelecida por um usuário. Esta política é útil se você precisa executar threads múltiplas na mesma prioridade.
SCHED_FIFO
funcionam até que sejam bloqueadas, retiradas ou pré-esvaziadas por uma thread com uma prioridade maior. Configurar uma prioridade de 99 é portanto desencorajado, pois isto colocaria seus processos no mesmo nível de prioridade que a thread de migração e as threads watchdog. Se estas threads forem bloqueadas porque sua thread entrou no loop computacional, estes não serão executados. Os sistemas de uniprocessador será bloqueado neste caso.
SCHED_FIFO
inclui o mecanismo do pacote de largura de banda. Isto projeta programadores de aplicativos de realtime de tarefas realtime que podem monopolizar a CPU. Este mecanismo pode ser ajustado através dos seguintes parâmetros de sistema de arquivo /proc
:
/proc/sys/kernel/sched_rt_period_us
- Define o período de tempo a ser considerado cem porcento da largura de banda de CPU, em microsegundos ('us' sendo o texto simples mais próximo de 'µs'). O valor parão é de 1000000µs, ou 1 segundo.
/proc/sys/kernel/sched_rt_runtime_us
- Define o período de tempo a ser devotado a threads de realtime em execução, em microsegundos ('us' sendo o texto simples mais próximo de 'µs'). O valor parão é de 950000µs, ou 0.95 segundos.
4.2.2. Políticas de agendamento normal
SCHED_OTHER
, SCHED_BATCH
e SCHED_IDLE
. No entanto, as políticas SCHED_BATCH
e SCHED_IDLE
pretendem ser direcionadas para trabalhos com baixa prioridade, e como tal, são de interesse limitado em um guia de ajuste de desempenho.
SCHED_OTHER
, ouSCHED_NORMAL
- A política de agendamento padrão. Esta polícia utiliza o Agendador Totalmente Justo (Completely Fair Scheduler - CFS) para fornecer períodos de acesso justos para todas as threads utilizando esta política. Os CFS estabelecem uma lista de prioridades dinâmicas baseadas em partes no valor
niceness
de cada thread do processo. (Consulte o Guia de Implementação para mais detalhes sobre este parâmetro e o sistema de arquivo/proc
.) Isto fornece aos usuários um nível indireto de controle sob a prioridade de processo, mas a lista de prioridade dinâmica pode somente ser modificada diretamente pelo CFS.
4.2.3. Seleção da política
SCHED_OTHER
e deixe o sistema gerenciar o uso da CPU para você.
SCHED_FIFO
. Caso você tenha um número de threads pequeno, considere isolar um soquete de CPU e mover suas threads para aqueles núcleos de soquete, assim não existirão outras threads competindo por tempo nos núcleos.
4.3. Interrupções e Ajuste de IRQ
/proc/interrupts
relaciona o número de interrupções por CPU por dispositivo de E/S. Ele exibe o número de IRQ, o número daquela interrupção manipulada por cada núcleo da CPU, o tipo de interrupção, e uma lista delimitada por vírgulas de motoristas que estão registrados para receber essa interrupção. (Consulte a página de manual proc (5) para mais detalhes: man 5 proc
)
smp_affinity
, que define os núcleos da CPU que podem executar o ISR para aquele IRQ. Esta propriedade pode ser usada para aprimorar o desempenho de aplicativo atribuindo a afinidade de interrupção e a afinidade do thread do aplicativo para um ou mais núcleos específicos. Isto permite o compartilhamento da linha do cache entre interrupções especificadas e threads de aplicativo.
/proc/irq/IRQ_NUMBER/smp_affinity
, que pode ser visualizado e modificado pelo usuário root. O valor armazenado neste arquivo é um bit-mask hexadecimal representando todos os núcleos da CPU no sistema.
# grep eth0 /proc/interrupts 32: 0 140 45 850264 PCI-MSI-edge eth0
smp_affinity
apropriado:
# cat /proc/irq/32/smp_affinity f
f
, ou seja, o IRQ pode ser atentido em qualquer CPU no sistema. Configurar este valor para 1
, como se segue, significa que somente a CPU 0 pode atender esta interrupção:
# echo 1 >/proc/irq/32/smp_affinity # cat /proc/irq/32/smp_affinity 1
smp_affinity
para grupos discretos de 32 bits. Isto é necessário em sistemas com mais do que 32 núcleos. Por exemplo, o seguinte exemplo demonstra que o IRQ 40 é atendido em todos os núcleos de um sistema de núcleo de 64:
# cat /proc/irq/40/smp_affinity ffffffff,ffffffff
# echo 0xffffffff,00000000 > /proc/irq/40/smp_affinity # cat /proc/irq/40/smp_affinity ffffffff,00000000
Nota
smp_affinity
de um IRQ define o hardware para que a decisão de atenter uma interrução com uma CPU específica seja feita em nível de hardware, sem intervenção do kernel.
4.4. Melhorias do NUMA no Red Hat Enterprise Linux 6
4.4.1. Bare-metal e Otimizações de Escalabilidade
4.4.1.1. Melhorias no aviso sobre a topologia
- detecção de topologia aprimorada
- Isto permite que o sistema operacional detecte os detalhes do hardware de baixo nível (tais como CPUs lógicas, threads hiper, núcleos, sockets, nós de NUMA e tempos de acesso entre nós) durante a inicialização, e otimizar o processamento em seu sistema.
- agendador totalmente justo
- Este novo modo de agendamento assegura que o tempo de execução seja compartilhado entre os processos elegíveis. Combinado a isto, a detecção da topologia permite os processos serem agendados nas CPUs dentro do mesmo soquete para evitar a necessidade por acesso de memória remota cara, e assegurar que o conteúdo do cache está preservado onde for possível.
malloc
malloc
agora é otimizado para assegurar que as regiões da memória que estão alocadas a um processo estejam o mais próximas fisicamente o possível do núcleo no qual o processo está sendo executado. Isto aumenta a velocidade do acesso de memória.- Alocação de buffer de E/S do skbuff
- Da mesma forma que o
malloc
, isto agora otimiza o uso de memória que esteja fisicamente próxima da CPU manuseando as operações de E/S como interrupções de dispositivo. - afinidade de interruptção de dispositivo
- Informações gravadas pelos drivers de dispositivo sobre o qual a CPU manuseia quais interrupções podem ser usadas para restringir manuseio de interrupção em CPUs dentro do mesmo soquete físico, preservando afinidade de cache e limitando comunicação de soquete cruzado de alto volume.
4.4.1.2. Melhorias em Sincronização de Multi-processador
- Bloqueios de Read-Copy-Update (RCU)
- Geralmente, 90% dos bloqueios são adquiridos somente para leitura. O bloqueio de RCU remove a necessidade de obter bloqueio de acesso exclusivo quando os dados que estiverem sendo acessados não sejam sendo modificados. Este modo de bloqueio é agora usado em alocação de memória de cache de página: bloqueio é agora usado somente para operações de alocação e desalocação.
- algorítimos per-CPU e per-socket
- Muitos algoritmos foram atualizados para realizar a coordenação de bloqueio entre CPUs cooperando na mesma soquete para permitir mais bloqueio refinado. Diversos spinlocks globais foram substituídos por métodos de bloqueio per-socket e zonas de alocador de memória atualizadas e listas de páginas de memórias relacionadas permietem alocação lógica para atravessar um subconjunto mais eficiente das estruturas de dados de mapeamento de memória ao executar operações de alocação ou desalocação.
4.4.2. Otimizaçãoes de Virtualização
- Fixação de CPU
- Convidados virtuais podem ser vinculados para executar em um soquete específico para otimizar o uso do cache local e remover a necessidade de comunicações inter-soquete caras e acesso de memória remota.
- transparent hugepages (THP)
- Com o THP habilitado, o sistema realiza automaticamente as requisições de alocação de memória do NUMA para quantias contínuas grandes de memória, reduzindo a contenção de bloqueio e o número de operações de gerenciamento de memória do translation lookaside buffer (TLB) necessárias e gerando um crescente desempenho de até 20% em convidados virtuais.
- Implementação de E/S baseado no kernel
- O subsistema de E/S de convidado virtual foi implementado no kernel, reduzindo imensamente o custo de comunicação entre-nó e acesso de memória, evitando uma alta quantia de mudança de contexto e sobrecarga de sincronização e comunicação.
Capítulo 5. Memória
5.1. Buffer de Conversão Enorme à parte (Huge TLB)
/usr/share/doc/kernel-doc-version/Documentation/vm/hugetlbpage.txt
5.2. Huge Pages e Transparent Huge Pages
- Aumente o número de entradas de tabela de páginana unidade de gerenciamento de memória de hardware
- Aumente o tamanho da página
5.3. Utilizando o Valgrind para o Uso de Memória de Perfil
valgrind --tool=toolname program
memcheck
, massif
, ou cachegrind
), e program com o programa que você deseja realizar o perfil com o Valgrind. Tenha em mente que a instrumentação do Valgrind fará com que o seu programa execute mais vagarosamente do que o normal.
man valgrind
quando o pacote valgrind estiver instalado, ou encontrado nos seguintes locais:
/usr/share/doc/valgrind-version/valgrind_manual.pdf
, and/usr/share/doc/valgrind-version/html/index.html
.
5.3.1. Uso de Memória de Perfil com o Memcheck
valgrindprograma
, sem especificar -- tool=memcheck
. Ele detecta e relata uma série de erros de memória que podem ser difíceis de detectar e diagnosticar, assim como o acesso à memória que não deve ocorrer, o uso de valores indefinidos ou não inicializado, memória heap liberada incorretamente, sobrepondo ponteiros, e vazamentos de memória. Os programas funcionam de dez à trinta vezes mais lentamente com Memcheck que quando executado normalmente.
/usr/share/doc/valgrind-version/valgrind_manual.pdf
.
--leak-check
- Quando ativado, Memcheck procura por vazamentos de memória quando termina o programa cliente. O valor padrão é
summary
, que gera o número de vazamentos encontrados. Outros valores possíveis sãoyes
efull
, sendo que ambos dão detalhes de cada vazamento individual, eno
, que desativa a verificação de vazamento de memória. --undef-value-errors
- Quando ativado (definido para
yes
), Memcheck relata erros quando os valores indefinidos são usados. Quando desativado (definido parano
), os erros de valor indefinido não são relatados. Isso é ativado por padrão. Desativar ele irá acelerar Memcheck. --ignore-ranges
- Permite que o usuário especifique uma ou mais faixas que o Memcheck deva ignorar durante a verificação de endereçamento. Múltiplas faixas são delimitadas por vírgulas, por exemplo,
--ignore-ranges=0xPP-0xQQ,0xRR-0xSS
.
/usr/share/doc/valgrind-version/valgrind_manual.pdf
.
5.3.2. Uso de Cache de Perfil com o Cachegrind
# valgrind --tool=cachegrind program
- as leituras de Cache de instrução de primeiro nível (ou as instruções executadas) e falta de leituras, e falta de leitura de instrução de cache de último nível;
- leituras de cache de dados (ou leituras de memória), falta de leituras, e falta de leituras de dados do cache de último nível;
- gravações de cache de dados (ou gravações de memória), falta de gravações, e falta de gravações de último nível
- ramificações condicionais executadas e mal previstas; e
- ramificações indiretas executadas e mal previstas.
cachegrind.out.pid
por padrão, onde pid é o ID do processo do programa no qual você executou o Cachegrind). Este arquivo pode ser processado mais tarde acompanhado da ferramenta cg_annotate, como abaixo:
# cg_annotate cachegrind.out.pid
Nota
# cg_diff first second
--I1
- Especifica o tamanho, associatividade e tamanho da linha do cache de instrução de primeiro nível, separado por vírgulas:
--I1=size,associativity,line size
. --D1
- Especifica o tamanho, associatividade e tamanho da linha do cache de dados de primeiro nível, separado por vírgulas:
--D1=size,associativity,line size
. --LL
- Especifica o tamanho, associatividade e tamanho da linha do cache último nível, separado por vírgulas:
--LL=size,associativity,line size
. --cache-sim
- Habilita ou desabilita a coleção de acesso a cache e contas faltando. O valor padrão é
yes
(habilitado).Note que desabilitar este e--branch-sim
deixa o Cachegrind sem informações para coletar. --branch-sim
- Habilita ou desabilita a coleção de instruções de ramificação e contas mal previstas. Isto é definido para
no
(desabilitado) por padrão, pois ele desacelera o Cachegrind em aproximadamente 25 porcento.Note que desabilitar este e--cache-sim
deixa o Cachegrind sem informações para coletar.
/usr/share/doc/valgrind-version/valgrind_manual.pdf
.
5.3.3. Heap do Perfil e Espaço de Pilha com Massif
massif
como uma ferramenta Valgrind que você deseja utilizar:
# valgrind --tool=massif program
massif.out.pid
, onde pid é o ID de processo do programa especificado.
ms_print
, assim como:
# ms_print massif.out.pid
--heap
- Especifica se deve realizar perfil de heap. Este valor padrão é
yes
. O perfil do Heap pode ser desabilitado configurando esta opção parano
. --heap-admin
- Especifica o número de bytes por bloco a usar para a administração quando um perfil de heap for habilitado. O valor padrão é
8
bytes por bloco. --stacks
- Especifica se deve criar o perfil da pilha. O valor padrão é
no
(desabilitado). Para habilitar perfis de pilha, definir esta opção parayes
, mas esteja ciente de que isso desacelera o Massif. Observe também que Massif assume que a pilha principal tem tamanho zero na inicialização para indicar melhor o tamanho da porção da pilha sobre a qual o programa que está sendo perfilado tem controle. --time-unit
- Especifica a unidade de tempo utilizado para a criação de perfil. Há três valores válidos para esta opção: instruções executadas (
i
), o valor padrão, que é útil na maioria dos casos, tempo real (ms
, em milissegundos), que pode ser útil em certos casos, e bytes alocados / desalocado na pilha e / ou stack (B
), que é útil para os programas de muito curto prazo, e para fins de teste, porque é o mais reproduzível em máquinas diferentes. Esta opção é útil ao criar gráficos de resultado de Massif comms_print
.
/usr/share/doc/valgrind-version/valgrind_manual.pdf
.
5.4. Ajuste de Capacidade
overcommit_memory
temporariamente para 1
, execute:
# echo 1 > /proc/sys/vm/overcommit_memory
sysctl
. Para maiores detalhes, consule o Deployment Guide, disponível em http://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/.
Ajustes de Memória relacionados com a Capacidade
/proc/sys/vm/
no sistema de arquivo do proc.
overcommit_memory
- Define as condições que determinam se uma requisição de memória grande é aceita ou negada. Existem três valores possíveis para este parâmetro:
0
— A configuração padrão. O kernel realiza o overcommit heurístico do kernel, manuseando isto através da estimativa da quantia de memória disponível e queda de requisições que sejam totalmente inválidas. Infelizmente, como a memória é alocada utilizando um heurístico ao invés de um algorítimo preciso, esta configuração pode as vezes permitir que a memória disponível no sistema seja sobrecarregada.1
— O kernel não faz manuseio de overcommit de memória. Sob esta configuração, o potencial para sobrecarga de memória aumenta, como também o desempenho para tarefas intensivas de memória.2
— The kernel nega requisições para memórias iguais ou maiores do que a quantia de swap total disponível e a porcentagem de RAM física especificada emovercommit_ratio
. Esta configuração é a melhor se você quiser diminuir o risco de overcommit de memória.Nota
Esta configuração é recomendada somente para sistemas com áreas de swap maiores do que sua memória física.
overcommit_ratio
- Especifica a porcentagem da RAM física considerada quando o
overcommit_memory
está definido para2
. O valor padrão é50
. max_map_count
- Define o número máximo de áreas de mapa de memória que um processo pode utilizar. Na maioria dos casos, o valor padrão de
65530
é adequado. Aumente este valor se seu aplicativo precisar mapear mais do que este número de arquivos. nr_hugepages
- Define o número de hugepages configurado no kernel. O valor padrão é 0. É possível alocar (ou desalocar) hugepages, somente se existirem páginas livres contínuas fisicamente no sistema. As páginas reservadas por este parâmetro não podem ser utilizadas para outros propósitos. Mais informações podem ser obtidas da documentação instalada:
/usr/share/doc/kernel-doc-kernel_version/Documentation/vm/hugetlbpage.txt
Ajustes de Kernel relacionados com a Capacidade
/proc/sys/kernel/
no sistema de arquivo do proc.
msgmax
- Define o tamanho permitido em bites de qualquer mensagem única em uma fila de mensagem. Este valor não deve exceder o tamanho da fila (
msgmnb
). O valor padrão é65536
. msgmnb
- Define o tamanho máximo em bites de uma única fila de mensagem. O valor padrão é
65536
bytes. msgmni
- Define o número máximo de identificadores de filas de mensagens (e portanto o número máximo de filas). O valor padrão em máquinas com arquitetura 64-bit é de
1985
; for 32-bit architecture, the default value is1736
. shmall
- Define a quantia total de memória compartilhada em bites que possa ser utilizada no sistema de uma só vez. O valor padrão para máquinas com arquitetura de 64-bit é de
4294967296
; para arquiteturas 32-bit o padrão é de268435456
. shmmax
- Define o segmento máximo de memória compartilhada pelo kernel, em bites. O valor padrão em máquinas com arquitetura de 64-bit é de
68719476736
; para arquitetura de 32-bit, o valor padrão é de4294967295
. Note, no entanto, que o kernel suporta valores muito maiores do que este. shmmni
- Define o número máximo de amplitude de sistema de sementos de memória compartilhada. O valor padrão é de
4096
em ambas arquiteturas de 64-bit e 32-bit. threads-max
- Define o número máximo de amplitude de sistema de discussões (tarefas) a serem utilizadas pelo kernel de uma só vez. O valor padrão é igual ao valor
max_threads
do kernel. A formula em uso é:max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE )
O valor mínimo dethreads-max
é de20
.
Ajustes de Sistema de Arquivo Relacionada com a Capacidade
/proc/sys/fs/
.
aio-max-nr
- Define o número máximo permitido de eventos em todos os contextos de E/S assíncrona. O valor padrão é de
65536
.Note que ao modificar este valor, você não pré-aloca ou redimensiona qualquer estrutura de dados do kernel. file-max
- Lista o número máximo de manuseio de arquivo que o kernel aloca. O valor padrão coincide com o valor de
files_stat.max_files
no kernel, o qual está definido para o valor maior entre os(mempages * (PAGE_SIZE / 1024)) / 10
, ouNR_FILE
(8192 in Red Hat Enterprise Linux). Aumentar este valor pode resolver erros causados pela falta de manuseios de arquivos disponíveis.
Ajustes Out-of-Memory Kill
/proc/sys/vm/panic_on_oom
para 0
instrui o kernel a chamar a função oom_killer
quando ocorrer o OOM. Geralmente o oom_killer
pode eliminar processos invasores e o sistema sobrevive.
oom_killer
. Está localizada em /proc/pid/
no sistema de arquivo do proc, onde pid é o ID do processo.
oom_adj
- Define um valor a partir de
-16
até15
que ajuda a determinar ooom_score
de um processo. Quanto maior o valor dooom_score
maior a probabilidade do processo ser eliminado pelooom_killer
. Configurar um valoroom_adj
de-17
desabilita ooom_killer
para aquele processo.Importante
Qualquer processo gerado pelo processo ajustado, irá herdar ooom_score
daquele processo. Por exemplo, se um processosshd
é protegido da funçãooom_killer
, todos os processos iniciados pela sessão SSH também serão protegidas. Isto pode afetar a habilidade das funções dooom_killer
para salvar o sistema se ocorrer um OOM.
5.5. Ajustando Memória Virtual
swappiness
- Um valor de 0 à 100 que controla o grau para o qual o sistema altera. Um valor alto dá prioridade ao desempenho do sistema, alterando os processos de forma agressiva fora da memória física quando eles não estão ativos. Um valor baixo dá prioridade à interação e evita processos de alteração fora da memória física o quanto de tempo for possível, o que diminui a latência de resposta. O valor padrão é
60
. min_free_kbytes
- O número mínimo de kilobytes para manter livre em todo o sistema. Este valor é usado para calcular um valor de marca d'água para cada zona de baixa memória, que recebem um número de páginas livres reservadas proporcionalmente ao seu tamanho.
Atenção
Seja cauteloso ao configurar este parâmetro, pois tanto valores muito baixos como muito altos podem causar danos.Configuraçãomin_free_kbytes
muito baixo previne o sistema de reclamar memória. Isto pode resultar em travamento de sistema e processos múltiplos de OOM-killing.No entanto, configurar este parâmetro para um valor que seja muito alto (5-10% do total de memória de sistema) causará uma falta de memória em seu sistema imediatamente. O Linux foi criado para utilizar todas as RAM disponíveis para realizar um cache dos dados de sistema de arquivo. Configurar um valor alto demin_free_kbytes
resulta em uma perda de tempo quando o sistema reclama memória. dirty_ratio
- Define um valor de porcentagem. Limpeza de dados sujos inicia com (via pdflush) quando os dados sujos comprimem esta porcentagem da memória de sistema total. O valor padrão é
20
. dirty_background_ratio
- Define um valor de porcentagem. Limpeza de dados sujos inicia no pano de fundo (via pdflush) quando os dados sujos comprimem esta porcentagem da memória de sistema total. O valor padrão é
10
. drop_caches
- Configurar este valor para
1
,2
, or3
faz com que o kernel derrube diversas páginas de combinação cache e cache de slab.- 1
- O sistema invalida e libera todas as memórias de cache de página.
- 2
- O sistema libera toda a memória não utilizada de cache de slab.
- 3
- O sistema libera toda a memória de cache de página e cache de slab.
Esta não é uma operação destrutiva. Como os objetos sujos não podem ser liberados, recomenda-se executar osync
antes de configurar este valor de parâmetro.Importante
O uso dodrop_caches
para liberar memória não é recomendado em um ambiente de produção.
swappiness
temporariamente para 50
, execute:
# echo 50 > /proc/sys/vm/swappiness
sysctl
. Para mais informações consulte o Deployment Guide, disponível em http://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/.
Capítulo 6. Entrada/Saída
6.1. Recursos
- Discos de estado sólido (SSDs) agora são reconhecidos automaticamente, e o desempenho do agendador de E/S é ajustado para tirar vantagem das E/S altas por segundo (IOPS) que estes dispositivos podem realizar.
- Foi adicionado um suporte descartado no kernel para reportar classes de blocos não utilizadas para armazenamento adjacente. Isto ajuda o SSDs com seus algorítimos de nivelamento por uso. Isto também ajuda o armazenamento que suporta provisionamento de blocos lógicos (um tipo de espaço de endereço virtual para armazenamento) po manter as marcações mais perto na quantia atual do armanzenamento em uso.
- A implementação da barreira do sistema de arquivo foi sobreposta no Red Hat Enterprise Linux 6.1 para torná-la mais útil.
pdflush
foi substituído pelas discussões de flusher por dispositivo de backup, que aprimora muito a escalabilidade do sistema em configurações com contas LUN grandes.
6.2. Análises
Figura 6.1. aio-stress output for 1 thread, 1 file
- aio-stress
- iozone
- fio
6.3. Ferramentas
si
(swap in), so
(swap out), bi
(block in), bo
(block out), e wa
(E/S tempo de espera). si
e so
são úteis quando o espaço swap estiver no mesmo dispositivo que sua partição de dados, e como um indicador de pressão de memória generalizada. O si
e bi
são operações de leitura, enquanto o so
e bo
são operações de gravação. Cada uma destas categorias é reportada em kilobytes. O wa
é o tempo ocioso, ele indica qual porção de fila de execução está bloqueada esperando pela E/S ser concluída.
free
, buff
, e cache
também valem ser observadas. O valor cache
crescendo junto do valor bo
seguido de uma caída de sistema cache
e um aumento no free
indica que o sistema está realizando um write-back e invalidação do cache da página.
avgqu-sz
), você poderá estimar sobre como o armazenamento deveria funcionar utilizando gráficos que você gerou ao caracterizar o desempenho de seu armazenamento. Algumas generalizações se aplicam: por exemplo, se a media de tamanho de requisição é de 4KB e a média de tamanho de fila é de 1, a produtividade pode não ser tão útil.
8,64 3 1 0.000000000 4162 Q RM 73992 + 8 [fs_mark] 8,64 3 0 0.000012707 0 m N cfq4162S / alloced 8,64 3 2 0.000013433 4162 G RM 73992 + 8 [fs_mark] 8,64 3 3 0.000015813 4162 P N [fs_mark] 8,64 3 4 0.000017347 4162 I R 73992 + 8 [fs_mark] 8,64 3 0 0.000018632 0 m N cfq4162S / insert_request 8,64 3 0 0.000019655 0 m N cfq4162S / add_to_rr 8,64 3 0 0.000021945 0 m N cfq4162S / idle=0 8,64 3 5 0.000023460 4162 U N [fs_mark] 1 8,64 3 0 0.000025761 0 m N cfq workload slice:300 8,64 3 0 0.000027137 0 m N cfq4162S / set_active wl_prio:0 wl_type:2 8,64 3 0 0.000028588 0 m N cfq4162S / fifo=(null) 8,64 3 0 0.000029468 0 m N cfq4162S / dispatch_insert 8,64 3 0 0.000031359 0 m N cfq4162S / dispatched a request 8,64 3 0 0.000032306 0 m N cfq4162S / activate rq, drv=1 8,64 3 6 0.000032735 4162 D R 73992 + 8 [fs_mark] 8,64 1 1 0.004276637 0 C R 73992 + 8 [0]
Total (sde): Reads Queued: 19, 76KiB Writes Queued: 142,183, 568,732KiB Read Dispatches: 19, 76KiB Write Dispatches: 25,440, 568,732KiB Reads Requeued: 0 Writes Requeued: 125 Reads Completed: 19, 76KiB Writes Completed: 25,315, 568,732KiB Read Merges: 0, 0KiB Write Merges: 116,868, 467,472KiB IO unplugs: 20,087 Timer unplugs: 0
- Q — Uma E/S de bloco é Enfileirada
- G — Obtenha RequisiçãoUma E/S de bloco enfileirada recentemente, não foi um candidato para mesclar com qualquer requisição existente, portanto uma requisição de camada de bloco nova é alocada.
- M — Uma E/S de bloco é Mesclada com uma requisição existente.
- I — Uma requisição é inserida na fila dos dispositivos.
- D — Uma requisição é enviada ao Dipositivo
- C — Uma requisição é concluída pelo motorista
- P — A fila do dispositivo de bloco é Ligada, para permitir a agregação de requisições.
- U — A fila de dispositivo é Desligada, permitindo que as requisições agregadas sejam enviadas ao dispositivo.
- Q2Q — tempo entre requisições enviadas à camada de bloco.
- Q2G —quanto tempo leva do tempo que uma E/S de bloco é enfileirada até o tempo que ela obtém uma requisição alocada para isto.
- G2I — quanto tempo leva desde que um pedido é atribuído até o momento em que é inserido na fila do dispositivo
- Q2M — quanto tempo leva desde quando um bloco de E/S foi enfileiirado até que se mescle com um pedido existente
- I2D — quanto tempo demora a partir do momento que um pedido é inserido na fila do dispositivo até que seja realmente emitido para o dispositivo
- M2D — quanto tempo leva desde que um bloco E/S seja mesclado com um pedido de saída até que o pedido seja emitido para o dispositivo
- D2C —tempo de serviço da requisição por dispositivo
- Q2C — tempo total gasto em camada de bloco para uma requisição
Figura 6.2. Exemplo de resultado do seekwatcher
6.4. Configuração
6.4.1. Completely Fair Queuing (CFQ)
ionice
, ou programaticamente atribuída através da chamada de sistema ioprio_set
. Por padrão, os processos são colocados na classe de agendamento de melhor esforço. As classes de agendamento em tempo real e de melhor esforço são subdivididos em oito prioridades de E/S dentro de cada classe, sendo a prioridade 0 a mais alta e 7 a mais baixa. Processos na classe de agendamento em tempo real estão programados muito mais agressivamente do que em processos em melhor esforço ou inativo, portanto, qualquer E/S de tempo real programada é sempre realizada antes da E/S de melhor esforço ou ocioso. Isto significa que a prioridade de E/S em tempo real pode desaparecer com as classes de melhor esforço e ociosas. O agendamento do melhor-esforço é a classe de agendamento padrão e 4 é a prioridade padrão nesta classe. Processos na classe de agendamento de repouso são apenas notados quando não há nenhuma outra E/S pendente no sistema. Assim, é muito importante definir apenas a classe de agendamento de E/S de um processo para ocioso se a E/S do processo não for necessária para fazer quaisquer progressos futuros.
/sys/block/device/queue/iosched/
:
slice_idle = 0 quantum = 64 group_idle = 1
group_idle
está configurado para 1, existe ainda o potencial para interrupções de E/S (onde o armazenamento do backend não é cheio devido à ociosidade). No entanto, estas interrupções serão menos frequentes do que a ociosidade em cada fila no sistema.
Ajustáveis
back_seek_max
- Buscas revertidas são geralmente ruins para o desempenho, pois podem incorrer em maiores atrasos no reposicionamento dos cabeçalhos do que as buscas normais. No entanto, o CFQ ainda vai realizá-las, se elas forem pequenas o suficiente. Este ajuste controla a distância máxima em KB que o agendador de E/S permitirá a procura revertida. O padrão é
16
KB. back_seek_penalty
- Devido à ineficiência da procura revertida, uma penalidade está associada a cada um. A pena é um multiplicador, por exemplo, considere a posição da cabeça do disco de 1024 KB. Suponha que existem dois pedidos na fila, um de 1008KB e outro em 1040KB. Os dois pedidos estão equidistantes da posição da cabeça atual. No entanto, depois de aplicar a pena de procura invertida (padrão: 2), a requisição em uma posição futura em discos estará agora duas vezes mais perto do que as requisições anteriores. Assim, a cabeça moverá para frente.
fifo_expire_async
- Este ajuste controla quanto tempo uma requisição assíncrona (gravação de buffer) pode ficar sem serviços. Após o tempo de expiração (em milisegundos), uma requisição assíncrona faltando será movida para a lista de expedição. O padrão é
250
ms. fifo_expire_sync
- Este é o mesmo que o ajuste fifo_expire_async, para requisições em sincronia (leitura e gravação de O_DIRECT). O padrão é
125
ms. group_idle
- Quando definido, o CFQ ficará em ocioso no último processo emitindo a E/S em um cgroup. Isto deve ser definido para
1
ao usar o cgroup de E/S de peso proporcional e configurando oslice_idle
to0
(geralmente feito em armazenamento rápido). group_isolation
- Se a isolação de grupo estiver ativada (definida para
1
), ela fornecerá uma isolação mais forte entre grupos a custo de rendimento. Em geral, se a isolação de grupo estiver desativada, a fairness é fornecida para cargas de trabalho sequenciais somente. A ativação da isolação de grupo, proporcionará fairness para ambas cargas de trabalho aleatória e sequencial. O valor padrão é0
) (desabilitado). Consulte oDocumentation/cgroups/blkio-controller.txt
para mais informações. low_latency
- Quando uma latência baixa é ativada (definida para
1
), o CFQ tenta fornecer um máximo de tempo de espera de 300 ms para cada processo emitindo E/S em um dispositivo. Isto favorece o fairness sobre o rendimento. Desabilitar a latência baixa (definindo-a para0
) ignora a latência de alvo, permitindo que cada processo no sistema obtenha uma faixa o tempo integral. Baixa latência é ativada por padrão. quantum
- O quantum controla o número de E/Ss que o CFQ irá enviar ao armazenamento por vez, principalmente limitando a profundidade da fila do dispositivo. Por padrão, isto é definido para
8
. O armazenamento pode suportar filas muito mais produndas, mas aumentar oquantum
também terá um impacto negativo na latêcia, especialmente na presença de cargas de trabalho de gravação sequencial grandes. slice_async
- Este ajuste controla a parte de tempo alocada para cada processo que emite E/S assíncronas (gravação em buffer). Por padrão ele é ajustado para
40
ms. slice_idle
- Isto especifica quanto tempo o CFQ deve ficar ocioso enquanto espera por novas solicitações. O valor padrão no Red Hat Enterprise Linux 6.1 e anteriores a ele é de
8
ms. No Red Hat Enterprise Linux 6.2 e posteriores a ele, o valor padrão é0
. O valor zero melhora a taxa de transferência de armazenamento RAID externo, removendo todos os ociosos da fila e nível de árvore de serviço. No entanto, um valor de zero pode degradar o rendimento da armazenagem não RAID interna, uma vez que aumenta o número total de procura. Para o armazenamento não-RAID, recomendamos umaslice_idle
valor que é maior do que 0. slice_sync
- Este ajuste dita a faixa de tempo alocada para um processo emitindo E/S assíncronas (leitura ou gravação diretas). O padrão é
100
ms.
6.4.2. Agendador de Prazo de E/S (Deadline I/O Scheduler)
Ajustáveis
fifo_batch
- Isto determina o número de leituras e gravações a serem emitidos em uma única vez. O padrão é
16
. Configurar este número para um valor maior resultará em melhor rendimento mas também aumentará a latência. front_merges
- Você pode definir este ajuste para
0
se você souber se sua carga de trabalho vai gerar alguma mesclagem de frente. A não ser que você tenha medido o cabeçalho desta verificação, recomenda-se deixá-lo como a configuração padrão. (1
). read_expire
- Este ajuste permite que você ajuste o número de milisegundos no qual a requisição de leitura deve ser atendida. Por padrão isto é definido para
500
ms (meio segundo). write_expire
- Este ajuste permite que você defina o número de milisegundos no qual uma requisição de gravação deve ser atendida. Por padrão ele é definido para
5000
ms (cinco segundos). writes_starved
- Este ajuste controla quantos grupos de leituras podem ser processados antes de processar um único grupo de gravação. Quanto maior o ajuste mais preferência é dada à leitura.
6.4.3. Noop
/sys/block/sdX/queue tunables
- add_random
- Em alguns casos, o cabeçalho de eventos de E/S que contribuem para o pool de entropia para
/dev/random
é mensurável. Em alguns casos, pode ser melhor ajustar este valor para 0. max_sectors_kb
- Por padrão, o tamanho máximo de requisição para disco é de
512
KB. Este ajuste pode ser utilizado tanto para aumentar ou diminuir o valor. O valor mínimo é limitado por tamanho de bloco lógico; o valor máximo é limitado pelomax_hw_sectors_kb
. Existem alguns SSDs que possuem um pior desempenho quando os tamanhos de E/S excedem o tamanho de bloco de remoção interno. Em alguns casos recomendamos ajustar omax_hw_sectors_kb
para baixo para apagar o tamanho do bloco. Você pode testar isto utilizando um gerador de E/S tal como o iozone ou aio-stress, variando o tamanho de histórico, por exemplo, de512
bytes para1
MB. nomerges
- Este ajuste é inicialmente um assistente de depuração. A maioria de cargas de trabalhos de mesclagem de requisição (até mesmo em armazenamento mais rápido tal como SSDs). Em alguns casos, no entanto, deseja-se desabilitar a mesclagem, tal como quando você vê quantos IOPS um backend de armazenamento pode processar sem desabilitar o cabeçalho de leitura ou realizando uma E/S aleatória.
nr_requests
- Cada fila de requisição tem um limiete no número total de descritores de requisição que pode ser alocado para cada uma das E/Ss das leituras e gravações. Por padrão, o número é
128
, o que significa 128 leituras e 128 gravações que podem ser enfileiradas uma por vez antes de colocar um processo em inativo. O processo inativo é o próximo a tentar alocar uma requisição, não necessariamente o processo que tenha alocado todas as requisições disponíveis.Se você possui aplicativo de latência sensível, você deve considerar diminuir o valor donr_requests
em sua fila de requisições e limitar a profundidade da fila de comando no armazenamento para um número mais baixo (até mesmo tão baixo quanto1
), para que a E/S writeback não possa alocar todos os descritores de requisições disponíveis e preencher a fila de dispositivo com uma E/S de gravação. Uma vez que onr_requests
tenha sido alocado, todos os outros processos que estão tentando realizar uma E/S serão transformados em inativos para esperar por requisições a ficarem disponíveis. Isto torna as coisas mais justas, pois as requisições são então distribuídas em uma moda de repetição alternada (ao invés de deixar um processo consumí-los todos em sucessão rápida). Note que este é o único problema ao utilizar a data limite ou agendadores de noop, pois a configuração CFQ padrão protege contra esta situação. optimal_io_size
- Em algumas circunstâncias o armazenamento adjacente irá reportar um tamanho de E/S adequado. Isto é mais comum em hardware e software RAID, onde o tamanho da E/S adequada é o tamanho da faixa. Se este valor é reportado, os aplicativos devem emitir uma E/S alinhada e em múltiplos do tamanho de E/S adequado sempre que possível.
read_ahead_kb
- O sistema operacional pode detectar quando um aplicativo está lendo dados seqüencialmente de um arquivo ou de disco. Nesses casos, ele executa um algoritmo inteligente de leitura antecipado, em que mais dados do que é solicitado pelo usuário é lido a partir do disco. Assim, nas próximas tentativas do usuário de ler um bloco de dados, ele já o fará no cache da página do sistema operacional. A desvantagem é que o sistema operacional pode ler mais dados do disco do que o necessário, o que ocupa espaço no cache de página até que ele seja expulso por causa da alta pressão de memória. Depois de vários processos realizando leituras falsas futuras, aumentaria a pressão de memória nesta circunstância.Para os dispositivos de mapeador, recomenda-se aumentar o valor do
read_ahead_kb
para um número maior, tal como8192
. A razão é que um mapeador de dispositivo é geralmente criado de dispositivos adjacentes múltiplos. Configurar este valor para um padrão (128
KB) multiplicado pelo número de dispositivos que você está mapeando é um bom começo para ajuste. rotational
- Discos rígidos tradicionais são rotacionais (feitos de discos rodopiantes). Os SSDs no entanto, não. A maioria de SSDs promoverão isto adequadamente. Se, no entanto, você encontar um dispositivo que não promova esta bandeira adequadamente, pode ser necessário configurar o rotacional para
0
manualmente; quando o rotacional estiver desabilitado, o elevador de E/S não usará lógica, que significa reduzir buscas, uma vez que existe pouca penalidade para busca de operações em mídia não rotacional. rq_affinity
- Conclusões de E/S podem ser processadas em uma CPU diferente daquela que emitiu a E/S. Configurar o
rq_affinity
para1
faz com que o kernel entregue conclusões para a CPU na qual a E/S foi emitida. Isto pode aprimorar a efetividade do cache de dados de CPU.
Capítulo 7. Sistemas de Arquivos
7.1. Considerações de ajustes para Sistemas de Arquivo
7.1.1. Formatando Opções
O tamanho do bloco pode ser selecionado no tempo mkfs
. A classe de tamanhos válidos depende do sistema: o limite acima é o tamanho máximo da página do sistema host, equanto o limite mais baixo depende do sistema de arquivo utilizado. O tamanho do bloco padrão é adequado para a maioria dos casos de uso.
Se seu sistema utiliza armazenamento em faixas tal qual o RAID, você poderá aprimorar o desempenho, alinhando os dados e metadados com a geometria de armazenamento adjacente no tempo mkfs
. Para o RAID software (LVM ou MD) e alguns armazenamentos de hardware corporativos, esta informação é enfileirada e definida automaticamente, mas em muitos casos o administrador precisa especificar esta geometria manualmente com o mkfs
na linha de comando.
Cargas de trabalho de metadados intensivos significa que a seção de log de um sistema de arquivo de agendamento (como o ext4 e XFS) é atualizado muito frequentemente. Para minimizar o tempo de busca do sistema de arquivos do diário, você pode colocar o diário no armazenamento dedicado. Note, no entanto, que a colocação do diário em armazenamento externo é mais lenta que o sistema de arquivos primário possa anular qualquer vantagem potencial associado com o uso de armazenamento externo.
Atenção
mkfs
, com os dispositivos de diário sendo especificados no tempo de montagem. Consulte as páginas man mke2fs(8)
, mkfs.xfs(8)
, e mount(8)
para maiores informações.
7.1.2. Opções de montagem
Uma barreira de gravação é um mecanismo do kernel usado para assegurar que os metadados do sistema de arquivos foi gravado corretamente e ordenado em armazenamento persistente, mesmo quando os dispositivos de armazenamento com gravações de caches voláteis perdem o poder. Os sistemas de arquivos com barreiras de gravação ativadas também garantem que todos os dados transmitidos via fsync ()
persistem através de uma queda de energia. O Red Hat Enterprise Linux permite barreiras por padrão em todos os hardwares que as suportam.
fsync ()
pesadamente, ou que cria e apaga muitos arquivos pequenos. Para o armazenamento, sem o cache de gravação volátil, ou no caso raro onde as inconsistências do sistema de arquivos e perda de dados após uma perda de potência é aceitável, barreiras podem ser desativadas usando a opção de montagem nobarrier
. Para mais informações, consulte o Guia de Administração de Armazenamento .
HIstóricamente, quando um arquivo é lido, o tempo de acesso (atime
) para aquele arquivo deve ser atualizado no metadado inode, que involve E/S de gravações adicionais. Se os metadados forem precisos atime
não forem necessários, monte o sistema de arquivo com a opção noatime
para eliminar estas atualizações de metadados. Na maioria dos casos, no entanto, o atime
não é um cabeçalho grande devido ao comportamento do atime relativo padrão (ou relatime
) no kernel do Red Hat Enterprise Linux 6. O comportamente do relatime
atualiza somente o atime
se o atime
for mais vejo do que o tempo de modificação (mtime
) ou tempo de mudança de status (ctime
).
Nota
noatime
também habilita o comportamento do nodiratime
; não há necessidade de definir ambos noatime
e nodiratime
.
O Read-ahead acelera acesso de arquivo buscando antecipadamente dados e carregando-os no cache de página para que possa estar disponível antes na memória ao invés de vir do disco. Algumas cargas de trabalho, tais como aquelas que envolvem transmissão contínua pesada de E/S sequencial, se beneficiam de valores altos de read-ahead.
blockdev
para visualizar e editar o valor read-ahead. Para visualizar o valor read-ahead atual para um dispositivo de bloco particular, execute:
# blockdev -getra device
# blockdev -setra N device
blockdev
não persistirá entre as inicializações. Nós recomendados criar um nível de execução do script init.d
para definir este valor durante a inicialização.
7.1.3. Manutenção de sistema de arquivo.
Operações de descarte em Lote e online são recursos de sistemas de arquivos montados que descartam blocos que não estão sendo utilizados pelo sistema de arquivo. Estas operações são úteis para ambos drives de estado sólido e armazenamento finalmente provisionado.
fstrim
. Este comando descarta todos os blocos não usados em um sistema de arquivo que coincida com os critérios de usuário. Ambos os tipos de operação são suportados para uso com o XFS e os sistemas de arquivo ext4 no Red Hat Enterprise Linux 6.2 e posteriores, desde que o dispositivo de bloco adjacente ao sistema de arquivo suporte as operações de discard físicas. As operações de Discard Físico são suportadas se o valor de /sys/block/device/queue/discard_max_bytes
não for zero.
-o discard
(tanto no /etc/fstab
quanto como parte do comando mount
), e executados em tempo real sem a intervenção do usuário. As operações de discard somente descartam blocos que esteja transitando de um usado para um livre. As operações discard são suportadas nos sistemas de arquivo ext4 no Red Hat Enterprise Linux 6.2 e posteriores, e nos sistemas de arquivo XFS no Red Hat Enterprise Linux 6.4 e posteriores.
7.1.4. Considerações de Aplicativos
Os sistemas de arquivo ext4, XFS, e GFS2 apoiam a pré-alocação eficiente do espaço através da chamada glibc fallocate (2)
. Nos casos em que os arquivos possam tornar-se muito fragmentados devido aos padrões de gravação, levando a má performance de leitura, a pré-alocação de espaço pode ser uma técnica útil. Pré-alocação marca de espaço em disco como se tivesse sido alocado para um arquivo, sem gravar nenhum dado naquele espaço. Até que os dados reais sejam gravados em um bloco pré-alocado, as operações de leitura retornarão como zeros.
7.2. Perfis para desempenho de sistema de arquivo.
desempenho de latência
- Um perfil de servidor para latência típica de ajuste de desempenho. Ele desabilita os mecanismos de economia de energia do tuned e ktune. Os modos
cpuspeed
mudam paraperformance
. O elevador de E/S é modificado paradeadline
para cada dispositivo. O parâmetrocpu_dma_latency
é registrado com um valor de0
(a latência menor possível) para qualidade de serviço de gerenciamento de energia para limitar a latência onde for possível. desempenho de rendimento
- Um perfil de servidor para um ajuste de desempenho de rendimento típico. Este perfil é recomendado se o sistema não tiver o armazenamento de classe corporativa. É o mesmo que
latency-performance
, exceto:kernel.sched_min_granularity_ns
(granularidade mínima de agendador) é definida para10
milisegundos,kernel.sched_wakeup_granularity_ns
(granularidade de ativação de agendador) é definida para15
milisegundos,vm.dirty_ratio
(taxa suja de máquina virtual) é definida para 40%, e- páginas transparentes enormes são habilitadas.
enterprise-storage
- Este perfil é recomendado para configurações de servidor de tamanho corporativo com armazenamento de classe corporativa, incluindo proteção e gerenciamento de cache de controlador com backup de bateria de um cache em disco. É o mesmo que o perfil
desempenho de rendimento
, exceto:- o valor
readahead
é definido para4x
, e - sistemas de arquivo non root/boot são remontados com
barrier=0
.
man tuned-adm
),ou em Guia de Gerenciamento de Energia disponível a partir do link http://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/.
7.3. Sistemas de Arquivos
7.3.1. Sistema de Arquivo Ext4
Nota
Para sistemas de arquivo muito grandes, o processo mkfs.ext4
pode levar um longo tempo para inicializar todas as tabelas de inodes no sistema de arquivo. Este processo pode ser deferido com a opção -E lazy_itable_init=1
. Se for utilizado, os processos do kernel continuarão a inicializar o sistema de arquivo após ser montado. A taxa na qual esta inicialização acontece pode ser controlada com a opção -o init_itable=n
para o comando mount
, onde a quantia de tempo gasta na realização n esta inicialização de fundo é mais ou menos 1/n. O valor padrão para n
é de 10
.
Como alguns aplicativos nem sempre realizam o fsync()
adequadamente após renomear um arquivo existente, ou truncado e regravado, o padrão do ext4 é a sincronização automática de arquivos após operações de substituição via renome e substituição via truncar. Este comportamento é altamente consistente com comportamentos de sistema de arquivo ext3 mais velhos. No entanto, as operações de fsync()
podem consumir bastante tempo, portanto se este comportamento automático não for necessário, use a opção -o noauto_da_alloc
com o comando mount
para desabilitá-lo Isto significa que o aplicativo deverá utilizar explicitamente o fsync()
para assegurar persistência de dados.
Por padrão, a E/S de comprometimento de diário recebe uma prioridade uma pouco mais alta do que uma E/S normal. Esta prioridade pode ser controlada com a opção journal_ioprio=n
do comando mount
. O valor padrão é 3
. Valores válidos variam desde 0 à 7, sendo 0 a E/S com prioridade mais alta.
mkfs
e ajuste, veja as páginas man mkfs.ext4(8)
e mount(8)
assim como o arquivo Documentation/filesystems/ext4.txt
no pacote kernel-doc.
7.3.2. O Sistema de Arquivo XFS
mkfs
variam em profundidade de b-trees, que modificam as características de escalabilidade de subsistemas diferentes.
7.3.2.1. Ajuste básico para XFS
mkfs.xfs
configura automaticamente a si próprio com a unidade de faixa correta e profundidade para alinhar com o hardware. Isto pode precisar ser configurado manualmente se o hardware RAID estiver em uso.
inode64
é altamente recomendada para sistemas de arquivo em muli-terabyte, exceto onde o sistema de aquivo for exportado via NFS e clientes NFS de 32 bits de legacia, que requerem acesso ao sistema de arquivo.
logbsize
é recomendada para sistemas de arquivo que são modificados frequentemente, ou em intermitências. O valor padrão é de MAX
(32 KB, unidade de faixa de log), e o tamanho máximo é 256 KB. O valor de 256 KB é recomendado para sistemas de arquivo que passam por modificações pesadas.
7.3.2.2. Ajuste avançado para XFS
O XFS impõe um limite arbitrário para o número de arquivos que um sistema de arquivos pode conter. Em geral, esse limite é alto o suficiente para que ele nunca seja atingido. Se você sabe que o limite padrão será insuficiente antes do tempo, você pode aumentar a percentagem de espaço do sistema de arquivo permitido para inodes com os mkfs.xfs
. Se você encontrar o limite do arquivo após a criação do sistema de arquivos (normalmente indicado por erros ENOSPC ao tentar criar um arquivo ou pasta, apesar de espaço livre disponível), você poderá ajustar o limite com os xfs_growfs
.
O tamanho do bloco do diretório é fixado para a vida de um sistema de arquivos, e não pode ser alterado, salvo mediante a formatação inicial com mkfs
. O bloco mínimo de diretório é o tamanho do bloco do sistema de arquivos, o qual tem como padrão MAX
(4 KB, o tamanho do arquivo de bloco do sistema). De um modo geral, não há nenhuma razão para reduzir o tamanho do bloco de diretório.
Ao contrário de outros sistemas de arquivos, o XFS pode realizar vários tipos de operações de alocação e desalocação simultaneamente, desde que as operações estejam ocorrendo em objetos não-compartilhados. Alocação ou desalocação de extensões podem ocorrer simultaneamente, desde que as operações simultâneas ocorram em diferentes grupos de alocação. Da mesma forma, a alocação ou desalocação de inodes podem ocorrer simultaneamente, desde que as operações simultâneas afetem diferentes grupos de alocação.
XFS pode armazenar pequenos atributos diretamente no inode se houver espaço disponível. Se o atributo encaixa no inodo, então ele pode ser recuperado e modificado sem a necessidade de E/S adicionais para recuperar blocos de atributos distintos. O diferencial de desempenho entre os in-line e atributos out-of-line podem facilmente ser uma ordem de magnitude mais lenta para os atributos de out-of-line.
O tamanho do log é o principal fator na determinação do nível possível de modificação de metadados sustentados. O dispositivo de log é circular, portanto, antes da parte final poder ser sobrescrita, todas as modificações no registro devem ser gravadas no local real no disco. Isto pode envolver uma quantidade significativa de procura para reproduzir todos os metadados sujos. A configuração padrão escala o tamanho do log em relação ao tamanho do sistema de arquivos em geral, assim, na maioria dos casos o tamanho do log não vai precisar de ajuste.
mkfs
faz isto por padrão para os dispositivos MD e DM, mas para o hardware RAID é possível que precise ser especificado. Configurá-lo corretamente evita todas as possibilidades do log de E/S causar uma E/S desalinhada e operações subsequentes de leitura-modificar-gravação ao gravar as modificações em disco.
ogbsize
) aumenta a velocidade com que as mudanças podem ser gravadas no log. O tamanho do buffer de log padrão é MAX
(32 KB, unidade de faixa de log), e o tamanho máximo é de 256 KB. Em geral, um maior valor resulta em desempenho mais rápido. No entanto, sob cargas de trabalho fsync-pesadas, buffers de log pequenos podem ser visivelmente mais rápidos do que os grandes buffers grandes com um grande alinhamento da unidade de faixa.
delaylog
também melhora o desempenho de modificação de metadados sustentados, reduzindo o número de alterações no log. Ela consegue isso através da agregação de mudanças individuais na memória antes de gravá-los no log: metadados modificados freqüentemente é gravado no log periodicamente em vez de em cada modificação. Essa opção aumenta o uso de memória de rastreamento de metadados sujos e aumenta as operações de perdas potenciais quando ocorre um travamento, mas pode melhorar a velocidade de modificação de metadados e escalabilidade por uma ordem de magnitude ou mais. O uso desta opção não reduz a dados ou a integridade de metadados quando fsync
, fdatasync
ou sync
são usados para garantir que os dados e metadados sejam gravados no disco.
7.4. Clustering
7.4.1. Global File System 2
- Arquivos pré-alocados e diretórios com o
fallocate
onde possível, para otimizar o processo de alocação e evitar a necessidade de bloquear páginas fonte. - Minimizar as áreas do sistema de arquivos que são compartilhadas entre vários nós para minimizar a invalidação do cache cross-nó e melhorar o desempenho. Por exemplo, se vários nós montarem o mesmo sistema de arquivos, mas acessarem diferentes sub-diretórios, você provavelmente vai conseguir um melhor desempenho movendo um subdiretório para um sistema de arquivo separado.
- Escolha um tamanho de grupo de recursos ideal e número. Isso depende de tamanhos de arquivo típicos e espaço livre disponível no sistema, e afeta a probabilidade de que vários nós tentarão usar um grupo de recursos simultaneamente. Muitos grupos de recursos podem retardar a alocação de blocos, enquanto o espaço de alocação é localizado, enquanto muito poucos grupos de recursos podem causar contenção de bloqueio durante a desalocação. Em geral, é melhor testar várias configurações para determinar o que é melhor para a sua carga de trabalho.
- Selecione seu hardware de armazenamento de acordo com os modelos de E/S esperados dos nós de cluster e os requerimentos de desempenho do sistema de arquivo.
- Use armazenamento de estado sólido onde possível para diminuir tempo de busca.
- Crie um sistema de arquivos de tamanho apropriado para o seu trabalho, e assegure-se que o sistema de arquivos nunca está em mais de 80% da capacidade. Sistemas de arquivos menores terão o tempo de backup proporcionalmente mais curtos, e requerem menos tempo e memória para o controle do sistema de arquivos, mas estão sujeitos a elevada fragmentação caso sejam pequenos demais para a sua carga de trabalho.
- Defina tamanhos de diários maiores para cargas de trabalho de metadados intensivo, ou quando dados com diário estiver em uso. Embora este use mais memória, ele melhora o desempenho, pois mais espaço diário está disponível para armazenar dados antes de uma gravação ser necessária.
- Assegure-se de que o relógico nos nós de GFS2 estão sincronizados para evitar problemas com os aplicativos em rede. Recomendamos o uso do NTP (Network Time Protocol).
- A menos que os tempos de acesso de arquivo ou diretório sejam críticos para a operação de seu aplicativo, monte o sistema de arquivo com as opções de montagem
noatime
enodiratime
.Nota
Red Hat recomenda o uso da opçãonoatime
com o GFS2. - Se você precisar usar quotas, tente reduzir a freqüência das operações de sincronização de cota ou usar a sincronização de quota difusa para evitar problemas de desempenho decorrentes de atualizações de arquivos de quotas constantes.
Nota
A conta de cotas "difusas" (fuzzy) pode permitir que usuários ou grupos excedam um pouco do limite de cota. Para minimizar isto, o GFS2 reduz o período de sincronização, de forma dinâmica quando um usuário ou grupo se aproxima do limite de cota.
Capítulo 8. Networking
8.1. Melhorias de Desempenho de Rede
8.1.1. Receive Packet Steering (RPS)
rx
tenha sua recepção de carga de trabalho softirq
distribuída entre diversas CPUs. Isto ajuda a prevenir tráfego em rede de ser afunilado em uma única fila de hardware NIC.
/sys/class/net/ethX/queues/rx-N/rps_cpus
, substituindo ethX
pelo nome de dispositivo correspondente do NIC (por exemplo, eth1
, eth2
) e rx-N
pela fila de recepção do NIC especificada. Isto permitirá que as CPUs especificadas no arquivo processem dados de uma fila rx-N
em ethX
. Ao especificar CPUs, consider o cache affinity da fila [4].
8.1.2. Receive Flow Steering
/proc/sys/net/core/rps_sock_flow_entries
- Isto controla o número máximo de soquetes/fluxos que o kernel pode conduzir em direção a qualquer CPU específica. Isto é um limite compartilhado com todo o sistema.
/sys/class/net/ethX/queues/rx-N/rps_flow_cnt
- Isto controla o número máximo de soquetes/fluxos que o kernel pode conduzir em direção a qualquer CPU específica. (
rx-N
) em um NIC (ethX
). Note que o resumo de todos os valores por fila para este ajustável em todos os NICs deve ser igual ou menor do que/proc/sys/net/core/rps_sock_flow_entries
.
8.1.3. suporte de getsockopt para thin-streams do TCP
getsockopt
foi aprimorada para suportar duas opções extras:
- TCP_THIN_DUPACK
- Este Booleano habilita o disparo dinâmico de retransmissão após um dupACK para thin streams.
- TCP_THIN_LINEAR_TIMEOUTS
- Este Booleano habilita o disparo dinâmico de limite de tempo linear para thin streams.
file:///usr/share/doc/kernel-doc-versão/Documentation/networking/ip-sysctl.txt
. Para mais informações sobre o thin-streams, consulte o file:///usr/share/doc/kernel-doc-versão/Documentation/networking/tcp-thin.txt
.
8.1.4. Suporte Transparent Proxy (TProxy)
file:///usr/share/doc/kernel-doc-version/Documentation/networking/tproxy.txt
.
8.2. Configurações de Rede Otimizadas
- netstat
- Um utilitário de linha de comando que imprime conexões de rede, tabelas de roteamento, estatísticas de interface, conexões mascaradas e associações de multicast. Ele recupera informações sobre subsistemas de rede a partir do sistema de arquivo
/proc/net/
. Estes arquivos incluem:/proc/net/dev
(Informações de dispositivo)/proc/net/tcp
(Informações de soquete TCP)/proc/net/unix
(Informações de soquete de domínio Unix)
Para mais informações sobrenetstat
e seus arquivos de referncia de/proc/net/
, consulte a página mannetstat
:man netstat
. - dropwatch
- Um utilitário de monitoramento que monitora pacotes despejados pelo kernel. Para mais informações, consulte a página man
dropwatch
:man dropwatch
. - ip
- Um utilitário para gerenciar e monitorar rotas, dispositivos, roteamento de política e túneis. Para mais informações consulte a página man
ip
:man ip
. - ethtool
- Um utilitário para exibir e modificar as configurações do NIC. Para mais informações, consulte a página man
ethtool
:man ethtool
. - /proc/net/snmp
- Um arquivo que exibe dados ASCII necessários para bases de informações de gerenciamento IP, ICMP, TCP e UDP para um agente
snmp
. Ele também exibe estatísticas de tempo real de UDP-lite.
/proc/net/snmp
indica que um ou mais soquetes que recebem filas estão cheias quando as pilhas de rede tentam enfileirar novas estruturas no soquete de um aplicativo.
8.2.1. Soquete recebe tamanho de buffer
sk_stream_wait_memory.stp
, sugere que a taxa de dreno da fila de soquete é muito lenta, então você pode aumentar a profundidade da fila de soquete do aplicativo. Para fazer isso, aumente o tamanho de buffers de recepção por utilizados por soquetes, configurando um dos seguintes valores:
- rmem_default
- Um parâmetro de kernel que controla o tamanho do default de buffers de recepção usados pelo soquete. Para configurar isto, execute o seguinte comando:
sysctl -w net.core.rmem_default=N
Substitua oN
pelo tamanho de buffer desejado, em bytes. Para determinar o valor para este parâmetro de kernel, visualize/proc/sys/net/core/rmem_default
. Tenha em mente que o valor dermem_default
deve ser maior do quermem_max
(/proc/sys/net/core/rmem_max
); se necessário, aumente o valor dermem_max
. - SO_RCVBUF
- A opção de soquete que controla o tamanho máximo de buffers de recepção de soquete, em bytes. Para mais informações sobre
SO_RCVBUF
, consulte a página man para mais detalhes:man 7 socket
.Para configurarSO_RCVBUF
, use o utilitáriosetsockopt
. Você pode recuperar o valor atualSO_RCVBUF
com ogetsockopt
. Para mais informações utilizando ambos utilitários, consulte a página mansetsockopt
:man setsockopt
.
8.3. Visão Geral de Recepção de Pacotes
Figura 8.1. Diagrama de caminho de recepção de rede
- Recepção de Hardware: a placa de interface de rede (NIC) recebe a estrutura a cabo. Dependendo de sua configuração do driver, o NIC tranferirá a estrutura para uma memória de buffer de hardware interno ou para um buffer de anel especificado.
- Hard IRQ: o NIC declara a presença de uma estrutura de rede ao interromper a CPU. Isto faz com que o driver do NIC perceba a interrupção e agende a operação IRQ leve.
- Soft IRQ: este estágio implementa o processo de estrutura de recepção e é executado no contexto de
softirq
. Isto significa que o estágio pré esvazia todos os aplicativos que estão executando em uma CPU específica, mas ainda permite que os IRQs rígidos a serem declarados.Neste contexto (em execução na mesma CPU como IRQ rígido, minimizando sobrecarga de bloqueio), o kernel realmente remove o quadro dos buffers de hardware NIC e o processa através da pilha de rede. A partir daí, o quadro é encaminhado, descartado ou passado para um soquete de escuta de alvo.Quando passado para um soquete, o quadro é anexado ao aplicativo que possui o soquete. Este processo é feito de forma iterativa até que o buffer de hardware NIC não tenha mais quadros, ou até que o peso do dispositivo (dev_weight
). Para mais informações sobre o peso do dispositivo, consulte o Seção 8.4.1, “Buffer de Hardware NIC” - Recepção de Aplicativo: o aplicativo recebe o quadro e desinfileira-o de qualquer posse de soquete via chamadas POSIX padrão (
read
,recv
,recvfrom
). Neste ponto, os dados recebidos sob a rede não existem mais na pilha de rede.
8.3.1. Afinidade de CPU/cache
8.4. Resolvendo Filas Comuns/ Problemas de Perda de Quadro
8.4.1. Buffer de Hardware NIC
softirq
, o qual declara o NIC via uma interrupção. Para interrogar o status desta fila, use o seguinte comando:
ethtool -S ethX
ethX
pelo nome de dispositivo correspondente do NIC. Isto irá exibir quantos quadros foram despejados dentro do ethX
. Geralmente, um despejo ocorre porque a fila não possui mais espaço de buffer no qual armazena quadros.
- Tráfego de entrada
- Você pode ajudar a evitar saturação de fila diminuindo a velocidade do tráfego de entrada. Você pode fazer isto filtrando, reduzindo o número de grupos de multicast unidos, abaixando o tráfego de transferência e assim por diante.
- Comprimento da Fila
- Como forma alternativa você também pode aumentar o comprimento da fila. Isto envolve aumentar o número de buffers na fila específica para qualquer máximo que o driver permitir. Para fazer isto, edite os parâmetros de anel
rx
/tx
deethX
usando:ethtool --set-ring ethX
Anexe os valores derx
outx
apropriados. Para mais informações, consulteman ethtool
. - Peso do dispositivo
- Também é possível aumentar a taxa na qual uma fila seja drenada. Para fazer isso, ajuste o peso do dispositivo do NIC adequadamente. Este atributo refere-se ao número máximo de quadros que a placa de rede pode receber antes do contexto
softirq
ter que render a CPU e se reagendar. É controlada pela variável/proc/sys/net/core/dev_weight
.
8.4.2. Fila de Soquete
softirq
. Os aplicativos então drenam as filas de seus soquetes correspondentes através de chamadas para read
, recvfrom
, e assim por diante.
netstat
; a coluna Recv-Q
exibe o tamanho da fila. Geralmente falando, saturações em filas de soquete são gerenciadas da mesma forma que as saturações de buffer de hardware NIC (ex.: Seção 8.4.1, “Buffer de Hardware NIC”):
- Tráfego de entrada
- A primeira opção é diminuir o tráfego de entrada, configurando a taxa na qual se enche a fila. Para isso, você pode filtrar quadros ou despejá-los de forma pré-vazia. Você também pode desacelerar o tráfego de entrada, diminuindo o peso do dispositivo [6].
- Profundidade da Fila
- Você também pode evitar saturação de fila de soquete aumentando a profundidade da fila. Para fazer isto, aumente o valor do parâmetro do kernel
rmem_default
ou a opção de soqueteSO_RCVBUF
. Para mais informações sobre ambos, consulte Seção 8.2, “Configurações de Rede Otimizadas”. - Frequência de chamada de aplicativo
- Sempre que possível, otimize o aplicativo para realizar realizar chamadas com mais freqüência. Trata-se de modificar ou reconfigurar o aplicativo de rede para realizar chamadas POSIX mais freqüentes (como
recv
,read
). Isso permite que um aplicativo drene a fila mais rápidamente.
8.5. Considerações do Multicast
softirq
.
softirq
. Adicionar um ouvinte a um grupo multicast implica que o kernel deve criar uma cópia adicional para cada quadro recebido para esse grupo.
softirq
pode levar a despejos de quadros, tanto na placa de rede quanto na fila de socket. Aumento de tempos de execução do softirq
traduzi em uma redução de oportunidade para que aplicações sejam executados em sistemas fortemente carregados, por isso a taxa em que os quadros multicast são perdidos aumenta à medida que o número de aplicações de escuta de grupos de multicast de alto volume aumenta.
/proc/sys/net/core/dev_weight
. Para mais informações sobre o peso do dispositivo e as implicações de ajustá-lo, consulte Seção 8.4.1, “Buffer de Hardware NIC”.
Apêndice A. Histórico de Revisões
Histórico de Revisões | |||||
---|---|---|---|---|---|
Revisão 4.0-22.8 | Sun Sep 11 2016 | Terry Chuang | |||
| |||||
Revisão 4.0-22.7 | Sun Sep 11 2016 | Terry Chuang | |||
| |||||
Revisão 4.0-22.6 | Thu Sep 8 2016 | Glaucia Cintra | |||
| |||||
Revisão 4.0-22.2 | Wed Jun 26 2013 | Glaucia Cintra | |||
| |||||
Revisão 4.0-22.1 | Thu Apr 18 2013 | Chester Cheng | |||
| |||||
Revisão 4.0-22 | Fri Feb 15 2013 | Laura Bailey | |||
| |||||
Revisão 4.0-19 | Wed Jan 16 2013 | Laura Bailey | |||
| |||||
Revisão 4.0-18 | Tue Nov 27 2012 | Laura Bailey | |||
| |||||
Revisão 4.0-17 | Mon Nov 19 2012 | Laura Bailey | |||
| |||||
Revisão 4.0-16 | Thu Nov 08 2012 | Laura Bailey | |||
| |||||
Revisão 4.0-15 | Wed Oct 17 2012 | Laura Bailey | |||
| |||||
Revisão 4.0-13 | Wed Oct 17 2012 | Laura Bailey | |||
| |||||
Revisão 4.0-12 | Tue Oct 16 2012 | Laura Bailey | |||
| |||||
Revisão 4.0-9 | Tue Oct 9 2012 | Laura Bailey | |||
| |||||
Revisão 4.0-6 | Thu Oct 4 2012 | Laura Bailey | |||
| |||||
Revisão 4.0-3 | Tue Sep 18 2012 | Laura Bailey | |||
| |||||
Revisão 4.0-2 | Mon Sep 10 2012 | Laura Bailey | |||
| |||||
Revisão 3.0-15 | Thursday March 22 2012 | Laura Bailey | |||
| |||||
Revisão 3.0-10 | Friday March 02 2012 | Laura Bailey | |||
| |||||
Revisão 3.0-8 | Thursday February 02 2012 | Laura Bailey | |||
| |||||
Revisão 3.0-5 | Tuesday January 17 2012 | Laura Bailey | |||
| |||||
Revisão 3.0-3 | Wednesday January 11 2012 | Laura Bailey | |||
| |||||
Revisão 1.0-0 | Friday December 02 2011 | Laura Bailey | |||
|