Sprzęt i cały system operacyjny w 128 GB RAM

A więc to co chcieliście: opis od włączenia przycisku power na kompie.

  1. Wciskam Power.

  2. Czekam długo, aż system Linux lub Windows – chciałbym na obu tak pracować – załaduje się cały do pamięci RAM, która wyniesie 128 GB lub 64 GB (gdy nie da rady z różnych powodów mieć 128 GB).

  3. Działam w systemie wykonując przeglądanie internetu, YouTube, ściąganie plików, nie wiem czy granie będzie możliwe ale fajnie by było.

  4. Najważniejsze jednak to odpalanie VirtualBoxa i praca z maszynami wirtualnymi.

  5. Pliki tych maszyn są tak powiedzmy od 18 GB do kilkudziesięciu.

  6. Są tam distro Linuxa które podaje ciągłym modyfikacjom prowadzącym do tego że co chwilę klikam zapisz stan maszyny, potem otwieram, zmieniam jeden detal, sprawdzam jak działa, zapisuje, odczytuje, znowu coś zmieniam, zapisuje migawki itd.

  7. Opisane w punkcie 6. zadania tak katują dyski, że limit TBW można szybko osiągnąć ale pomijam to bo liczy się dla mnie czas.

  8. Po skończonym dniu testowania zapisuje tylko pliki obrazu i stanu wirutalek na dysk. Komp zostaje włączony i tak chodzi non stop, prawie 24/7.

  9. Jeśli zechcę wyłączyć kompa to zapisuję całość aktualnego stanu systemu operacyjnego na dysk (coś w stylu synchronizacji).

  10. Nie wiem jak to się robi dla Linuksa krok po kroku i dla Windowsa ale podobno można.

  11. Mam nadzieję, że ten opis jest ok bo brakuje mi pomysłów jak uprościć przekazanie tego.

  12. Przypominam o tym, że UPS będzie więc nie robimy offtopa na temat tego że ram to pamięć ulotna i przypominam, że RAM jest nadal ZNACZNIE ZNACZNIE szybszy niż te nowe dyski na PCI-Expres 4.0. - chodzi o MB/s.

@bachus
Bo taki mały offtop był potrzebny z powodu tej informacji o błędach pamięci RAM.

Naucz się czytać ze zrozumieniem. Nigdzie czegoś takiego nie napisałem to Ty nie rozumiesz odpowiedzi ludzi.

Mam rozumieć że potrzebujesz super wydajności I/O ale jeszcze nie wiesz pod jakie zastosowania będzie CI to potrzebne?

Czyli na 99% nie zrobisz na tym konfiguracji z większą ilością RAM niż 32GB lub w najlepszym przypadku 64GB.

Ja to mam wrażenie, że Ty coś przeczytasz bez zrozumienia i wyciągasz z tego takie wnioski jakie akurat Ci są potrzebne …

I tu powstaje dziura, o której pisał Fizyda:

UPS NIC ci nie da, jeśli dojdzie do przekłamania danych, i uszkodzeniu ulegnie sama struktura logiczna dysku wirtualnego w RAM (o tym też już była mowa). I znowu mylisz błędy w plikach, z błędami I/O.
Moim zdaniem - usiłujesz przeforsować coś w stylu wyrzutni rakiet do niszczenia pojedynczego komara…

1 polubienie

Ja mam wrażenie, że on usilnie szuka kogoś kto poprze jego pomysł, klepnie po pleckach i powie że dobrze myśli. Ewentualnie przekona go argumentami pokroju: “nie rób tego bo to rozpocznie inwazję obcych na ziemię, los ludzkości teraz w Twoich rękach” do tego że to kiepskie rozwiązanie.

@bachus @Fizyda

Jak czegoś nie rozumiem
Jak chcę coś przeprowadzić a nie wiem jak

to przychodzę i pytam co właśnie zrobiłem.

Po co wycieczki osobiste, nie potrzebuje aprobaty tylko odpowiedzi na pytania.

No i tu kolejne : SAM muszę napisać? Nikt tego nie zrobił już w necie? Żadnego tutoriala? W Windowsie też musze zrobić?

Tylko z tematu nie wynika co chcesz “przeprowadzić”, wręcz dla mnie wygląda to jakbyś wpadł na super rozwiązanie i teraz szukał na siłę do czego je wykorzystać.

Może jestem dziwny, ale jak się kogoś o coś pytam lub proszę o radę to zawsze przedstawiam najdokładniej jak tylko umiem swój problem i jasno definiuję pytanie lub zakres pomocy jakiego oczekuję. Tutaj tego nie widziałem ani razu.

Nie ma bo nawet nie wiadomo jakiego rozwiązania do którego problemu potrzebujesz tego tutoriala.

@Fizyda Tutorial pt “Jak utoworzyć system operacyjny w RAM”

Zadaję chyba proste pytania?

@Fizyda Odpowiedz na to: Na chwile załóżmy ze system jest na dysku ale w linuksie jest tmpfs owy ramdisk o pojemności 16GB i na niego ściągam np. obraz .iso dystrybucji linuksa, a potem odpalam program który mi na pendravie utworzy z zapisanego tam obrazu bootowalny pendrive. Czy to zadziała, w sensie czy ściągniety obraz będzie pod jakimś względem gorszy od tego który bym zapisał zamiast w ramdisk na SSD i z niego potem na pendrive tworzył bootowalny nośnik?

Na tak zadane “proste pytanie”, niestety nie ma prostej odpowiedzi.

Spróbuję to wytłumaczyć na przykładzie “samochodowym”.
Wsiadasz do ciężarówki (host) z 16 metrową naczepą (RAM DISK). Uruchamiasz silnik w ciężarówce i ruszasz. W trakcie jazdy przesiadasz się do stojącego na naczepie samochodu osobowego, i ruszasz jak się da najszybciej do przodu (na dystansie 16 metrów). Przez chwilę - jedziesz szybciej niż ciężarówka, ale jeśli popełnisz najdrobniejszy błąd lub nie wyhamujesz - to i host, i ram disk, i osobówka i ty wypadniecie z drogi…

2 polubienia

Nie bo nie wiadomo co rozumiesz przez pojęcie “system operacyjny w RAM”

Jeśli nie dojdzie do błędów I/O to nie będzie, jeśli dojdzie to dostaniesz komunikat, że plik jest uszkodzony. Nie widzę tylko profitu z takiego czegoś.

Należy kupić kartę PCI(E) z odpowiednim kontrolerem i zasilaniem awaryjnym.
Kiedyś takie gadżety się zdarzały, nie wiem jednak czy dalej produkują takie wynalazki po pojawieniu się relatywnie tanich nośników flash nvme.

Znacznie tańsze jednak będzie utworzenie macierzy RAID z SSD niż takie eksperymenty.

Ja bym podszedł do tematu jeszcze inaczej. Wykorzystałbym system operacyjny który ma przyjazne kontenery i nie pakowałbym całego systemu operacyjnego w RAMie tylko główny OS zainstalował normalnie na dysku z normalnym botowaniem z dysku (a nie przez sieć) i tylko jeden konkretny kontener wrzucił w całości do RAMu.

Na przykładzie FreeBSD może to wyglądać następująco, zakładam że host-matka jest już zainstalowany normalnie na dysku, skonfigurowany i teraz tworzymy nowy kontener (jail) który będzie w całości w RAMie.

Tworzymy system plików w ramie, powiedzmy 6 gigabajtów, system plików niech dostępny będzie pod katalogiem /prosiak:

# mount -o size 6G -t tmpfs tmpfs /prosiak

Sprawdzamy czy tmpfs się utworzył:

# mount | grep prosiak
tmpfs on /prosiak (tmpfs, local)

Instalujemy tam pliki dla nowego kontenera:

# cd /usr/src
# make installworld DESTDIR=/prosiak
# make distribution DESTDIR=/prosiak

Tutaj po cichutku założyłem że mam wykonany makeworld w katalogu /usr/src, jeśli nie to zamiast make (installworld i distribution) można ściągnąć gotowe skompilowane pliki z http://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/. Wykonujemy to oczywiście raz na początku tworzenia kontenera, poźniej ten kontener sobie zapisujemy na dysku wykonując pełną kopię tarem (nie cp gdyż bsdowy cp nie skopiuje prawidłowo twardych linków).

Do łączenia z kontenerem będzie nam potrzebny interfejs, dodajemy 192.168.1.44 lub jakikolwiek inny:

# ifconfig em0 alias 192.168.1.44 netmask 255.255.255.255

Aby interfejs był widoczny także po restarcie to dodamy sobie odpowiedni wpis do /etc/rc.conf

# grep 192.168.1.44 /etc/rc.conf
ifconfig_em0_alias14="inet 192.168.1.44 netmask 255.255.255.255"

Aby z kontenera mieć możliwość wyjścia na świat (internet) dodajemy nata i regułki przepuszczające ruch, u mnie wykorzystuje pf (packet filter):

# grep 192.168.1.44 /etc/pf.conf
nat pass on $ext_if      from 192.168.1.44 to any -> 192.168.0.12
pass  in quick from 192.168.1.44 to any keep state
block in quick from any to 192.168.1.44

Potrzebna jeszcze będzie definicja kontenera w pliku /etc/jail.conf lub powiedzmy w /etc/myjails.conf (aby system matka nie startował takiego kontenera automatycznie po resecie). Niech to będzie taki najprostszy kontener bez dostępu do dźwięku, video i innych podejrzanych urządzeń:

# grep -A13 '^prosiak' /etc/myjails.conf
prosiak {
    exec.start = "/bin/sh /etc/rc";
    exec.stop = "/bin/sh /etc/rc.shutdown";
    exec.clean;
    mount.devfs;
    mount.fdescfs;
    mount.procfs;
    #host.hostname = "";
    path = "/prosiak";
    ip4.addr = "192.168.1.44";
    allow.mount = "true";
    allow.raw_sockets="true";
    allow.sysvipc="true";
}

W samym kontenerze włączymy demona ssh:

# cat /prosiak/etc/rc.conf
sshd_enable="YES"

Pozwolimy chwilowo rootowi logować się do tego kontenera przez ssh:

# grep PermitRootLogin /prosiak/etc/ssh/sshd_config
PermitRootLogin yes

Ustawimy hasło dla roota w kontenerze:

/usr/src# cd /prosiak
/prosiak# chroot .
root@s101:/ # passwd 
Changing local password for root
New Password:
Retype New Password:
(ctrl+D) aby wyjść z chroota

Zauważ że wcześniej użyłem chroot a więc hasło nie zmieniłem dla hosta-matki tylko dla kontenera. Teraz uruchamiam kontener:

# jail -f /etc/myjails.conf -c prosiak

Sprawdzam czy się uruchomił prawidłowo:

# jls | grep prosiak
     6  192.168.1.44                                  /prosiak

Loguje się do kontenera i ciesze systemem uruchomionym w RAMie:

$ ssh -p 22 root@192.168.1.44

Teraz w kontenerze ustawiam resolver aby rozwiązywać nazwy domen na adresy IP:

root@:~ # cat /etc/resolv.conf 
nameserver 192.168.1.12

Sprawdzam czy sieć działa:

root@:~ # ping dobreprogramy.pl
PING dobreprogramy.pl (194.0.171.163): 56 data bytes
64 bytes from 194.0.171.163: icmp_seq=0 ttl=113 time=80.173 ms
64 bytes from 194.0.171.163: icmp_seq=1 ttl=113 time=37.124 ms
^C

I wykonuje prosty test zapisu na nasz ‘dysk twardy’ który jest ramem:

root@:~ # dd if=/dev/zero of=test bs=4k count=1000000
1000000+0 records in
1000000+0 records out
4096000000 bytes transferred in 4.470327 secs (916264013 bytes/sec)

Czyli otrzymujemy 873MiB na sekundę.

Z ciekawości zrobiłem test zapisu na hoście na dysk SSD:

/root# dd if=/dev/zero of=test bs=4k count=1000000
1000000+0 records in
1000000+0 records out
4096000000 bytes transferred in 15.251581 secs (268562328 bytes/sec)

czyli 256MiB na sekundę

oraz na dysk talerzowy HDD:

/home/tomek$ dd if=/dev/zero of=test bs=4k count=1000000
1000000+0 records in
1000000+0 records out
4096000000 bytes transferred in 54.554454 secs (75080946 bytes/sec)

czyli 71.6MiB na sekundę.

Podsumowując na moim komputerze sam zapis do ramu jest szybszy ponad trzy krotnie
niż zapis na ssd. Ale komputer który mam w tej chwili pod ręką to Dual-Core E5700
z jakimś starszym dyskiem GOODRAM SSD i ramem DDR3. Ciekawe jakie wyniki byłyby
na jakimś potworze z nowym Ryzenem.

Po zakończeniu pracy z kontenerem będziesz chciał aby jego zawartość nie zniknęła czyli najpierw wyłączysz kontener:

/# jail -f /etc/myjails.conf -r prosiak
Stopping cron.
Waiting for PIDS: 42123.
Stopping sshd.
Waiting for PIDS: 42113.
.
Terminated
prosiak: removed

i zapiszesz jego stan powiedzmy do /swinka.tar.gz

# tar -czf /prosiak.tar.gz /prosiak

Jeśli będziesz chciał ponownie uruchomić kontener to montujesz tmpfs, zamiast make (installworld i distribution) które pokazałem na początku rozpakowujesz zawartość /prosiak.tar.gz, startujesz kontener przy pomocy ‘jail -c’ i logujesz sie ssh.

1 polubienie

Zrób może z tego wpis na blogu, bo fajnie piszesz. Już pisałem koledze o kontenerze, ale nie za bardzo wiadomo co chce robić…

1 polubienie

Nie chce mi się czytać całego tego tasiemca, ale pobierz sobie distro Linuksa puppylinux i przetestuj w codziennej pracy czy system ładowany do ram ci się podoba/sprawdza.

1 polubienie

Przeczytałem cały wątek i jak zauważyli przedmówcy cieżko stwierdzić o co może chodzić. Wywnioskowałem 3 scenariusze z Twojego opisu:

  1. Załadowanie “całego OS do RAM-disk”
    Pierwszym problemem jest załadowanie obrazu systemu operacyjnego do pamięci RAM. Pierwszym problemem jaki spotkasz na swojej drodze to załadowanie obrazu do pamięci. Potrzebujesz bootloadera, który zinicjuje taką pamięć RAM, wczyta do niego system operacyjny (załóźmy, że masz dysk NVMe) to obraz zainstalowanego Windowsa wczyta się w niego w miarę szybko - coś w okolicach 8 - 10 sekund. Potem system operacyjny musi jeszcze potrafić nie nadpisać pamięci w której sam rezyduje. Z Linuksem niema problemu - od dawna to potrafią np. dystrybucje LiveCD. Oczywiście w pamięci znika Ci na sam system operacyjny ok. 40GB RAM (czyli ze 128 zostaje Ci 88GB), zakładam, że chciałbyś mieć tam jakieś konto użytkownika i zainstalowanego przykładowo Chrome, które na momencie zje Ci z 10GB dysku, zostaje Ci 78GB. Wykorzystałeś 50GB RAM-u, z czego 80-90% jest tam kompletnie niepotrzebna. Nowoczesne systemy operacyjne na etapie uruchamiania i tak same ładują te biblioteki, których najczęściej używasz - tzw. prefetch.
  2. RAMdisk jako źródło obrazów maszyn wirtualnych - przed uruchomieniem maszyn wirtualnych tworzysz RAMdisk, kopiujesz na niego obrazy maszyn i z tego miejsca je uruchamiasz. Po zakończeniu pracy kompaktujesz obrazy maszyn i kopiujesz je do lokalizacji trwałej. Powiedzmy, że masz VM z czystym Ubuntu x2 i jednym Windowsem 10, znowu zmarnowałeś 50GB RAM na kompletnie nieprzydatne dane. Twój system potrzebuje z 8GB RAM do robienia swoich rzeczy, 50GB poszło na obrazy maszyn, zakładam, że wirtualki mają zdefiniowane po 8GB na Ubuntu i 16GB na Windowsa, zostaje Ci zabójcze 38GB RAM, a pamiętaj, że wirtualizator też ma swoje narzuty.
  3. Przechowywanie danych w RAM jako pamięci pojedyńczej aplikacji - to ma chyba najwięcej sensu. Definiujesz RAMdisk i kopiujesz do niego dane na jakich będziesz operował - przykładowo filmy czy grafiki na których będziesz pracował. Zwłaszcza jeśli będziesz n-krotnie otwierać te pliki i zapisywać.

Problemy są takie same we wszystkich trzech scenariuszach:

  1. ładowanie danych do RAMdisku
    Problematyka jest taka, że procedura startu będzie skomplikowana. W przypadku całego systemu operacyjnego problematyką jest załadowanie systemu operacyjnego (co niewątpliwie wydłuzy czas startu), w pozostałych dwóch scenariuszach jest prościej, ale nie nazwałbym tego przyjaznym dla użytkownika.
  2. praca oprogramowania na RAMdisku
    nie każda aplikacja / system operacyjny poradzi sobie z pracą na takim rozwiązaniu. Dużo częściej zdarza się korekcja danych wynikająca z błędów I/O w przypadku pamięci RAM niż w przypadku pamięci trwałej. Potencjalnie możesz mieć przekłamania na pojedyńczych bitach, a nawet całych słowach. Przez co informacja może być błędna lub całkowicie uszkodzona - zależnie od typu przechowywanych danych. W JPG-ku może zmienić jeden piksel, a w innych formatach może uszkodzić cały plik - np. exe może zostać uznany za szkodliwy jeśli przestanie się zgadzać suma kontrolna z certyfikacją. Rozwiązaniem może być pamięć z ECC, ale jest ona odpowiednio droższa. Nie eliminuje ona tego problemu całkowicie jednak znacząco zmniejsza ryzyko powstawania błędów w obszarze pamięci.
  3. zapis danych po skończonej pracy
    Najbardziej newralgiczny moment - może się zdażyć, że do niego nawet nie dotrzesz, przerwa w zasilaniu to Twój najmiejszy problem - da się mu zapobiegać przez rozwiązania UPS z SDR. Problemem jest to, że planujesz to ograć na pamięciach non-ECC i na desktopowych procesorach. Duża ilość operacji I/O zwiększa prawdopodobieństwo zakleszczenia się systemu gospodarza, co skończy się resetem, co w rezultacie doprowadzi do utraty danych.

Piszę to z perspektywy człowieka, który w stacjonarce ma skromne 256GB RAM ECC, procesory serwerowe i nawet tu zdarzają się zwisy systemu. Dlatego dane wrażliwsze niż system operacyjny trzymam na macierzy RAID6 z dedykowanym kontrolerem, własną pamięcią RAM i akumulatorkiem pozwalającym mu zakończyć kolejkę dysku co zabezpiecza w pewnym stopniu przed uszkodzeniem danych.

2 polubienia

Wycieczek osobistych raczej nie ma. Wszyscy w tym wątku są chętni aby Ci pomóc (zobacz na długość dyskusji), ale systematycznie dawkujesz i utrudniasz.

@Fizyda
Czyli analogicznie nie warto w ramdisku robić czegokolwiek niż np. umieszczać pliki TEMP przeglądarek internetowych ? To ponoć przyśpiesza pracę w starszych laptopach.
Nie zrozum mnie źlę - nadal pytam. To nie jest zły ton z mojej strony.

Ciężko dostępne i drogie zwykle to było. Warto zaktualizować stan rynku i się rozejrzeć. Dobra podpowiedź.

@tomms
Rewelka, duuuży plus za tę pracę!! Dziekuję
Czy to samo zrobię w Linux Mint stosując dokładnie kopiuj-wklej?

@bachus popieram, fantastyczna praca kolegi. Nie wiem co to kontener i wiem co chcę zrobić no kurcze ludzie

@anon741072 tradycyjnie pozamiatałeś pozytywnie więc będę ściągał to

@GioWDS Dobrze określiłeś to: n-razy będę coś mielił, napisałem to ileś postów wyżej. Co oznacza w Twoim wpisie zmarnowane bo wbrew pozorom nie jest jednoznaczne. Czym się różni 2) od 3) przy założeniu że będę n-razy zapisywał i odczytywał obraz i migawki maszyn wirtualnych z systemami opracyjnymi jak w pkt. 2?

@bachus uwierz mi, że robię wszystko jak potrafię aby uzyskać sprawnie pomoc i nie utrudniam. Prosiłeś o opisanie problemu od włączenia POWER. Dziękuję Ci za Twój wkład jak i wszystkim Uczestnikom.

Proszę jeszcze nie zamykać wątku i nie oznaczać jako rozwiązany (gubię się jako nowy na tym forum).

Tu nikt nie zamyka wątków - jedynie na Twoją jako autora wyraźną prośbę do moderatora, ew. jak zaczniemy się wyzywać :wink:
O przycisku POWER pisał kto inny. Szkoda, że nie chcesz podać czy to jakiś projekt akademicki, czy rzeczywiście coś budujesz co ma działać. Nie podajesz na jak dużych danych chcesz operowac, jakiego typu itd.

@bachus Za pomyłkę z POWER przepraszam. Wcześniej nie patrzyłem na ten przycisk Rozwiązanie, dopiero kiedy wpłynął przepis jednego z Użytkowników to zauważyłem.
Podawałem rozmiary plików, około kilkadziesiąt GB, typ podałem: .vdi i .sav (to największe).