XFS로 인한 커널 오OPS / CPU 스톨

rahim123 · 7월 23, 2023, 12:55오전

올해 대형 포럼을 Discourse로 마이그레이트한 이후, 가끔씩 클라우드 VM이 SSH로 접근 불가능해지고 가상 콘솔에 콜 트레이스가 표시되는 크래시를 겪고 있습니다. 크래시는 약 3~6주 간격으로 특정 패턴 없이 발생하고 있습니다. 처음에는 Clear Linux를 사용했는데, 이는 오래되고 집약적인 마이그레이션 과정에서 시스템 성능을 조금 더 끌어내기 위해 의도적으로 선택한 것이었습니다. 하지만 Clear Linux의 복잡한 성능 최적화 기능들이 시스템의 안정성을 떨어뜨리는 것이 아닌가 하고 의심하게 되어, 약 6주 전 Debian 12 Bookworm이 출시된 시점에 맞춰 Discourse를 Debian 12로 마이그레이트했습니다.

불행히도 오늘 Debian 시스템에서 첫 번째 크래시가 발생했습니다. 이벤트 순서는 다음과 같습니다:

Jul 22 05:00:22 kernel: BUG: kernel NULL pointer dereference, address: 0000000000000002
- kernel: Oops: 0000 [#1] PREEMPT SMP NOPTI
- kernel: CPU: 3 PID: 3235204 Comm: postmaster Not tainted 6.1.0-10-amd64 #1 Debian 6.1.37-1
- kernel: Voluntary context switch within RCU read-side critical section!
- kernel: CPU: 3 PID: 3235204 Comm: postmaster Tainted: G D 6.1.0-10-amd64 #1 Debian 6.1.37-1
journalctl에는 06:40:50이 마지막 로그 항목으로 표시됩니다. 하지만 OS와 Discourse는 계속 실행되었습니다. 마지막 항목은 같은 VM에서 실행 중인 Docker화 된 메일 에이전트의 표준 로그였습니다.
약 08:30에 Discourse가 정상적으로 실행 중임을 확인했습니다.
08:46 Discourse 에러 로그: Unexpected error in Message Bus : ActiveRecord::ConnectionNotEstablished : connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: could not fork new process for connection: Cannot allocate memory
08:53 Discourse 에러 로그: Failed to process hijacked response correctly : ActiveRecord::ConnectionNotEstablished : connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: could not fork new process for connection: Cannot allocate memory
09:01 Discourse 에러 로그: Failed to handle exception in exception app middleware : ActiveRecord::StatementInvalid : PG::ObjectNotInPrerequisiteState: ERROR: lost connection to parallel worker
Discourse의 마지막 게시물은 09:17에 작성되었습니다.
09:22 Discourse 에러 로그: 'Track Visit' is still running after 90 seconds on db default, this process may need to be restarted!
09:22 Discourse 에러 로그: Redis::TimeoutError (Connection timed out)
사이트가 다운된 것을 확인한 약 11:20까지 비슷한 Discourse 로그가 더 많이 기록되었습니다.

SSH로 로그인할 수 없게 되자, 가상 콘솔 뷰어에서 아래 스크린샷을 캡처하고 VM을 하드 리부트했습니다:

저는 오랫동안 Linux 서버를 관리해 왔는데, 이 일련의 이벤트는 제게 이해가 되지 않습니다. Discourse 로그는 메모리 부족(OOM) 이벤트의 상당히 명백한 징후로 보이며, 가상 콘솔은 같은 VM에서 실행 중인 Docker화 된 메일 서버의 구성 요소가 OOM 킬러에 의해 종료되었음을 확인시켜 줍니다. 하지만 journalctl에는 해당 OOM 조치에 대한 기록이 없는데, 이는 다른 시스템들이 실패하기 훨씬 전에 제대로 작동하지 않게 된 것으로 보입니다. 05:00:22에 발생한 것으로 보이는 첫 번째 이벤트는 postmaster 프로세스(Discourse 앱 컨테이너의 PostgreSQL)를 여러 번 언급하지만, DB가 완전히 다운된 것은 Discourse에 게시물이 성공적으로 작성된 09:17 이후였습니다.

현재 시스템은 하루 종일 실행된 후 정상적인 메모리 사용량을 보이고 있으며, 보통 이 정도 수준에서 유지됩니다:

#> free -m
               total        used        free      shared  buff/cache   available
Mem:            7751        4965         129        1832        4773        2785
Swap:           3875        2879         996

제 구성에서 약간 이례적인 점은 스왑 공간이 스왑 파일이나 스왑 파티션이 아니라 Zram을 통해 제공된다는 것입니다. 저는 수년 동안 Zram을 사용해 왔는데 문제가 없었습니다. 또한 클라우드 제공사의 Debian 이미지에서 사용되는 표준 EXT4 대신 XFS 루트 파일 시스템을 사용하기 위해 Debian 인스톨러 ISO로 VM을 처음부터 설치했습니다. 호스트는 Hetzner이며, 초기 Clear Linux 설치 이후 Debian으로의 마이그레이션을 위해 별도의 VM을 생성했으므로, 현재는 다른 하이퍼바이저 노드에 있는 것으로 추정되며 하드웨어 문제라고 생각하지 않습니다. 따라서 이것이 단순한 메모리 부족 상태였는지, 아니면 커널 6.1 + Zram + XFS + KVM/virtio 조합의 엣지 케이스를 발견한 것인지 궁금합니다. 여러분의 통찰력을 기대합니다.

pfaffman · 7월 23, 2023, 1:54오전

저희 입장에서는 그게 문제인 것 같습니다.

Postgres에 더 많은 메모리가 필요합니다. 메모리 설정을 조정하거나 RAM을 추가할 수 있지만, Postgres의 메모리 할당 방식을 변경해야 할 것 같습니다.

supermathie · 7월 23, 2023, 1:54오전

Hetzner 서버에서 ECC RAM을 사용하고 있나요?

제 첫 번째 직감은 하드웨어 문제입니다… 그리고 빠른 웹 검색을 통해 데스크톱 등급 하드웨어를 사용한다는 게시물을 확인할 수 있었습니다.

rahim123 · 7월 23, 2023, 2:05오전

음. 나는 동의하는 편인데, 처음에 발생했던 커널 오류를 제외하고는요. 이 VM은 오늘 아침까지 7월 6일부터 단 한 번의 커널 오OPS도 없이 실행되고 있었습니다. 해당 순간의 전체 출력입니다. page_fault_oops, handle_mm_fault, xfs_filemap_map_pages 관련 내용을 주목해 주세요:

Jul 22 05:00:22 myvm kernel: BUG: kernel NULL pointer dereference, address: 0000000000000002
Jul 22 05:00:22 myvm kernel: #PF: supervisor read access in kernel mode
Jul 22 05:00:22 myvm kernel: #PF: error_code(0x0000) - not-present page
Jul 22 05:00:22 myvm kernel: Oops: 0000 [#1] PREEMPT SMP NOPTI
Jul 22 05:00:22 myvm kernel: CPU: 3 PID: 3235204 Comm: postmaster Not tainted 6.1.0-10-amd64 #1  Debian 6.1.37-1
Jul 22 05:00:22 myvm kernel: Hardware name: Hetzner vServer/Standard PC (Q35 + ICH9, 2009), BIOS 20171111 11/11/2017
Jul 22 05:00:22 myvm kernel: RIP: 0010:next_uptodate_page+0x45/0x1f0
Jul 22 05:00:22 myvm kernel: Code: 0f 84 2f 01 00 00 48 81 ff 06 04 00 00 0f 84 a3 00 00 00 48 81 ff 02 04 00 00 0f 84 26 01 00 00 40 f6 c7 01 0f 85 8c 00 00 00 <48> 8b 07 a8 01 0f 85 81 00 00 00 8b 47 34 85 c0 74 7a 8d 50 01 4c
Jul 22 05:00:22 myvm kernel: RSP: 0000:ffffc1ae8274bcc0 EFLAGS: 00010246
Jul 22 05:00:22 myvm kernel: RAX: 0000000000000002 RBX: ffffc1ae8274bd18 RCX: 000000000000005e
Jul 22 05:00:22 myvm kernel: RDX: ffffc1ae8274bd18 RSI: ffffa0210863d2b0 RDI: 0000000000000002
Jul 22 05:00:22 myvm kernel: RBP: ffffa0210863d2b0 R08: 000000000000005e R09: 000055fb22bbdfff
Jul 22 05:00:22 myvm kernel: R10: 000000000000004f R11: 0000000000000000 R12: 000000000000005e
Jul 22 05:00:22 myvm kernel: R13: ffffa02194ad6980 R14: ffffa0210863d2b0 R15: ffffa02118538f60
Jul 22 05:00:22 myvm kernel: FS:  00007f423625fa40(0000) GS:ffffa0226bf80000(0000) knlGS:0000000000000000
Jul 22 05:00:22 myvm kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jul 22 05:00:22 myvm kernel: CR2: 0000000000000002 CR3: 000000010d87e000 CR4: 0000000000350ee0
Jul 22 05:00:22 myvm kernel: Call Trace:
Jul 22 05:00:22 myvm kernel:  <TASK>
Jul 22 05:00:22 myvm kernel:  ? __die_body.cold+0x1a/0x1f
Jul 22 05:00:22 myvm kernel:  ? page_fault_oops+0xd2/0x2b0
Jul 22 05:00:22 myvm kernel:  ? finish_task_switch.isra.0+0x9b/0x300
Jul 22 05:00:22 myvm kernel:  ? exc_page_fault+0x70/0x170
Jul 22 05:00:22 myvm kernel:  ? asm_exc_page_fault+0x22/0x30
Jul 22 05:00:22 myvm kernel:  ? next_uptodate_page+0x45/0x1f0
Jul 22 05:00:22 myvm kernel:  filemap_map_pages+0xb0/0x6e0
Jul 22 05:00:22 myvm kernel:  xfs_filemap_map_pages+0x41/0x60 [xfs]
Jul 22 05:00:22 myvm kernel:  do_fault+0x1a7/0x410
Jul 22 05:00:22 myvm kernel:  __handle_mm_fault+0x660/0xfa0
Jul 22 05:00:22 myvm kernel:  handle_mm_fault+0xdb/0x2d0
Jul 22 05:00:22 myvm kernel:  do_user_addr_fault+0x19c/0x570
Jul 22 05:00:22 myvm kernel:  exc_page_fault+0x70/0x170
Jul 22 05:00:22 myvm kernel:  asm_exc_page_fault+0x22/0x30
Jul 22 05:00:22 myvm kernel: RIP: 0033:0x7f42398b32a6
Jul 22 05:00:22 myvm kernel: Code: c7 5d 41 5c e9 3b 3d 00 00 5a 31 c0 5d 41 5c c3 0f 1f 40 00 89 f1 89 f8 48 83 e1 3f 48 83 e0 3f 83 f9 30 77 3f 83 f8 30 77 3a <66> 0f 12 0f 66 0f 12 16 66 0f 16 4f 08 66 0f 16 56 08 66 0f ef c0
Jul 22 05:00:22 myvm kernel: RSP: 002b:00007ffc8a9aae68 EFLAGS: 00010287
Jul 22 05:00:22 myvm kernel: RAX: 0000000000000001 RBX: 000055fb22b39750 RCX: 0000000000000010
Jul 22 05:00:22 myvm kernel: RDX: 0000000000000000 RSI: 00007f41b1534550 RDI: 000055fb22b59d01
Jul 22 05:00:22 myvm kernel: RBP: 0000000000000009 R08: 0000000000000000 R09: 000055fb22b39750
Jul 22 05:00:22 myvm kernel: R10: 00007f41b1534550 R11: 000000000000002c R12: 00007f42398c3180
Jul 22 05:00:22 myvm kernel: R13: 0000000000000000 R14: 0000000000000009 R15: 00007f42398c3180
Jul 22 05:00:22 myvm kernel:  </TASK>
Jul 22 05:00:22 myvm kernel: Modules linked in: ipt_REJECT nf_reject_ipv4 xt_multiport xt_nat xt_tcpudp veth xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat nf_tables nfnetlink br_netfilter bridge stp llc lz4 lz4_compress zram zsmalloc overlay binfmt_misc intel_rapl_msr intel_rapl_common ghash_clmulni_intel sha512_ssse3 sha512_generic iTCO_wdt intel_pmc_bxt iTCO_vendor_support virtio_rng aesni_intel crypto_simd watchdog cryptd pcspkr rng_core virtio_gpu virtio_console virtio_balloon virtio_dma_buf drm_shmem_helper drm_kms_helper button evdev joydev serio_raw sg fuse dm_mod drm loop efi_pstore configfs qemu_fw_cfg ip_tables x_tables autofs4 xfs libcrc32c crc32c_generic hid_generic usbhid hid sr_mod cdrom sd_mod t10_pi ahci crc64_rocksoft crc64 crc_t10dif libahci crct10dif_generic virtio_net net_failover virtio_scsi failover libata xhci_pci scsi_mod psmouse xhci_hcd crct10dif_pclmul crct10dif_common
Jul 22 05:00:22 myvm kernel:  crc32_pclmul crc32c_intel i2c_i801 i2c_smbus lpc_ich scsi_common usbcore virtio_pci virtio_pci_legacy_dev virtio_pci_modern_dev virtio usb_common virtio_ring
Jul 22 05:00:22 myvm kernel: CR2: 0000000000000002
Jul 22 05:00:22 myvm kernel: ---[ end trace 0000000000000000 ]---
Jul 22 05:00:22 myvm kernel: RIP: 0010:next_uptodate_page+0x45/0x1f0
Jul 22 05:00:22 myvm kernel: Code: 0f 84 2f 01 00 00 48 81 ff 06 04 00 00 0f 84 a3 00 00 00 48 81 ff 02 04 00 00 0f 84 26 01 00 00 40 f6 c7 01 0f 85 8c 00 00 00 <48> 8b 07 a8 01 0f 85 81 00 00 00 8b 47 34 85 c0 74 7a 8d 50 01 4c
Jul 22 05:00:22 myvm kernel: RSP: 0000:ffffc1ae8274bcc0 EFLAGS: 00010246
Jul 22 05:00:22 myvm kernel: RAX: 0000000000000002 RBX: ffffc1ae8274bd18 RCX: 000000000000005e
Jul 22 05:00:22 myvm kernel: RDX: ffffc1ae8274bd18 RSI: ffffa0210863d2b0 RDI: 0000000000000002
Jul 22 05:00:22 myvm kernel: RBP: ffffa0210863d2b0 R08: 000000000000005e R09: 000055fb22bbdfff
Jul 22 05:00:22 myvm kernel: R10: 000000000000004f R11: 0000000000000000 R12: 000000000000005e
Jul 22 05:00:22 myvm kernel: R13: ffffa02194ad6980 R14: ffffa0210863d2b0 R15: ffffa02118538f60
Jul 22 05:00:22 myvm kernel: FS:  00007f423625fa40(0000) GS:ffffa0226bf80000(0000) knlGS:0000000000000000
Jul 22 05:00:22 myvm kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jul 22 05:00:22 myvm kernel: CR2: 0000000000000002 CR3: 000000010d87e000 CR4: 0000000000350ee0
Jul 22 05:00:22 myvm kernel: ------------[ cut here ]------------
Jul 22 05:00:22 myvm kernel: Voluntary context switch within RCU read-side critical section!
Jul 22 05:00:22 myvm kernel: WARNING: CPU: 3 PID: 3235204 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x4ee/0x690
Jul 22 05:00:22 myvm kernel: Modules linked in: ipt_REJECT nf_reject_ipv4 xt_multiport xt_nat xt_tcpudp veth xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat nf_tables nfnetlink br_netfilter bridge stp llc lz4 lz4_compress zram zsmalloc overlay binfmt_misc intel_rapl_msr intel_rapl_common ghash_clmulni_intel sha512_ssse3 sha512_generic iTCO_wdt intel_pmc_bxt iTCO_vendor_support virtio_rng aesni_intel crypto_simd watchdog cryptd pcspkr rng_core virtio_gpu virtio_console virtio_balloon virtio_dma_buf drm_shmem_helper drm_kms_helper button evdev joydev serio_raw sg fuse dm_mod drm loop efi_pstore configfs qemu_fw_cfg ip_tables x_tables autofs4 xfs libcrc32c crc32c_generic hid_generic usbhid hid sr_mod cdrom sd_mod t10_pi ahci crc64_rocksoft crc64 crc_t10dif libahci crct10dif_generic virtio_net net_failover virtio_scsi failover libata xhci_pci scsi_mod psmouse xhci_hcd crct10dif_pclmul crct10dif_common
Jul 22 05:00:22 myvm kernel:  crc32_pclmul crc32c_intel i2c_i801 i2c_smbus lpc_ich scsi_common usbcore virtio_pci virtio_pci_legacy_dev virtio_pci_modern_dev virtio usb_common virtio_ring
Jul 22 05:00:22 myvm kernel: CPU: 3 PID: 3235204 Comm: postmaster Tainted: G      D            6.1.0-10-amd64 #1  Debian 6.1.37-1
Jul 22 05:00:22 myvm kernel: Hardware name: Hetzner vServer/Standard PC (Q35 + ICH9, 2009), BIOS 20171111 11/11/2017
Jul 22 05:00:22 myvm kernel: RIP: 0010:rcu_note_context_switch+0x4ee/0x690
Jul 22 05:00:22 myvm kernel: Code: 49 89 3f 49 83 bc 24 98 00 00 00 00 0f 85 66 fe ff ff e9 58 fe ff ff 48 c7 c7 68 53 70 94 c6 05 d7 0e ad 01 01 e8 d2 8e f6 ff <0f> 0b e9 70 fb ff ff a9 ff ff ff 7f 0f 84 2c fc ff ff 65 48 8b 3c
Jul 22 05:00:22 myvm kernel: RSP: 0018:ffffc1ae8274bc60 EFLAGS: 00010086
Jul 22 05:00:22 myvm kernel: RAX: 0000000000000000 RBX: ffffa0226bfb1c00 RCX: 0000000000000000
Jul 22 05:00:22 myvm kernel: RDX: 0000000000000003 RSI: ffffffff9474105e RDI: 00000000ffffffff
Jul 22 05:00:22 myvm kernel: RBP: 0000000000000000 R08: 0000000000000000 R09: ffffc1ae8274bad0
Jul 22 05:00:22 myvm kernel: R10: 0000000000000003 R11: ffffffff94ed43a8 R12: 0000000000030e40
Jul 22 05:00:22 myvm kernel: R13: ffffa02175d09980 R14: ffffc1ae8274bd50 R15: 0000000000000000
Jul 22 05:00:22 myvm kernel: FS:  0000000000000000(0000) GS:ffffa0226bf80000(0000) knlGS:0000000000000000
Jul 22 05:00:22 myvm kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jul 22 05:00:22 myvm kernel: CR2: 00007f41ef6dd70e CR3: 00000000059f6000 CR4: 0000000000350ee0
Jul 22 05:00:22 myvm kernel: Call Trace:
Jul 22 05:00:22 myvm kernel:  <TASK>
Jul 22 05:00:22 myvm kernel:  ? __warn+0x7d/0xc0
Jul 22 05:00:22 myvm kernel:  ? rcu_note_context_switch+0x4ee/0x690
Jul 22 05:00:22 myvm kernel:  ? report_bug+0xe6/0x170
Jul 22 05:00:22 myvm kernel:  ? irq_work_queue+0xa/0x50
Jul 22 05:00:22 myvm kernel:  ? handle_bug+0x41/0x70
Jul 22 05:00:22 myvm kernel:  ? exc_invalid_op+0x13/0x60
Jul 22 05:00:22 myvm kernel:  ? asm_exc_invalid_op+0x16/0x20
Jul 22 05:00:22 myvm kernel:  ? rcu_note_context_switch+0x4ee/0x690
Jul 22 05:00:22 myvm kernel:  __schedule+0xac/0xa20
Jul 22 05:00:22 myvm kernel:  schedule+0x5d/0xe0
Jul 22 05:00:22 myvm kernel:  rwsem_down_write_slowpath+0x34e/0x730
Jul 22 05:00:22 myvm kernel:  exit_mmap+0xf6/0x2f0
Jul 22 05:00:22 myvm kernel:  __mmput+0x3e/0x130
Jul 22 05:00:22 myvm kernel:  do_exit+0x2fc/0xb10
Jul 22 05:00:22 myvm kernel:  make_task_dead+0x8d/0x90
Jul 22 05:00:22 myvm kernel:  rewind_stack_and_make_dead+0x17/0x20
Jul 22 05:00:22 myvm kernel: RIP: 0033:0x7f42398b32a6
Jul 22 05:00:22 myvm kernel: Code: Unable to access opcode bytes at 0x7f42398b327c.
Jul 22 05:00:22 myvm kernel: RSP: 002b:00007ffc8a9aae68 EFLAGS: 00010287
Jul 22 05:00:22 myvm kernel: RAX: 0000000000000001 RBX: 000055fb22b39750 RCX: 0000000000000010
Jul 22 05:00:22 myvm kernel: RDX: 0000000000000000 RSI: 00007f41b1534550 RDI: 000055fb22b59d01
Jul 22 05:00:22 myvm kernel: RBP: 0000000000000009 R08: 0000000000000000 R09: 000055fb22b39750
Jul 22 05:00:22 myvm kernel: R10: 00007f41b1534550 R11: 000000000000002c R12: 00007f42398c3180
Jul 22 05:00:22 myvm kernel: R13: 0000000000000000 R14: 0000000000000009 R15: 00007f42398c3180
Jul 22 05:00:22 myvm kernel:  </TASK>
Jul 22 05:00:22 myvm kernel: ---[ end trace 0000000000000000 ]---

저도 어느 정도 같은 생각을 하고 있습니다. 다만 이 문제는 다소 반복되는 성격을 띠고 있어, 완전히 무작위라고 보기에는 약간 부족합니다. Hetzner가 아마 ECC RAM을 사용하지 않을 것이라고 추측합니다. 그것이 아마도 그렇게 저렴한 가격에 많은 것을 제공할 수 있는 이유일 것입니다. 심지어 그들의 전용 서버조차도 보도에 따르면 ECC를 갖추지 않았거나 갖추지 않은 것으로 보입니다. 하지만 그렇다고 하더라도 Hetzner는 인프라 측면에서 일반적으로 매우 신뢰할 수 있다고 평가받고 있습니다.

RGJ · 7월 23, 2023, 5:23오전

제 직감으로는 이쪽 일 것 같습니다. Zram과 XFS를 하나씩 제거해 보시고 어떤 일이 일어나는지 확인해 보세요. Zram을 1순위 용의자로 보고 있습니다. Discourse는 일반적인 swap와 ext4로 충분히 정상적으로 실행됩니다. 이러한 최적화 작업이 재미있을 수는 있지만, 현재는 설치 복잡도를 높이고 있습니다. 인스턴스가 정상적으로 실행되는 것을 확인한 후, 하나씩 다시 추가해 보며 어디서 문제가 발생하는지 확인해 보세요.

일반적인 원칙으로, 먼저 권장 설치 환경에 최대한 가깝게 유지한 후에 본인의 스마트한 설정들을 추가하는 것이 좋습니다.

rahim123 · 7월 23, 2023, 6:26오전

답변 감사합니다. Zram을 비활성화하고 2GB의 스왑 파일을 추가해 보려고 합니다. 파일 시스템 변경은 Debian을 새로 설치하여 VM을 완전히 다시 구축해야 하므로, XFS가 실제로 문제를 일으킬 일은 거의 없어야 합니다.

RGJ · 7월 23, 2023, 9:42오전

그랬으면 좋겠지만, XFS에 대해 이야기하기 시작하면 끝이 없습니다. 지난 10년 동안 XFS로 인한 커널 메모리 문제 때문에 최소 200시간을 낭비했습니다.

rahim123 · 11월 19, 2023, 10:31오후

음, @RGJ 님이 XFS에 대해 완전히 옳게 말씀하셨네요. 올바른 방향으로 이끌어 주셔서 감사합니다. (2002년경부터 XFS를 주로 1순위로 사용해 왔기 때문에, 파일시스템으로서 XFS가 매우 안정적이라는 것을 당연하게 여겨왔습니다. 실제로도 안정적이지만,Apparently 메모리 관련 버그가 있는 것 같습니다.) zRAM을 비활성화한 후에도 동일한 문제가 발생했으며, 이후 Debian이 XFS 충돌에 대한 패치를 포함하는 6.1 커널 업데이트를 배포했습니다:

6.1.0-13 커널을 설치한 이후로 서버는 42일 동안 아무 문제 없이 작동하고 있습니다.

글		댓글	조회수
Discourse not using much RAM Self-hosting server-resources	30	2174	8월 8, 2021
Discourse installation has been getting slower and slower and slower Self-hosting server-resources	36	2249	4월 15, 2023
Unusually high CPU usage Self-hosting	31	1455	2월 18, 2026
Can't install Discourse with only 10 GB disk, run out of space Self-hosting docker , server-resources	42	13704	9월 6, 2017
Crashing with out of memory error when opening a topic Product Support server-resources	6	1147	1월 19, 2019

XFS로 인한 커널 오OPS / CPU 스톨

Related topics