Systemausfall

Lockslay

Member
Nov 27, 2020
115
1
23
50
Hallo zusammen,

ich hatte jetzt zum zweiten mal, dass mein PVE streikte.
Kein Webzugang, kein ssh, ich musste die PVE neu starten.

Als Fehler, wurde mir das Angezeigt:


Code:
3315571 systend-journa1a[468]: Failed to rotate /var/log/journal/86 333014]
systend-journaldI4681: Failed to rotate /var/log/journal/8680e80082#45fe8995b4969e97bec/systen. journal: Read-only file sys ten 333342] systend- journala[4681: Failed
to rotate /var/log/journal/86808d0082d45fe89₫95b4969e97bec/user-1000. journal: Read-only file systen

Hardware:
intel nuc10fnh ist im Einsatz
PVE 8.1.4

Unter /var/log/journal/8680e8d0082d45fe89d95b4969e97bec liegen zahlreiche Logs, welche kann ich aber gebrauchen.
Was könnte der Fehler sein?

Code:
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning            : 0
temperature                : 44°C (317 Kelvin)
available_spare                : 100%
available_spare_threshold        : 5%
percentage_used                : 4%
endurance group critical warning summary: 0
Data Units Read                : 8.791.400 (4,50 TB)
Data Units Written            : 38.664.641 (19,80 TB)
host_read_commands            : 73.244.937
host_write_commands            : 259.254.987
controller_busy_time            : 2.579
power_cycles                : 458
power_on_hours                : 659
unsafe_shutdowns            : 226
media_errors                : 0
num_err_log_entries            : 896
Warning Temperature Time        : 1
Critical Composite Temperature Time    : 0
Temperature Sensor 1           : 44°C (317 Kelvin)
Thermal Management T1 Trans Count    : 36
Thermal Management T2 Trans Count    : 1
Thermal Management T1 Total Time    : 3023

Thermal Management T2 Total Time : 325
 
Hallo,

df -h
Code:
Dateisystem                     Größe Benutzt Verf. Verw% Eingehängt auf
udev                              16G       0   16G    0% /dev
tmpfs                            3,2G    1,4M  3,2G    1% /run
/dev/mapper/proxmoxnuc--vg-root  456G     95G  338G   22% /
tmpfs                             16G     46M   16G    1% /dev/shm
tmpfs                            5,0M       0  5,0M    0% /run/lock
efivarfs                         192K     59K  129K   32% /sys/firmware/efi/efivars
/dev/nvme0n1p2                   456M    331M  100M   77% /boot
/dev/nvme0n1p1                   511M     12M  500M    3% /boot/efi
/dev/fuse                        128M     20K  128M    1% /etc/pve
192.168.0.132:/PVE_DAten          18T    6,9T   11T   39% /mnt/pve/PVE_Daten_NAS
tmpfs                            3,2G       0  3,2G    0% /run/user/1000
 
Was ist das für eine NVMe? Hast du mal in syslog geschaut, ob es weitere Meldungen vorher gab?
 
Hallo,

ich habe eine SSD M2 Speicher im Einsatz.
Hier die Logs vom PVE
https://paste.debian.net/1306078

Die syslog finde ich unter /var/log nicht.

root@proxmoxnuc:/var/log# ls
Code:
alternatives.log    corosync        glusterfs  private              pve-firewall.log.3.gz  README          wtmp
alternatives.log.1  dpkg.log        ifupdown2  pve              pve-firewall.log.4.gz  runit
apt            dpkg.log.1        installer  pveam.log          pve-firewall.log.5.gz  samba
btmp            fail2ban.log    journal    pve-firewall.log       pve-firewall.log.6.gz  sysstat
btmp.1            faillog        lastlog    pve-firewall.log.1     pve-firewall.log.7.gz  unattended-upgrades
ceph            fontconfig.log  lxc        pve-firewall.log.2.gz  pveproxy             vzdump
 
Also ganz eindeutige Hinweise habe ich keine gesehen beim überfliegen. Es gibt aber ein paar Einträge zum Filesystem und der Disk selbst.

Deine Disk ist eine CT500P5SSD8 mit 300 TBW. Mir scheint das Verhältnis TBW und PoH etwas zu krass, du scheinst sehr viel zu schreiben, kann das sein?
 
Hallo,

ich habe auf dem Gerät ein Verschlüsseltes Linux Debian mit PVE und einigen VE und LXE laufen.

Mir scheint das Verhältnis TBW und PoH etwas zu krass, Was genau meinst du damit?

Jitsi Nextcloud Matrix Element Reserve Proxy und ein VPN server.

Ich hatte das System bis vor ein paar Tagen auf einer HDD Hardware, da lief alle problemlos.
Kann im BIOS etwas nicht stimmen?
 
Last edited:
Mir scheint das Verhältnis TBW und PoH etwas zu krass, Was genau meinst du damit?
Lt. deinem Auszug sind 20 TB geschrieben, das sind rund 30 GB pro Stunde oder 720 GB pro Tag. Lt. Percentage used sind rund 12 TB geschrieben.

Gehen wir von 12 TB aus und teilen das durch die 659 Stunden dann dürfte deine NVMe in ca 1,88 Jahren durchgeschrieben sein. Sprich du müsstest dich darauf einstellen alle 2 Jahre deine Node neu zu machen und eine NVMe zu kaufen.
Die hohe Last kann sicherlich durch die Verschlüsselung kommen. Grundsätzlich würde ich dir raten das Geld in eine Enterprise Variante zu stecken, die machen in der Regel das 5 bis 6 fache an Schreibleistung und dürften damit rund 8 - 10 Jahre bei dir halten.

Ich denke nicht, dass es etwas mit dem BIOS zu tun hat. Vielleicht ist eher ein Temperaturproblem, das Netzteil defekt oder der RAM hat ein Problem. Es kann aber auch an der verbauten NIC liegen, denn bei den NUCs gibt es hier ja bereits etliche Threads die ähnliche Auswirkungen beschreiben was wohl von der Realtek NIC herrührt. Könnte womöglich auch bei dir zutreffen, denn augenscheinlich gibt es eben keine Anzeichen.
 
Hallo,

ich glaube nicht, dass es an der Verschlüsselung liegt, das würde doch nur die CPU betreffen.
Über welche Info in den Logs bist du an das Verhältnis TBW und PoH gekommen?

Würde gerne was lernen ;-)
 
ich glaube nicht, dass es an der Verschlüsselung liegt, das würde doch nur die CPU betreffen.
Die CPU berechnet das ganze, aber die Disk muss diese Daten auch wieder weg schreiben. Gerade bei einer Vollverschlüsselung sind mehr Aktionen erforderlich um die Daten und die Mengen wirklich zu verschleiern. Daher sollte man wenn auf die native Verschlüsselung des Datenträger setzen oder nur das verschlüsseln, was auch verschlüsselt sein soll. Verschlüsselung kostet generell Ressourcen und kann nie 1:1 zu einem unverschlüsselten System performen. Zwar ist es heute nicht mehr so gravierend wie früher, aber dennoch nicht ohne Kosten. Maßgeblich hängt aber alles von der gewählten Lösung / Implementierung etc. pp. ab.
Über welche Info in den Logs bist du an das Verhältnis TBW und PoH gekommen?
Du hast die SMART Werte geschickt. Und TBW kann man über Portale wie z. B. Geizhals einfach ermitteln oder über die Herstellerseiten. Das Modell stand beim SMART Service im Log, dementsprechend hatte ich die PoH, das was bereits geschrieben wurde in Percent und TB aus deinem SMART Abzug, das Modell aus dem Log und die TBW von der Herstellerseite. Was anschließend folgt ist einfach die Schreiblast durch die Anzahl der Stunden zu teilen und dann eben die TBW dadurch zu teilen.
Sicher ist das nichts hundertprozentiges und es betrachtet womöglich auch nicht einen temporären höheren Schreibaufwand etc. aber es gibt mal einen ersten Anhaltspunkt. Wenn dir also keine besonderen Ereignisse bekannt sind wie z.B. du hast mehrfach eine VM mit 500 GB Speicher gelöscht und wiederhergestellt oder schreibst täglich all deine ISO Files neu oder was auch immer, dann kannst du also durchaus davon ausgehen, dass deine Disk bei der gleichen Last wie in den vergangenen Stunden nach ca. 2 Jahre sterben wird.
 
  • Like
Reactions: Lockslay
Was würdet ihr zu dieser Meldung sagen:

Feb 02 14:09:47 proxmoxnuc kernel: rc rc0: receive overflow
 

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!

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!