Caught signal (Segmentation fault)

L

luckiluck

New Member
Oct 14, 2024
5
1
3
Hallo,

ich habe einen PVE 8.2.7 Ceph Cluster .. sporadisch, 1x täglich fällt ein Node aus. Da ich die Meldung "Caught signal (Segmentation fault)" im Log der anderen Nodes nicht sehe, vermute ich, dass dies die Ursache ist. Der Failover der VMs und Container funktioniert problemlos.

Ich bin etwas ratlos was die Ursache ist. Das Node muss ich dann immer ausschalten und wieder anschalten. Das Node startet problemlos und es findet eine Recovery Objekte statt.

Die drei Nodes sind von der Hardware her identisch.

Was könnte die Ursache sein?

Herzliche Grüße und besten Dank vorab
Sebastian
----

Code: 
Oct 14 08:03:52 pve3 ceph-osd[1226]:  NOTE: a copy of the executable, or `objdump -rdS <executable>` is needed to interpret this.
Oct 14 08:03:52 pve3 ceph-osd[1226]:      0> 2024-10-14T08:03:52.519+0200 7d932b4006c0 -1 *** Caught signal (Segmentation fault) **
Oct 14 08:03:52 pve3 ceph-osd[1226]:  in thread 7d932b4006c0 thread_name:bstore_kv_sync
Oct 14 08:03:52 pve3 ceph-osd[1226]:  ceph version 18.2.4 (2064df84afc61c7e63928121bfdd74c59453c893) reef (stable)
Oct 14 08:03:52 pve3 ceph-osd[1226]:  1: /lib/x86_64-linux-gnu/libc.so.6(+0x3c050) [0x7d934285b050]
Oct 14 08:03:52 pve3 ceph-osd[1226]:  2: tc_memalign()
Oct 14 08:03:52 pve3 ceph-osd[1226]:  3: posix_memalign()
Oct 14 08:03:52 pve3 ceph-osd[1226]:  4: (ceph::buffer::v15_2_0::create_aligned_in_mempool(unsigned int, unsigned int, int)+0x14b) [0x57eec5a5ed3b]
Oct 14 08:03:52 pve3 ceph-osd[1226]:  5: (ceph::buffer::v15_2_0::create_aligned(unsigned int, unsigned int)+0x22) [0x57eec5a5ee32]
Oct 14 08:03:52 pve3 ceph-osd[1226]:  6: (ceph::buffer::v15_2_0::create(unsigned int)+0x22) [0x57eec5a5ee72]
Oct 14 08:03:52 pve3 ceph-osd[1226]:  7: (ceph::buffer::v15_2_0::list::obtain_contiguous_space(unsigned int)+0xa3) [0x57eec5a5f083]
Oct 14 08:03:52 pve3 ceph-osd[1226]:  8: (BlueFS::_compact_log_dump_metadata_NF(unsigned long, bluefs_transaction_t*, int, unsigned long)+0x16d) [0x57eec57e0e4d]
Oct 14 08:03:52 pve3 ceph-osd[1226]:  9: (BlueFS::_compact_log_async_LD_LNF_D()+0x464) [0x57eec57f1a14]
Oct 14 08:03:52 pve3 ceph-osd[1226]:  10: (BlueFS::_maybe_compact_log_LNF_NF_LD_D()+0xcd) [0x57eec57f2c2d]
Oct 14 08:03:52 pve3 ceph-osd[1226]:  11: (BlueFS::fsync(BlueFS::FileWriter*)+0x12f) [0x57eec57f33cf]
Oct 14 08:03:52 pve3 ceph-osd[1226]:  12: (BlueRocksWritableFile::Sync()+0x14) [0x57eec5807ad4]
Oct 14 08:03:52 pve3 ceph-osd[1226]:  13: /usr/bin/ceph-osd(+0x13e3d76) [0x57eec5e98d76]
Oct 14 08:03:52 pve3 ceph-osd[1226]:  14: (rocksdb::WritableFileWriter::SyncInternal(bool)+0x681) [0x57eec5ecd401]
Oct 14 08:03:52 pve3 ceph-osd[1226]:  15: (rocksdb::WritableFileWriter::Sync(bool)+0x393) [0x57eec5ed1ec3]
Oct 14 08:03:52 pve3 ceph-osd[1226]:  16: (rocksdb::DBImpl::WriteToWAL(rocksdb::WriteThread::WriteGroup const&, rocksdb::log::Writer*, unsigned long*, bool, bool, unsigned long, rocksdb::DBImpl::LogFileNumberSize&)+0x51d) [0x57eec5d318dd]
Oct 14 08:03:52 pve3 ceph-osd[1226]:  17: (rocksdb::DBImpl::WriteImpl(rocksdb::WriteOptions const&, rocksdb::WriteBatch*, rocksdb::WriteCallback*, unsigned long*, unsigned long, bool, unsigned long*, unsigned long, rocksdb::PreReleaseCallback*, rocksdb::PostMemTableCallback*)+0x17ea) [0x57eec5d3a14a]
Oct 14 08:03:52 pve3 ceph-osd[1226]:  18: (rocksdb::DBImpl::Write(rocksdb::WriteOptions const&, rocksdb::WriteBatch*)+0x74) [0x57eec5d3ac04]
Oct 14 08:03:52 pve3 ceph-osd[1226]:  19: (RocksDBStore::submit_common(rocksdb::WriteOptions&, std::shared_ptr<KeyValueDB::TransactionImpl>)+0x85) [0x57eec5cb9965]
Oct 14 08:03:52 pve3 ceph-osd[1226]:  20: (RocksDBStore::submit_transaction_sync(std::shared_ptr<KeyValueDB::TransactionImpl>)+0xa1) [0x57eec5cba711]
Oct 14 08:03:52 pve3 ceph-osd[1226]:  21: (BlueStore::_kv_sync_thread()+0x1218) [0x57eec5785028]
Oct 14 08:03:52 pve3 ceph-osd[1226]:  22: (BlueStore::KVSyncThread::entry()+0xd) [0x57eec57b114d]
Oct 14 08:03:52 pve3 ceph-osd[1226]:  23: /lib/x86_64-linux-gnu/libc.so.6(+0x89144) [0x7d93428a8144]
Oct 14 08:03:52 pve3 ceph-osd[1226]:  24: /lib/x86_64-linux-gnu/libc.so.6(+0x1097dc) [0x7d93429287dc]
Oct 14 08:03:52 pve3 ceph-osd[1226]:  NOTE: a copy of the executable, or `objdump -rdS <executable>` is needed to interpret this.
Oct 14 08:03:53 pve3 systemd[1]: ceph-osd@5.service: Main process exited, code=killed, status=11/SEGV
Oct 14 08:03:53 pve3 systemd[1]: ceph-osd@5.service: Failed with result 'signal'.
Oct 14 08:03:53 pve3 systemd[1]: ceph-osd@5.service: Consumed 31min 27.802s CPU time.
Oct 14 08:03:53 pve3 kernel: libceph (81290533-0f9d-4009-a368-3b7e9262cbb3 e1584): osd5 down
Oct 14 08:04:03 pve3 systemd[1]: ceph-osd@5.service: Scheduled restart job, restart counter is at 1.
Oct 14 08:04:03 pve3 systemd[1]: Stopped ceph-osd@5.service - Ceph object storage daemon osd.5.
Oct 14 08:04:03 pve3 systemd[1]: ceph-osd@5.service: Consumed 31min 27.802s CPU time.
Oct 14 08:04:03 pve3 systemd[1]: Starting ceph-osd@5.service - Ceph object storage daemon osd.5...
Oct 14 08:04:03 pve3 systemd[1]: Started ceph-osd@5.service - Ceph object storage daemon osd.5.
Oct 14 08:04:31 pve3 pveproxy[487557]: worker exit
Oct 14 08:04:31 pve3 pveproxy[1383]: worker 487557 finished
Oct 14 08:04:31 pve3 pveproxy[1383]: starting 1 worker(s)
Oct 14 08:04:31 pve3 pveproxy[1383]: worker 507864 started
Oct 14 08:04:33 pve3 ceph-osd[507265]: 2024-10-14T08:04:33.761+0200 752b23d8e840 -1 osd.5 1583 log_to_monitors true
Oct 14 08:04:34 pve3 ceph-osd[507265]: 2024-10-14T08:04:34.003+0200 752b16a006c0 -1 osd.5 1583 set_numa_affinity unable to identify public interface '' numa node: (2) No such file or directory
Oct 14 08:04:36 pve3 kernel: libceph (81290533-0f9d-4009-a368-3b7e9262cbb3 e1587): osd5 up
Oct 14 08:05:01 pve3 CRON[508077]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Oct 14 08:05:01 pve3 CRON[508078]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Oct 14 08:05:01 pve3 CRON[508077]: pam_unix(cron:session): session closed for user root
Oct 14 08:05:18 pve3 pmxcfs[823]: [status] notice: received log
Oct 14 08:06:03 pve3 pveproxy[493126]: worker exit
Oct 14 08:06:03 pve3 pveproxy[1383]: worker 493126 finished
Oct 14 08:06:03 pve3 pveproxy[1383]: starting 1 worker(s)
Oct 14 08:06:03 pve3 pveproxy[1383]: worker 508442 started
-- Reboot --

Code: 
HEALTH_WARN: Degraded data redundancy: 26814/8525754 objects degraded (0.315%), 33 pgs degraded, 33 pgs undersized
pg 3.0 is stuck undersized for 32m, current state active+recovery_wait+undersized+degraded+remapped, last acting [4,3]

HEALTH_WARN: 1 daemons have recently crashed
osd.5 crashed on host pve3 at 2024-10-14T06:03:52.520471Z
 
Hallo Sebastian, Segmentation fault kann leider sehr viele Ursachen haben... ich sehe das die osd.5 davon betroffen ist. Ist es immer die gleiche OSD?

Eine unzureichende Speicherzuweisung oder eine Überbelegung von Ressourcen kann auch zu segfault führen. Beschädigte oder ungültige Daten im OSD-Speicher oder in die Metadaten können auch zum Absturz des Prozesses führen.

Was sagt dir denn:
Code: 
head /proc/pressure/*
und
Code: 
pveceph status
wenn alle Nodes aktive und up sind?

Bitte auch noch
Code: 
lsblk --ascii -M -o +HOTPLUG,ROTA,PHY-SEC,FSTYPE,MODEL,TRAN
und
Code: 
ceph osd df tree
 
Hallo Mario,

ich habe die Commands auf dem betroffenen Node 3 abgesetzt, aktuell läuft auch noch die Recovery, alle drei Nodes sind aktiv. Beim letzten Fall war nur die osd.5 betroffen. Davor auch die osd.2, die musste ich dann sogar komplett entfernen und wieder neu einbinden.

Ganz herzlichen Dank !!!

Viele Grüße
Sebastian

Code: 
root@pve3:~# head /proc/pressure/*
==> /proc/pressure/cpu <==
some avg10=0.00 avg60=0.00 avg300=0.00 total=83092074
full avg10=0.00 avg60=0.00 avg300=0.00 total=0

==> /proc/pressure/io <==
some avg10=18.95 avg60=20.02 avg300=20.47 total=4843374851
full avg10=18.01 avg60=19.31 avg300=19.73 total=4666380149

==> /proc/pressure/memory <==
some avg10=0.00 avg60=0.00 avg300=0.00 total=50
full avg10=0.00 avg60=0.00 avg300=0.00 total=50
root@pve3:~#

Code: 
root@pve3:~# pveceph status
  cluster:
    id:     81290533-0f9d-4009-a368-3b7e9262cbb3
    health: HEALTH_WARN
            Degraded data redundancy: 5740/9502884 objects degraded (0.060%), 8 pgs degraded, 8 pgs undersized
            1 daemons have recently crashed
            1 slow ops, oldest one blocked for 48 sec, osd.3 has slow ops
 
  services:
    mon: 3 daemons, quorum pve1,pve2,pve3 (age 6h)
    mgr: pve2(active, since 22h), standbys: pve1, pve3
    mds: 2/2 daemons up, 1 standby
    osd: 6 osds: 6 up (since 6h), 6 in (since 6h); 8 remapped pgs
 
  data:
    volumes: 2/2 healthy
    pools:   7 pools, 193 pgs
    objects: 3.17M objects, 4.1 TiB
    usage:   12 TiB used, 15 TiB / 28 TiB avail
    pgs:     5740/9502884 objects degraded (0.060%)
             185 active+clean
             6   active+recovery_wait+undersized+degraded+remapped
             1   active+recovering+undersized+degraded+remapped
             1   active+undersized+degraded+remapped+backfill_wait
 
  io:
    client:   44 MiB/s wr, 0 op/s rd, 30 op/s wr
    recovery: 6.0 MiB/s, 1 objects/s
 
root@pve3:~#

Code: 
root@pve3:~# lsblk --ascii -M -o +HOTPLUG,ROTA,PHY-SEC,FSTYPE,MODEL,TRAN
    NAME               MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS HOTPLUG ROTA PHY-SEC FSTYPE    MODEL      TRAN
    sda                  8:0    0   3.7T  0 disk                   0    0     512 LVM2_memb Verbatim V sata
    `-ceph--64643c83--ca11--4bf8--bcac--809b4f80d97d-osd--block--a1b0989c--8e41--4d38--9dfb--8ab9a321f06c
                       252:0    0   3.7T  0 lvm                    0    0     512 ceph_blue           
    sdb                  8:16   0   5.5T  0 disk                   1    1    4096 LVM2_memb WDC WD60ND usb
    `-ceph--9ca098c4--4323--4e9c--a59c--34bdd0d63daa-osd--block--9ce05ee8--bcb6--49aa--988b--b175d37f1336
                       252:6    0   5.5T  0 lvm                    0    1    4096 ceph_blue           
    nvme0n1            259:0    0 476.9G  0 disk                   0    0     512           NE-512 228 nvme
    |-nvme0n1p1        259:1    0  1007K  0 part                   0    0     512                      nvme
    |-nvme0n1p2        259:2    0     1G  0 part /boot/efi         0    0     512 vfat                 nvme
    |-nvme0n1p3        259:3    0   255G  0 part                   0    0     512 LVM2_memb            nvme
    | |-pve-swap       252:1    0    32G  0 lvm  [SWAP]            0    0     512 swap                 
    | |-pve-root       252:2    0    64G  0 lvm  /                 0    0     512 ext4                 
,-> | |-pve-data_tmeta 252:3    0   1.3G  0 lvm                    0    0     512                     
'-> | `-pve-data_tdata 252:4    0 124.5G  0 lvm                    0    0     512                     
 |  `-nvme0n1p4        259:4    0 220.9G  0 part                   0    0     512                      nvme
 `--pve-data           252:5    0 124.5G  0 lvm                    0    0     512                     
root@pve3:~#

Code: 
root@pve3:~# ceph osd df tree
ID  CLASS  WEIGHT    REWEIGHT  SIZE     RAW USE  DATA     OMAP     META     AVAIL    %USE   VAR   PGS  STATUS  TYPE NAME   
-1         27.55197         -   28 TiB   12 TiB   12 TiB  949 MiB   30 GiB   15 TiB  44.42  1.00    -          root default
-3          9.18399         -  9.2 TiB  4.1 TiB  4.1 TiB  317 MiB  9.9 GiB  5.1 TiB  44.50  1.00    -              host pve1
 3    hdd   5.45799   1.00000  5.5 TiB  1.9 TiB  1.9 TiB  332 KiB  4.0 GiB  3.5 TiB  35.22  0.79   96      up          osd.3
 0    ssd   3.72600   1.00000  3.7 TiB  2.2 TiB  2.2 TiB  317 MiB  5.9 GiB  1.6 TiB  58.08  1.31   97      up          osd.0
-5          9.18399         -  9.2 TiB  4.1 TiB  4.1 TiB  317 MiB   10 GiB  5.1 TiB  44.50  1.00    -              host pve2
 4    hdd   5.45799   1.00000  5.5 TiB  1.9 TiB  1.9 TiB  366 KiB  4.2 GiB  3.5 TiB  35.22  0.79   96      up          osd.4
 1    ssd   3.72600   1.00000  3.7 TiB  2.2 TiB  2.2 TiB  317 MiB  6.0 GiB  1.6 TiB  58.09  1.31   97      up          osd.1
-7          9.18399         -  9.2 TiB  4.1 TiB  4.1 TiB  315 MiB  9.7 GiB  5.1 TiB  44.25  1.00    -              host pve3
 5    hdd   5.45799   1.00000  5.5 TiB  1.9 TiB  1.9 TiB  327 KiB  4.5 GiB  3.6 TiB  34.83  0.78   88      up          osd.5
 2    ssd   3.72600   1.00000  3.7 TiB  2.2 TiB  2.2 TiB  315 MiB  5.2 GiB  1.6 TiB  58.06  1.31   97      up          osd.2
                        TOTAL   28 TiB   12 TiB   12 TiB  949 MiB   30 GiB   15 TiB  44.42                                 
MIN/MAX VAR: 0.78/1.31  STDDEV: 11.70
root@pve3:~#
 
Hi, der I/O Pressure ist schon heftig hoch. Du hast auch nur eine SSD und eine HDD pro Node, wie sieht denn deine Poolkonfiguration aus und hast den Bluestore für die HDDs auf die SSDs gepackt?
 
  • Like
Reactions: mariol
Falk R. said:
Hi, der I/O Pressure ist schon heftig hoch. Du hast auch nur eine SSD und eine HDD pro Node, wie sieht denn deine Poolkonfiguration aus und hast den Bluestore für die HDDs auf die SSDs gepackt?
Click to expand...
Hallo,

ja, das wird wohl daran gelegen haben, dass ich massiv Daten kopiert habe und gleichzeitig die Recovery lief. Aber im Grunde sollte das kein Thema sein. Klar ist Wait-IO nie schön, aber im HDD-Pool für mich unrelevant. Den hdd-pool verwende ich ausschliesslich für CephFS (Samba / Datenarchiv).

Nun sieht es anders aus, normal Betrieb (Recovery ist durch und keine Kopieraktion):
Code: 
root@pve3:~# head /proc/pressure/*
==> /proc/pressure/cpu <==
some avg10=0.00 avg60=0.00 avg300=0.00 total=184153454
full avg10=0.00 avg60=0.00 avg300=0.00 total=0

==> /proc/pressure/io <==
some avg10=0.16 avg60=0.33 avg300=0.98 total=8711560112
full avg10=0.16 avg60=0.30 avg300=0.94 total=8378749058

==> /proc/pressure/memory <==
some avg10=0.00 avg60=0.00 avg300=0.00 total=73
full avg10=0.00 avg60=0.00 avg300=0.00 total=73
root@pve3:~#

Soweit ich weiß ist mit dem Reef Release der Filestore Type deprecated und wird nicht länger unterstützt. Daher habe ich mir da keine Gedanken gemacht. Gibt da auch keine Auswahl in Proxmox 8.2.7. Im Grunde verwende ich die Default-Konfig im Proxmox, ich habe einzig die Crush-Rules per CLI angelegt. Was vielleicht Sinn machen würde die Meta-Daten auf eine SSD auszulagern?

Und ja, ich habe momentan nur eine SSD und eine HDD pro Node .. ich habe nur eine Lab Umgebung und kommt nicht auf Performance an. Die VMs und CTs laufen im SSD-Pool / RBD. Werde ich aber noch auf NVMe umstellen und mal schauen of die knapp 4TB des SSD-Pool für mein Datenarchive reichen. Dann könnte ich auf den verzichten.

Frage: Ich habe gelesen für Ceph soll man nur unpartitioniert Devices verwenden. Daher frage ich mich warum Proxmox mir das anbietet auch Partitions als OSD zu verwenden. Oder könnte man eine Partition auf einer NVMe für Meta-Daten verwenden?

Da ich nun mit der Migration von meiner alten ZFS basierten PVE Umgebung auf den Ceph Cluster durch bin, lasse ich das mal so laufen und schaue ob es wieder zum Problem kommt.

Auf jeden Fall ganz herzlichen Dank für die Hinweise und Hilfestellung. Über Tipps und Trick bin ich natürlich sehr dankbar.

Viele Grüße
Sebastian

1728927995993.png
 
Klar kannst du auch Partitionen nutzen, musst nur wissen was du tust und welche Abhängigkeiten du schaffst.
Der Bluestore der HDDs sollte unbedingt auf SSD ( mindestens 1% der Capacity, empfohlen 4% )
Die Metadaten bitte auch immer auf SSD.
Das sollte eine Menge verbessern.

Ich habe gelesen Verbatim SSD, ich hoffe keine Consumer SSDs.
 
Hallo, also könnte ich die NVMe Partitionieren und für die notwendigen Bluestore und Metadaten verwenden? So hatte ich es auf meinem Proxmox mit ZFS für ZIL und L2ARC gemacht.
Naja, Enterprise SSDs sind es keine. Müssen es unbedingt SLC oder MLC Module sein, die sind mir zu klein, oder geht auch 3D NAND (Samsung 990 Pro, TBW: 2400 TB und MTBF: 1,5 Mio. h)? Geht auch Transcend MTE250S (4TB), ist zwar eine 3D TLC, aber mit TBW: 3120 TB und MTBF: 3 Mio. h.
Danke dir, Grüße und einen schönen Abend!
 
luckiluck said:
Hallo, also könnte ich die NVMe Partitionieren und für die notwendigen Bluestore und Metadaten verwenden? So hatte ich es auf meinem Proxmox mit ZFS für ZIL und L2ARC gemacht.
Naja, Enterprise SSDs sind es keine. Müssen es unbedingt SLC oder MLC Module sein, die sind mir zu klein, oder geht auch 3D NAND (Samsung 990 Pro, TBW: 2400 TB und MTBF: 1,5 Mio. h)? Geht auch Transcend MTE250S (4TB), ist zwar eine 3D TLC, aber mit TBW: 3120 TB und MTBF: 3 Mio. h.
Danke dir, Grüße und einen schönen Abend!
Click to expand...
Hi, ich habe auch schon SSDs in mehrere Partitionen geteilt und Bluestore sowie OSD drauf gelegt.
Am besten SSDs mit PLP nutzen. Dann hast du deutlich bessere Schreibperformance und die halten ein vielfaches an schreiben ab.

Hier mal ein Beispiel:
PLP SSDs
 
Falk R. said:
Hi, ich habe auch schon SSDs in mehrere Partitionen geteilt und Bluestore sowie OSD drauf gelegt.
Am besten SSDs mit PLP nutzen. Dann hast du deutlich bessere Schreibperformance und die halten ein vielfaches an schreiben ab.

Hier mal ein Beispiel:
PLP SSDs
Click to expand...
Hallo,
Ich habe alle drei Nodes mit je zwei „SSD Kingston DC1000B 960GB M.2 (22x80) NVMe PCIe 3.0 SEDC1000BM8/960G“ ausgestattet und partitioniert, so dass ich den OSDs 10% für DB und 1% für WAL spendieren konnte. Musste dann für zusätzliche Kühlung der PLP NVMes sorgen, da diese ohne Kühlung extrem heiß werden und es dann wieder zum OSD Crash gekommen ist. Mit Kühlung ist das alles kein Problem und läuft stabil. Und bin begeistert, hatte drei inkonsistente PGs die beim Deep-Scrub gelöst wurden. Seither alles grün, stabil und Performance prima. Nächste Aktion wird sein, den HDD Pool gegen Enterprise SSDs auszutauschen. Muss aber sagen, beim Sync der SSDs mit DB/WAL auf PLP NVMe wird das 2,5GBit Ethernet nicht ausgereizt. Hat ca. 4,5h gedauert für knapp 2,4TB. Habe viel gelernt
Vielen Dank
 
  • Like
Reactions: Falk R.
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back