Высокий wa%

4х3Тб дисков

Это самые медленные диски или бывают ещё более медленные?

Высокий wa говорит о том что тупят диски. Вместо бенчмарков лучше бы помониторил iops какой-нибудь мониторилкой типа заббикса.

sda 1% 18.0 120.0|R >

sda5 1% 18.0 120.0|R

sdc 3% 86.0 441.9|RW

sdc5 3% 86.0 441.9|RW

sdd 64% 1769.5 120.0|RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRWW

sdd5 63% 1769.5 120.0|RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRWW

sdb 87% 1267.6 383.9|RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRWWWWWWWWWW

sdb5 87% 1267.6 383.9|RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRWWWWWWWWWW

Totals Read-MB/s=9.2 Writes-MB/s=2.6 Transfers/sec=797.3

Примерно в течении дня ситуация похожая. Только нагруженность в 100. Диски sdb5 и sdd5 в массиве, согласно layout, находятся в raid0. Что примечательно нагрузка идет преимущественно на них, а не на их зеркальные тома.

Это откуда вообще цифры?

Transfers/sec=797.3

Что это? Если это iops, то это невероятно много для одного raid10. Остается докупать диски чтобы размазать нагрузку по ним.

Например если у тебя мускуль на тех же дисках, то стоит его убрать оттуда для начала.

Вот например калькулятор http://www.thecloudcalculator.com/calculators/disk-raid-and-iops.html

Согласно ему твой сетап не сможет больше двухсот.

Прикрути заббикс чтобы видеть понятные цифры.

так никто и не говорил про iops. Это показания nmap по нагруженности и распределению нагрузки по дискам. Zabbix вообще никакого смысла ставить не вижу. Ничего принципиально нового он мне не покажет

А по этим цифрам из Nmon видно, что почти при полной нагрузке двух разделов в рейде 10, находящихся относительно друг друга в нулевом рейде, мы имеем лишь 10 Мб в сек для операций чтения.

Количество мб/сек ничего не говорит о ситуации. Единственная важная цифра это количество операций ввода-вывода. Количество мб/сек полностью зависит от характера нагрузки, и 10 мб/сек может быть непреодолимым максимумом в твоем случае. На самом деле бывает и меньше.

Nmon показывает какую то фантастику — твоему рейду не по зубам 797 iops. Попробуй другой тул, например iostat.

Нет ничего удивительного в WA овер 90% когда иопсы на диск приближаются к его максимуму.

Вангую что твой рейд10 может максимум 220, а там все 180 в час пик, и это не удивительно, ведь там миллионы файлов и мускуль.

судя по ману nmon, это не iops для массива, это суммарные операции для всех дисков. и их по-любому будет больше, чем обращений к массиву, т.к. они учитывают и служебные операции работы самого массива.

avg-cpu: %user %nice %system %iowait %steal %idle

6.75 0.10 1.83 13.53 0.00 77.80

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn

sda 46.56 1975.87 1138.18 285642824 164540699

sdc 51.34 2037.13 1186.73 294498309 171560403

sdd 192.92 4018.79 1138.17 580977841 164540443

sdb 187.43 4088.24 1186.73 591017717 171560211

md0 0.01 0.02 0.00 3017 12

md1 0.15 0.14 0.45 20544 65372

md2 15.00 83.96 392.86 12138189 56794196

md3 468.98 5027.20 1538.27 726759121 222380944

Ну вот, каким то образом большая нагрузка на sdb sdd и маленькая на sda sdc. Не сильно понятно как так получилось, видимо там какие то хитрые рейды на разделах.

cat /proc/mdstat прояснил бы многое.

А вообще, всем известно что 200 iops это потолок для большинства винтов, так что тут нужно добавлять винты или пытаться размазать нагрузку более равномерно.

md3 : active raid10 sdb5[0] sda5[4] sdd5[2] sdc5[5]

3677227008 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]

md2 : active raid1 sdb4[0] sda4[6] sdc4[4] sdd4[5]

1073610560 blocks super 1.2 [4/4] [UUUU]

md1 : active (auto-read-only) raid1 sdb3[0] sda3[3] sdd3[2] sdc3[4]

16768896 blocks super 1.2 [4/4] [UUUU]

md0 : active raid1 sdb2[0] sda2[6] sdd2[5] sdc2[4]

976320 blocks super 1.2 [4/4] [UUUU]

Похоже что raid-10 распределен по всем дискам, но по какой то причине диски нагружены не равномерно. В интернетах пишут что если выполнять чтение в один поток, тот данные читаются с одного диска, а если делать мелкие чтения из рахных потоков, то будет читаться с разных дисков.

Получается либо ты в вомент съема статистики выполнял какой нибудь dd if=/dev/md3 of=/dev/null либо какой-нибудь другой процесс читал много в один поток.

Есть такая тулза — iotop. Она показывает процессы которые юзают диск. Похоже что там нет сортировки по iops, а есть только по mb/sec, но это лучше чем ничего.

я знаю про iotop. Там всегда в топе mysql и nginx

Тогда это все выглядит как какая то лажа со стороны софтварного линуксового raid10

кажется нашлась проблема. Сейчас начали сыпаться ошибки kernel: [62495.552688] BUG: soft lockup - CPU#6 stuck for 22s! [netstat:3816]

kernel: [62495.552759] Modules linked in: tcp_diag inet_diag xt_multiport iptable_filter ip_tables x_tables nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc tcp_htcp loop snd_hda_codec_realtek snd_hda_intel coretemp crc32c_intel snd_hda_codec snd_hwdep aesni_intel psmouse snd_pcm acpi_cpufreq aes_x86_64 mperf i2c_i801 aes_generic i2c_core pcspkr serio_raw snd_page_alloc cryptd snd_timer iTCO_wdt processor video snd evdev joydev iTCO_vendor_support soundcore button ext4 crc16 jbd2 mbcache dm_mod raid10 raid1 md_mod sg sd_mod crc_t10dif usbhid hid ahci libahci libata scsi_mod ehci_hcd e1000e xhci_hcd fan thermal thermal_sys usbcore usb_common [last unloaded: scsi_wait_scan] Dec 23 21:04:10

kernel: [62495.555650] CPU 6 ну и так далее инфа трассировки.

И так по всем ядрам периодически. Либо ACPI некорректный, либо баг проца, ибо нам как раз недавно менял хостер платформу. И мне кажется это как-то связано =)

А ты уверен что на реальном железе сидишь ?
Такие сообщения норма для машин в перегруженном гипервизоре.

iops

добавлять винты

Выкидавать все винты. c: perda 1700

Да, железо реальное. Но беда не приходит одна, после замены платформы всплалы следующая проблема:

kworker нагружает проц до предела. Посмотрел счетчик системных прерываний

grep . -r /sys/firmware/acpi/interrupts/

Все ок, кроме одного:

/sys/firmware/acpi/interrupts/gpe1E: 152201245 enabled

Растет просто космос. Отправил ему disabled - нагрузка спала. Но это лишь устранение симптомов, а не лечение болезни. Подскажите, за что отвечает это прерывание и в какую сторону копать?