The story
After few months with a2b2.com 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 fivebean.com for this purpose.
First 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.
Offer
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. ae-72-72.ebr2.Frankfurt1.Level3.net 0.0% 53 43.1 43.3 41.8 54.0 2.2 ae-92-92.ebr2.Frankfurt1.Level3.net 9. ae-43-43.ebr2.Washington1.Level3.net 0.0% 53 141.8 142.6 139.9 153.2 1.8 10. ae-2-2.ebr2.Chicago2.Level3.net 0.0% 53 142.7 143.4 142.3 144.4 0.5 11. ae-5.ebr2.Chicago1.Level3.net 0.0% 53 142.7 146.6 141.0 155.5 4.6 12. ae-24-52.car4.Chicago1.Level3.net 3.8% 53 213.5 150.6 140.8 282.8 30.2 13. WBS-CONNECT.car4.Chicago1.Level3.net 0.0% 53 146.9 147.2 145.3 161.5 2.4 14. 208.79.234.18 0.0% 53 161.6 167.9 160.5 295.5 20.2 15. 209.188.90.57 3.8% 53 162.0 163.9 160.6 193.9 5.7 16. maui.fivebean.com 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:
Support
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.
Panel
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).
Summary
So far, so good. You can check how this deployment is working under this address (It's a node from monitoring system site-uptime.net, 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