NvME förlorar prestanda med tiden.

Läser man recension om enheten så här enheten väldigt lite cache och skriver långsamt.
Den rekommenderas inte jämför med andra diskar.
https://www.tomshardware.com/reviews/crucial-p2-m-2-nvme-ssd

Skriver det så mycket att du har en skrivtakt större än 40 MB/s hela tiden?, och är det relaterat till spelet eller något annat som håller på (tex chia-mining som du ovetandes gör för att du fått skit i datorn - du får titta med SMART på disken och se hur det räknar upp i antal skrivna sektorer och tex ta ett par värden med 1 minuts mellanrum och räkna ut differensen och ta detta gånger 512 och se skrivmängden, detta är dolt av malware/viruset och ser noga till att ingen skrivlast syns i task manger eller under resource monitor och indikerar att det håller på att skriva sönder din disk... )?.

Sedan har det blivit ganska (o)lustigt att flashmedia har en skrivtakt numera man såg på snurrdiskar kring mitten av 2000-talet när man skrivit förbi de första typ 30 GB SLC-cachen och inte ger paus i skrivandet....

Förr även med vanlig SSD kunde man skriva hela disken igenom från första till sista sektorn med halva eller hela SATA-bussens hastighet (ca 270 resp 550 MB/s ) utan stallning och om det var halva eller hela SATA-hastigheten berodde på hur mycket minne det var i SSD:n.

På 4 timmar och 20 minuter ungefär för tiden mellan inläggen har det skrivits 1.2 GiByte vilket ger en skrivtakt av ca 80 kiByte i sekunden. inget att anmärka på.

så, vi kan nog utesluta chia-mining i bakgrunden på denna disk i alla fall.

Däremot att loggentrys har fördubblats på denna korta tid är oroande - gör backup på alla viktiga och känsliga filer omedelbart på annan media ifall det värsta händer - SSD/NVMe är inte snälla när de behaga gå sönder och ger ingen andra chans till skillnad från snurrdiskarna i de allra flesta fallen där man kan mjölka ut data med ddrescue under lång tid och faktiskt ofta rädda mer än 99.9% av datat även om det såg surt ut i början.

[github]
Inte underligt att det är besvärligt för dig med 'nvme-cli' på github - det är källkodspaket och är tänkt att kompileras under linux och har du inte en sådan miljö uppsatt på datorn så är denna oanvändbart för dig.

Har du WSL installerad och aktiverad samt tex. en ubuntu installerad så kanske, kanske det går att köra i denna "sudo apt-get install nvme-cli" och därefter köra kommandot om du hittar NVMe enheten under /dev/

Annars blir det att köra i en 'riktig' Ubuntu på någon live-iso från en USB-sticka - men förstår att det ä knöligt om man aldrig har gjort sådana saker innan.

Borde inte gör någon skillnad vilket slot du använder, man kan vara värt att se om det står något i manualen.
Och håller med xxargs att dina skrivhastigheter inte är så stora att det borde påverka.
Men möjligen är det en kombination av att den helt enklet är kass och börjar bli kassare? (gå sönder...)
Om du har någon gammal ssd disk så kan du installera spelen på den disken, så behöver NVMe-disken inte skriva/läsa lika mycket.

I och med error info log entry rusar i antal plötsligt så är det troligen något knas i din NVMe-lagring men inte i sådan omfattning att det börja varna ännu - är inte van med hur NVMe rapporterar men saknar faktiskt lite av de normerade värdena som finns på SATA-SSD nu när de inte redovisas i NVMe-lagring och en lärdom av detta är att när antalet error info log entry börja rusa i antal på kort tid så bör det kanske jämställas med reallokerade sektorer på snurrdiskar som tidig indikation att man kommer att få problem snart. - att byta M.2 socket tror jag inte hjälper då det är troligen interna problem i själva lagringen såvida det inte är trubbel med kommunikationen på PCIe-lanes i sig - men för att se detta bör man få ut loggen på vad som felar... - dock att prova byta plats på M.2-socket skadar inte just för att utesluta problem med socket-hållaren eller med använda PCIe-lanes för nu använda M.2-socket, eller rent av att det inte sitter på rätt sätt i hållaren i nuläget...

Både SATA, SAS-diskar har betydligt mer information som kan läsas ut än de standardmässiga grafiska SMART-programmen brukar visa upp, nu har jag ingen dator hemma med NVMe-minne och exprementera i linux och tex. se vad "smartctrl -ax /dev/xxx" kan tänkas rapportera på NVMe-media - om det går alls vill säga (och motsvarande sdparm när det gäller SAS/SCSI-diskar).

Inte ett måste, men kan hjälpa skrivprestandan i avseende hastighet och minska lite på WAF - men den delen har nog minskat i betydelse med relativt stora SSD/NVMe-storlekar. Sådant var viktigare när SSD var 64-128 GB i storlek.

Jo förresten, det kan ha betydelse för flashlagring med QLC-minne då trim berättar för disken vilka sektorer vars kopplade flashminne kan friställas för SLC-cache då ju mer ledigt på disken ju större SLC-cache kan disken använda för snabb lagring innan skrivprestandan blir bedrövligt långsam (typ 40 MB/s) efter ett ganska lågt antal GB kontinuerlig skrivning

Ett alternativt sätt att visa vilka sektorer som inte användes och kunde kopplas bort så att bakomliggande flashen kunde raderas var att man helt enkelt skrev de lediga sektorer med bara '0' - vilket var enda sättet att tala om för SSD vilka sektorer som var 'lediga' innan TRIM-stödet implementerades.

I windows sägs officiellt att de kör TRIM endast på AHCI-enheter - dvs. SATA-SSD som inte finns i någon RAID-konstellation, inte på NVMe men förmodligen har drivrutiner för NVMe-lagring en ekvivalent funktion.

Windows brukar köra trim strax efter på filer som raderats och ibland en filsystem-TRIM enligt kalender (den kör också en enklare fildefragmentering typ 1 gång i veckan - väldigt diskret eftersom folk har fått islaget att man skall inte köra defragmentering på SSD - men problemet är att om NTFS skall hålla över tiden så måste det göras då och då ändå)

I linux så hanteras SATA-diskar och NVMe lika i avseende TRIM och där har man filosofi att man kör TRIM manuellt bara ibland och tex. när det har varit stora aktiviteter och mycket raderade filer eller schemalagt - och argumentet är att trim-processen på många flashlagringar kan dra ned prestanda ganska ordentligt medans TRIM-processen genomförs och därför bör göras vid tidpunkt när det inte gör så mycket om disken blir trög en stund. Givetvis går det att ha 'windowslik' TRIM direkt efter radering av filer även i linux med argumentet 'discard' i fstab för enheten.

Trim (i linux fstrim) fungerar också på krypterande volymen - men att nollställa sektorer längst ned närmast disken anses också något som sänker säkerheten då mönstret av nollade sektorer kan ge information om diskens innehåll - dvs hur välfylld den är och av mönstret också berätta vilken filsystem som används och därmed vilka positioner som har (meta)data som aldrig ändras och man kan ganska säker veta vad som finns skrivet där (som superblock eller första blocken i $MFT) - vilket underlättar attacken.

Om du inte har gjort det innan så kör igång crystaldiskinfo (gratis) och kolla hälsan på disken.
Du kan även köra tester för att se hur disken presterar.