Új hozzászólás Aktív témák

• trance89 őstag

  #16827

  #16807 ubyegon2

  máj. 17., 10:05:44

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  trance89

  őstag

  #16807 ubyegon2

  #16807 ubyegon2

  Manapság egy nvme ssd gyorsabb, sokkal, mint nemrég a memória volt, az elhasználódás miatt is kár aggódni a gyakorlatban, szóval amíg beállítanám inkább leírom, hogy szerintem kár beállítani ;-)

  Szerinted kár beállítani a zram-ot, érdekesmód két kifejezetten modernebb alapokra építkező Arch alapú disztró mégis default alkalmazza ezeket a BTRFS mellett, Garuda és CachyOS, amikre gondolok.

  Ez a sokkal gyorsabb is fura nekem, mivel az NVMe PCIe 4.0 szekvenciális sebessége ugye napi használatnál semmit nem jelent, de ez a Data Bandwidth kb azonos a DDR2 RAM meg a PCIe 4.0 NVMe között. Egyrészt van ez, másrészt ami gyorsaságnál, így a swap használatnál is lényeges lenne, az igencsak megdöbbentő különbség lesz, most figyelj!

  A PCIe 4.0 Response Latency 40000 nanosecundum, a DDR2 RAM ugyanezen értéke 10 nanosecundum! Azért itt van kis különbség és tegyük hozzá, hogy a az NVMe PCIe SSD technológia az minimum DDR4-es RAM-ot feltételez, de inkább DDR5-öt! A DDR2 párja a Sata SSD max!

  Én örülök a zram említésének, mert hiába a nagyon kevés RAM-mal rendelkező hardverek miatt jött létre, az a mai rendszerekben is kifejezetten okos dolog, nem véletlen a két említett kifejezetten modern disztró említése.

  Amúgy én is régóta rágom már a userek fülét a Kezdő topikban a zram kipróbálása miatt!

  En inkabb a zswap-et kapcsoltam be a zram helyett pont az itt leirtak miatt, nagyon jo iras:
  https://easylinuxtipsproject.blogspot.com/p/swappiness.html

  zswap taxes the CPU less than zRam. Sometimes much less: especially with desktop use the difference can be significant. But there's more at play:
  
  As explained in depth in this fine article, zswap sits as gatekeeper in front of your disk swap, compresses pages in RAM, and automatically tiers "cold" data (data which is unlikely to be needed soon) to disk. It integrates directly with the kernel's memory management and distributes pressure gracefully.
  
  zRam on the other hand, is a compressed RAM block device with a hard capacity limit. When you put swap on it and it fills up, there is no automatic eviction, and the kernel has very little leverage to do anything about the situation.
  
  When the zRam "device" is full, the system either starts to kill processes because of acute memory shortage or falls back to lower-priority swap, causing so-called LRU inversion: your fastest storage tier is clogged with the coldest data, with no way to evict it. That actively forces your working set of "warm" data (data that'll probably be used again soon) onto the slowest storage.

  In such a case, zRam isn't just failing to help. It is, instead, actively making things worse than having no compressed swap at all.
  
  And even worse, the longer the system has been running, the more broken things get: warm pages drift to disk, cold pages fossilize in zRam, and the gap between what zRam is holding and what you actually need keeps widening. Not exactly helpful....
  
  zRam only really makes sense for extremely memory-constrained embedded systems, diskless setups, or cases with specific security requirements around keeping private data off persistent storage. And there's even more bad news: swap on zRam is also increasingly becoming unsupported upstream.
  
  You can find more background information about why zswap is usually better than zRam here. Web page gone? Download an offline copy of that article here.
  
  Note: Don't install zRam when you use zswap, because it's downright counterproductive in combination with zswap!
  
  Both zswap and zRam provide a compressed cache and would, when used simultaneously, wind up using more system memory than each individually. Simultaneous use makes therefore no sense and would even be detrimental.

Új hozzászólás Aktív témák