Szybki rzut oka na polską chmurę czyli test e24cloud beta.

Jakiś czas temu serwis e24cloud, czyli polski hosting pod modnym szyldem chmury w wydaniu Beyond.pl, wszedł w fazę beta i publicznych testów, czyli praktycznie każdy chętny może – za darmo – pobawić się modną chmurą. Aktualnie firma rozdaje zaproszenia do testów o równowartości 200 zł, aby dostać kod należy postępować ze wskazówkami ze strony stwórz chmurę, czyli skorzystać z aplikacji na Facebooku.

Dłuższy wpis w trakcie tworzenia, a tymczasem szybki rzut oka na wady i zalety oferowanego testu (nie chciałbym, żeby było to traktowane jako test finalnej usługi, bo może się zmienić, poza tym parę kryteriów wybitnie testowych).

Wady:

  • brak IPv6 w domyślnej instalacji, brak możliwości wykupienia/wyklikania w panelu
  • przy pierwszym wyborze tylko 5 OS, w tym stary Debian (Lenny)
  • przy pierwszym wyborze konieczność wybrania 2 rdzeni
  • domyślne hasło roota tylko 8 znaków [a-zA-Z0-9]
  • 0,18 zł przy nieaktywnej (wstrzymanej) maszynie (2 CPU), 0,34 zł przy działającej
  • nie można dorzucić dodatkowych zasobów (CPU/RAM) do istniejącej maszyny
  • liczba CPU i RAM sztywno powiązane (każdy CPU to 2 GB RAM)
  • spora ilość błędów w panelu i słaba stabilność (nawet jak na wersję beta)
  • długi czas reakcji na zgłoszenie ticketa

Zalety:

  • maszyna szybko się generuje
  • wystarczający wybór presetów – siedem, w tym nowy Debian (Squeeze)
  • dostępny spory zakres sprzętu – 1-48 CPU i 2-96 RAM, dodatkowy HDD do 5 TB
  • 25 dni to wystarczający czas na przetestowanie
  • dobra wydajność (CPU)

Zabawa trwa, wkrótce można się spodziewać dłuższego i pełniejszego opisu testowanej usługi. Jeśli ktoś lubi się bawić, to pewnie warto skorzystać z darmowego testu, chociaż szału póki co nie ma.

UPDATE: W końcu otrzymałem odpowiedź na ticketa dotyczącego wyłączania się maszyny – wynika z błędu w panelu. Dodaję stosowny punkt, bo prawie 48h na prostą informację, że problem wynika z panelu to sporo. I usuwam niską stabilność usługi, bo wynika z błędów w panelu, nie w samej usłudze. Wiem, niby nieważne, czemu przestaje działać, ale jakoś wypada to oddzielić.

UPDATE: Widzę, że nadal jest trochę wejść z wyszukiwarek w poszukiwaniu informacji. Powyższe dane są stare i dotyczą wersji beta. Aktualna usługa jest zmieniona pod niektórymi względami. Aktualizacji danych lub nowego wpisu, chwilowo nie będzie, bo w tej chwili byłbym nieobiektywny.

Grzejnik znowu działa.

Trochę note for myself (ale tej kategorii tu nie ma), bo pewnie znowu będę się zastanawiał za parę miesięcy czy lat, kiedy dokładnie włączyłem maszynkę, albo coś w tym stylu – geekowy grzejnik znowu działa. W tym roku wystartował 13 października późnym wieczorem.

W tej chwili działa na nim – tradycyjnie już – mprime, węzeł Tora (lekkie zmiany konfiguracji i dodany monitoring – widać, że ładnie przerzuca dane) i… radio internetowe oczywiście przez MPD. Apt-p2p poległ, jak pisałem wcześniej, widzę, że nowych wersji nie ma.

Oczywiście przeszło mi przez głowę uruchomienie minera bitcoin zamiast mprime, ale opłacalność „kopania” bitcoinów spadła, poza tym już dobre pół roku temu nie było sensu robić tego na CPU… Chociaż w pewnym momencie wyglądało, że opłaca się kupić sprzęt do tego – po paru miesiącach wychodziło się na zero (wliczając prąd). O ile nie walnąłem się w obliczeniach.

Praca na desktopie z małą ilością RAM po raz drugi.

Jakiś czas temu pisałem o pierwszym podejściu do małej ilości RAM na desktopie, więc pora na część drugą. Przejrzałem podrzucone linki nt. optymalizacji działania dekstopu. Dysk był już ustawiony optymalnie, niepotrzebne usługi powyłączane, więc tak naprawdę tylko zmniejszyłem ilość uruchamianych konsol w inittabie. Nie zauważyłem zmiany w ilości zużywanego RAM, ale i tak ich nie potrzebuję – dwie wystarczają z naddatkiem. Swappiness nadal jest ustawione na 0 i IMO działa OK.

Zauważyłem, że spowalnianie występuje głównie na jednym desktopie (tym w pracy, starszy, bardziej zapchany dysk), przy pracy z pakietami (aktualizacja listy, instalacja), co skłania mnie do wniosku, że głównym winowajcą jest fragmentacja filesystemu. W obu przypadkach jest to ReiserFS (zaszłość, kiedyś był najlepszym wyborem, teraz chętnie widziałbym ext4 w tym miejscu), ale w domu z pewnością fragmentacja jest mniejsza – pół dysku zawsze było wolne.

Tak czy inaczej, wydaje mi się, że wypracowałem sposób na drastyczne ograniczenie spowalniania komputera przy pracy z pakietami. Korzystam z niego mniej więcej raz na tydzień. Cudów nie ma, czyli najpierw zamykam programy, które zużywają najwięcej RAM: Iceweasel, czyli Firefox, Icedove, czyli Thunderbird i PSI. Trwa to chwilę, a zwalnia znaczne obszary RAM.

Następnie uruchamiam prosty skrypt, który robi sync na dyskach, opróżnia bufory dyskowe, a następnie wyłącza i ponownie włącza swap.

#!/bin/bash

echo Syncing hard discs
sync
sleep 5
sync

echo Flushing disc buffers
echo 3 > /proc/sys/vm/drop_caches

echo Turning swap off
swapoff -a

echo Turning swap on
swapon -a

Celem jest najpierw zwolnienie jak największego obszaru pamięci, a następnie wymuszenie przerzucenia danych ze swap do RAM. Szybsze od restartu, działa w tle, więc można pracować w tym czasie. Po wykonaniu skryptu można swobodnie uruchomić przeglądarkę, pocztę, komunikator i aktualizować system. Najgorsze co może się wydarzyć, to niewyłączenie swapa, jeśli nie będzie wystarczającej ilości dostępnej pamięci, ale nie jest to krytyczne i zdarza się rzadko (zwł. po wyłączeniu przeglądarki). Wydaje mi się, że po takim zabiegu system działa znacznie lepiej.