You can view more reviews at lowendreview.com
Here is a Low End Review for you…
fileMEDIA are a German based hosting provider who were founded in 2008. They operate as a ‘Einzelunternehmer’, which roughly translates as sole trader in English but they’re currently hosting around 5000 VPS. fileMEDIA have appeared once on LowEndBox with a KVM offer and have featured on LowEndTalk a few times.
As well as standard KVM plans, fileMEDIA also offer SSD and storage servers. In addition to their Jena German location, they also provide services from Lenoir, NC and Frankfurt, Germany.
Disclaimer
I am in no way affiliated with fileMEDIA but I have been a customer of theirs since January 2013 (3 Months). This server was benchmarked and reviewed whilst it was in production. Therefore it should be noted that the below results are of a server currently being used.
Introduction
Back in early January, I published an offer for a €3.49 256MB KVM server in Jena, Germany. At the time, I was interested in finding new LowEndBox ‘hidden gem’ providers as I hadn’t purchased a new VPS in a while. Furthermore, I had not already got a server in Germany. Johannes, the owner, had presented himself well in our email correspondence and his offer looked interesting.
The plan I purchased had 256MB RAM, 15GB Raid 10 Diskspace, 1TB Bandwidth and was IPv6 enabled. As well as a 7 day money back guarantee, they were offering 50% of your first month, bringing the initial cost to €1.75 +vat. I thought I had nothing to lose, so I signed up there and then.
Support & Communication
My server was instantly set up by fileMEDIA. Everything was fine and thus I had no reason to contact support. When I initially signed up their site was only available in German, it’s nice to see they have added an English version. Unfortunately, not every page has been translated yet but it’s a start. Still you can use google translate if you cannot speak German to navigate their site. WHMCS and emails sent from them however are just in German.
After about a month of service with them, I received an email from them informing me about ‘network maintenance’. Some switches needed replacing. fileMEDIA provided me with ample notice but again the email was in German. I suppose most of their clients are German and they’re a German company so I cannot really complain about that. Plus, luckily I can speak high-school German, so does not affect me. They could however do what EDIS does and send the email in both languages.
Hardware Information
According to their website at the time, their nodes were using a mix of E3 (1230v2, 1270 and 1270v2) and E5 (2620) CPUs, with 32GB and 96GB of RAM respectively and 12 to 24 hard drives in hardware RAID 10. Servers seemed to be owned by them – refreshing, as many German providers use Hetzner.
root@jena:~# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 13 model name : QEMU Virtual CPU version (cpu64-rhel6) stepping : 3 cpu MHz : 3392.292 cache size : 4096 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 4 wp : yes flags : fpu de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm up pni cx16 hypervisor lahf_lm bogomips : 6784.58 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
Meminfo Results
root@jena:~# cat /proc/meminfo MemTotal: 254836 kB MemFree: 46200 kB Buffers: 146412 kB Cached: 42296 kB SwapCached: 0 kB Active: 171028 kB Inactive: 23396 kB Active(anon): 2212 kB Inactive(anon): 3612 kB Active(file): 168816 kB Inactive(file): 19784 kB Unevictable: 0 kB Mlocked: 0 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 254836 kB LowFree: 46200 kB SwapTotal: 499704 kB SwapFree: 499704 kB Dirty: 4 kB Writeback: 0 kB AnonPages: 5736 kB Mapped: 4404 kB Shmem: 116 kB Slab: 11296 kB SReclaimable: 7820 kB SUnreclaim: 3476 kB KernelStack: 488 kB PageTables: 348 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 627120 kB Committed_AS: 38800 kB VmallocTotal: 765956 kB VmallocUsed: 5924 kB VmallocChunk: 750888 kB HardwareCorrupted: 0 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 4096 kB DirectMap4k: 12276 kB DirectMap4M: 249856 kB
Inode Allocation:
root@jena:~# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/mapper/jena-root
936560 25469 911091 3% /
tmpfs 31854 5 31849 1% /lib/init/rw
udev 30632 557 30075 2% /dev
tmpfs 31854 1 31853 1% /dev/shm
/dev/sda1 124496 222 124274 1% /bootvmstat:
root@jena:~# vmstat procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 0 0 0 46124 146416 42376 0 0 0 0 1 4 0 0 100 0
The Network
Overall, the network performed well. At times I have noticed speeds to drop off the radar but this seems to be a seldom event. In these tests below, the network was tested three times and the medium result has been posted.
The Cachefly download speedtest result performed well on the shared Gigabit port.
root@jena:~# wget -O /dev/null http://cachefly.cachefly.net/100mb.test --2013-03-28 13:55:03-- http://cachefly.cachefly.net/100mb.test Resolving cachefly.cachefly.net... 205.234.175.175 Connecting to cachefly.cachefly.net|205.234.175.175|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 104857600 (100M) [application/octet-stream] Saving to: `/dev/null' 100%[========================================>] 104,857,600 24.4M/s in 5.3s
I’ve ran a few download and upload tests from around the world, for a more accurate portrayal of the network.
Hosted by Vodafone UK (London) Download: 74.44 Mbit/s Upload: 17.60 Mbit/s Hosted by Interserver, inc (Secaucus, NJ) Download: 104.25 Mbit/s Upload: 5.39 Mbit/s Hosted by Vodafone DE (Frankfurt) Download: 197.43 Mbit/s Upload: 40.61 Mbit/s Hosted by Vodafone NL (Utrecht) Download: 98.64 Mbit/s Upload: 30.60 Mbit/s
Ping to Google was nothing spectacular, but the server is located in a smaller city. Jena is likely being served by Google in Frankfurt which is over 250km away.
root@jena:~/speedtest-cli-master# ping -c 5 google.com PING google.com (173.194.35.14) 56(84) bytes of data. 64 bytes from mil01s16-in-f14.1e100.net (173.194.35.14): icmp_req=1 ttl=60 time=32.7 ms 64 bytes from mil01s16-in-f14.1e100.net (173.194.35.14): icmp_req=2 ttl=60 time=32.7 ms 64 bytes from mil01s16-in-f14.1e100.net (173.194.35.14): icmp_req=3 ttl=60 time=32.9 ms 64 bytes from mil01s16-in-f14.1e100.net (173.194.35.14): icmp_req=4 ttl=60 time=32.7 ms 64 bytes from mil01s16-in-f14.1e100.net (173.194.35.14): icmp_req=5 ttl=60 time=32.9 ms --- google.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4005ms rtt min/avg/max/mdev = 32.749/32.830/32.929/0.178 ms
Benchmark Tests
In these tests below, they were tested three times and the medium result has been posted. Firstly I ran a disk IO test.
root@jena:~# dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync; rm test 16384+0 records in 16384+0 records out 1073741824 bytes (1.1 GB) copied, 7.32455 s, 147 MB/s
ioping is very slow and not very consistent. In one of the three tests I ran for the above test, I got a result of the 22MB/s. Either at the time an abuser was around or something is up with their storage solution.
root@jena:~/ioping/ioping# ./ioping -c 10 . 4096 bytes from . (ext3 /dev/mapper/jena-root): request=1 time=7.9 ms 4096 bytes from . (ext3 /dev/mapper/jena-root): request=2 time=8.2 ms 4096 bytes from . (ext3 /dev/mapper/jena-root): request=3 time=5.9 ms 4096 bytes from . (ext3 /dev/mapper/jena-root): request=4 time=8.1 ms 4096 bytes from . (ext3 /dev/mapper/jena-root): request=5 time=0.4 ms 4096 bytes from . (ext3 /dev/mapper/jena-root): request=6 time=18.0 ms 4096 bytes from . (ext3 /dev/mapper/jena-root): request=7 time=0.5 ms 4096 bytes from . (ext3 /dev/mapper/jena-root): request=8 time=0.3 ms 4096 bytes from . (ext3 /dev/mapper/jena-root): request=9 time=0.4 ms 4096 bytes from . (ext3 /dev/mapper/jena-root): request=10 time=0.4 ms --- . (ext3 /dev/mapper/jena-root) ioping statistics --- 10 requests completed in 9051.5 ms, 200 iops, 0.8 mb/s min/avg/max/mdev = 0.3/5.0/18.0/5.5 ms
UnixBench results were better than I had predicted. The VPS only has one CPU core, this is one of the better results that I have seen for a 1 core VPS.
# # # # # # # ##### ###### # # #### # #
# # ## # # # # # # # ## # # # # #
# # # # # # ## ##### ##### # # # # ######
# # # # # # ## # # # # # # # # #
# # # ## # # # # # # # ## # # # #
#### # # # # # ##### ###### # # #### # #
Version 5.1.3 Based on the Byte Magazine Unix Benchmark
Multi-CPU version Version 5 revisions by Ian Smith,
Sunnyvale, CA, USA
January 13, 2011 johantheghost at yahoo period com
1 x Dhrystone 2 using register variables 1 2 3 4 5 6 7 8 9 10
1 x Double-Precision Whetstone 1 2 3 4 5 6 7 8 9 10
1 x Execl Throughput 1 2 3
1 x File Copy 1024 bufsize 2000 maxblocks 1 2 3
1 x File Copy 256 bufsize 500 maxblocks 1 2 3
1 x File Copy 4096 bufsize 8000 maxblocks 1 2 3
1 x Pipe Throughput 1 2 3 4 5 6 7 8 9 10
1 x Pipe-based Context Switching 1 2 3 4 5 6 7 8 9 10
1 x Process Creation 1 2 3
1 x System Call Overhead 1 2 3 4 5 6 7 8 9 10
1 x Shell Scripts (1 concurrent) 1 2 3
1 x Shell Scripts (8 concurrent) 1 2 3
========================================================================
BYTE UNIX Benchmarks (Version 5.1.3)
System: jena: GNU/Linux
OS: GNU/Linux -- 2.6.32-5-686 -- #1 SMP Sun Sep 23 09:49:36 UTC 2012
Machine: i686 (unknown)
Language: en_US.utf8 (charmap="ANSI_X3.4-1968", collate="ANSI_X3.4-1968")
CPU 0: QEMU Virtual CPU version (cpu64-rhel6) (6784.6 bogomips)
x86-64, MMX, Physical Address Ext, SYSCALL/SYSRET
00:11:30 up 89 days, 2:51, 1 user, load average: 0.00, 0.00, 0.00; runlevel 2
------------------------------------------------------------------------
Benchmark Run: Sat Apr 06 2013 00:11:30 - 00:39:46
1 CPU in system; running 1 parallel copy of tests
Dhrystone 2 using register variables 23046099.5 lps (10.0 s, 7 samples)
Double-Precision Whetstone 3560.0 MWIPS (10.0 s, 7 samples)
Execl Throughput 7537.1 lps (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 813677.1 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 225040.0 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 1999842.3 KBps (30.0 s, 2 samples)
Pipe Throughput 1519688.2 lps (10.0 s, 7 samples)
Pipe-based Context Switching 403572.8 lps (10.0 s, 7 samples)
Process Creation 25677.1 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 9694.2 lpm (60.1 s, 2 samples)
Shell Scripts (8 concurrent) 1211.4 lpm (60.1 s, 2 samples)
System Call Overhead 1363632.1 lps (10.0 s, 7 samples)
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 23046099.5 1974.8
Double-Precision Whetstone 55.0 3560.0 647.3
Execl Throughput 43.0 7537.1 1752.8
File Copy 1024 bufsize 2000 maxblocks 3960.0 813677.1 2054.7
File Copy 256 bufsize 500 maxblocks 1655.0 225040.0 1359.8
File Copy 4096 bufsize 8000 maxblocks 5800.0 1999842.3 3448.0
Pipe Throughput 12440.0 1519688.2 1221.6
Pipe-based Context Switching 4000.0 403572.8 1008.9
Process Creation 126.0 25677.1 2037.9
Shell Scripts (1 concurrent) 42.4 9694.2 2286.4
Shell Scripts (8 concurrent) 6.0 1211.4 2019.0
System Call Overhead 15000.0 1363632.1 909.1
========
System Benchmarks Index Score 1571.9GeekBench went well as well.
http://browser.primatelabs.com/geekbench2/1809767
Conclusion
fileMEDIA provide a reliable and friendly service. My server has performed well, with only a few bumps during my time with them. The only really problem I noticed was the inconsistent diskspeeds but this has not really been an issue for the system I was running on this VPS. Even when they have been fluctuating, in my opinion, they have not reached too low of a level. At first the network had a few issues, but fileMEDIA quickly resolved them according to my testing.
I believe the service is good value for money and can make a nice addition to any budding VPS collection. To improve, I would recommend fileMEDIA take on board my comments regarding the English language, but other than that, keep up what you’re doing!
Related Posts:
- How To Create a DNS Server On Ubuntu 18.04 - July 10, 2019
- How To Create a DNS Server On Debian Stretch - June 27, 2019
- How To Install and Use A Plex Media Server On Raspbian Stretch - June 17, 2019
i will try buy ^_^
Which script are you using for download and upload test? If you are using speedtest-cli script upload speeds are not accurate.
Cheers I’ll make a note of that. Do you know of any alternatives?
Most accurate one is a phyton script below.Compare with speedtest-cli and notice the difference.
http://www.lowendtalk.com/discussion/6567/command-line-speedtest.net-via-tespeed
On serverbear:
50% lifetime discount for PowerBoxes and StorageBoxes.
[b]serverbear2013[/b]
Just a thought
According to my experiences, AFAIK a single vmstat generally doesn’t show anything relevant. An output of ten lines like “vmstat 1 10” may show better what’s going on with the iowait and cs numbers, which I guess are the most important for us.
Another thing.
The inode allocation part is irrelevant since this is a KVM server and you can reinstall and reformat your disk to your pleasure. Of course, unless the server was autoprovisioned with a template.
Thanks for this review, I am considering several providers to replace a server at Germany
Thanks Yomero. I will take your comments onboard for my next review (who said they liked Pizza?).
Liam, I think there’s a small typo in your disclaimer: “I am in no way affiliated with fileMEDIA but I have been a customer of theirs since January 2012 (3 Months).” If it’s been 3 months, I think you meant “January 2013”.
Cheers.
I also bought last month a VPS from FileMEDIA (tariff Powerox START).
Disk system tests on ServerBear where pretty well and I decided to order a VPS.
After short testing observed that file system performance was not acceptable for my purposes and asked for moneyback. The answer:
But they offered to migrate to another location. Migration was made and where disk speed is a little bit higher:
With my tariff I obtained 2 CPUs, but obtained worse results than topic starter with one (results from the first location before migration):
I used this code and for the first month obtained discount. For the next month I received bill for the full summ without discount.
Sorry to hear. Yes, as mentioned above, the disk speeds were a little unstable. I’m not sure if they’re using RAID. Did it affect what you were using the VPS for? Apart from making benchmarks look a little ugly, it shouldn’t affect most things people use their vps for.
I imported one of the websites for a test and was not satisfied with page generation time and decided to abandon migration.
Hi,
I have been a customer of theirs since they was featured in LEB(KVM micro), I’m pretty satisfied, Their ping to my local connection is lowest compared to another hosts, through Rostelecom i get around 130-170ms (Jena->Tehran) which is the best for me.
I did several I/O tests and the result was between 104 to 253MB/s!
[root@de1 ~]# wget -O /dev/null http://cachefly.cachefly.net/100mb.test
–2013-04-29 14:39:58– http://cachefly.cachefly.net/100mb.test
Resolving cachefly.cachefly.net… 205.234.175.175
Connecting to cachefly.cachefly.net|205.234.175.175|:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: â/dev/nullâ
100%[======================================>] 104,857,600 24.2M/s in 4.4s
2013-04-29 14:40:03 (22.6 MB/s) – â/dev/nullâ
Nice review!
Just a little hint – the ping to Google is rather high as it routes to Google servers in Milano. The hostname mostly contains the 3-letter airport code (in this case “mil”).
Hello,
yes we using Hardware Raid cards for our nodes. Few nodes using lsi, another ones areca or adaptec. I think the lsi nodes are the best. We using only lsi cards in our new location in Frankfurt, Germany (global switch) now. The performance should be better.
The old promotion is expired. But we having a new discout promotion too. Use LET-YEARLY-2013 as promotion code to get 50% lifetime discount for all annually, biennially and triennially orders.
Our new location offers now a direct connection to DE-CIX, google,..:
ping -c 5 google.com
PING google.com (173.194.112.165) 56(84) bytes of data.
64 bytes from fra07s32-in-f5.1e100.net (173.194.112.165): icmp_seq=1 ttl=60 time=1.75 ms
64 bytes from fra07s32-in-f5.1e100.net (173.194.112.165): icmp_seq=2 ttl=60 time=2.14 ms
64 bytes from fra07s32-in-f5.1e100.net (173.194.112.165): icmp_seq=3 ttl=60 time=1.77 ms
64 bytes from fra07s32-in-f5.1e100.net (173.194.112.165): icmp_seq=4 ttl=60 time=1.86 ms
64 bytes from fra07s32-in-f5.1e100.net (173.194.112.165): icmp_seq=5 ttl=60 time=2.07 ms
— google.com ping statistics —
5 packets transmitted, 5 received, 0% packet loss, time 4007ms
rtt min/avg/max/mdev = 1.750/1.919/2.140/0.160 ms
traceroute google.com
traceroute to google.com (173.194.112.165), 30 hops max, 60 byte packets
1 gateway.ipv4.fra.filemedia.net (62.113.241.1) 0.158 ms 0.181 ms 0.181 ms
2 de-cix10.net.google.com (80.81.192.108) 1.534 ms 1.513 ms 1.524 ms
3 209.85.241.110 (209.85.241.110) 2.818 ms 2.297 ms 2.801 ms
4 72.14.238.57 (72.14.238.57) 2.981 ms 2.963 ms 2.939 ms
5 fra07s32-in-f5.1e100.net (173.194.112.165) 2.758 ms 1.807 ms 2.040 ms