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
This entry was posted in en and tagged , . Bookmark the permalink.