Onderwerp: 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

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

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.

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.

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:

Code:

--------------------------------------
|        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

/sbin/hdparm -t /dev/sda

voor de iops moet je iets als hdparm / seeker.c gebruiken, al zegt dat ook niet alles.

http://learnitwithme.com/?page_id=267

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.

Code:

[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

Code:

--------------------------------------
|        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

Oorspronkelijk geplaatst door Randy

Ik heb eenzelfde VPS bij TransIP, maar niets aan te merken op de snelheid in vergelijking met de prijs.

Code:

[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

Code:

# ./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.