Skip to content

Entries tagged "hosting".

Is Your Hosting Oversold?

Hosting is cheaper than virtual server or dedicated machine on a network. This fact is true because resources are shared between many customers and one can place hundreds of accounts on one physical server. Adding too much accounts leads to slowing server responses and to instability in general. It's called overselling. Do you know how to check if your hosting account is overselled?

The Fighters

I'm comparing three hosting providers here:

  • - popular host provider from USA
  • - good hosting, 24/7 administration from Poland
  • - Polish company, servers in Germany, cheap hosting with SSH option

I'm using separate Linux box located in Poland to reach analysed servers with few tools (awk, cron, bash).

The Time

First, the most important value you can measure is time to get a response from your server. Of course checking only for ping values is not sufficient here. You have to measure HTTP traffic (typical task for hosting account is to serve content by HTTP protocol). Let's think about what resources can slow down your response time:

  • CPU (too much load caused by other customers)
  • bandwidth (too much concurrent traffic to/from server)
  • SQL database overload (typically on separate server)

Let's observer three hostings in work by measuring their time to get simple dynamically generated page (5 minute interval):

A legend:

  • red:
  • green:
  • blue:

As you can see sometimes server uses very log time to get pages (up to 14 seconds). You can see how often such situation occurs and make histogram from time. Lets zoom fragment of this graph:

You can see differences here between server in the same country (low ping values) and from USA (higher minimal time = pings above 200 ms). The closest server (green) has higher average time value because of higher variance.

I added -1 value if HTTP client (here: wget) returned an error during fetching a page. You can see red host (DreamHost) was inaccessible by 25 minutes. Let's compare average time to get a page:

  • 0,522 s
  • 0,330 s
  • 0,747 s


The higher availability - less page visitors will see blank screen during viewing your page. You can measure that parameter by collecting response time (shown above) and compare failed (or very slow) responses to all responses. You can get percentage availability then. Lets assume more than 4 seconds as unacceptable slow value. Here are the results:

  • 99,4914 %
  • 98,5758 %
  • 99,0854 %

So: the best is the more expensive from the three taken into account.

CPU Load & database

Let's control how CPU load and DB efficiency impact on time to get response on DreamHost account. We measure inside server to get load values and use 1-minute interval to get data from system:


  • red: CPU loadavg (1-minute)
  • green: time to fetch locally file via HTTP CGI script that's not connecting DB
  • blue: time to fetch locally file via HTTP that use SQL connection

Let's zoom interesting fragment:

As you can see:

  • simple scripts can operate efficiently with high (30) load
  • average load of my server is pretty good (under 2)
  • peak load is not very big (30 - once per few days)
  • there's a factor that has impact on execution time, but it's not load average (see next picture). It's a SQL database load that's not directly measured

Why I will not use DreamHost for any serious task?

Let's see situation after one week:

And look into interesting fragment:

You see regular page loading (with SQL queries) over 10 seconds over 7 hours! No comments.


Using simple tools (wget, cron, bash) you can measure parameter of your new hosting account and decide if it has enough level of availability (it's not oversold). I had many critical problems with load average in the past with few hosting companies so it's better to monitor host for a while before any serious web application is placed on new hosting.

Wydajność SAN na przykładzie RPS w OVH

SAN (Storage Area Network) jest w dużym uproszczeniu sieciowym systemem plików. Pozwala scentralizować zasoby dyskowe z kilku fizycznych serwerów i udostępnić je poprzez sieć przy wykorzystaniu np. NFS lub iSCSI. Daje to znaczne oszczędności dzięki czemu można zaoferować tanie serwery dedykowane oparte o Inel Atom i sieciowy dysk.

Taką właśnie ofertę przygotowało ponad rok temu francuskie OVH. Entuzjastyczne opinie (serwer dedykowany za taką cenę!) dość szybko zostały ostudzone poprzez informacje o bardzo słabej wydajności dostępu do macierzy dyskowej po sieci. Użytkownicy informowali o spadku wydajności dysku do 400 kB/sek. (współczesne dyski dają zwykle kilkadziesiąt MB/sek.).

Ostatnio OVH po wielu walkach zapanowało jak się zdaje nad QOS dla dysku, ale wyższa gwarancja transferu jest okupiona odpowiednio większym kosztem.

Z tego przykładu można wysnuć następujące wnioski:

  • w przyrodzie nie ma czegoś takiego jak "unlimited"
  • współdzielone zasoby bez limitów zwykle kończą się jakimś mechanizmem limitowania ze względu na skończoną przepustowość

Trend do wprowadzania limitów obserwujemy też w hostingu (coraz więcej dostawców mierzy aktywnie zużycie zasobów we współdzielonym hostingu). Mechanizmy typu VPS (gwarantowane stałe zasoby) stają się także coraz bardziej popularnym wyborem dla twórców serwisów internetowych. shared hosting review

The story

After few months with without VPS panel (see: HyperVM exploit story) i decided to say bye-bye and move my monitoring node to another host. I selected small company for this purpose.

1First I thought about VPS but then saw few interesting options mentioned on shared hosting offer:

Ruby on Rails (FastCGI), PHP 5.2.9 (IONCube/Zend Optimizer), mySQL 5.0.67, Perl 5.8.8, Python 2.4.3, GD Graphics Library, ImageMagick 5+, CGI-BIN, SSI (server side includes), Trac, Subversion and more!

Looks like we have long running processes-friendly hosting! I asked them about rules and got the answer:

The CGI processes are executed by suexec and would run as the user (script owner). We currently do not have any process limitations on scripts but we do have scripts that monitor for high usage and in which case we work with the user to resolve. If you have any other questions please let us know.

Seems very interesting. I appreciate hosts that control resource usage (CPU/disk) because that lowers possibility of abusing all resources on a server by one customer. Good.


The offer is pretty good: $1.02/mo when paid for one year in advance. Compare it to Dreamhost: $8.95/mo* or Bluehost: $6.95/mo. The servers are in Chicago:

8.       0.0%    53   43.1  43.3  41.8  54.0   2.2
9.     0.0%    53  141.8 142.6 139.9 153.2   1.8
10.          0.0%    53  142.7 143.4 142.3 144.4   0.5
11.            0.0%    53  142.7 146.6 141.0 155.5   4.6
12.        3.8%    53  213.5 150.6 140.8 282.8  30.2
13.     0.0%    53  146.9 147.2 145.3 161.5   2.4
14.                            0.0%    53  161.6 167.9 160.5 295.5  20.2
15.                            3.8%    53  162.0 163.9 160.6 193.9   5.7
16.                        0.0%    53  163.6 165.5 160.8 176.0   3.4

Ping is about 160 ms from Warsaw. Not bad.

I paid using PayPal and have running account in minutes.

Environment Details

I checked for limits under ssh:

$ ulimit -a
core file size          (blocks, -c) 200000
data seg size           (kbytes, -d) 200000
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 200704
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) 200000
open files                      (-n) 100
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 20
virtual memory          (kbytes, -v) 200000
file locks                      (-x) unlimited

Parameters that shows some restrictions relevant to me:

  • Max memory size (RSS): restricted to 200 MB. It's okay for me because my scripts often use less than 20 MB of RSS
  • Maximum open files: 100 concurrent opened descriptors - seems reasonable
  • Maximum user processes limited to 20: it may influence multi threaded applications. Monitoring processes are started as separated threads, so I have to limit concurrent measurements accordingly
  • Virtual memory: it may influence multi threaded applications with big stack size

I asked if max user processes could be raised but got the answer:

To maintain stability cpanel sets this limit as a hard value and unfortunately we cannot modify it at this time. We apologize for any inconvenience.

I discovered that no quota was configured on my account:

$ quota -v(no output)

Seems not all aspects of server are configured properly. Another issue is with SSH login time:

$ time ssh fb ls(...)
real    0m52.980s
user    0m0.032s
sys     0m0.012s

It's weird, another host with "Turbo" package seems to be much faster:

$ time ssh gamma ls(...)
real    0m2.505s
user    0m0.028s
sys     0m0.008s

Slow SSH connection states bolded out:

debug1: Next authentication method: publickey
debug1: Offering public key: /home/(...)/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: read PEM private key done: type RSA
debug1: Enabling compression at level 6.
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.

No idea what is broken (a network timeout somewhere)?

Another issue is random restarts. Apache is restarted from time to time. I suspect there's automated watchdog that kill processes that use too much resources, Here you can see more timing information from FastCGI process (Trac instance) on this machine. Below one week monitoring with 5 minutes interval result:



Few things have to be adjusted by support ticket:

  • SSH was disabled by default - they enabled it for me
  • Crontab was blocked - it was enabled, too
  • Few system Python-related libraries was missing - were added in minutes

I evaluate support quality as very good.


It's a regular shared hosting so you can use user-friendly tools like CPanel. It's classic tool for such task and is pretty intuitive in usage.


My presonal preference is shell, so I use it if possible (e.g. crontab edits).


So far, so good. You can check how this deployment is working under this address (It's a node from monitoring system, BTW). I'll write more details about hosting after few months of usage.

VPS also is considered to be checked, I'll write more details after setup.

To sumarize:

  • + cheap economical offer
  • + Trac/Subversion out of the box
  • - slow SSH login
  • - frequent (few times a week) short (<few minutes) downtimes VPS review

Inspired by article I wanted to experiment with custom OS installations on low-end OpenVZ environment (where memory constraints differ when compared to Xen or dedicated server), so purchased lowest plan from Ram Host: Nano:

  • OpenVZ
  • 80MB RAM
  • 10 GB disk space
  • 50 GB data transfer

It cost only $2.99/mo, so it's very easy to start experiments with VPS environment for anyone. I paid using PayPal and have to wait next day to service become visible (manual fraud checking on PayPal notifications maybe?).2

OpenVZ vs Xen

OpenVZ is technology that is much easier to oversell: disk storage can be easily shared between customers (one filesystem for all customers), the same with memory. Another problem that may occur when many customers are placed on one node is host swapping: your "dedicated" memory may be placed inside swap file. Imagine your VPS response time then ;-)

For serious applicances I'm using only Xen-based solutions. You have dedicated RAM, dedicated disk (filesystem is truly yours). Sharing is only performed on CPU (equal share typically) and bandwitch. Typical Xen offer starts at $20/mo (I recommend for stable Xen solution).

So: why I'm testing RAM Host then? I was intrigued by fact that they publish host usage statistics (not very common among hosting providers, a good sign host has nothing to hide.):


Control panel

After disaster I don't trust HyperVM users anynmore. RAM Host uses custom panel called RAMCP.


Directly after installation you have clean system even without SSH installed. Good (no unsafe defaults). You must:

  1. log to host machine (not your VPS!) on "vz" account
  2. then authorize youself on "Console Drop" by your credential configured during sign-up process
  3. after that you have root shell and you can install SSH and configure root password to be able to log using SSH

I had problem with executing "aptitude install ssh" (cannot fork new process error) and have to lower default stack size first:

# ulimit -s 128
# aptitude install ssh

After that operation installation was succesful. I installed SSH keys and got the root console.

Linode VPS, welcome to Europe

Linode, VPS hosting company I'm using, just opened signups to new dataceneter in Europe. This new deployment is located at Telecity Group’s Powergate facility.

Checking tracerote to London from Warsas shows the benefits:

Packets               Pings
 Host                        Loss%   Snt   Last   Avg  Best  Wrst StDev
 5.     0.0%    21   32.7  32.9  31.7  39.8   1.7
 6.    0.0%    21   32.7  34.3  30.3  83.4  11.4
 7.    0.0%    21   40.7  46.6  40.7 100.3  14.7
 8.    0.0%    21   48.9  55.1  48.0 127.5  20.5
 9.     0.0%    21   48.5  48.7  48.0  49.7   0.4
10. globix-118206-ldn-b2.c.t  9.5%    21   48.8  58.0  48.3 216.9  38.5
11. te4-1-dist65-01.lon10.te  0.0%    21   50.0  49.5  48.6  50.1   0.4
12.        0.0%    21   49.0  50.0  48.7  57.9   2.0

Now packet travels only 50ms to server from Warsaw (Newark location I'm using now has 130ms). It's big improvement.


Recenzja VPS w /

Wybór dostawcy

Jedną z usług które dostarczam moim klientom są serwery wirtualne (VPS) na potrzeby różnych systemów (głównie opartych o protokół HTTP). VPS to jest wirtualna maszyna posiadająca własne IP i dostęp do root-a, ale współdzieląca sprzęt (CPU, pamięć, dysk) z innymi VPS-ami. Podział pozwala ograniczyć cenę usługi przy zachowaniu dość dobrego poziomu izolacji i bezpieczeństwa (lepszego niż przy współdzielonym hostingu).

Zwykle wynajmuję maszyny w USA ze względu na niską cenę za transfer. Jednak ze względu na potrzebę uzyskania niskich czasów dostępu zdecydowałem się na założenie konta u polskiego dostawcy VPS. Nie potrzebuję wyśrubowanych parametrów, więc wycelowałem w segment budżetowy (poniżej 40 PLN brutto za miesiąc). odpadło w przedbiegach ze względu na bardzo słaby poziom supportu. W nie miałem wcześniej okazji wcześniej stawiać maszyn wirtualnych, ale znalazłem kilka negatywnych opinii na temat problemów z dostępnością maszyn.

Na początku odrzuciłem ze względu na niską gwarantowaną dostępność serwera (tylko 99%). Oznacza to możliwość niedziałania serwera 7 godzin w miesiącu. Uzyskałem jednak od nich linki do rzeczywistych statystyk dostępności serwerów w Polsce i w Niemczech i tam parametry nie wyglądają tak źle (około 99,7 %). Przynajmniej stawiają sprawę uczciwie i nie obiecują gruszek na wierzbie.


Domena jest względnie świeża, ale firma stojąca za tą marką operuje jeszcze w kilku serwisach:

$ whois | grep -i 'creat\|compa'
created:                2009.02.19 10:59:40
company: Statnet Biuro Uslug Informatycznych  Maciej Dolny

$ whois | grep -i 'creat'
created:                2001.04.20 13:00:00

Obie marki VPS oferują lokalizacje w Polsce (Łódź, IWACOM) lub w Niemczech (Hetzner). O ile o IWACOM nie mam wyrobionej opinii to o Hetzner słyszałem wiele pozytywnych opinii. Obie lokalizacje oferują atrakcyjne czasy dostępu z Polski (poniżej 30 ms). W stosunku do serwerów w stanach (ponad 120 ms) wynik jest bardzo dobry.


Tańsza marka operuje na serwerach w Polsce. Oferuje dwa tryby wirtualizacji: OpenVZ (współdzielony kernel, dostępna pamięć "burst") oraz Xen (własny kernel, dostępny swap). Generalnie Xen jest bardziej przewidywalny jeśli chodzi o pamięć, a tym zbliżony do serwera dedykowanego (ograniczana jest pamięć RSZ a nie VSZ). Każdy z planów ma opcję zarówno w OpenVZ jak i w Xen.

Podstawowa różnica jest taka, że opcja OpenVZ ma dwukrotnie więcej dostępnej przestrzeni dyskowej niż Xen. Dzieje się tak dlatego, że maszyny wirtualne OpenVZ współdzielą przestrzeń dyskową (w Xen zakłada się własny system plików), w związku z czym w OpenVZ łatwiejszy jest tzw. overselling.

Podobnie dzieje się z przydziałem pamięci RAM. Host OpenVZ może wejść w SWAP nie z twojej winy, w Xen masz jawnie przydzielany RAM + SWAP i fakt "swapowania" wynika bezpośrednio z aktywności uruchomionych procesów na wirtualce.

Zdecydowałem się na opcję "OpenVZ VPS S" (256 MB RAM, 20 GB przestrzeni na dysku, transfer 50 GB/mc). Wybrałem "Debian Lenny 5.0" jako system operacyjny.


Po masakrze spowodowanej (najprawdopodobniej) przez HyperVM w firmie a2b2 pozytywną cechą u dostawcy serwerów wirtualnych stało się udostępnienie własnego panelu zarządzającego. Firma którą jest stać na napisanie własnego softu zapewne ma więcej kompetencji technicznych niż ta która korzysta z gotowców takich jak HyperVM.

Statnet dysponuje własnym autorskim panelem.


Z jego poziomu można:

  • Obejrzeć wystawione Faktury
  • Uiścić opłatę za serwer (panel integruje się z
  • Skontaktować się z supportem (system ticketów)
  • Zatrzymać / uruchomić serwer
  • Obejrzeć statystyki zużytego transferu

Miłym zaskoczeniem była zwiększona gwarantowana pamięć RAM (384 MB, w ofercie mieli 256 MB). Czyżby ktoś zapomniał dodać informacji o promocji na stronie WWW?


Wygląd i funckjonalność panelu nie budzi zastrzeżeń (układ menu jest czytelny) z kilkoma wyjątkami:

  • Panel nie wspiera połączenia szyfrowanego HTTPS. Oznacza to, że hasło do logowania do panelu idzie jawnym tekstem po HTTP. Jeśli nie jesteś w zaufanej sieci powinieneś tunelować ruch do panelu po SSH do zaudanej maszyny
  • Od aktywacji konta nie ma możliwości samodzielnej pełnej reinstalacji systemu operacyjnego (trzeba kontaktować się z supportem).

Panel do zarządzania kontem jest napisany w Javie (najprawdopodobniej oparto się na bibliotece Struts), pracuje pod Apache Tomcat/5.0.28 + Lighttpd. Nie jest to więc typowa "dłubanina" w PHP (Java wymaga większych kompetencji programistycznych).

Dostępny jest także panel ze statusem dostępności hostów i z informacjami o planowanych pracach. Bardzo przydatna rzecz kiedy występują problemy - można sprawdzić czy nie są one spowodowane planowanymi pracami (mniejsze obciążenie supportu). Panel napisany jest w Django :-) i działa pod mod_python + Apache, korzysta z MySQL-a jako systemu bazodanowego.


Po opłaceniu konta dane serwer został założony w ciągu kilku minut, a na podany adres e-mail przyszły dane do logowania poprzez SSH. Pomimo, że hasło wydawało się dość mocne w pierwszym kroku zestawiłem połączenie po kluczu publicznym i zablokowałem logowanie po haśle.

Wylądowałem na maszynie Znajdują się tu aktualnie około 20 VPS-ów (info wyciągnięte ze statystyk zużycia łącza).

Polecenie free wskazuje pamięć "burst", czyli potencjalnie dostępną, ale nie gwarantowaną przez kontener VPS.

# free -m
         total       used       free     shared    buffers     cached
Mem:           768         36        731          0          0          0
-/+ buffers/cache:         36        731
Swap:            0          0          0

Kontener OpenVZ może ubić największe procesy jeśli suma zużytej pamięci przekroczy pamięc gwarantowaną. Chwilowy (nie gwarantowany) "burst" może pomóc jeśli np. instalujemy oprogramowanie (aptitude może potrzebować nawet 80 MB pamięci wirtualnej).

Dostępna przestrzeń dyskowa jest zgodna ze specyfikacją:

# df -h
Filesystem            Size  Used Avail Use% Mounted on
simfs                  20G  409M   20G   2% /
tmpfs                 3.9G     0  3.9G   0% /lib/init/rw
tmpfs                 3.9G     0  3.9G   0% /dev/shm

Co ciekawe wygląda na to, że cztery rdzenie procesora są dostępne:

# cat /proc/cpuinfo | grep 'cpu MHz'
cpu MHz         : 1995.001
cpu MHz         : 1995.001
cpu MHz         : 1995.001
cpu MHz         : 1995.001

(w ofercie był wymieniony jeden rdzeń: "procesor: 2 GHz (fair scheduler)").

UPDATE 2010-01-13: Cztery rdzenie są widoczne, ale VPS jest wyraźnie ograniczany do około 25% mocy procesora (widać to pod obciążeniem). Czyli efektywnie jest dostępny jeden rdzeń 2Ghz.

Oto wynik parsowania informacji o dostępnych zasobach w VPS-ie OpenVZ uzyskanych z pliku /proc/user_beancounters przy pomocy specjalnego skryptu:

****** vmguarpages and oomguarpages limits are unspecified
****** each VE privvmpages limit should be <= 0.6 * RAM (=1228 MB), probably [much] lower.
   816 MB Allocation Limit [privvmpages limit]
****** only high value processes have a chance in this range
****** having this safety range is important to permit critical processes
   768 MB Allocation Barrier [privvmpages barrier]
****** allocation requests in this range have a chance
   768 MB Allocation Guarantee [vmguarpages barrier]
****** allocation will succeed in this range
   768 MB Memory Guarantee [oomguarpages barrier]
    37 MB ( 128 MB Max) page memory allocated [privvmpages held]
    16 MB (  87 MB Max) memory + swap used [oomguarpages held]
    16 MB (  87 MB Max) page memory used [physpages held]
8796093022207 MB (9007199254740991 KB) kernel memory limit [kmemsize limit]
****** a safety range here, between limit and barrier, is important
8796093022207 MB (9007199254740991 KB) kernel memory barrier [kmemsize barrier]
    3 MB (  3169 KB) kernel memory used [kmemsize held]
    0 MB (   434 KB) buffer memory used [*buf held]
 Used : Max_Used : Limit    for Other Resources
   4739    5019  9223372036854775807   numfile
      5      13  9223372036854775807   numflock
     10      10  9223372036854775807   numiptent
     99     116  9223372036854775807   numothersock
     24      42                 1024   numproc
      2       3                  255   numpty
      0       8                 1024   numsiginfo
      8      91  9223372036854775807   numtcpsock

Co ciekawe gwarantowany RAM okazał się większy od zadeklarowanego w ofercie (768 MB). Jak widać VPS nie jest poprawnie skonfigurowany :-( Nie da się każdemu z 20 VPS-ów na tej maszynie zagwarantować takiej samej dostępnej pamięci (host wejdzie w SWAP kiedy wszyscy zaalokują i użyją całą pamięć). To jest potencjalne zagrożenie stabilności serwera.

UPDATE (2010-01-04): administrator skorygował konfigurację maszyny, teraz jest już prawidłowa:

 560 MB Allocation Limit [privvmpages limit]
 512 MB Allocation Barrier [privvmpages barrier]
 256 MB Allocation Guarantee [vmguarpages barrier]
 256 MB Memory Guarantee [oomguarpages barrier]
 37 MB ( 128 MB Max) page memory allocated [privvmpages held]
 16 MB (  87 MB Max) memory + swap used [oomguarpages held]
 16 MB (  87 MB Max) page memory used [physpages held]

Pomiar dostępności oparty o statyczną stronę HTTP opisuje jak serwer odpowiada zasobem statycznym (plik html). Widać dość dużą wariancję czasu odpowiedzi:


Co ciekawe pomiar z Niemiec pokazuje dużo lepsze czasy odpowiedzi serwera:


Czyżby jakaś dziwna trasa pakietów pomiędzy Krakowem a Łodzią? Sprawdźmy to:

 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1.     0.0%    37    0.0   0.0   0.0   0.0   0.0
 2.                     0.0%    37    0.6   0.6   0.4   2.9   0.4
 3.            21.6%    37    4.0   3.9   3.0  13.3   2.0
 4. ???                               
 5.                      0.0%    36   12.8   9.1   7.0  30.8   4.3

Jak widać problem stanowi router - łącze to nie jest najlepszej jakości. Zobaczymy jak idzie ruch z Niemiec:

Host                                            Loss%   Snt   Last   Avg  Best  Wrst StDev
 1.                 0.0%    36    0.0   0.0   0.0   0.1   0.0
 2.                                 0.0%    36    0.7   0.8   0.4   3.0   0.6
 3.                           20.6%    35    4.6   3.3   2.9   6.8   0.8
 4.          0.0%    35   25.9  28.8  25.5  69.3   8.2
 5.  0.0%    35   26.1  26.7  25.8  28.8   0.8
 6.                               0.0%    35   26.8  26.3  25.5  27.5   0.5

Do Niemiec mamy znacznie mniejszy rozrzut pomiarów.

Przeprowadziłem "test restartu": uruchomiłem polecenie "reboot" z wnętrza VPS-a i sprawdziłem czy system automatycznie wstanie. Zdarzało mi się często na źle skonfigurowanych hostach OpenVZ że polecenie takie było interpretowane jako "halt", czyli system automatycznie nie uruchamiał się po restarcie. W tym przypadku maszyna pojawiła się po chwili ponownie w sieci.



  • bliska lokalizacja (PL/DE)
  • sensowny cennik
  • dostępne statystyki uptime


  • brak połączenia HTTPS do panelu
  • brak samodzielnej reinstalacji OS-a
  • błędy (świadome?) w konfiguracji VPS-ów

HTTP Method selection for, network monitoring service was extended today by HTTP method selection option. You can choose to use HEAD (smaller network overhead) or GET (maximum 10 kB is downloaded in one measurement). Get option allow to download and analyse HTML content for specific keywords (required, like static text on webpage or undesirable, like IFRAME viruses).


Does Your VPS Need A Dedicated IP Address? No!

6I believed dedicated server / VPS (Virtual Private Server) always requires dedicated IP adress. Until today.

I found (thanks, LowEndBox) interesting option where you can build your VPS totally custom parameters including shared IP address.How can it work? With shared IP? Youre joking! - you may ask. It works.

TOCICI offers "Nginx Accelerated Shared IP" wchich mean:

  • Your VPS will be hidden behind NAT like typical workstation
  • External Ngnix HTTP server will redirect HTTP traffic to your box based on URL domain
  • You can define custom ports to be forwarded to your box (SSH incoming traffic)


  • Very cheap option (no cost of dedicated IP required, you can start VPS from 1-2 USD)
  • Security (by default no ports visible to external world)


  • Standard ports except 80 (HTTP) unavailable: no DNS services
  • No HTTPS available (requires separate IP)
  • SSH login requires custom port (your local network may block high ports to prevent P2P)

The service fills gap between shared hosting and classic VPS. The only problem from my point of view is the distance between Europe and Portland, Oregon in the USA. 220 ms from Warsaw. 1 year Xen-based VPS review sells unmanaged VPS servers based on Xen virtualisation technology.

VPS stands for Virtual Private Server and it means one phisycal server is split into smaller parts and every "part" gains his own IP, disk space, CPU and IO resources. You are sharing server resources with other VPS-es, but have much better isolation and customisation than shared hosting supports.

Off-topic note: Besides there's management panel for Linode you should know Linux/Unix administration very well to make use of "unmanaged VPS". If you are not advanced administrator better stay with shared hosting or buy "managed VPS". It will save you many headaches later. VPS (like dedicated server) is not a "piece of cake" for novice webmaster. You've been warned.

It's a review written after one year use of Linode services for one of my customers,


Linode is not the most expensive VPS provider out here. Plans start from 20 USD/mo for 360 MB of RAM that is sufficient for many typical web applications.


I selected lowest plan, Linode 360.


4Linode uses developed in house, powerful VPS panel that allows:

  • start/stop/reboot VPS
  • manage DNS records
  • manage disk space (make, resize partitions), etc.
  • see statistics (IO/net/CPU usage)
  • manage support tickets
  • buy add-ons (additional IPs, memory, disk space)
  • pay for services (by credit card)

You can also create many user accounts and assign them permissions (for example to manage one DNS domain). It's very useful if you want split administration between many persons.

DNS record management is intuitive. Of course you can check your assigned IP addresses and set Rev DNS for your server.

Very interesting option is a Lish console. This mechanism allows you to login your VPS after you messed up with firewall settings. You can compare this access channel to have physical keyboard and monitor attached to machine. Lish comes in two forms:

  • AJAX web-based console
  • SSH server

Personally I prefer SSH access (faster). Access to Lish console can be set using passwords or public keys (RSA for instance). Key-based login eliminates password entry every time you want to access machine.

Ticket system is very simple, but effective (and the most important: someone's behind and responds fast). I used it very occasionally:

  • switch billing scheme from montly to hourly
  • 1 issue with panel (missing IO graph)
  • 2 issues with VPS (not accessible)

All requests were resolved quickly and I'm satisfied with the service.


It's a Xen, so:

  • your filesystem is exclusively yours (no inode limits as in OpenVZ)
  • memory assigned is truly yours (no burst/fake ram on swap partition as in OpenVZ)
  • dedicated SWAP is present

Linode offers 32-bit guest systems, that means: lower memory usage than 64 bit. You can safely stick to 32-bit version if your memory requirements are lower than 4 GB (If they are bigger why bothering with VPS-es?).

Linode offers the following locations (I bolded out locations that are best for Europe customers):

  • London, GB, UK (new)
  • Newark, NJ, USA
  • Atlanta, GA, USA
  • Dallas, TX, USA
  • Fremont, CA, USA

I'm using Newark and Atlanta locations (London was not available one year ago). Both seems to be pretty stable.


It's accessibility measured by of one of websites hosted with Linode (details).


As you can see availability is really good.


I rate this service "A" grade.

OVH VPS Classic Review

I'm a very happy (an US VPS supplier) customer and my expectations regarding service quality are pretty high. VPS is a virtualization technique that allows to share the same hardware among few operating systems with dedicated IP and root access. Having migration to another server in mind I've decided to give a try our European VPS providers.

One of the biggest hosting providers is OVH. I hope those French guys do better hosting services than cars :-)

Minimum VPS offer is reachable for 5 EUR + VAT / month. It gives you only 512MB of RAM:


Despite the fact that they announce only 64-bit systems I was very surprised to see 32-bits of operating system version as well (at least of my favourite Debian) available:


The biggest benefit of 64-bit systems are (if you have less than 3GB of RAM) is that you get slight performance upgrade, but you have to pay in slightly bigger memory usage. As CPU resources are usually less important for me than available RAM (especially on low-end VPS instance) I've decided to go with 32-bit version then.

We have three locations in Europe available for selection, I went with Strasbourg as it's close to German border (so to Warsaw/Poland):


You can pay monthly, quarterly, twice a year or yearly. I've selected 3 months (to have a chance to evaluate server stability and performance over a longer period).

Manager software at OVH is the ugliest web interface I've ever seen. It opens new window on every possible occasion, is totally littered and it's very hard to find out there anything.


Anyway, I've switched to "new" interface (another one?) to manage new VPS system. Here you have few typical options you can expect from a VPS provider interface:

  • transfer used
  • selected ports status (nice feature, I can say)
  • admin options: reboot, password reset, reinstall, reverse DNS, OS reload, console prompt, offer change

Note that there's only one (primary) IP address available, so you will have some trouble when hosting multiple HTTPS sites.

Let's check what's inside then.

Network parameters

Ping time from Warsaw is not bad, we have 37ms average time for a packet (ICMP) travel:

$ ping -c 5
PING ( 56(84) bytes of data.
64 bytes from icmp_req=1 ttl=54 time=38.3 ms
64 bytes from icmp_req=2 ttl=54 time=38.8 ms
64 bytes from icmp_req=3 ttl=54 time=41.6 ms
64 bytes from icmp_req=4 ttl=54 time=35.2 ms
64 bytes from icmp_req=5 ttl=54 time=35.3 ms

--- ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 35.282/37.899/41.625/2.371 ms

We can inspect whole route with more details:

$ mtr --report
HOST: dt                          Loss%   Snt   Last   Avg  Best  Wrst StDev
  8.|--            40.0%    10   37.4  37.4  29.1  55.2   9.4
  9.|--            0.0%    10   48.7  46.4  33.7  83.7  15.0
 10.|--           90.0%    10   36.5  36.5  36.5  36.5   0.0
 11.|--         0.0%    10   36.9  42.2  35.0  62.1   8.4
 12.|--       0.0%    10   40.8  38.0  32.0  48.6   5.1

Finally: the speed tests performed using HTTP (no encryption overhead on VPS, median result from three runs):

# wget -O /dev/null
--2014-02-06 23:15:44--
Connecting to connected.
HTTP request sent, awaiting response... 200 OK
Length: 4415803 (4.2M) [application/zip]
Saving to: `/dev/null'

100%[================================>] 4,415,803   8.04M/s   in 0.5s    

2014-02-06 23:15:45 (8.04 MB/s) - `/dev/null' saved [4415803/4415803]

OVH promises 100 MBit/s, thus ~10 MB/s. As we can see real values are slightly lower, near 8 MB/s. It's not bad (I used U.S. server to test, so may hit local bandwidth restrictions).


# free -h
              total       used       free     shared    buffers     cached
 Mem:          512M        16M       495M         0B         0B       9.0M
 -/+ buffers/cache:       7.7M       504M
 Swap:         128M         0B       128M

It's o,5GB as specified in offer. Note that for OpenVZ your kernel memory is not counted towards used memory - it's different memory model than XEN where you have separate kernel.

For OpenVZ virtualization you might have some additional restrictions (besides memory for all your processes). You can reach those values by /proc/user_beancounters file:

# cat /proc/user_beancounters 
Version: 2.5
       uid  resource                     held              maxheld              barrier                limit              failcnt
    46990:  kmemsize                 10343161             13320192  9223372036854775807  9223372036854775807                    0
            lockedpages                     0                  489               131072               131072                    0
            privvmpages                  1925                25304               131072               524288                    0
            shmpages                      647                  663  9223372036854775807  9223372036854775807                    0
            dummy                           0                    0  9223372036854775807  9223372036854775807                    0
            numproc                        15                   33  9223372036854775807  9223372036854775807                    0
            physpages                   41390                47954                    0               131072                    0
            vmguarpages                     0                    0               131072               131072                    0
            oomguarpages                  833                  833               131072               131072                    0
            numtcpsock                      5                    5  9223372036854775807  9223372036854775807                    0
            numflock                        1                    7  9223372036854775807  9223372036854775807                    0
            numpty                          1                    4  9223372036854775807  9223372036854775807                    0
            numsiginfo                      0                   12  9223372036854775807  9223372036854775807                    0
            tcpsndbuf                   87200               111312  9223372036854775807  9223372036854775807                    0
            tcprcvbuf                   81920               862096  9223372036854775807  9223372036854775807                    0
            othersockbuf                    0                19736  9223372036854775807  9223372036854775807                    0
            dgramrcvbuf                     0                 8720  9223372036854775807  9223372036854775807                    0
            numothersock                   18                   22                  500                  500                    0
            dcachesize                5574544              7664915  9223372036854775807  9223372036854775807                    0
            numfile                       190                  280  9223372036854775807  9223372036854775807                    0
            dummy                           0                    0  9223372036854775807  9223372036854775807                    0
            dummy                           0                    0  9223372036854775807  9223372036854775807                    0
            dummy                           0                    0  9223372036854775807  9223372036854775807                    0
            numiptent                      24                   24  9223372036854775807  9223372036854775807                    0

Typically kmemsize (kernel size for this guest OS) and numproc (the number of available processes) is restricted (I've learned 1&1 restricts numproc to 160!). Here we have no restrictions added for those two parameters, good.


As specified we can see only one core, so will be limited here:

# grep 'cpu MHz\|bogomips' /proc/cpuinfo 
cpu MHz        : 3000.000
bogomips    : 6000.00

The bogomips value (+/- perfomance of the CPU) is 50% better than my 2GHz laptop. The difference comes from higher CPU clock used (3GHz vs 2 GHz).


Typical resource that is oversold by hosting companies. I'm not talking about space itself, but about performance. I've seen many comlaints in the past related to high IO lags (thus high load) due to overused disk usage on crowded servers for virtual and classic hosting.

We can see simfs (virtual filesystem), inodes are shared with host:

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/simfs       25G  401M   25G   2% /
tmpfs            52M   28K   52M   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           128M     0  128M   0% /run/shm

As we are on OpenVZ container we don't have access to hdparm tool. We can make quick & dirty workaround for measure disk write speed (medium result selected):

# sync; dd if=/dev/zero of=/tmp/test bs=64k count=16k; rm /tmp/test
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 8.67465 s, 124 MB/s

Not bad, probably disk is not overloaded. For comparison my ThnkPad with 5200 RPM HDD:

$ sync; dd if=/dev/zero of=/tmp/test bs=64k count=16k; rm /tmp/test
16384+0 records in
16384+0 records out
1073741824 bytes (1,1 GB) copied, 33,3557 s, 32,2 MB/s

Geez, I should switch to SSD! :-)


As you probably know that above measurements are worth nothing if you have long downtimes and / or periods with extremely high load of a host I've launched monitoring of HTTP response time to track changes over longer period: I'll shave stats report as soon as they're ready in separate post. I can share my recommendation then: is OVH VPS worth of your money or not.

UPDATE 2015-03-17: In recent day OVH started to randomly kill my processes (OOM on host?) even if I'm much below OpenVZ limits and allocated memory usage. I switched to another provider instantly. Thus I DO NOT RECOMMEND OVH VPS SOLUTION. Select Linode instead, you will save your time and money.

Bye bye, OVH, Welcome, Linode

After few days of OVH VPS problems (randomly killing processes w/o OpenVZ resources overuse) I've deicded to return to Linode. I know those guys from many years and I used it for commercial deployments with quite good performance and stability.

The result is quite good as you might see from the response graph. Performance problems are gone (without touching software).

No more French/OpenVZ pseudo-products! Viva la XEN!