High await in sar

Question

Meu servidor de banco de dados tem a seguinte saída do sar para o dispositivo de dados:

[postgres@dbsrv07 ~]$ LC_ALL=POSIX sar -d  |egrep "await|dev253-2"

00:00:01          DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util

00:10:01     dev253-2   2721.27  18357.23  20291.52     14.20    613.68    225.51     0.15     40.60

00:20:01     dev253-2   1345.04    574.92  10685.38      8.37    290.65    215.99      0.06      8.61

00:30:01     dev253-2    801.39    193.53   6364.92      8.18     87.49    109.34      0.07      5.95

00:40:01     dev253-2    832.95    195.70   6617.82      8.18     89.30    107.20      0.07      5.87

00:50:01     dev253-2    835.58    162.90   6644.64      8.15     85.35    102.14      0.06      5.24

01:00:01     dev253-2    847.99    232.36   6722.90      8.20     89.91    106.03      0.07      5.64

01:10:01     dev253-2   2240.78   2295.28  17543.52      8.85    163.37     72.91      0.10     23.06

01:20:01     dev253-2   2706.18   1358.97  21482.68      8.44    175.98     65.00      0.08     20.73

01:30:01     dev253-2   5839.31   3292.69  45960.39      8.43    520.98     89.19      0.07     42.24

01:40:01     dev253-2   5221.88   1945.32  41384.97      8.30    553.92    106.05      0.06     33.85

A alta espera persiste ao longo do dia.

Estou certo em supor que isso indica um gargalo de E / S?

Obrigado

    

Answer 1

svctm é uma medida do tempo que o armazenamento demorou para responder depois que o comando deixou o agendador de IO e o IO não estava mais sob o controle do kernel. Você está vendo menos de 1ms aqui, o que é excelente.

aguardar é uma medida do tempo que um determinado IO gastou em todo o agendador de IO. Você está vendo centenas de milissegundos aqui, o que é muito ruim. Diferentes pessoas / fornecedores têm ideias diferentes sobre o que é "bom", diria que com menos de 50 ms é bom.

Se o seu armazenamento físico for lento, você verá um svctm grande e um grande aguardando. Se o IO do kernel estiver lento, você verá um grande svctm.

Qual programador IO você está usando neste dispositivo? Dado o pequeno tamanho de E / S (8kb), você se preocupa mais com a latência de solicitações do que com a taxa de transferência em massa. Provavelmente, seria melhor usar o planejador de prazo, em oposição ao planejador cfq padrão.

Isso é feito colocando elevator = deadline na linha do kernel no grub.conf e reinicializando.

Além disso, como você tem centenas de pedidos de veiculação em fila de espera ( avgqu-sz ), e você está entrando em milhares de IOPS ( tps ), e eu diria que estes são IO do banco de dados que provavelmente são direcionados para que eles não possam ser mesclados em solicitações maiores ou tirem proveito do pagecache, você pode estar esperando muito do subsistema de armazenamento.

    

Answer 2

Quase (: -))

await é uma combinação de tempo de serviço e tempo de espera (latência), onde você está realmente preocupado com o tempo de espera. Se o seu tempo de serviço for da ordem de 10 milissegundos, as coisas estão ficando lentas quando a espera é tão grande quanto o tempo de serviço.

10 ms é um bom tempo de serviço para uma matriz de disco da Sun: não sei qual é o melhor momento para o disco, mas suspeito que você esteja vendo um gargalo de E / S.

- [email protected]

    

Answer 3

Do comentário da superjami, parece que você tem um gargalo "acima" do disco / array. Gostaria de perguntar à comunidade postgres o que eles recomendam na forma de agendamento. Em meus dias no Solaris, nós teríamos usado a tabela de agendadores "cray" para uma máquina que era basicamente um mecanismo de banco de dados ...

- dave