LINUX.ORG.RU
ФорумAdmin

Производительность дисковой подистемы, load average: 51.36

 ,


0

2

Добрый день! С недавних пор, как на сервере развернули чудо-приложение написанное на java и которое стало использоваться все диски этого сервера, серверу стало очень плохо:

[root@xxx ~]# iostat -xhm
Linux 2.6.32-642.el6.x86_64 (xxxx)     08/28/2017      _x86_64_        (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.85    0.20    1.30   26.48    0.00   68.18

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               9.64   954.54  198.02  881.11     8.23     7.19    29.27     0.33    0.31    0.34    0.30   0.10  11.30
sdc              43.68   218.98   29.56   24.24     0.31     0.95    48.04     0.57   10.60    9.62   11.79   2.24  12.04
sdd             119.57   206.23  108.51   22.40     1.00     0.89    29.65     1.51   11.55   11.21   13.21   2.83  37.03
sdb              55.33    52.59   51.11    6.71     0.70     0.23    32.99     0.51    8.78    9.16    5.92   2.75  15.90
sdh              35.83     0.06   25.41    0.05     0.24     0.00    19.62     0.18    6.88    6.88    4.62   1.51   3.84
sdi             254.53   376.18  170.39   42.21     1.85     1.64    33.56     3.23   15.20    3.92   60.74   3.42  72.71
sdf              77.95   138.61   67.99   18.18     0.65     0.61    29.90     1.00   11.57   11.12   13.26   3.12  26.92
sdj             427.69   265.24  236.55   32.97     3.04     1.17    31.97     3.57   13.23   13.77    9.36   3.59  96.68
sdk             109.94   185.25   97.91   22.08     0.92     0.81    29.59     1.56   12.98   12.14   16.71   3.10  37.25
sde             227.63   283.89  156.28   29.95     1.63     1.23    31.46     2.51   13.47   12.61   17.97   2.53  47.10
sdl             286.41   174.09  184.14   19.83     1.98     0.76    27.49     2.69   13.20   13.07   14.44   2.53  51.54
sdm              57.02   320.55   42.94   33.12     0.44     1.38    48.96     1.13   14.91   11.84   18.90   2.62  19.89
sdg             289.45   246.58  205.43   27.90     2.18     1.07    28.56     3.10   13.29    7.89   53.04   3.24  75.71
dm-0              0.00     0.00  208.13 1835.64     8.23     7.19    15.45     0.11    0.05    0.34    0.01   0.06  11.26
dm-1              0.00     0.00    0.00    0.00     0.00     0.00     8.00     0.00    0.06    0.06    0.00   0.06   0.00

Вывод TOP:

top - 18:32:45 up 12 days,  8:38,  3 users,  load average: 51.36, 50.24, 49.55
Tasks: 681 total,   1 running, 680 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.8%us,  1.1%sy,  0.2%ni, 68.2%id, 26.5%wa,  0.0%hi,  0.2%si,  0.0%st
Mem:  131909456k total, 127509032k used,  4400424k free, 42026080k buffers
Swap:  4194300k total,        0k used,  4194300k free, 52157492k cached

   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                             
 60262 xxxx  20   0 44.6g  12g 1.9g S 56.2  9.7  15298:38 java                                                                                                 
  5616 xxxx  20   0 26.5g 3.5g  12m S 42.6  2.8   5095:33 java                                                                                                 
  4735 xxxx  20   0 26.7g 3.6g  12m S 38.7  2.9   6325:49 java                                                                                                 
  5658 xxxx  20   0 13.7g 2.0g  12m S 13.6  1.6 554:24.34 java                   

Как видно WA доходит до 25%, что очень много... и load average: 51.36, 50.24, 49.55... По всем признакам что-то не так с дисковой подсистемой. Можно как-то выяснить в чем точная причина ? Очереди на диск замерить? Или может быть есть где-то в ядре счетчика , размер буфера, переполнение его и другая информация которая реально отражает работу с дисками ?

Посмотри сначало что приложение с дисками делает наверняка там понапихали threadов для работы с hdd не заморачивайся на его скоростт. Далее можно в памяти сделать ram диск. Или оторвать нос разработчикам

Jopich1
()
Ответ на: комментарий от Jopich1

Ну и плюс стандартные тесты dd никто не отменял

Jopich1
()

svctm неплох для SATA, гораздо больше времени уходит на ожидание в очереди. NCQ отключен что-ли?

bigbit ★★★★★
()
Ответ на: комментарий от bigbit

Как проверить ?

scsi 0:0:0:0: Direct-Access     ATA      ST8000NM0055-1RM PA28 PQ: 0 ANSI: 6
scsi 0:0:1:0: Direct-Access     ATA      ST8000NM0055-1RM PA28 PQ: 0 ANSI: 6
scsi 0:0:2:0: Direct-Access     ATA      ST8000NM0055-1RM PA28 PQ: 0 ANSI: 6
scsi 0:0:3:0: Direct-Access     ATA      ST8000NM0055-1RM PA28 PQ: 0 ANSI: 6
scsi 0:0:4:0: Direct-Access     ATA      ST8000NM0055-1RM PA28 PQ: 0 ANSI: 6
scsi 0:0:5:0: Direct-Access     ATA      ST8000NM0055-1RM PA28 PQ: 0 ANSI: 6
scsi 0:0:6:0: Direct-Access     ATA      ST8000NM0055-1RM PA28 PQ: 0 ANSI: 6
scsi 0:0:7:0: Direct-Access     ATA      ST8000NM0055-1RM PA28 PQ: 0 ANSI: 6
scsi 0:0:8:0: Direct-Access     ATA      ST8000NM0055-1RM PA28 PQ: 0 ANSI: 6
scsi 0:0:9:0: Direct-Access     ATA      ST8000NM0055-1RM PA28 PQ: 0 ANSI: 6
scsi 0:0:10:0: Direct-Access     ATA      ST8000NM0055-1RM PA28 PQ: 0 ANSI: 6
scsi 0:0:11:0: Direct-Access     ATA      ST8000NM0055-1RM PA28 PQ: 0 ANSI: 6
ahci 0000:00:11.4: AHCI 0001.0300 32 slots 4 ports 6 Gbps 0x3 impl SATA mode
ata1: SATA max UDMA/133 abar m2048@0x91e01000 port 0x91e01100 irq 122
ata2: SATA max UDMA/133 abar m2048@0x91e01000 port 0x91e01180 irq 122
ahci 0000:00:1f.2: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x30 impl SATA mode
ata9: SATA max UDMA/133 abar m2048@0x91e00000 port 0x91e00300 irq 123
Romanyuk
() автор топика
Ответ на: комментарий от Romanyuk

Еще немного информации:

cat /sys/block/sd*/queue/scheduler 
noop anticipatory [deadline] cfq 
noop anticipatory [deadline] cfq 
noop anticipatory [deadline] cfq 
noop anticipatory [deadline] cfq 
noop anticipatory [deadline] cfq 
noop anticipatory [deadline] cfq 
noop anticipatory [deadline] cfq 
noop anticipatory [deadline] cfq 
noop anticipatory [deadline] cfq 
noop anticipatory [deadline] cfq 
noop anticipatory [deadline] cfq 
noop anticipatory [deadline] cfq 
noop anticipatory [deadline] cfq 


[root@xxx ~]# cat /sys/block/sd*/device/queue_depth
256
32
32
32
32
32
32
32
32
32
32
32
32
[root@xxx ~]# cat /sys/block/sd*/queue/nr_requests 
8192
8192
8192
8192
8192
8192
8192
8192
8192
8192
8192
8192
8192

Romanyuk
() автор топика
Ответ на: комментарий от anonymous

еще такое бывает, когда количество файлов в темп помойке или там, где песатели написали, измеряется 5-6-7 нулями и они их не чистят. Грешит таким жабаподелия. Надо кроном чистить.

anonymous
()
Ответ на: комментарий от Romanyuk

Судя по всему, NCQ включен.
А первое измерение в iostat надо отбрасывать, т.к. это средние значения с момента загрузки ОС.
iostat -xhm 3
vmstat 3
sar -d

bigbit ★★★★★
()
Ответ на: комментарий от bigbit

iostat -xhm 3


Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               3.67   572.00   51.00  695.00     3.56     4.95    23.36     0.08    0.10    0.37    0.08   0.10   7.43
sdj            2486.33    53.33  438.67   19.67    11.70     0.29    53.54     5.89   12.81   12.87   11.41   2.16  99.07
sde            1898.00   162.67  673.33    4.67    10.27     0.65    33.01     9.87   14.62   14.68    4.71   1.46  99.10
sdi            1576.00   215.00  237.00   36.67     7.41     0.98    62.82     6.04   22.07   20.24   33.93   3.65  99.90
sdd            1515.00    88.00  328.33   26.67     7.67     0.45    46.81     9.43   26.17   26.51   22.07   2.78  98.67
sdm            1078.67   135.00  980.67   32.00     8.27     0.65    18.04    10.34   10.19    9.98   16.49   0.98  99.10
sdh            1416.67    20.00  728.00    0.67     8.60     0.08    24.41     8.27   11.19   11.20    2.00   1.37  99.47
sdl            1028.67   155.33  937.00   26.00     7.87     0.71    18.23     9.52   10.36    9.89   27.12   1.03  98.77
sdg            1072.33   166.33  298.00    6.67     5.73     0.68    43.03    11.95   39.31   39.47   32.10   3.26  99.27
sdc            1215.67   118.33  737.00    5.00     7.85     0.48    23.00    11.27   15.14   14.75   72.40   1.34  99.27
sdb             103.67    85.33   56.00   27.33     0.67     0.44    27.30     0.80    9.62    9.79    9.28   3.03  25.23
sdk            3079.33   112.00  323.00    4.33    13.85     0.45    89.52     6.48   19.80   17.21  212.69   3.01  98.43
sdf            1106.33   330.67  281.33   46.67     5.75     1.52    45.39    15.43   43.46   37.54   79.17   3.04  99.80
dm-0              0.00     0.00   54.67 1266.67     3.56     4.95    13.18     0.11    0.08    0.35    0.07   0.05   7.23
dm-1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
[/]

Romanyuk
() автор топика
Ответ на: комментарий от Romanyuk

Ну, результаты видишь сам.
Все диски, кроме одного, загружены на 99%, запросы накапливаются в очередях (колонка avgqu-sz), отсюда высокий await. Очень много смерженных реквестов (rrqm/s) - налицо последовательное чтение.

bigbit ★★★★★
()
Ответ на: комментарий от bigbit

Это как-то решается сменой I/O планировщика ? Танцами с глубиной очередей? Итд... Или оставить как есть на совесть разработчикам ПО, которое юзает все эти диски?

Romanyuk
() автор топика
Ответ на: комментарий от Romanyuk

Сомневаюсь, что это поможет. Количество iops запредельное для SATA-дисков.

bigbit ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.