Forum Debian Users Gang

Firefox cache trzyma w ~/.cache/mozilla/ , zatem podlinkuj sobie ten katalog do /tmp/ i będziesz miał go w RAM. Możesz sobie nawet wydzielić kawałek pamięci operacyjnej i podmontować go w to wskazane miejsce.

Ostatnio edytowany przez morfik (2017-01-30 18:55:37)

Jak zrobiłeś wszystko prawidłowo z tego linka to masz cache Firefoxa w RAM-ie. Sprawdź w pasku adresu Firefoxa about:cache

Ostatnio edytowany przez jawojx (2017-01-30 22:15:51)

Przy dysku tak samo jak i przy ramie jest informacja że nic nie jest przechowywane na dysku tylko wszystko jest w pamięci. Zobacz że nawet wielkość przechowywanych plików jest taka sama.

only stored in memory = tylko przechowywane w pamięci

A i jeszcze. Jeżeli jeszcze chcesz trzymać cały profil Firefoxa w pamięci RAM, to do tego lepsze jest profile-sync-daemon niż cache do ramdysku.

Ostatnio edytowany przez jawojx (2017-01-30 23:58:26)

Cały temat był w twoim wcześniejszym wątku i wydaje mi się że wszystko już było. Ja mam takie opcje dodane do fstab discard,noatime,commit=600, czyli discard mam.

Nie bardzo wiem co jeszcze chcesz wiedzieć, czy trim działa ?
Co do działania trim, to pokaż:

ls -l /etc/systemd/system | grep fstrim

systemctl status fstrim.timer

z roota sprawdź czy trimuje.

fstrim --verbose --all

Jeszcze szybkość odczytu bym zobaczył.
Sprawdź z roota.

hdparm -t /dev/sdx  #<-- za x oczywiście twoja litera dysku SSD

Ostatnio edytowany przez jawojx (2017-01-31 11:44:28)

Jak widać trim działa. Co do

Dysk to GOODRAM iridium pro 240gb i w różnych tbenchmarkach wynik osiągał ok 500mb/s
ale w przypadku hdparam nie mam punktu odniesienia

to jak tam jest SATA 3 to słabo, ale może masz tam SATA 2 na płycie, to nie wiele da się zrobić. Pokaż z roota:

hdparm -I /dev/sdx | grep Transport  #<-- za x oczywiście twoja litera dysku SSD

Ostatnio edytowany przez jawojx (2017-01-31 17:52:12)

No masz na płycie tylko kontroler SATA II. Przełącznik T z pamięci dysku, przełącznik t z dysku, nas interesuje tylko t. Mogłoby być trochę więcej, ale to jest normalny odczyt na kontrolerze SATA II tak w przedziale 250-280, niby powinno być ze 300 tyle teoria, ale ja na SATA II nigdy tyle  nie widziałem.

Pokaż w jakim czasie uruchamia się system.

systemd-analyze

Ostatnio edytowany przez jawojx (2017-01-31 18:40:49)

Siedem czy dziewięć to mała różnica ważne że startuje tak jak powinien z SSD szybko i bez problemów które odbiły by się na czasie uruchomienia. Czyli wiesz robi noatime, a nie wiesz nic o commit.

Cytat z manuala:

commit=nrsec
    Sync all data and metadata every nrsec seconds. The default value is 5 seconds

Czyli czas po którym dane zostaną uaktualnione/zapisane/synchronizowane na dysk, domyślnie jest 5 s. Ja mam 600 = 10 minut, ale ja tak ustawiam jak mam UPS lub baterie w laptopie. Ryzyko takie że jak się coś sypnie, nie ma danych z ostatnich paru minut i tyle. Jak nie masz częstych braków w dostawie energii ryzyka nie ma dużego. Musisz wybrać sam z tym że domyślne 5s. przy SSD to przesada jak dla mnie.

Możesz zmienić jeszcze planistę/schedulera na taki który lepiej sobie radzi SSD. Ja mam ustawiony deadline. Zobacz co masz ustawione:

cat /sys/block/sdx/queue/scheduler #<-- za x oczywiście twoja litera dysku SSD

Więcej o tym tu:
https://wiki.debian.org/SSDOptimization#Low-Latency_IO-Scheduler

No nie wyśpię się, zagapiłem się.

A co masz źle rozumieć, dobrze wnioskowałeś. Uaktualniany jest czas zmiany, a nie czas odczytu. Można, nie trzeba zmieniać. Ja mam i nie było problemów.

Na działającym systemie możesz zmienić scheduler i sprawdzić co ci bardziej odpowiada. Masz trzy dostępne noop deadline cfq. Już wiesz że cfq masz jako domyślny.

Z roota:

echo  deadline > /sys/block/sdx/queue/scheduler  #<-- za x oczywiście twoja litera dysku SSD

O  schedulerze możesz poczytać tu:
https://ex-android.blogspot.com/2016/02/io-schedulers-poradnik.html

Wady które tam są opisane przy deadline, ja nie miałem tych zachowań.

Jak i na Wikipedii coś też jest:

https://pl.wikipedia.org/wiki/Dyspozytor

Doczytałem coś z początku wątku.

1) Odnośnie /tmp to po zmianie w pliku fstab zauważyłem że /tmp w ramie zajmuje w porywach do 100KB co wydaje mi się wartością śmiesznie małą i odnosze wrażenie że coś poknociłem

Co do 2GB dla ramdysku dla tmp, to może być mało jak np. będziesz kopiował DVD ( można oczywiście zmienić tmp dla programu ). To że przydzielasz tyle, pewnie już to zauważyłeś, nie zabiera tyle miejsca w pamięci. Dopiero jak coś tam skopiujesz zobaczysz że RAM-u zabrało. Ale może nic nie robisz na dużych plikach to i to jest aż nadto. Możesz zrobić tak:

dd if=/dev/zero of=/tmp/1G_test bs=1M count=1000

A sprawdzić zajętą pamięć potem usunąć i sprawdzić jeszcze raz.