RAM dysk jako pamięć podręczną przeglądarki.

[Taboret]

0

Witam.
Obiło mi się o oczy, że w przypadku dysków SSD, aby wydłużyć ich żywotność, dobrym rozwiązaniem jest przeniesienie pamięci podręcznej przeglądarki na RAM dysk.

Tylko jak to wygląda w praktyce.
Na lapku mam 16 GB RAM. Z przeglądarek używam Brave, Chromium i FireFoxa, Sporo oglądam na nich filmów z internetu, w tym telewizje internetowe, więc pamięć podręczna przeglądarki jest mocno w użyciu. 
Także czy to ma sens tworzenie pamięci podręcznej na dysku RAM i ile musiałbym tej pamięci wydzielić. Poza tym, co się stanie jeśli w trakcie korzystania z przeglądarki i oglądania filmów / telewizji RAM dysk się zapełni? Czy istnieje jakaś możliwość "dynamicznego" czyszczenia pamięci podręcznej przeglądarki aby uniknąć przepełnienia RAM dysku.

Pozdrawiam.

[mati75]

1

Gra raczej nie warta świeczki. Mi dysk ssd padł po 11 latach użytkowania. Równie dobrze może się to wydarzyć po pół roku czy dwóch latach.

Wracając do tematu. Robiłem coś takiego właśnie jak ram dysk dla przeglądarek aby przyspieszyć ich działanie na dysku hdd. Robiąc 6GB ram dysku przy 16GB ramu nie powinno być problemu, ale są inne problemy. Nie będzie historii przeglądarki, aby ją zachować trzeba zrobić dodatkowe skrypty backupujące i kopiujące dane na dysk.

Nie jest to ani dobre ani proste rozwiązanie.

[morfik]

1

Ja mam 16G i mam wrzucone katalogi /tmp/ , /var/tmp/ , /var/cache/apt/ i ~/.cache/ do pamięci RAM (generalnie to te rzeczy opisane tutaj). Czy to jakoś poprawi żywotność dysku ssd? No trochę poprawi jak bardzo?

Kod:

2023-12-22T15-55-06  241 Lifetime_Writes_GiB     -O--C-   100   100   000    -    9099
...
2023-12-23T02-24-38  241 Lifetime_Writes_GiB     -O--C-   100   100   000    -    9100
2023-12-24T14-38-22  241 Lifetime_Writes_GiB     -O--C-   100   100   000    -    9104
2023-12-25T15-18-41  241 Lifetime_Writes_GiB     -O--C-   100   100   000    -    9106
...
2024-01-01T10-11-46  241 Lifetime_Writes_GiB     -O--C-   100   100   000    -    9118
2024-01-02T19-17-13  241 Lifetime_Writes_GiB     -O--C-   100   100   000    -    9122
2024-01-03T10-09-23  241 Lifetime_Writes_GiB     -O--C-   100   100   000    -    9125
...

2024-12-31T17-25-06 241 Lifetime_Writes_GiB     -O--C-   100   100   000    -    10340
....
2025-01-01T17-25-06 241 Lifetime_Writes_GiB     -O--C-   100   100   000    -    10343
...
2025-04-01T17-25-05 241 Lifetime_Writes_GiB     -O--C-   100   100   000    -    10787

Dysk kupiony jako używany dlatego nie ma monitorowania od 0 GiB. Jak widać przez rok zapis jest na poziomie 1200GiB, czyli jakieś 3,5GiB dziennie. Ten dysk ma gwarantowane 180 TiB. Obecnie mam 10TiB zapisanych, więc jeszcze jakieś 150 lat mi ten dysk podziała. Czy warto robić taką optymalizację na 150 lat do przodu? To już niech każdy sobie sam odpowie, ja uważam, że warto -- kto wie z jakim gównem elektronicznym będziemy mieli do czynienia za 100 lat wiec lepiej być przygotowanym (stos dyskietek 3,5'' FDD razem z napędami też trzymam ). A tak poważnie to musisz zobaczyć ile danych ci dziennie zapisuje i ocenić ile jaki czas taki dysk chcesz użytkować. Ja tutaj mam dwa dyski, ten ssd robi mi za obsługę systemu, resztę danych mam na dużym hdd, a to z tego faktu, że pobieranie, np. obrazów z linux tylko po to by wypalić je na pendrive, to moim zdaniem trochę bez sensu by marnować kilka GiB zapisu na dysku ssd -- podobnie z edycją kontenerów mkv.

Zużycie RAM będzie różne w zależności co na tej maszynie będziesz robił. Przeglądarki mogą zostać skonfigurowane w taki sposób by cache ładować do RAM. Firefox ma browser.cache.disk.enable w about:config , domyślnie włączona, czyli cache zapisuje na dysk. Więc można sobie to przestawić bez dodatkowych zabiegów i problem załatwiony. Oglądanie filmów w necie tylko ułamek pamięci zajmuje (tyle ile zbuforuje do przodu i stare dane zwykle są wywalane, więc nigdy ci w RAM nie będzie trzymał całego filmu). Ja jak oglądam sobie coś w sieci to w mpv mam taki profil:

Kod:

[cache-big]
profile-desc="use 6 GiB cache"
cache=yes
demuxer-max-bytes=6GiB
demuxer-readahead-secs=30000

I wtedy faktycznie cały film jest zaciągany do RAM i do momentu zamknięcia mpv film zajmuje np. 4 GiB, czy ile tam miał. Ale przeglądarki tego nie robią.

Ile miejsca na taki cache? To zależy ile wolnego RAM masz. Musisz sobie popatrzyć i dobrać wartość. Przy czym np. 6 GiB na cache to jest próg -- system tego nie rezerwuje. Czyli możesz mieć w użyciu nawet i 15 GB z tych 16 GB i jednocześnie 6 GiB pod katalog z cache, ale jak zaczniesz zapisywać dane to wtedy SWAP się przyda, bo inaczej to komp ci się powiesi. SWAP to tylko na dysku hdd.

@mati75 -- historia przeglądarki jak najbardziej będzie, bo ona jest trzymana w katalogu z profilem (przynajmniej w firefox), a nie w cache.

[Taboret]

0

No to chyba wszystko wyjaśnione.

Dzięki.

[mati75]

0

Problem z firefox jest taki że trzyma cache w .mozilla, tam gdzie wszystko. Tak jest u mnie:

Kod:

du -hs .mozilla/
3,6G    .mozilla/
du -hs .cache/mozilla/
1,2G    .cache/mozilla/

Osobiście to tylko journal z systemd posłałem do ramu, bo to badziewie nawet konfiguracje wielkości i długości trzymania logów ignoruje. Najgorsze w przypadku systemów działających z kart pamięci.

[kszyhus]

0

Gra raczej nie warta świeczki. Mi dysk ssd padł po 11 latach użytkowania.

Mi jeszcze nie padł żaden a mam ich już sporo.
Pierwszy zakupiłem w 2014 roku (PLEXTOR 128GB), także myślę, że nie ma sensu kombinować.

[mati75]

0

Na to nie ma reguły. Tysiące dysków montowałem w serwerach przez ostatnie kilka lat i zdarzały się takie co padały po 2 dniach. W poniedziałek kolega miał problem z nowym dyskiem wyjętym z pudełka. W przypadku komputera osobistego robienie czegoś na siłę nie ma sensu. Może się to sprawdzić jedynie w przypadku dysków hdd, bo rzeczywiście szybkość przeglądarki mocno się poprawia.

Podstawą przy korzystaniu z dysków ssd/nvme to działajaca kopia, przede wszystkim nie na tym samym dysku.

[morfik]

0

Problem z firefox jest taki że trzyma cache w .mozilla, tam gdzie wszystko. Tak jest u mnie:

Kod:

du -hs .mozilla/
3,6G    .mozilla/
du -hs .cache/mozilla/
1,2G    .cache/mozilla/

No faktycznie jakiś "niewielki" cache trzyma w ~/.mozilla/ . Niewielki na potrzeby pojedynczych stron www ale jak ktoś odwiedza tysiące stron to może się trochę tego uzbierać. Niemniej jednak, jak sprawdziłem oglądanie YT, to odpowiadający mu katalog w podkatalogu /storage/ nie powiększał się, więc filmy buforuje w RAM standardowo, ewentualnie w ~/.cache/mozilla/ . Tak czy inaczej ten cały cache można wrzucić do RAM wyłączając browser.cache.disk.enable . I chyba jednak sobie to wyłączę.

Osobiście to tylko journal z systemd posłałem do ramu, bo to badziewie nawet konfiguracje wielkości i długości trzymania logów ignoruje. Najgorsze w przypadku systemów działających z kart pamięci.

To dziwne, u mnie honoruje:

Kod:

#  egrep -v "^#" /etc/systemd/journald.conf

[Journal]
Storage=persistent
SystemMaxUse=128M
SystemMaxFileSize=32M
RuntimeMaxUse=128M
RuntimeMaxFileSize=128M
ForwardToSyslog=yes
ForwardToWall=no
Audit=no


# du -hs /var/log/journal
128M    /var/log/journal

Gra raczej nie warta świeczki. Mi dysk ssd padł po 11 latach użytkowania.

Mi jeszcze nie padł żaden a mam ich już sporo.
Pierwszy zakupiłem w 2014 roku (PLEXTOR 128GB), także myślę, że nie ma sensu kombinować.

Mi dla odmiany po paru dniach użytkowania padł dysk z tego artykułu (Goodram SSDPR-CX400-02T-G2) Dosłownie zapisałem na nim 2 TB i zdechł. Szkoda, że nie napisali co się popsuło ale przynajmniej hajs mi oddali, a o zapisane dane, nawet nie prosiłem.

[mati75]

0

Konfigurację systemd mam niemal identyczną z tą różnicą że zamiast 128MB mam 64MB i jest tak:

Kod:

90M     /var/log/journal

po puszczeniu powiedzmy:

Kod:

journalctl --vacuum-size=10M

jest

Kod:

25M     /var/log/journal

to na stabilnym debianie, za to na sidzie:

Kod:

375M    /var/log/journal

config identyczny, w sumie wrzucę do crona polecenie czyszczące jak nie chce po dobroci

[morfik]

0

Spróbuj:

Kod:

# journalctl --rotate && journalctl  --vacuum-size=10M

Z tym czyszczeniem to chyba jest nieco bardziej skomplikowane, muszę poczytać jak dokładnie to działa. Generalnie to ta rozbieżność bierze się chyba z tego powodu, że czyszczenie działa tylko na archiwalnych plikach dziennika (tych utworzonych przez --rotate). Jeśli masz aktywny plik dziennika to go nie rusza.

Pokaż też:

Kod:

#  journalctl --disk-usage