Добрый день!
Есть у меня работающий кластер CEPH , в нем три физические ноды с 20-ю HDD, соответственно 20 OSD сервисов на на одну ноду.
Несколько дней назад обнаружил, что на одном из северов при попытке запустить утилиту типа top, htop, “ps aux” происходит незамедлительное зависание сессии. В процессе поиска причины пришел к выводу, что все эти утилиты зависают при получении информации о одном из процессов OSD (их 20-ть). Процесс OSD плотно работает с физическим HDD , возможно были какие-то глюки со стороны HDD, это не ясно т.к ошибок нет, тем не менее, один сервис OSD впал в ступор..
Убить его я не могу, получить информацию о нем тоже.. Все операции которые пытаются с ним работать зависают.
Мне крайне не хочется перезагружать сервер целиком, т.к на нем сейчас успешно работают еще 19 OSD, да и процедура перезапуска целой ноды CEPH не из приятных..
В логах обнаружил вот такой вот паник:
Sep 22 09:20:56 node1 kernel: divide error: 0000 [#1] SMP
Sep 22 09:20:56 node1 kernel: Modules linked in: st nls_utf8 ufs qnx4 hfsplus hfs minix ntfs msdos jfs 8021q garp mrp stp llc openvswitch nf_defrag_ipv6 nf_conntrac
Sep 22 09:20:56 node1 kernel: ip6_udp_tunnel ablk_helper udp_tunnel cryptd ptp megaraid_sas pps_core mdio fjes wmi
Sep 22 09:20:56 node1 kernel: CPU: 3 PID: 2840681 Comm: ms_pipe_read Not tainted 4.4.0-21-generic #37-Ubuntu
Sep 22 09:20:56 node1 kernel: Hardware name: LENOVO System x3650 M5: -[5462AC1]-/00YL824, BIOS -[TCE124M-2.10]- 06/23/2016
Sep 22 09:20:56 node1 kernel: task: ffff887a2a55ee00 ti: ffff883f4de68000 task.ti: ffff883f4de68000
Sep 22 09:20:56 node1 kernel: RIP: 0010:[<ffffffff810b584c>] [<ffffffff810b584c>] task_numa_find_cpu+0x23c/0x710
Sep 22 09:20:56 node1 kernel: RSP: 0000:ffff883f4de6bbd8 EFLAGS: 00010206
Sep 22 09:20:56 node1 kernel: RAX: 0000000000000000 RBX: ffff883f4de6bc78 RCX: 0000000000000000
Sep 22 09:20:56 node1 kernel: RDX: 0000000000000000 RSI: ffff883f800c0000 RDI: ffff883f5dca4400
Sep 22 09:20:56 node1 kernel: RBP: ffff883f4de6bc40 R08: 000000012b8a9ebb R09: 0000000000000233
Sep 22 09:20:56 node1 kernel: R10: 00000000000001b4 R11: 00000000000129f4 R12: ffff883f35192940
Sep 22 09:20:56 node1 kernel: R13: 000000000000000d R14: 000000000000003c R15: 00000000000000bc
Sep 22 09:20:56 node1 kernel: FS: 00007f066ed97700(0000) GS:ffff883f800c0000(0000) knlGS:0000000000000000
Sep 22 09:20:56 node1 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Sep 22 09:20:56 node1 kernel: CR2: 0000560b1ffd7200 CR3: 0000003f4dc1e000 CR4: 00000000001406e0
Sep 22 09:20:56 node1 kernel: Stack:
Sep 22 09:20:56 node1 kernel: 0000000000000000 0000000000000000 0000000000000003 ffff887a2a55ee00
Sep 22 09:20:56 node1 kernel: 000000000000003d fffffffffffffc55 0000000000016d00 000000000000003d
Sep 22 09:20:56 node1 kernel: ffff887a2a55ee00 ffff883f4de6bc78 00000000000003c9 00000000000001d5
Sep 22 09:20:56 node1 kernel: Call Trace:
Sep 22 09:20:56 node1 kernel: [<ffffffff810b615e>] task_numa_migrate+0x43e/0x9b0
Sep 22 09:20:56 node1 kernel: [<ffffffff810b6749>] numa_migrate_preferred+0x79/0x80
Sep 22 09:20:56 node1 kernel: [<ffffffff810bad64>] task_numa_fault+0x7f4/0xd40
Sep 22 09:20:56 node1 kernel: [<ffffffff810ba3d5>] ? should_numa_migrate_memory+0x55/0x130
Sep 22 09:20:56 node1 kernel: [<ffffffff811bf790>] handle_mm_fault+0xbc0/0x1820
Sep 22 09:20:56 node1 kernel: [<ffffffff816fde24>] ? SYSC_recvfrom+0x144/0x160
Sep 22 09:20:56 node1 kernel: [<ffffffff8106b537>] __do_page_fault+0x197/0x400
Sep 22 09:20:56 node1 kernel: [<ffffffff8106b7c2>] do_page_fault+0x22/0x30
Sep 22 09:20:56 node1 kernel: [<ffffffff81826678>] page_fault+0x28/0x30
Sep 22 09:20:56 node1 kernel: Code: 55 b0 4c 89 f7 e8 25 c8 ff ff 48 8b 55 b0 49 8b 4e 78 48 8b 82 d8 01 00 00 48 83 c1 01 31 d2 49 0f af 86 b0 00 00 00 4c 8b 73 78
Sep 22 09:20:56 node1 kernel: RIP [<ffffffff810b584c>] task_numa_find_cpu+0x23c/0x710
Sep 22 09:20:56 node1 kernel: RSP <ffff883f4de6bbd8>
Sep 22 09:20:56 node1 kernel: ---[ end trace 3005b3606a1553b7 ]---
Как думаете, есть ли способ убить повисший процесс без перезагрузки всего сервере ?
OS: Ubuntu16.04
