Ah, yes, it’s been more than a year without downtime and that is because we host ourselves in CloudSigma.
I remember the first days, right after Rackspace and all. Richard Couture was very uncertain about “The Cloud”. He disliked Rackspace and kept saying: “I want a server I can touch!”. Well, after a year, I’d like you to hear him saying: “CloudSigma rules!”. He doesn’t miss a thing about real servers.
The service has been great and flexible as we need it. We even host a Mageia mirror thanks to CloudSigma.
This year, we started building our wiki and the PHPCabal, PythonCabal and ArduinoCabal communities.
Our website provides all kinds of info about our activities
Guadalajara owns them a lot. Our FOSS community is possible, in great part, thanks to them.
Thank you, CloudSigma, for the past year. We’re grateful. We, also, congratulate you for your grant U.S.A. opening. May you conquer the world and keep offering great KVM/Qemu virtualization options to the world.
If you like the poster, feel free to do whatever you want with it; as long as it stays under Creative Commons Unported 3.0 Share-Alike license. Also, feel free to share your work with me in my email: renich@woralelandia.com. The svg files will be at the link show bellow.
Creative Commons Poster
# Source files
http://downloads.woralelandia.com/design/2d/linuxcabal/
Can you explain what server sizing you’ve been using for those of us considering moving to the cloud (and CloudSigma in particular)?
Have you sized it big enough to handle all your database and other needs? Any I/O bottlenecks? Do you see the need to use their new SSD drives?
If you only answer one question, PLEASE answer the first one
Yeah, sure!
The server is re-sized easily while using LVM. I think you can learn all that from the LVM2 howto. Also, RedHat’s documentation on it is awesome.
http://tldp.org/HOWTO/LVM-HOWTO/
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Logical_Volume_Manager_Administration/index.html
Keep in mind that is much easier if you have logical volumes (lv) for every partition you use. Let’s say, for example, you have
lv_tmp
lv_var
lv_root
lv_usr_local
lv_backup
lv_home
You could, live, just resize lv_var without too much trouble. If you need to resize the HDD, you would need to restart but, either way, it’s not too much downtime for a hardware resize, is it?!
Let me see if I can find a HowTo on this… ah, yes! http://www.fedoraforum.org/forum/showthread.php?t=269774
I’ve resized from 20 GB to 400GB without problems. Never tried anything above that.
Nope, no I/O problems. I’d recommend using 2 HDDs so you can tell your LV to do striping; its definitely faster.
SSD is awesome for the system. I like to have a 20 GB drive for the root, tmp and usr partitions. I would use an SSD drive for var alone too… if 50 GB is all I need.
It’s, at least, 2x faster. Another recommendation, if you’re up to it, is using btrfs with compression, autodefrag, ssd and noatime so you can have a taste of true speed… you will not believe it…
If you need any more tips, just post… or email if you feel like it.
Uh-oh! I was asking what server resources (CPU, RAM, etc) you have set up for your CloudSigma server instance(s). I think you answered a different question.
Sorry maybe I was not clear enough(?)! I’d appreciate learning what the answer to my question is but I do really appreciate that you answered at all in the first place!
LOL, ok. I don’t understand what you asked then. I’ve used instances of .5 GHz, .5 GB in RAM and 10 HDD.
Actually, my minimal instance is 1 1 20. I, usually, split the processor in 2 per Ghz.
I, also, have a 4 Ghz image; with 4 processors and it works incredible.
Mix all this with SSD and BTRFS and you’ll get mega-speed
Yeah! That’s what I was asking! The re-sizing question was if you found your original resources too small and needed to increase them.
Do you run web applications successfully with 1GHz CPU, 1GB RAM?
When you say you split the processor, you mean that you use the Advanced Options and you manually indicate one core for every 1GHz server size you have?
4GHz is a bit expensive for me so I hope I can run safely on around 2.5GHz, maybe 1.5GB RAM but since I’m replacing a 2.2GHz dual core CPU (effectively 4.4GHz) it might seem a little slow to me?
Anyway, it’s so nice of you to respond here!!! THANK YOU!!
Definitelly. I have no problems running webservers and dns and stuff like that in a 1 GHz processor.
Yes, I split the processor in the Advanced Options tab. Try 1 Ghz and split the processor in 2. You will be surprised.
The thing is that, KVM/Qemu, can’t limit the processor speed. So, even if you buy .25, you will get a full 2.2 GHz Opteron processor; with lot’s of cache and L2 cache.
When you split the processor in 2, you get 2 of those. Etc.
You should not assing 1.5 GB of ram. I would go for rounded numbers: 1, 2, 4, etc. This will give you much better performance given the memory pages you get assigned. Remember how DDR works. Even if it’s virtual, you will get real ram block assignment.
Wow, even try 2 cores with even just a 1GHz instance? OK! Great advice!
(I understand no limits under KVM, but I didn’t think about that you get lots more power if you grab more cores! Nice trick!)
How DDR works is over my head but I’ll take your word for it – going with 1, 2, 3, 4 GB is better? OK!
Again thanks sincerely.
My pleasure
Alright since you’re so nice, one followup question — during busy times of the day, does splitting your GHz into multiple cores (thru Advanced Settings) does that backfire? I mean, if you have smaller GHz per core limit when the machine is busy, can this hurt you?
If it doesn’t hurt you, why wouldn’t you choose 10 cores always, no matter how many GHz you have?
I will reply bellow here to your comment since we reached the maximum comment level.
Well, KVM/Qemu does let you emulate processors.
I dunno, for sure, if, when you have 1 GHz and you say you need 2 processors, they get emulated or assigned for real.
I havent gone as far as emulating the 10 processors. This, you should try yourself.
Try some nice benchmarking tool. A simple one, like: http://hardinfo.berlios.de/HomePage
That one will tell you the difference.
You would do me a favor if you could come back with the results. Try one core, two cores, 4 cores and 10 cores. That will give you a good idea of what the performance is.
I’ll look into the benchmarking as I’m interested to test against my dedicated server.
I tried increasing CPU cores, but they have a limit built in that only lets you get a maximum of 1 CPU per GHz, so if my server is 2 GHz, I can only get 2 cores maximum anyhow.
Oh well it was a nice thought
But it’s still a GREAT tip from you because the default for a 2GHz server seems to be one core.
Are you possitive on this? Because I, currently, have 2 cores per 1 GHz on several machines.
I had a 2GHz server configured, went to the advanced tab and set it to 10 cores. When I clicked “save” it gave me an error explaining that it’s 1 core per GHz minimum. Maybe you started your instance before they implemented this limitation. Better not reboot!!
FWIW, I wanted a CLI benchmarking tool, so I used some dd tests and unixbench. Here’s what I got on a 2GB RAM 2.0GHz CPU manually set to 2 cores using their default CentOS6 server instance (preinstalled by them) at their Las Vegas center:
I don’t know what I’m doing so don’t give too much weight to these (just scraped them together from surfing the net).
dd if=/dev/zero of=test bs=16k count=64k conv=fdatasync; dd if=test of=/dev/null bs=16k count=64k iflag=direct; rm -f test
65536+0 records in
65536+0 records out
1073741824 bytes (1.1 GB) copied, 10.0773 s, 107 MB/s
65536+0 records in
65536+0 records out
1073741824 bytes (1.1 GB) copied, 21.6251 s, 49.7 MB/s
dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync; dd if=test of=/dev/null bs=64k count=16k iflag=direct; rm -f test
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 10.256 s, 105 MB/s
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 6.05759 s, 177 MB/s
# # # # # # # ##### ###### # # #### # #
# # ## # # # # # # # ## # # # # #
# # # # # # ## ##### ##### # # # # ######
# # # # # # ## # # # # # # # # #
# # # ## # # # # # # # ## # # # #
#### # # # # # ##### ###### # # #### # #
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
2 x Dhrystone 2 using register variables 1 2 3 4 5 6 7 8 9 10
2 x Double-Precision Whetstone 1 2 3 4 5 6 7 8 9 10
2 x Execl Throughput 1 2 3
2 x File Copy 1024 bufsize 2000 maxblocks 1 2 3
2 x File Copy 256 bufsize 500 maxblocks 1 2 3
2 x File Copy 4096 bufsize 8000 maxblocks 1 2 3
2 x Pipe Throughput 1 2 3 4 5 6 7 8 9 10
2 x Pipe-based Context Switching 1 2 3 4 5 6 7 8 9 10
2 x Process Creation 1 2 3
2 x System Call Overhead 1 2 3 4 5 6 7 8 9 10
2 x Shell Scripts (1 concurrent) 1 2 3
2 x Shell Scripts (8 concurrent) 1 2 3
========================================================================
BYTE UNIX Benchmarks (Version 5.1.3)
System: host.cloudsigma.com: GNU/Linux
OS: GNU/Linux — 2.6.32-71.29.1.el6.x86_64 — #1 SMP Mon Jun 27 19:49:27 BST 2011
Machine: x86_64 (x86_64)
Language: en_US.utf8 (charmap=”UTF-8″, collate=”UTF-8″)
CPU 0: AMD Opteron(tm) Processor 6176 (4600.9 bogomips)
Hyper-Threading, x86-64, MMX, AMD MMX, Physical Address Ext, SYSCALL/SYSRET
CPU 1: AMD Opteron(tm) Processor 6176 (4600.9 bogomips)
Hyper-Threading, x86-64, MMX, AMD MMX, Physical Address Ext, SYSCALL/SYSRET
00:45:43 up 1 min, 1 user, load average: 0.22, 0.08, 0.03; runlevel 3
————————————————————————
Benchmark Run: Tue Jan 31 2012 00:45:43 – 01:13:38
2 CPUs in system; running 1 parallel copy of tests
Dhrystone 2 using register variables 19157922.8 lps (10.0 s, 7 samples)
Double-Precision Whetstone 1994.2 MWIPS (9.9 s, 7 samples)
Execl Throughput 1622.0 lps (29.6 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 538034.5 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 161926.9 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 957765.0 KBps (30.0 s, 2 samples)
Pipe Throughput 898479.2 lps (10.0 s, 7 samples)
Pipe-based Context Switching 9231.5 lps (10.0 s, 7 samples)
Process Creation 2631.7 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 3074.5 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 626.6 lpm (60.0 s, 2 samples)
System Call Overhead 1537692.0 lps (10.0 s, 7 samples)
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 19157922.8 1641.6
Double-Precision Whetstone 55.0 1994.2 362.6
Execl Throughput 43.0 1622.0 377.2
File Copy 1024 bufsize 2000 maxblocks 3960.0 538034.5 1358.7
File Copy 256 bufsize 500 maxblocks 1655.0 161926.9 978.4
File Copy 4096 bufsize 8000 maxblocks 5800.0 957765.0 1651.3
Pipe Throughput 12440.0 898479.2 722.3
Pipe-based Context Switching 4000.0 9231.5 23.1
Process Creation 126.0 2631.7 208.9
Shell Scripts (1 concurrent) 42.4 3074.5 725.1
Shell Scripts (8 concurrent) 6.0 626.6 1044.3
System Call Overhead 15000.0 1537692.0 1025.1
========
System Benchmarks Index Score 575.9
————————————————————————
Benchmark Run: Tue Jan 31 2012 01:13:38 – 01:41:36
2 CPUs in system; running 2 parallel copies of tests
Dhrystone 2 using register variables 38245958.7 lps (10.0 s, 7 samples)
Double-Precision Whetstone 3992.7 MWIPS (9.9 s, 7 samples)
Execl Throughput 3825.3 lps (29.7 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 320291.1 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 78473.3 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 751060.1 KBps (30.0 s, 2 samples)
Pipe Throughput 1798479.1 lps (10.0 s, 7 samples)
Pipe-based Context Switching 329030.0 lps (10.0 s, 7 samples)
Process Creation 9650.2 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 4955.1 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 649.6 lpm (60.1 s, 2 samples)
System Call Overhead 1689428.1 lps (10.0 s, 7 samples)
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 38245958.7 3277.3
Double-Precision Whetstone 55.0 3992.7 725.9
Execl Throughput 43.0 3825.3 889.6
File Copy 1024 bufsize 2000 maxblocks 3960.0 320291.1 808.8
File Copy 256 bufsize 500 maxblocks 1655.0 78473.3 474.2
File Copy 4096 bufsize 8000 maxblocks 5800.0 751060.1 1294.9
Pipe Throughput 12440.0 1798479.1 1445.7
Pipe-based Context Switching 4000.0 329030.0 822.6
Process Creation 126.0 9650.2 765.9
Shell Scripts (1 concurrent) 42.4 4955.1 1168.6
Shell Scripts (8 concurrent) 6.0 649.6 1082.7
System Call Overhead 15000.0 1689428.1 1126.3
========
System Benchmarks Index Score 1026.2
whoa! Nice!
This test is useful if you repeat it on the same setup with just one core; so we can compare.
Good job!
Same server running with one core. Looks like only a little better than the lower scoring core when testing with 2 cores. That’s no good (but what do I know). I ran these tests more than once and every time the numbers were very similar. What’s your expert analysis? Running 2 cores seems like a good option to me.
# # # # # # # ##### ###### # # #### # #
# # ## # # # # # # # ## # # # # #
# # # # # # ## ##### ##### # # # # ######
# # # # # # ## # # # # # # # # #
# # # ## # # # # # # # ## # # # #
#### # # # # # ##### ###### # # #### # #
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: host.cloudsigma.com: GNU/Linux
OS: GNU/Linux — 2.6.32-71.29.1.el6.x86_64 — #1 SMP Mon Jun 27 19:49:27 BST 2011
Machine: x86_64 (x86_64)
Language: en_US.utf8 (charmap=”UTF-8″, collate=”UTF-8″)
CPU 0: AMD Opteron(tm) Processor 6176 (4600.9 bogomips)
x86-64, MMX, AMD MMX, Physical Address Ext, SYSCALL/SYSRET
05:01:35 up 1 min, 1 user, load average: 0.27, 0.09, 0.03; runlevel 3
————————————————————————
Benchmark Run: Tue Jan 31 2012 05:01:35 – 05:29:30
1 CPU in system; running 1 parallel copy of tests
Dhrystone 2 using register variables 19374115.0 lps (10.0 s, 7 samples)
Double-Precision Whetstone 2003.6 MWIPS (9.9 s, 7 samples)
Execl Throughput 2418.5 lps (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 550688.1 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 171909.9 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 1024326.0 KBps (30.0 s, 2 samples)
Pipe Throughput 1056539.5 lps (10.0 s, 7 samples)
Pipe-based Context Switching 220444.7 lps (10.0 s, 7 samples)
Process Creation 5778.0 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 2892.4 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 378.4 lpm (60.1 s, 2 samples)
System Call Overhead 1572710.1 lps (10.0 s, 7 samples)
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 19374115.0 1660.2
Double-Precision Whetstone 55.0 2003.6 364.3
Execl Throughput 43.0 2418.5 562.4
File Copy 1024 bufsize 2000 maxblocks 3960.0 550688.1 1390.6
File Copy 256 bufsize 500 maxblocks 1655.0 171909.9 1038.7
File Copy 4096 bufsize 8000 maxblocks 5800.0 1024326.0 1766.1
Pipe Throughput 12440.0 1056539.5 849.3
Pipe-based Context Switching 4000.0 220444.7 551.1
Process Creation 126.0 5778.0 458.6
Shell Scripts (1 concurrent) 42.4 2892.4 682.2
Shell Scripts (8 concurrent) 6.0 378.4 630.7
System Call Overhead 15000.0 1572710.1 1048.5
========
System Benchmarks Index Score 813.5
So, it is definitely better with 2 cores
This is very helpful! Thanks a lot, Juenca!
And thanks to you! Cheers!
OTOH! The previous tests were at Las Vegas. I signed up for a Zurich test account and got some discouraging results. The processors at Zurich appear to be 2.2GHz, while at Las Vegas 2.3GHz, but the bigger difference is that Las Vegas is a new location for CloudSigma and they don’t appear to have sold much of their capacity yet. This is verified by looking at their WHOIS data and poking around in some other places that show the IPs from Zurich have been used and developed more reputation.
I have so far run two benchmark tests with a 2GHz instance using 2 cores both in the middle of the day and mid-evening (local time) and the MUCH more disappointing performace can be seen below.
Oh, and disk speed is also reduced – by as much as half in some tests. This could be caused by the fact that due to having a higher usage, my server instance wasn’t on the same machine as my disk (whereas in Las Vegas, it probably was).
I’ll try to run a couple more tests, but buyer beware.
# # # # # # # ##### ###### # # #### # #
# # ## # # # # # # # ## # # # # #
# # # # # # ## ##### ##### # # # # ######
# # # # # # ## # # # # # # # # #
# # # ## # # # # # # # ## # # # #
#### # # # # # ##### ###### # # #### # #
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
2 x Dhrystone 2 using register variables 1 2 3 4 5 6 7 8 9 10
2 x Double-Precision Whetstone 1 2 3 4 5 6 7 8 9 10
2 x Execl Throughput 1 2 3
2 x File Copy 1024 bufsize 2000 maxblocks 1 2 3
2 x File Copy 256 bufsize 500 maxblocks 1 2 3
2 x File Copy 4096 bufsize 8000 maxblocks 1 2 3
2 x Pipe Throughput 1 2 3 4 5 6 7 8 9 10
2 x Pipe-based Context Switching 1 2 3 4 5 6 7 8 9 10
2 x Process Creation 1 2 3
2 x System Call Overhead 1 2 3 4 5 6 7 8 9 10
2 x Shell Scripts (1 concurrent) 1 2 3
2 x Shell Scripts (8 concurrent) 1 2 3
========================================================================
BYTE UNIX Benchmarks (Version 5.1.3)
System: cloudsigma: GNU/Linux
OS: GNU/Linux — 2.6.32-220.el6.x86_64 — #1 SMP Tue Dec 6 19:48:22 GMT 2011
Machine: x86_64 (x86_64)
Language: en_US.utf8 (charmap=”UTF-8″, collate=”UTF-8″)
CPU 0: AMD Opteron(tm) Processor 6174 (4400.7 bogomips)
Hyper-Threading, x86-64, MMX, AMD MMX, Physical Address Ext, AMD virtualization, SYSCALL/SYSRET
CPU 1: AMD Opteron(tm) Processor 6174 (4400.7 bogomips)
Hyper-Threading, x86-64, MMX, AMD MMX, Physical Address Ext, AMD virtualization, SYSCALL/SYSRET
10:51:19 up 3:43, 1 user, load average: 0.16, 0.06, 0.11; runlevel 3
————————————————————————
Benchmark Run: Tue Jan 31 2012 10:51:19 – 11:20:19
2 CPUs in system; running 1 parallel copy of tests
Dhrystone 2 using register variables 8896121.7 lps (10.0 s, 7 samples)
Double-Precision Whetstone 1306.6 MWIPS (9.7 s, 7 samples)
Execl Throughput 1165.3 lps (29.8 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 186014.0 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 60888.2 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 373331.4 KBps (30.0 s, 2 samples)
Pipe Throughput 451685.8 lps (10.0 s, 7 samples)
Pipe-based Context Switching 7869.9 lps (10.0 s, 7 samples)
Process Creation 2096.9 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 1419.0 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 239.1 lpm (60.1 s, 2 samples)
System Call Overhead 693189.6 lps (10.0 s, 7 samples)
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 8896121.7 762.3
Double-Precision Whetstone 55.0 1306.6 237.6
Execl Throughput 43.0 1165.3 271.0
File Copy 1024 bufsize 2000 maxblocks 3960.0 186014.0 469.7
File Copy 256 bufsize 500 maxblocks 1655.0 60888.2 367.9
File Copy 4096 bufsize 8000 maxblocks 5800.0 373331.4 643.7
Pipe Throughput 12440.0 451685.8 363.1
Pipe-based Context Switching 4000.0 7869.9 19.7
Process Creation 126.0 2096.9 166.4
Shell Scripts (1 concurrent) 42.4 1419.0 334.7
Shell Scripts (8 concurrent) 6.0 239.1 398.4
System Call Overhead 15000.0 693189.6 462.1
========
System Benchmarks Index Score 293.0
————————————————————————
Benchmark Run: Tue Jan 31 2012 11:20:19 – 11:48:50
2 CPUs in system; running 2 parallel copies of tests
Dhrystone 2 using register variables 15239235.9 lps (10.0 s, 7 samples)
Double-Precision Whetstone 2531.2 MWIPS (7.6 s, 7 samples)
Execl Throughput 1638.4 lps (29.5 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 235258.1 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 84530.2 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 510697.3 KBps (30.0 s, 2 samples)
Pipe Throughput 803628.6 lps (10.0 s, 7 samples)
Pipe-based Context Switching 166824.5 lps (10.0 s, 7 samples)
Process Creation 3969.0 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 1740.8 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 273.7 lpm (60.2 s, 2 samples)
System Call Overhead 1004768.5 lps (10.0 s, 7 samples)
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 15239235.9 1305.8
Double-Precision Whetstone 55.0 2531.2 460.2
Execl Throughput 43.0 1638.4 381.0
File Copy 1024 bufsize 2000 maxblocks 3960.0 235258.1 594.1
File Copy 256 bufsize 500 maxblocks 1655.0 84530.2 510.8
File Copy 4096 bufsize 8000 maxblocks 5800.0 510697.3 880.5
Pipe Throughput 12440.0 803628.6 646.0
Pipe-based Context Switching 4000.0 166824.5 417.1
Process Creation 126.0 3969.0 315.0
Shell Scripts (1 concurrent) 42.4 1740.8 410.6
Shell Scripts (8 concurrent) 6.0 273.7 456.2
System Call Overhead 15000.0 1004768.5 669.8
========
System Benchmarks Index Score 542.6
whoa! good job!
So, yeah; basically, the performance in ZRH is half of the LVS region. Hmm… let’s report this to them; maybe they can do something about it.
Hey, Juenca,
Robert, CloudSigma co-founder, read this and he replied:
“Hi Renich,
My feedback would be that this is basically because the system he tested in Zurich had a drive on a different machine to his CPU/RAM. As you know the current set-up runs on local disk so that makes a very big difference to performance. As you know we are transitioning away from a local disk set-up in the near future (all things being well from you!) so this kind of performance difference will go away.
We don’t content resources heavily so the difference is coming from this not the fact that it is overloaded.”
So, there you have it
Thanks for re-posting that.
So it seem my guess was right – they have more customers in Zurich so you have less chance to have disk & cpu on same machine. I have rebooted lotta times (allow possibility for instances to move) in past few days and continued benchmarks, and Zurich’s performance is consistently only 50% of Las Vegas.
If I keep getting this difference consistently then it seem to argue that even if they are not over-committed, they are at least more busy/sold out in Zurich. I hope they solve this problem soon.
But I don’t buy Robert response 100% because aren’t some of the unixbench tests pure CPU test? I really doubt ALL of the tests are dependent on file I/O. I’d like to hear Robert respond directly to this.
What do you think about that point? I am guess that because KVM doesn’t limit upward CPU resource that this is also a result of that they have few customers yet in Las Vegas and their Zurich machines are heavily used. They may or may not be over-committed, but maybe the performance I’m seeing there is the more realistic view of what they provide as “2 core-GHz” (which is disappointingly slow to me).
I guess once they fill up customers in Las Vegas, it will be the same.
About their solution, I was reading about their infrastructure, and it seems to make a point that they pride themselves on NOT using a SAN storage solution, since that’s both a bottleneck that so many providers have, AND it’s a single point of failure. So if now they move to non-local storage, will it be SAN? Do they have any details about this? I hope for the best they can make it lots better.
Any chance you pass along some of these thoughts to him?
Dear Juenca,
In general the performance of CloudSigma is better than most public IaaS clouds out there. Of course the performance level you see can vary depending on your specific use case. It sounds like you are running benchmarks which tells you how well benchmarks run in our cloud but nothing else. The fit between them and actually how people use our cloud is very poor (see http://www.cloudsigma.com/en/blog/2010/08/28/9-cloud-server-benchmarking ). We actually have a number of HPC users using our cloud in Zurich (which you say is lower performance) without issues.
Real world sites that monitor us report very good performance. A good exmple is https://www.cloudsleuth.net/web/guest/global-provider-view . They are running a web server in our cloud, if you select Europe you can see
You are correct that with KVM you can get additional CPU if it is available on the host machine and this is a free bonus. In general we like to talk about price/performance. Actually really what customers care about is, for $XX how much work can I get done? What that equates to in raw materials isn’t in itself important as long as price/performance stacks up against the alternatives well. Bundling makes that quite difficult to achieve. That’s why we advise finding the right resource combination for your servers in CloudSigma then comparing against what you need to purchase to match that in terms of performance elsewhere. You can then factor back in price and compare successfully.
In terms of your comments regarding SAN, no we won’t move to using a SAN for the reasons you suggest, we will use a distributed system but we won’t be disclosing the details for competitive reasons. It won’t have a single point of failure and will be high availability as oppose to the local storage solution we use now. It will offer a major step up in terms of performance too so we are quite excited about rolling this out later this year.
btw, u host in which region? your main services run on 4GHz?
Well, I have a server with as much as 4 GHz and 4 GB or RAM. It’s for MySQL and it works wonders.
Normally, I use 2 Ghz and 2-4 GB or RAM.
I like setting up the system with LVM; installing / and /user on SSD. The rest, on magnetic drives.
I get incredible performance with a setup like this.
Currently, I have most servers on ZRH. I have a few in LVS and they, both, work incredible. The ZRH network rules IMHO. And, yeah, LVS’ hardware rules as well.
About the storage; yeah, they don’t use SAN. I have no clearance on talking about the solution being implemented so I can just tell you it definitely rules. It’s not SAN anyway… but it still rules
As you might have guessed, I am consulting for them these days.
Thank for your information. Do you encrypt all your disks (do you see fast performance even with a 15% performance hit for encryption)?
I’m glad for the secret new storage system and I hope coming soon for all users!
I just a little sad that CPU is so much slow in Zurich (and I think, unrelated to disks).
thankk you once again!!
Nah, I don’t use encryption. SELinux is enough for me
You know, regarding CPU, would it be too much to ask you to contact support and ask them to migrate your servers? I really am confused since I have some servers in Zürich and they work pretty well!
Thank you for suggestion. Thier docs say I can do that myself by cloning a drive – forces it to a different machine. Not guaranteed to boot on that machine but that’s the first try. So I played that and I can see the mobo UUID is different so I think I’m on different machine now so I ran benchmarks —
Yes, in fact the speed is better on this other machine. Still not what Las Vegas gives though. Basically a small boost — like I get nighttime speeds during the daytime. That according to few benchmarks over the day.
So better/more promising, but it still not good for customers if we have to guess about what server will perform better than another one! I like lot CloudSigma but this seems big problem to me.
And I read about some of the benchmarks in unixbench and I think true that Drystone and Whetstone only test CPU power so Robert claim that scores were so lower because of I/O problems is avoiding the issue.
Hope for very best I/O solution but looks like they might need to review CPU performance too?