🚀 go-pugleaf

Wcale nie przypadkiem, dnia Tue, 14 Jul 2015 11:40:46 +0200 
 doszła do mnie wiadomość <55a4d91e$0$2190$65785112@news.neostrada.pl>
 od Czarek Grądys <czarekgr@wa.onet.pl>  :
>Witam.
>Może głupie pytanie, ale może ktoś się orientuje, jak wpływa na limit 
>zapisu partycjonowanie dysku SSD?
>Powiedzmy założę małą partycję i będę na niej sporo zapisywał. Czy 
>kontroler będzie starał się te zapisy rozmieścić po całym dysku, czy ta 
>partycja jest na sztywno i te same komórki będą męczone?
>Zastanawia mnie to, ze względu na swap.

https://en.wikipedia.org/wiki/Wear_leveling
Wear Leveling powoduje, że dysk wykorzysta wszystkie wolne komórki
pamięci FLASH bez względu na partycjonowanie. Jedynym problemem może
być brak wsparcia dla TRIM ze strony systemu, który wykorzystujesz.
W przypadku braku wsparcia dla TRIM ze strony systemu najlepiej jest
zostawić sporą część dysku niespartycjonowaną(nawet 50%) lub
"trimować" go ręcznie za pomocą aplikacji producenta/linuxa live z
pena.

-- 
Gdyby się wysadziło ich planety, zburzyło miasta,
spaliło księgi, a ich samych wytłukło do nogi,
może udałoby się ocalić naukę miłości bliźniego. SL.

On 14.07.2015, Czarek Grądys <czarekgr@wa.onet.pl> wrote:
> Może głupie pytanie, ale może ktoś się orientuje, jak wpływa na limit 
> zapisu partycjonowanie dysku SSD?

Nie wpływa, chyba, że jako partycjonowanie rozumiesz też grzebanie w ilości
miejsca dostępnego na dysku (czyli np. z dysku oznaczonego jako 400GB chcesz
zrobić 480GB zabierając część z przestrzeni przyblokowanej przez producenta).

> Zastanawia mnie to, ze względu na swap.

Swap na SSD to nie jest dobry pomysł, chyba, że zmienisz swappiness na 0 żeby 
swap był używany tylko w ostateczności i wiesz, że nie będzie to za często. W 
przeciwnym wypadku proponuje rozbudowę RAMu. Wyjdzie taniej i szybciej.

-- 
Pozdrawiam
orcus

W dniu .07.2015 o 13:33 <orcus@pwr.wroc.pl> pisze:

>> Może głupie pytanie, ale może ktoś się orientuje, jak wpływa na limit
>> zapisu partycjonowanie dysku SSD?
>
> Nie wpływa, chyba, że jako partycjonowanie rozumiesz też grzebanie w  
> ilości
> miejsca dostępnego na dysku (czyli np. z dysku oznaczonego jako 400GB  
> chcesz
> zrobić 480GB zabierając część z przestrzeni przyblokowanej przez  
> producenta).
>
>> Zastanawia mnie to, ze względu na swap.
>
> Swap na SSD to nie jest dobry pomysł, chyba, że zmienisz swappiness na 0  
> żeby
> swap był używany tylko w ostateczności i wiesz, że nie będzie to za  
> często. W
> przeciwnym wypadku proponuje rozbudowę RAMu. Wyjdzie taniej i szybciej.
>
A to ciekawe co piszesz z rozbudową pamięci, bo pomimo, że mam 8GB RAM, to  
Windows 8.1 i tak zrzuca co się da do Swapa :) Jak mu Swapa wyłączyłem,  
albo ograniczyłem wielkość do jakiejś małej wartości (choć i ustawiałem na  
np. 8GB i efekt był podobny), to system po pewnym czasie rzucał warningami  
o braku pamięci... Żeby było zabawniej, pamięć była zajęta w okolicach  
50%. Reszta to jakieś śmieci, które miały być właśnie odłożone do Swapa. I  
nic nie daje okresowe "przeczyszczenie" pamięci.

To już wolałem grzecznie mu przywrócić automatyczny rozmiar, niż wkurzać  
się, gdy z powodu braku pamięci, ubijało mi w końcu jakiś program. A nie  
uruchamiam ich pińset, tylko jeden-trzy...

-- 
...

W dniu .07.2015 o 09:31 Dziki Facet <spam@fck.u> pisze:

>>> Może głupie pytanie, ale może ktoś się orientuje, jak wpływa na limit
>>> zapisu partycjonowanie dysku SSD?
>>
>> Nie wpływa, chyba, że jako partycjonowanie rozumiesz też grzebanie w  
>> ilości
>> miejsca dostępnego na dysku (czyli np. z dysku oznaczonego jako 400GB  
>> chcesz
>> zrobić 480GB zabierając część z przestrzeni przyblokowanej przez  
>> producenta).
>>
>>> Zastanawia mnie to, ze względu na swap.
>>
>> Swap na SSD to nie jest dobry pomysł, chyba, że zmienisz swappiness na  
>> 0 żeby
>> swap był używany tylko w ostateczności i wiesz, że nie będzie to za  
>> często. W
>> przeciwnym wypadku proponuje rozbudowę RAMu. Wyjdzie taniej i szybciej.
>>
> A to ciekawe co piszesz z rozbudową pamięci, bo pomimo, że mam 8GB RAM,  
> to Windows 8.1 i tak zrzuca co się da do Swapa :) Jak mu Swapa  
> wyłączyłem, albo ograniczyłem wielkość do jakiejś małej wartości (choć i  
> ustawiałem na np. 8GB i efekt był podobny), to system po pewnym czasie  
> rzucał warningami o braku pamięci... Żeby było zabawniej, pamięć była  
> zajęta w okolicach 50%. Reszta to jakieś śmieci, które miały być właśnie  
> odłożone do Swapa. I nic nie daje okresowe "przeczyszczenie" pamięci.
>
> To już wolałem grzecznie mu przywrócić automatyczny rozmiar, niż wkurzać  
> się, gdy z powodu braku pamięci, ubijało mi w końcu jakiś program. A nie  
> uruchamiam ich pińset, tylko jeden-trzy...
>
Kajam się - pomyliłem grupy - myślałem że to p.c.pecet ;)


-- 
...

On 16.07.2015, Dziki Facet <spam@fck.u> wrote:
> W dniu .07.2015 o 09:31 Dziki Facet <spam@fck.u> pisze:
>
>>>> Może głupie pytanie, ale może ktoś się orientuje, jak wpływa na limit
>>>> zapisu partycjonowanie dysku SSD?
>>>
>>> Nie wpływa, chyba, że jako partycjonowanie rozumiesz też grzebanie w  
>>> ilości
>>> miejsca dostępnego na dysku (czyli np. z dysku oznaczonego jako 400GB  
>>> chcesz
>>> zrobić 480GB zabierając część z przestrzeni przyblokowanej przez  
>>> producenta).
>>>
>>>> Zastanawia mnie to, ze względu na swap.
>>>
>>> Swap na SSD to nie jest dobry pomysł, chyba, że zmienisz swappiness na  
>>> 0 żeby
>>> swap był używany tylko w ostateczności i wiesz, że nie będzie to za  
>>> często. W
>>> przeciwnym wypadku proponuje rozbudowę RAMu. Wyjdzie taniej i szybciej.
>>>
>> A to ciekawe co piszesz z rozbudową pamięci, bo pomimo, że mam 8GB RAM,  
>> to Windows 8.1 i tak zrzuca co się da do Swapa :) Jak mu Swapa  
>> wyłączyłem, albo ograniczyłem wielkość do jakiejś małej wartości (choć i  
>> ustawiałem na np. 8GB i efekt był podobny), to system po pewnym czasie  
>> rzucał warningami o braku pamięci... Żeby było zabawniej, pamięć była  
>> zajęta w okolicach 50%. Reszta to jakieś śmieci, które miały być właśnie  
>> odłożone do Swapa. I nic nie daje okresowe "przeczyszczenie" pamięci.
>>
>> To już wolałem grzecznie mu przywrócić automatyczny rozmiar, niż wkurzać  
>> się, gdy z powodu braku pamięci, ubijało mi w końcu jakiś program. A nie  
>> uruchamiam ich pińset, tylko jeden-trzy...
>>
> Kajam się - pomyliłem grupy - myślałem że to p.c.pecet ;)

Tutaj możesz jedynie usłyszeć:
- Ile RAMu potrzebuje Windows? Tyle ile mu dasz * 2

Chociaż jak zaczniesz odpalać Javę na Linuxie to będzie podobnie. Ile dasz, tyle weźmie.
Ostatnio mi oomkiller ubił Javę na maszynie z 512GB RAMu (i był to jedyny 
"niesystemowy" proces).

-- 
Pozdrawiam
orcus

Dnia 16.07.2015 orcus@pwr.wroc.pl <orcus@pwr.wroc.pl> napisał/a:
> Chociaż jak zaczniesz odpalać Javę na Linuxie to będzie podobnie. Ile
> dasz, tyle weźmie.

Nie prawda. Weźmie maksymalnie tyle ile ma ustawione w properties/policy (i
ewentualnych ustawieniach ulimit). Każdy rodzaj aplikacji (standalone, applet,
Java WebStart i to w zależności czy jest z opcją -server czy -client) ma
swoje defaultowe limity ale zawsze można je zmodyfikować (chociażby opcją
-Xmx=rozmiar bezpośrednio w poleceniu 'java' czy ustawiając to w zmiennej
środowiskowej _JAVA_OPTIONS dla "zwykłych" aplikacji), przed zbliżeniem się
do tych limitów java nie uruchamia garbage collectora, bo to "strata
czasu" (po co ma odzyskiwać pamięć skoro nie jest to potrzebne?). W linuxie
domyślnie funkcjonuje model leniwego przydzielania pamięci, kernel nie
szuka/rezerwuje pamięci w momencie gdy proces o nią prosi, ale dopiero
wtedy, gdy proces zaczyna sie do niej odwoływać, stąd jeśli nie ma
odpowiedniego "zapasu" ram, to sama alokacja pamięci może się zakończyć
sukcesem, ale już korzystanie z tej pamięci nie (bo kernel może nie być w
stanie wygospodarować pamięci, mimo że wcześniej odpowiedział na prośbe o
jej alokację odpowiedział "ok"). Połączenie niewiedzy o tych dwóch faktach
(sposób zarządzania pamięcią przez Javę i przez kernel) powoduje
powstawanie legend miejskich na temat tego jakich to niby "hektarów RAM"
potrzebuje Java aby normalnie działać :D

On 16.07.2015, Pit <nospam@sdf.lonestar.org> wrote:
> Dnia 16.07.2015 orcus@pwr.wroc.pl <orcus@pwr.wroc.pl> napisał/a:
>> Chociaż jak zaczniesz odpalać Javę na Linuxie to będzie podobnie. Ile
>> dasz, tyle weźmie.
>
> Nie prawda. Weźmie maksymalnie tyle ile ma ustawione w properties/policy (i
> ewentualnych ustawieniach ulimit). Każdy rodzaj aplikacji (standalone, applet,
> Java WebStart i to w zależności czy jest z opcją -server czy -client) ma
> swoje defaultowe limity ale zawsze można je zmodyfikować (chociażby opcją
> -Xmx=rozmiar bezpośrednio w poleceniu 'java' czy ustawiając to w zmiennej
> środowiskowej _JAVA_OPTIONS dla "zwykłych" aplikacji), przed zbliżeniem się
> do tych limitów java nie uruchamia garbage collectora, bo to "strata
> czasu" (po co ma odzyskiwać pamięć skoro nie jest to potrzebne?). 

Dzięki! Przekażę kolegom którzy tą Javą się zajmują. Nie miałem o tym pojęcia.

> W linuxie
> domyślnie funkcjonuje model leniwego przydzielania pamięci, kernel nie
> szuka/rezerwuje pamięci w momencie gdy proces o nią prosi, ale dopiero
> wtedy, gdy proces zaczyna sie do niej odwoływać, stąd jeśli nie ma
> odpowiedniego "zapasu" ram, to sama alokacja pamięci może się zakończyć
> sukcesem, ale już korzystanie z tej pamięci nie (bo kernel może nie być w
> stanie wygospodarować pamięci, mimo że wcześniej odpowiedział na prośbe o
> jej alokację odpowiedział "ok"). 

Tutaj niestety zdajemy się na heurystykę kernela a że nie ma swapa na tych maszynach 
(tak, wiem - "linux nie został zaprojektowany by działać bez swapa") to 
overcommiting działa całkiem nieźle i zwykle przewiduje jak zachowa się
aplikacja. 

> Połączenie niewiedzy o tych dwóch faktach
> (sposób zarządzania pamięcią przez Javę i przez kernel) powoduje
> powstawanie legend miejskich na temat tego jakich to niby "hektarów RAM"
> potrzebuje Java aby normalnie działać :D

"Mój" use-case to HPC więc zwyczajnie spodziewałem się, że ta sama aplikacja w
Javie będzie chciała 2-3 razy więcej pamięci niż ten sam algorytm zapisany w C
lub nawet pythonie. To też raczej wiedza zdobyta empirycznie bez znajomości
samej Javy. Masz może gdzieś materiały nt. jak przydusić Javę żeby potrzebowała
mniej więcej tyle samo pamięci co zbliżone algorytmy zapisane w innych językach?

-- 
Pozdrawiam
orcus

Dnia 17.07.2015 orcus@pwr.wroc.pl <orcus@pwr.wroc.pl> napisał/a:
> "Mój" use-case to HPC więc zwyczajnie spodziewałem się, że ta sama aplikacja w
> Javie będzie chciała 2-3 razy więcej pamięci niż ten sam algorytm zapisany w C
> lub nawet pythonie. To też raczej wiedza zdobyta empirycznie bez znajomości
> samej Javy. Masz może gdzieś materiały nt. jak przydusić Javę żeby potrzebowała
> mniej więcej tyle samo pamięci co zbliżone algorytmy zapisane w innych językach?

Aż tak przydusić Javę, żeby pamięciowo była porównywalna z C, to się nie da
(to jednak wirtualizacja a nie aplikacja natywna i to w dodatku
wirtualizacja na emulowanej maszynie a nie fizycznej, sam "emulator" swoje
waży), poza tym w Javie wszystko jest pakowane w obiekty (no prawie
wszystko :D) a to też daje dodatkowy narzut w porównaniu do struktur w C.
Generalnie Javy się nie "dusi na maksa", bo nie ma sensu aby RAM leżał
odłogiem, tylko ustawia takie limity aby Java mogła korzystać z jak
największej ilości RAM, ale nie "przeginała".
Trzeba by było odpalić jvisualvm (część JDK, nie ma tego w JRE)
i "podłączyć" się do aplikacji (można z innego komputera, Java VisualWM nie
musi chodzić na tym samym komputerze co badana aplikacja) i sprawdzić ile
rzeczywiście tego RAM-u aplikacja potrzebuje do pracy (bo alokować w
systemie może znacznie więcej tylko po to, aby nie było potrzeby częstego
uruchamiania garbage collectora, dodatkowo Java trzyma też w pamięci
"przekompilowany w locie do postaci natywnej" najczęściej używany kod) i
dopiero wtedy można myśleć o ustawianiu limitów (ale też bez "duszenia", bo
to nie ma sensu).
A do Pythona nie ma co porównywać, to zupełnie różne klasy wydajności.