9.2.4. Verificação da latência de operação do sistema de arquivo usando a métrica baseada no ponto de traço do kernel

O GFS2 PMDA suporta a coleta de métricas a partir dos pontos de rastro do núcleo do GFS2. Por padrão, a leitura dessas métricas é desativada. A ativação dessas métricas ativa os pontos de rastro do kernel GFS2 quando as métricas são coletadas a fim de preencher os valores das métricas. Isto poderia ter um pequeno efeito no rendimento de desempenho quando estas métricas de pontos de traço do kernel são ativadas.

O PCP fornece a ferramenta pmstore, que permite modificar as configurações do PMDA com base em valores métricos. A métrica gfs2.control.* permite a troca de pontos de rastreamento de kernel GFS2. O exemplo a seguir usa o comando pmstore para habilitar todos os pontos de rastreamento do kernel GFS2.

# pmstore gfs2.control.tracepoints.all 1
gfs2.control.tracepoints.all old value=0 new value=1

Quando este comando é executado, o PMDA liga todos os tracepoints GFS2 no sistema de arquivo debugfs. Tabela 9.1, “Lista métrica completa” explica cada um dos tracepoints de controle e sua utilização, Uma explicação sobre o efeito de cada tracepoint de controle e suas opções disponíveis também está disponível através da chave de ajuda em pminfo.

O GFS2 promove métricas que contam o número de solicitações de promoção no sistema de arquivos. Estas solicitações são separadas pelo número de solicitações que ocorreram na primeira tentativa e "outras" que são concedidas após sua solicitação inicial de promoção. Uma queda no número de promoções da primeira vez com um aumento em "outras" promoções pode indicar problemas com a contenção de arquivos.

As métricas de solicitação de demota GFS2, assim como as métricas de solicitação de promoção, contam o número de solicitações de demota que ocorrem no sistema de arquivo. Estes, entretanto, também são divididos entre as solicitações que vieram do nó atual e as solicitações que vieram de outros nós do sistema. Um grande número de solicitações demoteadas de nós remotos pode indicar a contenção entre dois nós para um determinado grupo de recursos.

A ferramenta pminfo exibe informações sobre as métricas de desempenho disponíveis. Este procedimento exibe uma lista do número de glocks com a bandeira de suporte Wait (W) para cada sistema de arquivo GFS2 montado. O seguinte comando pminfo exibe uma lista do número de glocks com a bandeira de suporte Wait (W) para cada sistema de arquivo GFS2 montado.

# pminfo -f gfs2.latency.grant.all gfs2.latency.demote.all

gfs2.latency.grant.all
    inst [0 or "afc_cluster:data"] value 0
    inst [1 or "afc_cluster:bin"] value 0

gfs2.latency.demote.all
    inst [0 or "afc_cluster:data"] value 0
    inst [1 or "afc_cluster:bin"] value 0

É uma boa idéia determinar os valores gerais observados quando a carga de trabalho está funcionando sem problemas para poder perceber mudanças no desempenho quando esses valores diferem de sua faixa normal.

Por exemplo, você pode notar uma mudança no número de pedidos de promoção esperando para completar em vez de completar na primeira tentativa, o que o resultado do comando seguinte lhe permitiria determinar.

# pminfo -f gfs2.latency.grant.all gfs2.latency.demote.all

gfs2.tracepoints.promote.other.null_lock
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.promote.other.concurrent_read
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.promote.other.concurrent_write
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.promote.other.protected_read
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.promote.other.protected_write
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.promote.other.exclusive
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

A saída do comando seguinte permitiria determinar um grande aumento nas solicitações de demote remoto (especialmente se de outros nós de cluster).

# pminfo -f gfs2.tracepoints.demote_rq.requested

gfs2.tracepoints.demote_rq.requested.remote
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.demote_rq.requested.local
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

A saída do comando seguinte poderia indicar um aumento inexplicável dos fluxos de toras.

# pminfo -f gfs2.tracepoints.log_flush.total

gfs2.tracepoints.log_flush.total
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0