Dziś post sprzętowy. Do tej pory nie poruszałem tego typu tematyki na blogu, ale prywatnie hardware interesuje mnie nie mniej niż software:)
Jak wiadomo w większości codziennych juzkejsów dysk jest wąskim gardłem naszego narzędzia pracy. Standardowym sposobem na przyśpieszenie maszyny jest wymiana dysku na SSD. Na dzień dzisiejszy aby tak na prawdę przyśpieszyć codzienną ogólną pracę (mieszanka zapisów i odczytów) trzeba wydać relatywnie sporą sumę na na prawdę szybki dysk.
Można jednak pójść znacznie dalej z prędkością odczytu/zapisu pokusić się o stworzenie dysku w pamięci RAM.
Dysk tego typu jest widziany w systemie tak samo jak zwykłe dyski. Na starcie może on pobrać swój obraz z HDD/SSD do RAM i od tej pory pracujemy na pamięci, która jest bardzo blisko procesora. RamDisk może oczywiście periodycznie utrwalać się na dysku klasycznym (mając więcej niż 1 rdzeń w procesorze nie jest to problem).
Tutaj przegląd RamDisków dla Windows: http://www.raymond.cc/blog/archives/2009/12/08/12-ram-disk-software-benchmarked-for-fastest-read-and-write-speed/.
Od kilku dni testuję na Win7 x64: http://memory.dataram.com/products-and-services/software/ramdisk
który jest darmowy do 4GB.
Na taki dysk można skopiować całe środowisko dev: JDK (wystarczy skopiować), Eclipse, Maven+Repo, Servery...
Po prostu śmiga!
//========================================
Dokupując RAM zwróćcie uwagę oczywiście na taktowanie (tak aby było maksymalne na jakie pozwala szyna) ale również na latencją CAS http://pl.wikipedia.org/wiki/CAS_latency.
Przykładowo DDR3 1066MHz w wersji CL7 jest o 10% szybszy niż w wersji CL9. A różnica w cenie kości 4GB to dosłownie kilka zł:)
Rozwiązaniem lepszym niż RamDisk (który zapisuje obraz na HDD/SDD) byłby soft, który buforowałby w RAM wskazane katalogi i udostępniał je przez interfejs sterownika dysku. Tak aby po prostu w tle synchronizować się z klasycznym dyskiem wprost do wskazanych katalogów - bez obrazu dysku. Rodzaj stałego obszaru cache dysku. Znacie może tego typu rozwiązania softwareowe (bo istnieją mniej więcej tego typu sprzętowe kontrolery do dysków ssd)?
11 komentarzy:
Nawet jeżeli mamy dysk SSD warto katalogi takie jak target trzymać w ramdysku, żeby zbyt szybko nie zajechać SSD ciągłymi operacjami zapisu małych pliczków *.class.
Dla użytkowników systemu Linux podmontowanie ramdysku pod dany katalog nie jest żadnym problemem wystarczy:
# mount -t tmpfs tmpfs /home/user_name/workspace/project_name/target
Bardzo łatwo można stworzyć skrypt który wyszuka wszystkie katalogi target i w ten sposób je podmontuje. Minus takiego rozwiązania jest taki, że po każdym restarcie komputera wszystkie projekty muszą być kompletnie przebudowane, co czasem może zająć kilka minut ...
Tak, pamięć flash jest dobra - od odczytu:)
Z analogicznego powodu, o którym piszesz ludzie przenoszą tymczasowe katalogi przeglądarek na ramdiski. Tylko, że aby cache przeglądarki miał sens, ramisk musi zapisywać swój obraz na dysk klasyczny. W przypadku cache nie to zasób krytyczny więc można zapisywać przy zamknięciu systemu.
Podobno poza tym przeglądarka zauważą lnie przyśpiesza, ale tego jeszcze nie testowałem.
Mała uwaga "The FREE License promotion is available to U.S.A, Canada and Great Britain customer only." Więc w firmie nie wypada go instalować
Z tego co rozumiem, to ten zapis odnosi się do darmowej licencji na wersję full, którą dostajesz jeżeli zakupisz na stronie pamięć.
Natomiast wersja do 4GB bez zakupów wygląda na darmową (wyświetla tylko reklamę przy uruchomieniu).
Podejrzewam, że jeśli aplikacja jest dobrze napisana, to zabawa w ramdysk nic nie daje, bo raz odczytane pliki siedzą sobie w keszu w RAM-ie, a (przynajmniej w przypadku Windowsa) programista aplikacji może sobie potuningować sposób otwierania pliku: goto http://msdn.microsoft.com/en-us/library/aa363858%28v=vs.85%29.aspx#caching_behavior
Podejrzewam, że Java tak przyspiesza po przerzuceniu na ramdysk, bo te supermagiczne opcje tuningowania są chyba z poziomu Javy niedostępne. W przypadku nie-Javy, jeśli aplikacja była dobrze napisana to ramdysk pewnie takiego kopa by nie dał.
Przyszedł mi do głowy pomysł na toola, który by optymalizował wywołania WinAPI czy POSIX API. Np. taki Maven (który jest bardzo dyskożerny) w momencie gdy próbuje coś pisać do katalogu "target" powinien to robić w pamięci a nie na dysku - te pliki zawsze można przegenerować wpisując ponownie mvn clean package, więc ich ewentualna utrata nie byłaby żadnym problemem. No tyle, że Windows/Linuks pewnie nic o tym nie wie od Mavena, i każdy nawet najmniejszy zapis do katalogu "target" znacznie spowalnia system plików, bo system dodatkowo musi zadbać o spójność systemu plików, co w przypadku katalogu "target" jest zupełnie niepotrzebne.
A może coś takiego już istnieje - na pewno by było wygodniejsze w użyciu niż ramdyski.
Wygląda na to, że w rzeczywistości jest z tym trochę zabawy i "tracimy" część RAM (bo chyba trzeba ją na sztywno wydzielić?). W czym jest to lepsze od zwykłego cache'u systemu operacyjnego?
No w tym lepsze, bo szybsze :-)
Wierzę Sławkowi, zresztą w podobne eksperymenty bawili się chłopaki w mojej poprzedniej pracy bo dyski były tam strasznie wolne, i rzeczywiście podobno coś tam pomagało.
A dlaczego szybsze? Wg mnie szybsze bo Windows/Linuks świetnie keszuje odczyt, ale gorzej zapis, bo raz na jakiś czas zaległe zapisy trzeba dokonać i to w odpowiedniej kolejności by zachować spójność systemu plików. Tymczasem dla plików tymczasowych czy tych z katalogu "target" spójność nie jest ważna - nawet jak dysk się zepsuje czy zabraknie prądu i coś do targeta się nie tak zapisze to nie problem - wołasz jeszcze raz mvn clean install i wszystko się przebuduje.
Windows (i Linuks pewnie też) ma opcje optymalizacji takich sytuacji z zapisem (goto mój link wyżej - prawdopodobnie flaga FILE_ATTRIBUTE_TEMPORARY by tu najbardziej pasowała). Ale w Javie z tego co wiem czegoś takiego nie ma, i prawdopodobnie dlatego ten ramdysk tak przyspiesza. Po prostu wtedy katalog 'target' Mavena staje się niczym więcej jak współdzieloną pamięcią - zapis na dysk odbywa się rzadko o ile w ogóle.
Mój pomysł by polegał na napisaniu (albo znalezieniu) narzędzia, który by przechwytywało funkcję CreateFile (którą gdzieś tam wewnętrznie woła Java), rozpoznawało pliki z katalogów 'target' czy '${user.home}/.m2/repository' i automatycznie im nadawało ten atrybut FILE_ATTRIBUTE_TEMPORARY przy otwieraniu pliku. Rozwiązanie na pewno mniej kłopotliwe w użyciu niż ramdysk.
Napiszcie prosze koledzy jak stabilne jest takie rozwiazanie z RamDiskiem? Czy istnieja obawy, ze w pewnych okolicznosciach (jakich?) utracimy to co aktualnie sie znajduje w pamieci a razem z tym nasza prace? Bo po dzisiejszej rozmowie z adminem w mojej firmie dowiedzialem sie, ze mozemy wyprobowac takie rozwiazanie, ale nie chcialbym namowic kolegow a potem zbierac gromy gdy przytrafi im sie katastrofa :-)
@Konrad
heh no oczywiście, że "tracimy". Dla 2GB ramdisku rezerwowane jest 2 z haczykiem GB ramu, czyli na dzień dzisiejszy ok 45zł brutto w przypadku sodimm;P
Lepsze jest w sumie tylko tym, że działa szybciej;P Po prostu sprawdź. Poza tym jak już wspomniano w komentarzach powyżej, potencjalnie wydłuża życie dysków SSD.
@Piotr
Przez ostatnie 2 dni pracowałem na nim po 8h bez przerwy. Laptop był również hibernowany i "wskrzeszany".
Sytuacja utraty, które mogę sobie wyobrazić, to oczywiście odcięcie zasilania (ale w laptopie zabezpiecza to bateria) i zawieszenie (jeżeli komuś się to jeszcze zdarza). Konkretnie w sofcie Dataramu jest opcja autozapisu obrazu co zadaną ilość sekund.
Co do zabezpieczenia kodu, to można by np w okresie testowania i nieufności komitować co chwilę do lokalnego repo, ale chyba nie o to chodzi aby żyć w takim stresie;)
To chyba już lepiej pójść na kawę w czasie jak coś większego się buduje niż stresować się że coś niezakomitowanego zniknie z ramdysku.
Ale dobrym pomysłem byłby ramdysk na Hudsonie czy innym serwerze CI - tam nawet jak stracimy dane to żadna strata, bo wszystko jest już zakomitowane.
No i projektanci IDE czy Mavena nie do końca pomyśleli: wystarczyłoby źródła trzymać w jednym miejscu (na dysku twardym), a katalogi 'classes', 'target' i podobne gdzieś w katalogu 'tmp' (czyli właśnie w linuksowym tmpfs czy na windowsianym ramdysku).
No i zawsze pozostaje ten mój pomysł z modyfikowaczem systemu plików. Kod dla Windows znalazłem chyba prawie gotowy, tylko trzeba trochę chęci (a u mnie niestety ostatnio z tym marnie) + z kilkadziesiąt dupogodzin by to obczaić i skleić do kupy:
- http://blogs.msdn.com/b/erick/archive/2006/03/27/562257.aspx
- katalog src\filesys\miniFilter w WinDDK
Prześlij komentarz