LINUX.ORG.RU
ФорумAdmin

гадание на гуще iostat

 , ,


0

1

Кто-нибудь может пованговать, есть ли какая-то патология? Сервер начинает подтупливать, демоны начинают отваливаться по таймауту. Мне подозрителен высокй показатель %system. Это нормально? И что это значит. Нагрузка на сервер есть - билд-ферма это.

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          40.08    0.00   40.79   12.75    0.00    6.38

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
loop0             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
sda              61.02  2513.88 1001.13 1247.61 15731.47 52741.83    60.90    74.21   33.00   13.69   48.50   0.39  87.22
dm-0              0.00     0.00 1062.75 3702.59 15705.18 52767.60    28.74   119.43   25.06   13.71   28.31   0.18  87.25
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

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          31.89    0.00   62.10    0.68    0.00    5.33

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
loop0             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
sda               9.80   665.40  539.93  594.27 10496.53 39179.73    87.60     6.11    5.39    4.03    6.63   0.55  62.21
dm-0              0.00     0.00  549.60 1201.47 10491.20 39146.40    56.69     6.93    3.95    4.20    3.84   0.36  62.51
dm-1              0.00     0.00    0.07    0.00     0.27     0.00     8.00     0.00    0.00    0.00    0.00   0.00   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          30.12    0.00   65.23    1.75    0.00    2.91

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
loop0             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
sda              15.40   275.40  509.00  178.40  8809.60 19375.73    82.01     9.84   14.32    5.73   38.81   0.64  43.65
dm-0              0.00     0.00  524.40  418.13  8808.27 19376.80    59.81     9.42    9.83    5.92   14.74   0.57  54.19
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

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          29.97    0.00   58.58    2.33    0.00    9.12

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
loop0             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
sda              35.83  2183.99 1045.01 1579.00 16835.70 64403.15    61.92    32.26   12.11    7.23   15.33   0.42 109.00
dm-0              0.00     0.00 1080.91 3696.39 16834.38 64406.30    34.01    50.85   10.57    7.36   11.51   0.23 112.07
dm-1              0.00     0.00    0.33    0.20     1.31     0.79     8.00     0.00    6.50   10.40    0.00   6.50   0.34

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          18.53    0.00   71.43    5.59    0.00    4.44

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
loop0             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
sda               9.93   214.93  161.53  179.80  4223.20 10728.27    87.61    14.46   40.32   20.07   58.51   1.19  40.72
dm-0              0.00     0.00  172.73  384.00  4247.20 10938.40    54.55    17.78   30.60   21.19   34.84   0.73  40.75
dm-1              0.00     0.00    0.00    0.07     0.00     0.27     8.00     0.00    4.00    0.00    4.00   4.00   0.03
Deleted

Загрузи диск, посмотри растёт ли схожий показатель. Может это sync так долго идёт. По сути там особо и нечему тормозить на билд ферме больше.

pon4ik ★★★★★
()

есть ли какая-то патология

Твой диск не очень способен в 3kiops, Или ты их туда слишком последовательно засовываещь (судя по svctm*tps - не твой случай).

От первого помогает размазать данные по нескольким, или (хуже но дороже) более быстрое устройство. От второго - увеличение очереди.

Да, забыл, ещё может помочь побольше памяти для кеша и отключение всяких журналов там, куда пишут..

Сервер начинает подтупливать, демоны начинают отваливаться

А от этого - ionice -c 3 тем, кто больше всего жрёт.

DonkeyHot ★★★★★
()
Последнее исправление: DonkeyHot (всего исправлений: 2)
Ответ на: комментарий от funky

Я тоже думал про подкачку, но своп там чистосимволический.

Хотя заметно, что памяти впритык. Я немного снизил количество активных исполнителей-сборщиков (с 32 до 20), вроде стало лучше по стабильности. Хотелось бы понять, где узкое место, память, рам, проц, диски и сбалансировать сервер, добавив туда чего-нибудь. Диск там не ssd, кажется простой железный или фейковый raid1, сервак далеко.

Например, мне кажется, что сборщиков должно быть 64 по количеству ядер. Пусть они там молотят в параллель, даже если на каком-то забыли сделать -j мейку. Памяти 64ГБ и, вероятно, этого мало. Ну это я подрасчитаю.

Баянный вопрос, буду искать еще сам, на какой показатель ориентироваться в отношении дисковой подсистемы, что бы убедиться, что затык например в ней, а не в проце.

# vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
215 37 143216 508396 2075332 5763708    0    0    25   368    0    0 20  5 74  0  0

# free -m
              total        used        free      shared  buff/cache   available
Mem:          64103       55304         822           2        7976        8131
Swap:           975         139         836

за ответы спасибо всем в треде, полезно, просвещаюсь

Deleted
()
Последнее исправление: Deleted (всего исправлений: 3)
Ответ на: комментарий от Deleted

должно быть 270K IOPS random read (4K) performance по спеке

1. В приведеном больше записи. 2. коефициент кореляции действительности и должнобыти не всегда достаточно большой. 3. многое может зависеть от других компонент. 4. Произведение времени обслуживания на кол-во запросов почти 128 секунд в секунду(?умолчательная длинна очереди?) — оно точно не успевает.

Гугель говорит, что nr_requests больше 1 байта, т.ч. можно попробовать увеличить, Ещё стоит на планировщик посмотреть - может быть ядро не догадалось ssdугодный поставить.

DonkeyHot ★★★★★
()

$ cat /proc/interrupts

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

Свап, как видно, не дрючится. Так что дело не в нем. В целом можно сказать, что чем длиннее очередь avgqu-sz, тем более не справляется с нагрузкой дисковая система. И да, посмотри что у тебя в /sys/block/sda/queue/scheduler. Для ssd лучше noop.

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

посмотри что у тебя в /sys/block/sda/queue/scheduler. Для ssd лучше noop.

был CFQ (оказывается дефолт в ubuntu1804), поставил deadline пока (еще до твоего совета noop)

Есть еще подозрение, что лучше там было XFS, а не ext4 https://kernel.ubuntu.com/~cking/fs-tests/jan-2019/kernel-tests-samples/0004.0015.0000-unknown-unknown/daily-fio-stats-io-ops/write-sync-rand-1/index.html

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.