The Aggressive Netowrks ( @aggressivenetworks ) provider has invited some beta testers to review their new product. The specifications of the provided VPS are bellow:
RAM: 128MB
Swap: 128MB
HDD: 15 GB (Raid10)
Bandwidth: 200GB@ 1 Gbps
IPv4 network: NAT 19 Ports + 1 SSH
IPv6 network: /112 ipv6
The image used to build the container is outdated and doesn't include the last libc patch. We all know how to update our servers, I think, but should be a great idea to build new images with the latest updates:
root@trial:~# apt-get upgrade
Reading package lists... Done
Building dependency tree... Done
The following packages will be upgraded:
apt base-files debian-archive-keyring libapt-pkg4.12 libc-bin libc6 libssl1.0.0 locales multiarch-support tzdata
10 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 16.7 MB of archives.
After this operation, 778 kB of additional disk space will be used.
Do you want to continue [Y/n]?
The container, however, has very small set of running process out of box, cutting out services like xinetd and saslauthd from the startup:
root@trial:~# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.6 3140 840 ? Ss Feb01 0:00 init
root 2 0.0 0.0 0 0 ? S Feb01 0:00 [kthreadd/108]
root 3 0.0 0.0 0 0 ? S Feb01 0:00 [khelper/108]
root 112 0.0 0.2 2396 352 ? S Feb01 0:00 upstart-udev-bridge --daemon
root 120 0.0 0.4 2364 648 ? Ss Feb01 0:00 /sbin/udevd --daemon
root 167 0.0 0.3 2360 404 ? S Feb01 0:00 /sbin/udevd --daemon
root 168 0.0 0.3 2360 404 ? S Feb01 0:00 /sbin/udevd --daemon
root 336 0.0 0.1 2388 244 ? S Feb01 0:00 upstart-socket-bridge --daemon
root 1546 0.0 0.7 33852 980 ? Sl Feb01 0:00 /usr/sbin/rsyslogd -c5
root 1626 0.0 0.4 6340 584 ? Ss Feb01 0:00 /usr/sbin/sshd
root 1647 0.0 0.4 1976 616 tty1 Ss+ Feb01 0:00 /sbin/getty 38400 console
root 1649 0.0 0.4 1976 616 tty2 Ss+ Feb01 0:00 /sbin/getty 38400 tty2
root 2086 0.0 1.6 9280 2100 ? Ss 06:28 0:00 sshd: root@pts/0
root 2088 0.0 0.9 3044 1276 pts/0 Ss 06:28 0:00 -bash
root 3041 0.0 0.7 2692 976 pts/0 R+ 06:39 0:00 ps aux
Memory and swap is just what should be:
root@trial:~# free -m
total used free shared buffers cached
Mem: 128 7 120 0 0 5
-/+ buffers/cache: 1 126
Swap: 128 4 123
You have 4 cores to use and this is very interesting. I don't know if we will keep with the 4 cores after trial but this is a good point to choose this server over the competitors:
root@trial:~# nproc
4
Each core comes from a Intel(R) Xeon(R) CPU E3-1230 v3 @ 3.30GHz as you can see bellow:
root@trial:~# cat /proc/cpuinfo
processor : 0
vendor_id : Genu
cpu family : 6
model : 60
model name : Intel(R) Xeon(R) CPU E3-1230 v3 @ 3.30GHz
stepping : 3
microcode : 16
cpu MHz : 3292.615
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf cpuid_faulting pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase bmi1 hle avx2 smep bmi2 erms invpcid rtm
bogomips : 6585.23
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
All the other 3 cores are the same as this one (obviouslly). The CPU has performed very well on some tests:
root@trial:~# wget dl.getipaddr.net/speedtest.sh 2>/dev/null -O- | bash
---------------CPU test--------------------
CPU: 4 x Intel(R) Xeon(R) CPU E3-1230 v3 @ 3.30GHz
Time taken to generate PI to 5000 decimal places with a single thread: 0m21.527s
root@trial:~# openssl speed sha1
Doing sha1 for 3s on 16 size blocks: 8379526 sha1's in 2.99s
Doing sha1 for 3s on 64 size blocks: 6913999 sha1's in 3.00s
Doing sha1 for 3s on 256 size blocks: 4157273 sha1's in 3.00s
Doing sha1 for 3s on 1024 size blocks: 1652443 sha1's in 3.00s
Doing sha1 for 3s on 8192 size blocks: 262372 sha1's in 3.00s
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
sha1 44840.27k 147498.65k 354753.96k 564033.88k 716450.47k
root@trial:~# openssl speed sha256
Doing sha256 for 3s on 16 size blocks: 7529214 sha256's in 2.99s
Doing sha256 for 3s on 64 size blocks: 4584302 sha256's in 3.00s
Doing sha256 for 3s on 256 size blocks: 1991055 sha256's in 3.00s
Doing sha256 for 3s on 1024 size blocks: 614873 sha256's in 3.00s
Doing sha256 for 3s on 8192 size blocks: 82313 sha256's in 3.00s
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
sha256 40290.11k 97798.44k 169903.36k 209876.65k 224769.37k
Disk I/O is pretty good too:
root@trial:~# dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 0.711218 s, 1.5 GB/s
Network speed is OK, but UP/DOWN for/from some locations is really slow:
root@trial:~# wget dl.getipaddr.net/speedtest.sh 2>/dev/null -O- | bash
-------------Speed test--------------------
Testing North America locations
Speedtest from Portland, Oregon, USA [ generously donated by http://bonevm.com ] on a shared 100 Mbps port
Download Speed: 9.90 MB/sec
Upload speed: 5.18 MB/sec
Speedtest from Seattle, Washington, USA on a shared 100 Mbps port
Download Speed: 9.39 MB/sec
Upload speed: 3.67 MB/sec
Speedtest from Los Angeles, CA, USA [ generously donated by http://maximumvps.net ] on a shared 1 Gbps port
Download Speed: 19.74 MB/sec
Upload speed: 11.41 MB/sec
Speedtest from Los Angeles, CA, USA [ generously donated by TeraFire, LLC ] on a shared 1 Gbps port
Download Speed: 13.70 MB/sec
Upload speed: 8.00 MB/sec
Speedtest from Denver, CO, USA on a shared 100 Mbps port
Download Speed: 5.48 MB/sec
Upload speed: 15.34 MB/sec
Speedtest from Kansas City, MO, USA [ generously donated by http://megavz.com ] on a shared 1 Gbps port
Download Speed: 5.09 MB/sec
Upload speed: 8.98 MB/sec
Speedtest from Dallas, TX, USA [ generously donated by http://cloudshards.com ] on a shared 1 Gbps port
Download Speed: 38.85 MB/sec
Upload speed: 18.30 MB/sec
Speedtest from Chicago, IL, USA [ generously donated by http://vortexservers.com ] on a shared 1 Gbps port
Download Speed: 34.68 MB/sec
Upload speed: 25.18 MB/sec
Speedtest from Beauharnois, Quebec, Canada [ generously donated by http://mycustomhosting.net ] on a shared 1000 Mbps port in / 500 Mbps port out
Download Speed: 10.40 MB/sec
Upload speed: 3.14 MB/sec
Speedtest from Beauharnois, Quebec, Canada [ generously donated by http://hostnun.net/ ] on a shared 500 Mbps port
Download Speed: 11.38 MB/sec
Upload speed: 2.55 MB/sec
Speedtest from Buffalo, NY, USA on a shared 1 Gpbs port (location may be slow):
Download Speed: 6.49 MB/sec
Upload speed: 2.16 MB/sec
Speedtest from Atlanta, GA, USA [ generously donated by http://hostus.us ] on a shared 1 Gbps port
Download Speed: 65.67 MB/sec
Upload speed: 25.13 MB/sec
Speedtest from Lenoir, NC, USA [ generously donated by http://megavz.com ] on a shared 1 Gbps port
Download Speed: 19.68 MB/sec
Upload speed: 27.75 MB/sec
Speedtest from Jacksonville, FL, USA [ generously donated by http://maximumvps.net ] on a shared 1 Gbps port
Download Speed: 61.73 MB/sec
Upload speed: 16.82 MB/sec
Testing EU locations
Speedtest from Tallinn, Estonia on a shared 1 Gbps port
Download Speed: 4.49 MB/sec
Upload speed: 7.04 MB/sec
Speedtest from Paris, France on a shared 1 Gbps port
Download Speed: 6.09 MB/sec
Upload speed: 3.66 MB/sec
Speedtest from Milan, Italy [ generously donated by http://www.prometeus.net ] on a shared 1 Gbps port
Download Speed: 15.31 MB/sec
Upload speed: 6.62 MB/sec
Speedtest from Dusseldorf, Germany [ generously donated by http://megavz.com ] on a shared 1 Gbps port
Download Speed: 8.30 MB/sec
Upload speed: 7.37 MB/sec
Speedtest from Falkenstein, Germany [ generously donated by http://megavz.com ] on a shared 1 Gbps port
Download Speed: 0 MB/sec
Upload speed: 0 MB/sec
Speedtest from Bucharest, Romania [ generously donated by http://www.prometeus.net ] on a semi-dedicated 1 Gbps port
Download Speed: 9.08 MB/sec
Upload speed: 2.09 MB/sec
Testing Asian locations
Speedtest from Tokyo, Japan on a shared 1 Gbps port
Download Speed: 2.65 MB/sec
Upload speed: 3.01 MB/sec
Testing Australian locations
Speedtest from Sydney, Australia on a shared 1 Gbps port
Download Speed: 2.29 MB/sec
Upload speed: 1.08 MB/sec
I've stressed the container using:
root@trial:~# stress --cpu 4 --io 1 --vm 1 --vm-bytes 128M --hdd 1 --timeout 180s --verbose
This was the result:
Without hangs, drops, locks or anything. But I think that a load limit should be imposed over the containers to stop abusers from running the node out of resources.
I've managed to compile and run a full web stack on the containeir (web server, php, sqlite) using monkeyServer.sh and it is running the Linfo script (that show details of the host running the script) and can be viewed from http://trial.alexteles.com:10602/, a set of PHP benchmark scripts that can be accessed from http://trial.alexteles.com:10602/bench.php and the phpinfo() output from http://trial.alexteles.com:10602/phpinfo.php.
I will release the ServerBear benchmark link when it get ready.