Bekijk Volledige Versie : TransIP Linux VPS Performance
Collega's,
Sinds kort werken wij, naast Windows en Linux VPS'en op XenServer, met enkele gehuurde VPS'en van TransIP.
Daarop draaien enkele Joomla- en Wordpress sites van klanten.
Het betreft een CentOS 6 server met DirectAdmin 1.39.3, met 2 cores en 1 GB geheugen.
Niet bijzonder qua specs, maar dit is altijd te wijzigen. Vooralsnog draaien op deze specifieke server slecht 5 Joomla en 1 Wordpress sites, die qua bezoekersaantallen minimaal zijn.
Op deze server krijg ik regelmatig de melding dat de HTTP server is weggevallen (Standaard Apache). Het valt op, dat dit telkens precies 5 minuten betreft. Verder krijg ik, meestal op andere tijden de melding "The system load average is 13.92" (ook wel eens rond de 20 of 25). Als ik dan direct op het systeem kijk, is alles natuurlijk weer rustig :rolleyes:
Het lijkt er dus op dat eén of ander proces de HTTP server regelmatig onderuit haalt. De specs van de server lijken mij niet erg ondergespecificeerd met die paar rustige sites.
Herkent iemand dit, of hebben jullie een tip voor logging die het probleem kan meten? Op mijn 2 andere Linux VPS'en met dezelfde specs, heb ik dit probleem niet. En opnieuw inspoelen vind ik te makkelijk :rolleyes:
Een klant van ons is juist weggegaan bij Transip door bovenstaand probleem. De iops willen wel eens traag zijn wat tot bovenstaande problemen kan resulteren. Ik zeg niet dat dat bij jou het geval is maar het is vaker voorgekomen.
systemdeveloper
19/11/12, 16:42
De iops zijn daar inderdaad niet bepaald indrukwekkend :(
Alhoewel een hdparm oid niet extreem slecht uit de bus komt 'voelt' het wel aan alsof je door de modder aan het lopen bent.
Edit: die hdparm is ongeveer 20% van wat we zelf op de vpssen hebben zie ik net, dus eigenlijk is dat toch wel een beetje extreem slow daar... :(
Zelf zit ik ook bij TransIP en heb eigenlijk geen last van dit probleem. Kan iemand mij een linkje of shell script sturen waarmee ik deze test kan runnen? Ben eigenlijk wel benieuwd wat de uitslag is.
systemdeveloper
19/11/12, 17:00
man hdparm ;)
of http://www.php-benchmark-script.com/
Mijn technische kennis is niet toereikend om hdparm te draaien (al zeg ik het zelf).
De uitslag van de PHP benchmark is:
--------------------------------------
| PHP BENCHMARK SCRIPT |
--------------------------------------
Start : 2012-11-19 17:05:28
Server : -
PHP version : 5.3.18
Platform : Linux
--------------------------------------
test_Math : 2.259 sec.
test_StringManipulation : 1.899 sec.
test_Loops : 1.746 sec.
test_IfElse : 1.716 sec.
--------------------------------------
Total time: : 7.62 sec.
--------------------------------------
| PHP BENCHMARK SCRIPT |
--------------------------------------
Start : 2012-11-19 17:05:36
Server : -
PHP version : 5.3.18
Platform : Linux
--------------------------------------
test_Math : 2.514 sec.
test_StringManipulation : 2.279 sec.
test_Loops : 1.730 sec.
test_IfElse : 1.030 sec.
--------------------------------------
Total time: : 7.553 sec.
VPS heeft 2 cores, 1GB ram, 100GB hdd
CeeReM.com
19/11/12, 17:21
/sbin/hdparm -t /dev/sda
systemdeveloper
19/11/12, 17:44
voor de iops moet je iets als hdparm / seeker.c gebruiken, al zegt dat ook niet alles.
http://learnitwithme.com/?page_id=267 (http://learnitwithme.com/?p=272)
SeekMark
SeekMark – a threaded random I/O tester, designed to test the number of seeks and hence get a rough idea of the access time of a disk and the number of iops it can perform . It was loosely inspired by the ‘seeker’ program (http://www.linuxinsight.com/how_fast_is_your_disk.html), when it was noticed that the results from seeker were very much the same for a RAID array as for a single disk, and a look at the code showed that it was doing one random read at a time, basically only triggering access to one drive and waiting for that to complete before continuing. What we want to see is not only the performance of a single spindle, but how much benefit we get on random reads as we add spindles.This pretty much only works on systems that allow you to open disks as files, although it’s written such that you can test against regular files. As long as the file is sufficiently large (a couple of gigs), I get pretty much the same results when testing against a file, partition, or whole disk. The file of course could also be fragmented, helping our cause somewhat.
Version 0.9 gains some functionality that allows it to be used as a quick and dirty random I/O generator. Seekmark does a good job of pounding your disk as hard as possible in all-or-nothing fashion, but now you can specify a delay to insert between seeks to reduce the load, in order to simulate some scenario. For example you may want to test performance of some other application while the system is semi-busy doing random I/O on a database file, or you may want to test shared storage between multiple hosts where one host has 4 processes doing 64k random reads every 20ms and another host has 2 processes, one doing busy 4k random writes as fast as possible and the other doing 128k reads every 50ms. With this, is a new -e option, that runs seekmark in endless mode. That is, it will simply run until it’s killed.re reference. I’d appreciate hearing results/feedback if anyone out there gives it a try.
Ik heb eenzelfde VPS bij TransIP, maar niets aan te merken op de snelheid in vergelijking met de prijs.
[root@shell ~]# ./seeker /dev/vda
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/vda [102400MB], wait 30 seconds..............................
Results: 48 seeks/second, 20.51 ms random access time
[root@shell ~]# hdparm -tT /dev/vda
/dev/vda:
Timing cached reads: 7730 MB in 2.00 seconds = 3867.39 MB/sec
Timing buffered disk reads: 220 MB in 3.01 seconds = 73.17 MB/sec
--------------------------------------
| PHP BENCHMARK SCRIPT |
--------------------------------------
Start : 2012-11-19 18:35:51
Server : @
PHP version : 5.4.8
Platform : Linux
--------------------------------------
test_math : 1.406 sec.
test_stringmanipulation : 1.435 sec.
test_loops : 0.875 sec.
test_ifelse : 0.943 sec.
--------------------------------------
Total time: : 4.659 sec.
[root@shell ~]# php -v
PHP 5.4.8 (cli) (built: Oct 20 2012 23:39:19)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
systemdeveloper
19/11/12, 18:59
Ik heb eenzelfde VPS bij TransIP, maar niets aan te merken op de snelheid in vergelijking met de prijs.
[root@shell ~]# ./seeker /dev/vda
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/vda [102400MB], wait 30 seconds..............................
Results: 48 seeks/second, 20.51 ms random access time
[root@shell ~]# hdparm -tT /dev/vda
/dev/vda:
Timing cached reads: 7730 MB in 2.00 seconds = 3867.39 MB/sec
Timing buffered disk reads: 220 MB in 3.01 seconds = 73.17 MB/sec
# ./seeker /dev/vda
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/vda [10240MB], wait 30 seconds.............................
Results: 158 seeks/second, 6.33 ms random access time
# hdparm -tT /dev/vda
/dev/vda:
Timing cached reads: 9374 MB in 2.00 seconds = 4695.65 MB/sec
Timing buffered disk reads: 68 MB in 3.04 seconds = 22.38 MB/sec
Ik zou zeggen... resultaten slaan als een tang op een varken ;)
Bedankt voor de reacties tot zover. Zal die benchmark morgen eens draaien.
Zit net de logs te bekijken en daar gaat mogelijk iets mis met de swapfile. Wat denken jullie?
Nov 19 17:52:42 qh-lxvps003 kernel: [<ffffffff81150db3>] alloc_pages_vma+0x93/0x150
Nov 19 17:52:42 qh-lxvps003 kernel: [<ffffffff81144fb9>] read_swap_cache_async+0xe9/0x140
Nov 19 17:52:42 qh-lxvps003 kernel: [<ffffffff811459c9>] ? valid_swaphandles+0x69/0x160
Nov 19 17:52:42 qh-lxvps003 kernel: [<ffffffff81145097>] swapin_readahead+0x87/0xc0
Nov 19 17:52:42 qh-lxvps003 kernel: [<ffffffff811361ca>] handle_pte_fault+0x71a/0xad0
Nov 19 17:52:42 qh-lxvps003 kernel: [<ffffffff8103cd18>] ? pvclock_clocksource_read+0x58/0xd0
Nov 19 17:52:42 qh-lxvps003 kernel: [<ffffffff81059e02>] ? finish_task_switch+0x42/0xd0
Nov 19 17:52:42 qh-lxvps003 kernel: [<ffffffff8113676d>] handle_mm_fault+0x1ed/0x2b0
Nov 19 17:52:42 qh-lxvps003 kernel: [<ffffffff814c92b6>] ? thread_return+0x4e/0x778
Nov 19 17:52:42 qh-lxvps003 kernel: [<ffffffff814ce503>] do_page_fault+0x123/0x3a0
Nov 19 17:52:42 qh-lxvps003 kernel: [<ffffffff814cbf75>] page_fault+0x25/0x30
Nov 19 17:52:42 qh-lxvps003 kernel: Mem-Info:
Nov 19 17:52:42 qh-lxvps003 kernel: Node 0 DMA per-cpu:
Nov 19 17:52:42 qh-lxvps003 kernel: CPU 0: hi: 0, btch: 1 usd: 0
Nov 19 17:52:42 qh-lxvps003 kernel: CPU 1: hi: 0, btch: 1 usd: 0
Nov 19 17:52:42 qh-lxvps003 kernel: Node 0 DMA32 per-cpu:
Nov 19 17:52:42 qh-lxvps003 kernel: CPU 0: hi: 186, btch: 31 usd: 166
Nov 19 17:52:42 qh-lxvps003 kernel: CPU 1: hi: 186, btch: 31 usd: 178
Nov 19 17:52:42 qh-lxvps003 kernel: active_anon:98219 inactive_anon:98065 isolated_anon:672
Nov 19 17:52:42 qh-lxvps003 kernel: active_file:92 inactive_file:366 isolated_file:32
Nov 19 17:52:42 qh-lxvps003 kernel: unevictable:4 dirty:0 writeback:139 unstable:0
Nov 19 17:52:42 qh-lxvps003 kernel: free:12634 slab_reclaimable:2750 slab_unreclaimable:14363
Nov 19 17:52:42 qh-lxvps003 kernel: mapped:125 shmem:22 pagetables:21116 bounce:0
Nov 19 17:52:42 qh-lxvps003 kernel: Node 0 DMA free:4940kB min:668kB low:832kB high:1000kB active_anon:2480kB inactive_anon:1864kB active_file:36kB inactive_file:348kB unevictable:0kB isolated(anon):2048kB isolated(file):128kB present:15368kB mlocked:0kB dirty:0kB writeback:196kB mapped:48kB shmem:0kB slab_reclaimable:64kB slab_unreclaimable:460kB kernel_stack:80kB pagetables:2696kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:5380 all_unreclaimable? no
Nov 19 17:52:42 qh-lxvps003 kernel: lowmem_reserve[]: 0 994 994 994
Nov 19 17:52:42 qh-lxvps003 kernel: Node 0 DMA32 free:45596kB min:44384kB low:55480kB high:66576kB active_anon:390396kB inactive_anon:390396kB active_file:332kB inactive_file:996kB unevictable:16kB isolated(anon):640kB isolated(file):128kB present:1018072kB mlocked:16kB dirty:0kB writeback:360kB mapped:452kB shmem:88kB slab_reclaimable:10936kB slab_unreclaimable:56992kB kernel_stack:4088kB pagetables:81768kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:15136 all_unreclaimable? no
Nov 19 17:52:42 qh-lxvps003 kernel: lowmem_reserve[]: 0 0 0 0
Nov 19 17:52:42 qh-lxvps003 kernel: Node 0 DMA: 51*4kB 322*8kB 6*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 4924kB
Nov 19 17:52:42 qh-lxvps003 kernel: Node 0 DMA32: 391*4kB 2536*8kB 278*16kB 31*32kB 4*64kB 1*128kB 2*256kB 2*512kB 2*1024kB 5*2048kB 1*4096kB = 45596kB
Nov 19 17:52:42 qh-lxvps003 kernel: 27826 total pagecache pages
Nov 19 17:52:42 qh-lxvps003 kernel: 27238 pages in swap cache
Nov 19 17:52:42 qh-lxvps003 kernel: Swap cache stats: add 101802578, delete 101775340, find 20829040/32167107
Nov 19 17:52:42 qh-lxvps003 kernel: Free swap = 0kB
Nov 19 17:52:42 qh-lxvps003 kernel: Total swap = 2097144kB
Nov 19 17:52:42 qh-lxvps003 kernel: 262141 pages RAM
Nov 19 17:52:42 qh-lxvps003 kernel: 6797 pages reserved
Nov 19 17:52:42 qh-lxvps003 kernel: 95523 pages shared
Nov 19 17:52:42 qh-lxvps003 kernel: 232938 pages non-shared
Nov 19 17:52:42 qh-lxvps003 kernel: Out of memory: kill process 31153 (httpd) score 214737 or a child
Nov 19 17:52:42 qh-lxvps003 kernel: Killed process 15385 (httpd) vsz:216460kB, anon-rss:1740kB, file-rss:108kB
Voelt als een mysql die iets te veel ruimte krijgt volgens zijn conf
Op een vm wil je geen swap partition hebben naar mijn mening, dit gaat je overall performance nekken/killen namelijk. De melding die je ziet geeft simpelweg een OOM (out of memory) error weer.
Voor een goed memory overzicht: free -m
Je kan dan zien hoeveel memory er allocated is en hoeveel swap.
Bij mij kwam dit eruit
# hdparm -tT /dev/vda3
/dev/vda3:
Timing cached reads: 9220 MB in 2.00 seconds = 4617.06 MB/sec
Timing buffered disk reads: 218 MB in 3.00 seconds = 72.56 MB/sec
Is toch wel een degelijke prestatie naar mijn menig..
Misschien leuk als meer mensen de output posten en vermelden of dit wel of niet bij TransIP is.
netrouting vps:
[root@server ~]# ./seeker /dev/xvda1
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/xvda1 [81920MB], wait 30 seconds..............................
Results: 106 seeks/second, 9.42 ms random access time
[root@server ~]# hdparm -tT /dev/xvda1
/dev/xvda1:
Timing cached reads: 5984 MB in 1.99 seconds = 3002.90 MB/sec
Timing buffered disk reads: 312 MB in 3.01 seconds = 103.52 MB/sec
yourwebhoster:
root@vps:~# ./seeker /dev/xvda1
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/xvda1 [20480MB], wait 30 seconds.............................
Results: 128 seeks/second, 7.80 ms random access time
root@vps:~# hdparm -tT /dev/xvda1
/dev/xvda1:
Timing cached reads: 15356 MB in 1.99 seconds = 7717.86 MB/sec
Timing buffered disk reads: 1042 MB in 3.01 seconds = 346.56 MB/sec
directvps basic:
vps:~# ./seeker /dev/xvda1
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/xvda1 [1024MB], wait 30 seconds.............................
Results: 142 seeks/second, 7.03 ms random access time
vps:~# hdparm -tT /dev/xvda1
/dev/xvda1:
Timing cached reads: 6294 MB in 2.05 seconds = 3074.29 MB/sec
Timing buffered disk reads: 272 MB in 3.01 seconds = 90.33 MB/sec
SinnerG, VPS met HA storage.
root@vps19:~# ./seeker /dev/vda
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/vda [47683MB], wait 30 seconds..............................
Results: 102 seeks/second, 9.78 ms random access time
root@vps19:~# hdparm -tT /dev/vda
/dev/vda:
Timing cached reads: 4704 MB in 2.00 seconds = 2353.32 MB/sec
Timing buffered disk reads: 190 MB in 3.03 seconds = 62.70 MB/sec
SebastiaanStok
20/11/12, 09:26
Domme vraag, maar heb je de accesss time wel uitgeschakeld :)
http://www.cyberciti.biz/faq/linux-noatime-ext3-ext4-fstab-configuration/
Zonder noatime gaat hij voor ieder bestand bijhouden wanneer het voor het laatst is opgevraagd.
Wil niet zeggen dat het probleem oplost, maar vele kleintjes maken één grote.
Bedankt Sebastiaan, ga ik ook even proberen.
Misschien dat ik toch maar weer aan mijn oorsponkelijke idee ga denken, een HP DL360 (die ik nog heb staan) met 2x QC in het rack hangen en daar met iSCSI een Iomega/EMC NAS van 4 TB koppelen en daar wat Linux VM's op plaatsen.
Heb ik in ieder geval zelf de performance in handen :nono:
systemdeveloper
20/11/12, 10:12
Niet echt eerlijk, maar vergeleken met een ssd dedi zijn alle vpssen toch maar zo-zo, de NICs zijn toch meestal de performance brekers wat throughput betreft en de storages wat iops betreft: (imho is die throughput niet eens erg spannend... leuk als je iet wilt kopieeren maar dat is zelden een hoofddoel op een server, IOPS, IOPS, IOPS!!!)
# hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 22264 MB in 2.00 seconds = 11149.34 MB/sec
Timing buffered disk reads: 500 MB in 0.54 seconds = 918.33 MB/sec
# ./seeker /dev/sda
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [819200MB], wait 30 seconds..............................
Results: 1425922 seeks/second, 0.00 ms random access time
vpsje (2 NICs maar wel beetje druk):
# hdparm -tT /dev/xvda1
/dev/xvda1:
Timing cached reads: 20748 MB in 1.99 seconds = 10432.80 MB/sec
Timing buffered disk reads: 100 MB in 0.82 seconds = 121.43 MB/sec
./seeker /dev/xvda
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/xvda [51200MB], wait 30 seconds..............................
Results: 2426 seeks/second, 0.41 ms random access time
[root@xv035 ~]#
Mooie cijfers, 1425922 seeks/second ten opzichte van 2426 seeks/second, dat is inderdaad een wereld van verschil :thumbup:
PimEffting
20/11/12, 11:44
Wij hebben een tijdje geleden ook een klant gemigreerd vanaf een VPS bij TransIP naar managed hosting bij ons.
Probleem van de performance: standaard stond een screensaver geinstalleerd die 98% CPU cycles nodig had.
Misschien is bij jou ook zoiets "simpels" aan de hand?
T. Verhaeg
20/11/12, 15:08
VPS (platform 2 nics, MPIO) met nagenoeg volle Equallogic storage:
Seeker
./seeker /dev/sda
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [40960MB], wait 30 seconds..............................
Results: 285 seeks/second, 4.38 ms random access time
HDParm
hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 17880 MB in 1.99 seconds = 8977.04 MB/sec
Timing buffered disk reads: 100 MB in 0.85 seconds = 117.64 MB/sec
Hmmm, net even getest, best wel bagger qua IOPS:
./seeker /dev/xvda
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/vda [102400MB], wait 30 seconds..............................
Results: 188 seeks/second, 5.29 ms random access time
T. Verhaeg
20/11/12, 15:19
Hmmm, net even getest, best wel bagger qua IOPS:
./seeker /dev/xvda
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/vda [102400MB], wait 30 seconds..............................
Results: 188 seeks/second, 5.29 ms random access time
Het is niet heel slecht, zeker niet als je er andere resultaten in dit topic tegen afzet.
Andere disk is ook zoiets. Is inderdaad best gemiddeld, als ik even terugscrol in dit topic. Niet vergelijken met de Dedicated Servers ;)
Zou ik een betere performance dan deze TransIP VPS krijgen, met mijn XenServer met een NAS (StorCenter van Iomega) via iSCSI?
Dus nu, hoeveel IOPS verwacht je voor welke prijs. Even een referentie: een SATA disk doet ~75 IOPS, een SAS disk (10K) een ~140 IOPS en een SAS disk (15K) ongeveer 175. En dit zijn reële praktijkwaarden.
Mooi ook om te zien hoe SSD's een wéreld van verschil maken:
Antieke WD800JB
# ./seeker /dev/hda
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/hda [76319MB], wait 30 seconds..............................
Results: 71 seeks/second, 13.93 ms random access time
'Nieuw' hyper-v platform (SSD based)
# ./seeker /dev/sda
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda [102400MB], wait 30 seconds..............................
Results: 5168 seeks/second, 0.19 ms random access time
Mijn development VM:
[root@dev ~]# seeker /dev/vda1
Seeker v3.0, 2009-06-17, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/vda1 [31455207 blocks, 16105065984 bytes, 14 GB, 15358 MB, 16 GiB, 16105 MiB]
[512 logical sector size, 512 physical sector size]
[1 threads]
Wait 30 seconds..............................
Results: 1473 seeks/second, 0.679 ms random access time
[root@dev ~]# hdparm -tT /dev/vda1
/dev/vda1:
Timing cached reads: 13804 MB in 2.00 seconds = 6911.10 MB/sec
Timing buffered disk reads: 348 MB in 3.00 seconds = 115.82 MB/sec
jeroenedig
06/03/13, 16:34
Tot op heden heb ik nog geen probleem gehad met de VPS bij TransIP. Maar zal het nu zeker extra in de gaten houden.