WN

WN (https://www.wn.se/forum/index.php)
-   Webbhotell (https://www.wn.se/forum/forumdisplay.php?f=13)
-   -   Dimensionera VPS (https://www.wn.se/forum/showthread.php?t=27029)

KPK 2008-02-10 01:28

Jag har nyligen öppnat ett VPS konto och är lite konfunderad av hur tillgängliga resurser snabbt tar slut. I nuläget är följande installerad på VPS-kontot:

Debian 4.0.
DirectAdmin kontrollpanel
Apache 2.2.8 Custombuild
MySQL
Dovecot
Exim
Antal användare: 1
Antal e-post/IMAP konto: 5
RAM: 512 MB

Antal sajter igång: knappt någon trafik alls eftersom utvecklingsarbete fortfarande pågar. Bara jag själv och den utvecklare som jag anlitar. Har en underdomän med lite undervisningsmaterial som har haft runt 100 besök.

Jag har haft återkommande problem med servern med processer som har gått ner. När jag hade 256MB RAM var det ju lite löjligt frekvent så jag följde supportens råd att uppgradera. Nu har det åter dykt upp problem, som jag kopplade ihop med ett stopp leverantören hade (för de dök ju enligt loggen upp precis då) men som supporten envist hävdar att det beror på att jag har för många processer igång och att minnet då inte räcker till.

Nu har jag ju en begränsad teknisk kompetens när det gäller linux, men jag får det inte riktigt ihop det. Kör jag top får jag följande:

Kod:

top - 00:47:02 up 5 days, 12:27, 1 user, load average: 0.44, 0.18, 0.04
Tasks: 92 total,  2 running, 90 sleeping,  0 stopped,  0 zombie
Cpu(s): 1.3%us, 1.3%sy, 0.0%ni, 96.7%id, 0.7%wa, 0.0%hi, 0.0%si, 0.0%st
Mem:  524288k total,  198612k used,  325676k free,    0k buffers
Swap:    0k total,    0k used,    0k free,    0k cached

 PID USER  PR NI VIRT RES SHR S %CPU %MEM  TIME+ COMMAND                 
 7708 user1  15  0 4784 2636 2180 S 1.7 0.5  0:11.97 imap                   
 9717 dovecot  15  0 3444 1720 1408 S 0.3 0.3  0:02.78 imap-login                 
  1 root  15  0 1952 664 564 S 0.0 0.1  0:01.94 init                   
 1925 user4  15  0 3320 1292 992 S 0.0 0.2  0:00.66 imap                   
 1930 dovecot  15  0 3444 1716 1408 S 0.0 0.3  0:00.57 imap-login                 
 3460 nobody  18  0 6540 272  64 S 0.0 0.1  0:00.00 directadmin               
 3462 nobody  18  0 6540 272  64 S 0.0 0.1  0:00.00 directadmin               
 3469 nobody  15  0 6540 272  64 S 0.0 0.1  0:00.00 directadmin               
 3470 nobody  16  0 6540 272  64 S 0.0 0.1  0:00.00 directadmin               
 3495 dovecot  15  0 3308 1496 1244 S 0.0 0.3  0:00.39 imap-login                 
 3517 nobody  15  0 6540 272  64 S 0.0 0.1  0:00.00 directadmin               
 3552 dovecot  15  0 3304 1492 1244 S 0.0 0.3  0:00.16 imap-login                 
 5140 user4  15  0 3436 1448 1104 S 0.0 0.3  0:00.27 imap                   
 5141 dovecot  15  0 3308 1496 1244 S 0.0 0.3  0:00.16 imap-login                 
 5220 root  15  0 7860 2556 1944 R 0.0 0.5  0:00.04 sshd                   
 5248 root  15  0 2796 1588 1192 S 0.0 0.3  0:00.00 bash                   
 7672 admin  18  0 3276 1212 936 S 0.0 0.2  0:01.01 imap                   
 7683 dovecot  15  0 3308 1496 1244 S 0.0 0.3  0:00.54 imap-login                 
 7684 dovecot  15  0 3304 1488 1244 S 0.0 0.3  0:00.60 imap-login                 
 7685 dovecot  15  0 3308 1496 1248 S 0.0 0.3  0:00.55 imap-login                 
 7688 user2  15  0 3328 1200 936 S 0.0 0.2  0:00.37 imap                   
 7696 dovecot  15  0 3304 1492 1244 S 0.0 0.3  0:00.60 imap-login                 
 7716 user6  15  0 6516 4128 3772 S 0.0 0.8  0:13.62 imap                   
 7721 dovecot  15  0 3308 1492 1244 S 0.0 0.3  0:00.53 imap-login                 
 7730 dovecot  15  0 3304 1492 1244 S 0.0 0.3  0:00.63 imap-login                 
 7732 dovecot  15  0 3304 1492 1244 S 0.0 0.3  0:00.62 imap-login                 
 7741 dovecot  15  0 3304 1492 1244 S 0.0 0.3  0:00.59 imap-login                 
 7742 dovecot  15  0 3304 1492 1244 S 0.0 0.3  0:00.61 imap-login                 
 9633 dovecot  15  0 3444 1716 1408 S 0.0 0.3  0:01.24 imap-login                 
 9671 dovecot  15  0 3440 1712 1408 S 0.0 0.3  0:01.23 imap-login                 
 9700 dovecot  15  0 3444 1716 1408 S 0.0 0.3  0:05.66 imap-login                 
 9712 dovecot  15  0 3444 1712 1408 S 0.0 0.3  0:01.14 imap-login

Minnet bör väl räcka? Belastningen är inte högre än så här. Ändå har jag alltså 94 processer igång, men bara ett fåtal som är aktiva samtidigt.

Vad säger egentligen det här?

Kod:

ersion: 2.5
    uid resource      held  maxheld  barrier  limit  failcnt
  11037: kmemsize    8940914  17382754  25165824  45508096  14235381
      lockedpages      0    8    1024    1024    0
      privvmpages    50369  84815  131072  262144  2615536
      shmpages      782    2718  131072  131072    0
      dummy        0    0    0    0    0
      numproc      95    189    350    350    0
      physpages    26459  49264    0 2147483647    0
      vmguarpages      0    0  131072  131072    0
      oomguarpages  26459  49264  131072  131072    0
      numtcpsock      32    85    1024    1024    0
      numflock      4    11    376    412    0
      numpty        1    3    32    32    0
      numsiginfo      0    27    256    256    0
      tcpsndbuf    190060  679744  1524288  1624288    0
      tcprcvbuf    189544  870888  1524288  1624288    0
      othersockbuf  372012  719496  2252160  4194304    0
      dgramrcvbuf      0  105444  262144  262144    0
      numothersock    170    240    400    400    2396
      dcachesize    404861  594860  1252660  1290240    0
      numfile      2168    4016    6000    6000    0
      dummy        0    0    0    0    0
      dummy        0    0    0    0    0
      dummy        0    0    0    0    0
      numiptent      74    74    400    400    0

Om jag har förstått ovanstående rätt så har jag faktiskt haft minnesproblem och socketproblem. Jag kopplar dock det här till de problem som uppstod när jag enbart hade 256MB. De senaste veckorna har jag kör på 512MB och borde inte ha nått taket så lätt. Supporten gick in och höjde max antal sockets. Det problem som uppstod med MySQL databasen var av det här slaget och inträffade gott och väl någon vecka efter att jag hade uppgraderat till 512MB RAM:

|008:02:04-11:16:25: ioctl can't find the server's ip address for venet0:0 : Bad file descriptor
2008:02:04-11:16:25: ioctl can't find the server's ip address for venet0:0 : Bad file descriptor
2008:02:04-11:17:36: Timeout from from IP_ADDRESS : last flagged: Request::readAndProcess(*skt, IP_ADDRESS, IP_ADDRESS)
2008:02:04-11:20:23: ioctl can't find the server's ip address for venet0:0 : Bad file descriptor
2008:02:04-11:20:23: ioctl can't find the server's ip address for venet0:0 : Bad file descriptor
2008:02:04-11:24:32: ioctl can't find the server's ip address for venet0:0 : Bad file descriptor
2008:02:04-11:24:32: ioctl can't find the server's ip address for venet0:0 : Bad file descriptor
2008:02:04-12:18:08: ioctl can't find the server's ip address for venet0:0 : Bad file descriptor
2008:02:04-12:18:08: ioctl can't find the server's ip address for venet0:0 : Bad file descriptor
2008:02:04-18:09:56: ioctl can't find the server's ip address for venet0:0 : Bad file descriptor
2008:02:04-18:09:56: ioctl can't find the server's ip address for venet0:0 : Bad file descriptor
2008:02:04-18:10:06: ioctl can't find the server's ip address for venet0:0 : Bad file descriptor
2008:02:04-18:10:06: ioctl can't find the server's ip address for venet0:0 : Bad file descriptor

Jag blir ju inte riktigt klokt på ovanstående information, men i praktiken innebar det att jag inte fick kontakt med MySQL databasen som jag använder för att utveckla den nuvarande sajten. I kontrollpanelen gick det inte heller att stoppa/starta om MySQL utan det enda som hjälpte var att starta om hela servern. Hur kan det här vara ett minnesproblem när alla andra tjänster fungerade som vanligt?

Jag är lite orolig för att det hela ska kapsejsa den dag jag går i produktion. Det vill jag ju helst slippa. Kan ni hjälpa mig att utröna om det verkligen är så att jag borde ta en dedikerad server (även om jag mer ser det där som rent försäljningssnack; jag har ju ingen trafik att prata om!) eller åtminstonen öka på RAM-minnet rejält (fr. 512MB --> 1GB)? Jag hade ändå planerat att så småningom köra med egen server men det känns lite tokigt att ett vanligt VPS-konto inte ska räcka till med min nuvarande användning. Det är ju smått löjligt då att sälja dessa grundpaket...

En, kanske inte så välgrundad, misstanke jag har är att de passar på att sälja mig massa tilläggstjänster när problemen kanske handlar om att överbeläggning i deras servrar eller andra konfigurationsfel. Och det känns ju lite surt att gå omkring med dylika misstankar...

Vad säger ni? Överförbrukar jag den hårdvaruspecifikation som gäller för mitt VPS-konto eller svamlar supporten med standardfraser för att begränsa egen arbetsinsats och passa på att sälja lite kringtjänster?

Märk väl: jag är inte förbannad på min leverantör men vill verkligen veta orsaken så att jag inte sitter med byxorna nere när det är skarpt läge...

Björklund 2008-02-10 06:16

Frågan är inte så lätt att svara på. Det räcker ju att du har en stor tabell som får MySQL att använda för mycket minne vid en enda SELECT. Det kan ju också vara så att du har ett PHP-skript som konsumerar ex 32MB (ex skala om bilder) körs denna 5 ggr samtidigt så är det genast uppe i 160MB + allt det andra du kör.

privvmpages säger hur mycket minne du har. Eftersom du har "errors" på "failcnt" så betyder det att du har förbrukat mer minne än vad din VPS är konfigurerad till.

Din leveerantör använder antingen Virtuozzo eller OpenVZ. Ta en titt på manualen vad pivvmpages igentligen betyder.

http://wiki.openvz.org/Privvmpages#privvmpages

En del appliaktioner förstår inte att "sockets" tar slut. Och då kan felmeddelanden bli lite svåra att tyda.
Troligen MySQL som borde skriva lite mer felhantering och bättre felmeddelanden om sockets tar slut.

Det är inte speciellt troligt att de lurar sig. /proc/user_beancounters ljuger inte. Det står ju klart o tydligt att du har konsumerat mer än vad din VPS är konfigurerad till.

KPK 2008-02-10 10:05

Ja, men den baseras ju på när jag "endast" hade 256MB RAM...

Jag har bara Drupal igång med en databas med knappt någon information alls på. Det är lustigt, men på ett hostingkonto jag har haft hos en leverantör i USA kunde jag ha betydligt större databaser igång utan problem...

Jag tror iofs inte heller att min nuvarande leverantör för VPS försöker luras. Men jag är förvånad att min nuvarande konfiguration enligt supporten inte skulle räcka för att komma igång med verksamheten...

Hur har ni andra som har VPS det egentligen? Vad lyckas ni köra på era konton och med hur mycket RAM-minne? Jag behöver utröna om VPS överhuvudtaget är ett alternativ (det verkar ju t.o.m. som att hostinglösning kan vara bättre) eller om det mer specifikt handlar om min aktuella leverantör innan jag beslutar mig för att gå vidare med andra lösningar.

Mvh,

SajtXL 2008-02-10 10:25

Om vi tittar på en liknande VPS med 512mb minne ser det ut så här:

Version: 2.5
uid resource held maxheld barrier limit failcnt
kmemsize 5212202 7236795 50000000 50000000 0
lockedpages 0 0 256 256 0
privvmpages 74504 102417 256000 256000 0
shmpages 910 2206 21504 21504 0
dummy 0 0 0 0 0
numproc 79 103 240 240 0
physpages 35964 48901 0 2147483647 0
vmguarpages 0 0 127000 2147483647 0
oomguarpages 35964 48901 26112 2147483647 0
numtcpsock 35 61 360 360 0
numflock 4 15 188 206 0
numpty 1 1 16 16 0
numsiginfo 0 14 256 256 0
tcpsndbuf 221484 1193844 1720320 2703360 0
tcprcvbuf 212992 776028 1720320 2703360 0
othersockbuf 189380 563648 1126080 2097152 0
dgramrcvbuf 0 173160 262144 262144 0
numothersock 94 125 360 360 0
dcachesize 465968 550268 2273280 2416640 0
numfile 2410 3011 5820 5820 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
numiptent 14 14 128 128 0

Ett 20 tal användare

KPK 2008-02-10 11:14

Gå det att nollställa /proc/user_beancounters? Många fel uppstod när jag endast hade 256MB RAM.

SajtXL, vad har du för processer igång? MySQL?

Magnus_A 2008-02-10 12:30

VPS är inget undermedel. Allt fungerar inte bättre bara för att flera ska äta av samma kaka samtidigt. En bra dialog med leverantören är A och O. Själv har jag haft problem med Postfix, som är en riktig resursätare av numtcpsock. Efter att leverantören höjt upp limiten så fungerar det smärtfritt. Alla linuxapplikationer är skrivna för att ha tillgång till alla resurser som "normalt" finns tillhanda på ett system. Minne är en sak men det finns många andra begränsningar.
Det sägs att /proc/user_beancounters ska nollställas efter reboot.

KPK 2008-02-10 12:59

Tack, Magnus! Jag hade bara förväntat mig att det skulle fungera ungefär som den hostinglösning som jag hade tidigare. Tydligen är det inte så enkelt även om jag i nuläget inte har någon direkt belastning av servern. Rent teoretiskt: hur kan mitt VPS konto mäkta med så lite (om det nu är det som är problemet) jämfört med ett ganska vanligt hostingkonto jag hade hos Hostmatters.com?

Hos mig nollställs dock inte /proc/user_beancounters efter reboot (jag tror bestämt att min leverantör kör Open VZ). Läst info: http://wiki.openvz.org/UBC_failcnt_reset och det tycks alltså bero på att följande är på: CONFIG_UBC_KEEP_UNUSED=y . Nåja, det faktum att siffrorna inte har förändrats också något om att det senaste problemet inte har någonting att göra med att jag skulle ha använt alla minnesresurser. Konstigt att supporten bara ser på siffrorna och inte när det aktuella problemet uppstod.

Björklund 2008-02-10 15:22

Citat:

Originally posted by KPK@Feb 10 2008, 13:59
Tack, Magnus! Jag hade bara förväntat mig att det skulle fungera ungefär som den hostinglösning som jag hade tidigare. Tydligen är det inte så enkelt även om jag i nuläget inte har någon direkt belastning av servern. Rent teoretiskt: hur kan mitt VPS konto mäkta med så lite (om det nu är det som är problemet) jämfört med ett ganska vanligt hostingkonto jag hade hos Hostmatters.com?

Det har ju igentligen inget med belastning att göra utan hur mycket minne dina applikationer använder.
Som jag förstår det har du inga problem med ex processorkapacitet?
Kan du kanske lista ut vad det igentligen som tar minne? Får du problem när du gör vissa saker (ex ett visst skript mot en speciell tabell i MySQL).
För att du skall komma vidare måste du ta reda på vad det är som tar slut på ditt minne. När Apache startar en PHP-process så är det undere det aktuell ögonblicket om PHP körs som tar upp minne. Så fort PHP-skriptet är fördigt lämnar den tillbaka minnet.

Ett webbhotell har troliget mycket mer minne än 256MB på sina servrar så om du har ett skript som använder mycket minne så är det ju inte så konstigt att det fungerar där.

KPK 2008-02-10 16:12

Tack. Ja, det skulle då enbart vara Drupal i sådana fall. Poängen med den "dispyt" som nu finns är dock att 512MB RAM inte skulle räcka och att det senaste problemet också skulle bero på bristande kapacitet trots att värdena för /proc/user_beancount alltså inte har förändrades när felet uppstod med kontakten till MySQL-databasen.

Tacksam dock för ett klargörande: webbhotellet ifråga hade säkert över flera hundra kunder som delade på samma hårdvaruresurser. Jag förstår ju att man då tillåter en viss överutnyttjande, men nog bör väl mina 512MB (som jag ensamt kan utnyttja) vara betydligt mer än den kanske 2-4 GB RAM de kanske har på en hostingserver?

När det gäller att replikera problemet: det går inte. Allting fungerar i nuläget. Det hade ju annars varit lätt att säga att Drupal hade varit problemet. Kanske är det ett resultat av att supporten har varit inne och höjt antalet sockets. Det som gör mig lite konfunderad är dock det faktum att supporten refererar till värden på /proc/user_beancounts som framför allt uppstod när jag hade 256MB RAM och inte vill kännas vid det senaste problemet som uppstod när de var inne och röjde på servern för att försöka åtgärda någonting annat...

Det här verkar ju tyvärr inte vara en exakt vetenskap eftersom så många variabler kan påverka utfallet. Från mitt perspektiv känns det dock inte så bra när supporten hela tiden tar fasta på /proc/user_beancounts vars värden inte är relaterade till det senaste problemet... Samtidigt kan jag ju inte riktigt veta om det är de som har fel eller om det är jag som har haft orimliga förväntningar. VPS-kontot bör ju mäkta med lite mer än hostingalternativet...

Hur många kör produktionssajter med en relativt intensivt utnyttjande av PHP och Drupal/Joomla/Vbulletin osv. på ett VPS konto med 512MB utan att råka ut för några minnesproblem? Eller bör man i ett redan tidigt skede sikta in sig på en dedikerad server eller co-location oavsett trafikmängden?

Magnus_A 2008-02-10 16:29

Vore kul att höra lite feedback från VPS-leverantörer här, hur de resonerar kring tilldelning av resurser och hur man går tillväga när resurserna inte räcker till för användarna.

KPK 2008-02-10 18:19

Jag har nu testat med Apache benchmark mot den domän där jag har Drupal installerat. Vid -n 100 och -c 10 (# ab -n 100 - c 10 -v 2 http://domän) så får jag följande resultat:

Server Software: Apache/2.2.8
Server Hostname: domän
Server Port: 80

Document Path: /
Document Length: 12855 bytes

Concurrency Level: 10
Time taken for tests: 49.105257 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 1343300 bytes
HTML transferred: 1285500 bytes
Requests per second: 2.04 [#/sec] (mean)
Time per request: 4910.526 [ms] (mean)
Time per request: 491.053 [ms] (mean, across all concurrent requests)
Transfer rate: 26.70 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 1
Processing: 471 4808 11216.5 995 48409
Waiting: 448 4780 11210.4 967 48385
Total: 471 4808 11216.5 995 48410

Percentage of the requests served within a certain time (ms)
50% 995
66% 1478
75% 2636
80% 3162
90% 9371
95% 42338
98% 44951
99% 48410
100% 48410 (longest request)

Inte alltför imponerande siffror. Ska jag tolka det som att VPS-kontot i kombination med Drupal & MySQL inte riktigt duger för en produktionssajt? 100 requests och 10 concurrent request låter ju inte alltför mycket när sajten väl är uppe. Om jag ändrar värden till 1000 requests och 100 concurrent requests så går sajten som väntat ner sig. Det förstår jag ju också att VPS-kontot inte är dimensionerat för. Faktum är att den går ner sig redan -n 200 -c 50. Hur är det för er som har VPS-konto som är jämförbara med mitt? (512MB RAM, Intel® Xeon® CPU E5310 @ 1.60GHz).

Värdena för /proc/user_beancounters har också mycket riktigt förändrats. Slutsatsen verkar sålunda rimlig att VPS-kontot som jag har nu inte riktigt duger för en produktionssajt med Drupal och MySQL. Mycket trist eftersom jag såg VPS som ett kostnadseffektivt alternativ till en början innan verksamheten har tagit fart. Kan det verkligen vara en rimlig slutsats att ett hostingalternativ är bättre till en början tills trafikmängden motsvarar en egen server (dedicated/co-location)? Vad tusan ska man då egentligen med VPS-konton egentligen? Eller handlar det mer om att Drupal kräver mer än vad det genomsnittliga VPS-kontot kan erbjuda?

KPK 2008-02-10 20:13

Genom att ändra lite i Drupals sätt att handskas med cache blir det faktiskt lite bättre.

Kod:

Server Software:    Apache/2.2.8
Server Hostname:    domain
Server Port:      80

Document Path:    /
Document Length:    12883 bytes

Concurrency Level:  10
Time taken for tests:  48.497947 seconds
Complete requests:  1000
Failed requests:    0
Write errors:      0
Total transferred:  13444017 bytes
HTML transferred:    12883000 bytes
Requests per second:  20.62 [#/sec] (mean)
Time per request:    484.979 [ms] (mean)
Time per request:    48.498 [ms] (mean, across all concurrent requests)
Transfer rate:    270.69 [Kbytes/sec] received

Connection Times (ms)
      min mean[+/-sd] median  max
Connect:    0  0  3.0  0  57
Processing:  46 483 501.1  480  4840
Waiting:    40 416 409.2  426  4663
Total:    46 483 501.2  480  4840

Percentage of the requests served within a certain time (ms)
 50%  480
 66%  565
 75%  626
 80%  670
 90%  796
 95%  1032
 98%  1878
 99%  2903
 100%  4840 (longest request)

Ganska kraftig förbättring jämfört med innan. Vid -n 1000 -c 30 får jag följande:

Kod:

Server Software:    Apache/2.2.8
Server Hostname:    domain
Server Port:      80

Document Path:    /search/node/searchstring
Document Length:    6951 bytes

Concurrency Level:  30
Time taken for tests:  48.732997 seconds
Complete requests:  1000
Failed requests:    0
Write errors:      0
Total transferred:  7534000 bytes
HTML transferred:    6951000 bytes
Requests per second:  20.52 [#/sec] (mean)
Time per request:    1461.990 [ms] (mean)
Time per request:    48.733 [ms] (mean, across all concurrent requests)
Transfer rate:    150.97 [Kbytes/sec] received

Connection Times (ms)
      min mean[+/-sd] median  max
Connect:    0  0  6.0  0  97
Processing:  96 1446 960.8  1241  10528
Waiting:    96 1445 960.8  1241  10527
Total:    96 1447 960.9  1241  10528

Percentage of the requests served within a certain time (ms)
 50%  1241
 66%  1410
 75%  1572
 80%  1695
 90%  2076
 95%  3227
 98%  4734
 99%  6272
 100% 10528 (longest request)

Vid -n 1000 och -c 100 går servern ner. Vad säger dock -n 1000 och -c 100 i verkliga sammanhang?

Björklund 2008-02-10 20:56

Citat:

Originally posted by KPK@Feb 10 2008, 21:13
Vid -n 1000 och -c 100 går servern ner. Vad säger dock -n 1000 och -c 100 i verkliga sammanhang?
Svårt att säga. Men en normal surfare klickar ju en gång. Läser lite och klickar igen.
Testet nedan simulerar 100st sessioner som skapar 1000 requests var (om jag fattat det rätt). Lite agressiva surfare kanske? :D

Har man så många besökare samtidigt bör det finnas ekonomi att ha en egen server.

patrikweb 2008-02-10 21:12

OpenVZ/Virtuozzo kräver massa optimering och inställningar för fungera med lite belastning. Då handlar det inte om endast hur mycket minne man har.

Krävs mycket att ställa in för det ska fungera optimalt, sedan är problemet att få sakerna fatta att dom gått över limit.

Men är dock /proc/user_beancounts som är intressant i det hela för veta var man går över för värden.

Sedan är det problem med att kunna bursta med vissa värden som minne, när väl någon annan behöver det minne så brukar saker kunna dö då den bara tar minnet rakt av.

Har själv slutat köra OpenVZ för vanliga VPS för att det blir bara onödigt jobb med det hela.

KPK 2008-02-10 21:24

Citat:

Ursprungligen postat av jonasb76
Citat:

Ursprungligen postat av KPK
Vid -n 1000 och -c 100 går servern ner. Vad säger dock -n 1000 och -c 100 i verkliga sammanhang?

Svårt att säga. Men en normal surfare klickar ju en gång. Läser lite och klickar igen.
Testet nedan simulerar 100st sessioner som skapar 1000 requests var (om jag fattat det rätt). Lite agressiva surfare kanske? :D

Har man så många besökare samtidigt bör det finnas ekonomi att ha en egen server.

Absolut. Det hade jag inte förväntat mig heller. 1000 requests och 100 samtidiga requests är ju mycket... I mitt fall kommer jag nog inte nå upp till dessa siffror eftersom verksamheten riktar sig till en väldefinierad målgrupp. Däremot är det intressant att 100 requests och 25 samtidiga tycks gå lite väl segt...

KPK 2008-02-10 21:35

Citat:

Originally posted by patrikweb@Feb 10 2008, 22:12
OpenVZ/Virtuozzo kräver massa optimering och inställningar för fungera med lite belastning. Då handlar det inte om endast hur mycket minne man har.

Krävs mycket att ställa in för det ska fungera optimalt, sedan är problemet att få sakerna fatta att dom gått över limit.

Men är dock /proc/user_beancounts som är intressant i det hela för veta var man går över för värden.

Sedan är det problem med att kunna bursta med vissa värden som minne, när väl någon annan behöver det minne så brukar saker kunna dö då den bara tar minnet rakt av.

Har själv slutat köra OpenVZ för vanliga VPS för att det blir bara onödigt jobb med det hela.

... och om så är fallet är det ju svårt för mig som kund att påverka. Är det flera som delar patrikwebs åsikt?

Det lustiga med benchmarkresultatet är dock att det fel som jag hade senast (och som fick mig att starta tråden) omöjligen kan ha föranletts av att jag skulle ha utsatt servern för dylika påfrestningar. Det inträffade ju precis när jag loggade in via den skyddade sidan. Loggfilen visade också ett felmeddelande som jag nu inte får.

Ni som säljer VPS-konton: vilket användningsområde tycker ni är lämpligt för VPS-konton? Utvecklingssajt? En sajt med max antal besök och x antal databasanrop/viss tid? Ser man till marknadsföringen kan man som kund lätt tro det ska räcka ganska långt... I en del fall kanske ett (vältilltaget) webhotellkonto t.o.m. är ett bättre alternativ?

patrikweb 2008-02-10 22:00

Handlar om vilken plattform och sedan belastning/minne man använder, kör du vmware och 512MB minne på den VM samt bra cpu i servern så skulle det räcka länge.

Men kör du 512MB minne nu så är det nästan bättre börja sattsa på dedikerad server, kan ju kosta lika mycket eller bli billigare med sedan.

Men rätt plattform så får du samma resultat på en virtuell server som du får på en dedikerad server i stort sätt, oftast då man normalt inte kan utnyttja alla core optimalt ändå annars.

Brukar vara så att kostnaden blir bättre fördel för dedikerad server när man kommer upp i 512MB minne och sedan och disk.

Sedan beror det mycket på leverantör med, du kan få bättre driftsäkerhet på en dedikerad och slipper kanske bli överbokad på prestanda.

Björklund 2008-02-10 22:22

Citat:

Ursprungligen postat av KPK
Citat:

Originally posted by -jonasb76@Feb 10 2008, 21:56
Citat:

Ursprungligen postat av KPK
Vid -n 1000 och -c 100 går servern ner. Vad säger dock -n 1000 och -c 100 i verkliga sammanhang?

Svårt att säga. Men en normal surfare klickar ju en gång. Läser lite och klickar igen.
Testet nedan simulerar 100st sessioner som skapar 1000 requests var (om jag fattat det rätt). Lite agressiva surfare kanske? :D

Har man så många besökare samtidigt bör det finnas ekonomi att ha en egen server.


Absolut. Det hade jag inte förväntat mig heller. 1000 requests och 100 samtidiga requests är ju mycket... I mitt fall kommer jag nog inte nå upp till dessa siffror eftersom verksamheten riktar sig till en väldefinierad målgrupp. Däremot är det intressant att 100 requests och 25 samtidiga tycks gå lite väl segt...

Det finns ju ingen "normal" besökare som klarar slänga iväg 100 reqeusts så fort som Apache bench.
Det är svårt att uppskatta exakt antal besökare. Men jag gissar på flera tusen besökare "samtidigt" om man testar med Apache bench med dina värden.

Varför inte testa skillnaden på din VPS och ditt webbhotell? Vore intressant och se skillnaden med Apache bench. Skulle också vara intressant att ta reda på vad webbhotellet hade vård hårdvara på servern (om det nu går att ta reda på det)

Björklund 2008-02-10 22:37

Citat:

Ursprungligen postat av KPK
Citat:

Ursprungligen postat av patrikweb
OpenVZ/Virtuozzo kräver massa optimering och inställningar för fungera med lite belastning. Då handlar det inte om endast hur mycket minne man har.

Krävs mycket att ställa in för det ska fungera optimalt, sedan är problemet att få sakerna fatta att dom gått över limit.

Men är dock /proc/user_beancounts som är intressant i det hela för veta var man går över för värden.

Sedan är det problem med att kunna bursta med vissa värden som minne, när väl någon annan behöver det minne så brukar saker kunna dö då den bara tar minnet rakt av.

Har själv slutat köra OpenVZ för vanliga VPS för att det blir bara onödigt jobb med det hela.

... och om så är fallet är det ju svårt för mig som kund att påverka. Är det flera som delar patrikwebs åsikt?

Mjaa.. Nej.

Med Virtuozzo/OpenVZ får du lite bättre prestanda än med VMWare då VMWare bootar hela operativsystem på varje virtuell server inkl drivrutiner för allt. Det skapar lite extra "overhead".
Virtuozzo/OpenVZ delar samma kärna mellan alla virtuella servrar vilket ger ökad prestanda.

En virtuall server i VMWare är dock mer som en "riktig" server då operativsystem och applikationerna inte fattar att de körs på delad hårdvara.

VMWare/Xen/MS Virtual server är "hårdvaru virtualisering" medans Virtuozzo/OpenVZ/VServer/BSD Jail/Solaris Containers är "operativ systems virtualisering".

Det är lite som att jämföra äpplen och päron.

Är du bara ute efter webbhosting så tycker jag "operativ systems virtualisering" ger mer för pengarna. Men du får hålla koll så du inte slår i taket på det "limits" du har köpt.

KPK 2008-02-10 22:41

Körde ab -n 1000 -c 100 -v 2 http://webhotellkonto. Motsvarande fixade alltså mitt VPS-konto ej.

Kod:

Server Software:    Apache/1.3.37 Server
Server Hostname:    xxxxx
Server Port:      80

Document Path:    /
Document Length:    396 bytes

Concurrency Level:  100
Time taken for tests:  5.216391 seconds
Complete requests:  1000
Failed requests:    0
Write errors:      0
Non-2xx responses:  1000
Total transferred:  534000 bytes
HTML transferred:    396000 bytes
Requests per second:  191.70 [#/sec] (mean)
Time per request:    521.639 [ms] (mean)
Time per request:    5.216 [ms] (mean, across all concurrent requests)
Transfer rate:    99.88 [Kbytes/sec] received

Connection Times (ms)
      min mean[+/-sd] median  max
Connect:  128 155 86.2  132  597
Processing:  135 342 168.8  347  855
Waiting:  134 340 167.9  345  854
Total:    264 498 180.3  504  1006

Percentage of the requests served within a certain time (ms)
 50%  504
 66%  544
 75%  570
 80%  619
 90%  811
 95%  871
 98%  895
 99%  908
 100%  1006 (longest request)

Det är ju en markant skillnad jämfört med VPS kontot! Rent prestandamässigt så klår ju webbhotellkontot mitt VPS-konto rejält! Eller vad sägs om följande siffror för -n 100 och -c 10:

Kod:

 
Server Hostname:    xxxx
Server Port:      80

Document Path:    /
Document Length:    396 bytes

Concurrency Level:  10
Time taken for tests:  3.119764 seconds
Complete requests:  100
Failed requests:    0
Write errors:      0
Non-2xx responses:  100
Total transferred:  53400 bytes
HTML transferred:    39600 bytes
Requests per second:  32.05 [#/sec] (mean)
Time per request:    311.976 [ms] (mean)
Time per request:    31.198 [ms] (mean, across all concurrent requests)
Transfer rate:    16.67 [Kbytes/sec] received

Connection Times (ms)
      min mean[+/-sd] median  max
Connect:  129 131  1.7  131  139
Processing:  134 153 39.6  138  279
Waiting:  133 152 39.6  137  279
Total:    264 284 40.0  270  415

Percentage of the requests served within a certain time (ms)
 50%  270
 66%  272
 75%  274
 80%  276
 90%  362
 95%  406
 98%  412
 99%  415
 100%  415 (longest request)

Det känns ju verkligen som om jag har bytt ner mig... :(

KPK 2008-02-10 22:47

Citat:

Ursprungligen postat av jonasb76
Citat:

Originally posted by -KPK@Feb 10 2008, 22:35
Citat:

Ursprungligen postat av patrikweb
OpenVZ/Virtuozzo kräver massa optimering och inställningar för fungera med lite belastning. Då handlar det inte om endast hur mycket minne man har.

Krävs mycket att ställa in för det ska fungera optimalt, sedan är problemet att få sakerna fatta att dom gått över limit.

Men är dock /proc/user_beancounts som är intressant i det hela för veta var man går över för värden.

Sedan är det problem med att kunna bursta med vissa värden som minne, när väl någon annan behöver det minne så brukar saker kunna dö då den bara tar minnet rakt av.

Har själv slutat köra OpenVZ för vanliga VPS för att det blir bara onödigt jobb med det hela.

... och om så är fallet är det ju svårt för mig som kund att påverka. Är det flera som delar patrikwebs åsikt?


Mjaa.. Nej.

Med Virtuozzo/OpenVZ får du lite bättre prestanda än med VMWare då VMWare bootar hela operativsystem på varje virtuell server inkl drivrutiner för allt. Det skapar lite extra "overhead".
Virtuozzo/OpenVZ delar samma kärna mellan alla virtuella servrar vilket ger ökad prestanda.

En virtuall server i VMWare är dock mer som en "riktig" server då operativsystem och applikationerna inte fattar att de körs på delad hårdvara.

VMWare/Xen/MS Virtual server är "hårdvaru virtualisering" medans Virtuozzo/OpenVZ/VServer/BSD Jail/Solaris Containers är "operativ systems virtualisering".

Det är lite som att jämföra äpplen och päron.

Är du bara ute efter webbhosting så tycker jag "operativ systems virtualisering" ger mer för pengarna. Men du får hålla koll så du inte slår i taket på det "limits" du har köpt.

Vilka erbjuder Xen/VMWare i Sverige?

KPK 2008-02-11 00:58

En hel del av mina problem tycks ha berott på att jag inte hade optimerat MySQL för användning med Drupal. När jag nu har gjort detta så kan jag plötsligt köra -n 1000 -c 100:

Kod:

Server Software:    Apache/2.2.8
Server Hostname:    domain
Server Port:      80

Document Path:    /
Document Length:    12855 bytes

Concurrency Level:  100
Time taken for tests:  48.9451 seconds
Complete requests:  1000
Failed requests:    0
Write errors:      0
Total transferred:  13416000 bytes
HTML transferred:    12855000 bytes
Requests per second:  20.83 [#/sec] (mean)
Time per request:    4800.945 [ms] (mean)
Time per request:    48.009 [ms] (mean, across all concurrent requests)
Transfer rate:    272.88 [Kbytes/sec] received

Connection Times (ms)
      min mean[+/-sd] median  max
Connect:    0  9 27.1  0  97
Processing:  324 4574 1935.1  4647  42007
Waiting:  163 4373 779.1  4553  5111
Total:    364 4583 1928.9  4648  42095

Percentage of the requests served within a certain time (ms)
 50%  4648
 66%  4684
 75%  4716
 80%  4741
 90%  4868
 95%  4975
 98%  5027
 99%  5118
 100% 42095 (longest request)

Servern går alltså inte ner sig även om det är segt jämfört med shared hostingkontot. Kör jag mer rimliga -n 100, -c 10 så får jag nu följande:

Kod:

Server Software:    Apache/2.2.8
Server Hostname:    domain
Server Port:      80

Document Path:    /
Document Length:    12855 bytes

Concurrency Level:  10
Time taken for tests:  4.645497 seconds
Complete requests:  100
Failed requests:    0
Write errors:      0
Total transferred:  1341600 bytes
HTML transferred:    1285500 bytes
Requests per second:  21.53 [#/sec] (mean)
Time per request:    464.550 [ms] (mean)
Time per request:    46.455 [ms] (mean, across all concurrent requests)
Transfer rate:    281.99 [Kbytes/sec] received

Connection Times (ms)
      min mean[+/-sd] median  max
Connect:    0  0  0.0  0    0
Processing:  44 451 1058.5  46  4521
Waiting:    39 445 1058.5  40  4515
Total:    44 451 1058.5  46  4521

Percentage of the requests served within a certain time (ms)
 50%  46
 66%  51
 75%  137
 80%  170
 90%  1564
 95%  3171
 98%  4482
 99%  4521
 100%  4521 (longest request)

Helt andra siffror jämfört med tidigare!

Jag tolkar det här som att det finns ytterligare behov av optimering mellan Drupal och MySQL, och att det primärt inte handlar om att 512MB RAM inte skulle räcka.

htiawe 2008-02-11 05:18

Vad rörde det sig om för optimeringar?
Är det specifika optimeringar som gäller endast Drupal mot MySQL eller bör dessa tillämpas i andra fall också? Känns ju dumt att man ska behöva optimera ihjäl sig.

Björklund 2008-02-11 05:47

Citat:

Originally posted by KPK@Feb 10 2008, 23:47
Vilka erbjuder Xen/VMWare i Sverige?
Det verkar som Patrikweb erbjuder det. Han nämnde det i denna tråden.

Hur stora är din databastabeller för MySQL? Hur ser din my.cnf ut?
Det kan ju vara så att webbhotell har optimerat MySQL och har mycket minne i sin MySQL server och läser in alla dina tabeller i ram-minnet. Din VPS har kanske för lite minne och my.cnf är inte optimerad för att läsa in allt i minnet?

KPK 2008-02-11 09:01

Citat:

Originally posted by htiawe@Feb 11 2008, 06:18
Vad rörde det sig om för optimeringar?
Är det specifika optimeringar som gäller endast Drupal mot MySQL eller bör dessa tillämpas i andra fall också? Känns ju dumt att man ska behöva optimera ihjäl sig.

Jag förstår samtidigt att en optimering måste till eftersom grundinställningarna i MySQL är generella. De optimeringar jag har gjort gäller nog specifikt MySQL <-> Drupal, men http://www.day32.com/MySQL/ kan nog användas i andra sammanhang också. Den ger förslag på optimeringar som kan göras i MySQL. Jag lade till följande i my.conf:

Kod:

[mysqld]
max_connections = 800
max_user_connections = 800
key_buffer = 36M
myisam_sort_buffer_size = 64M
join_buffer_size = 2M
read_buffer_size = 2M
sort_buffer_size = 3M
table_cache = 1024
thread_cache_size = 286
interactive_timeout = 25
wait_timeout = 1800
connect_timeout = 10
max_allowed_packet = 1M
max_connect_errors = 999999
query_cache_limit = 1M
query_cache_size = 16M
query_cache_type = 1
tmp_table_size = 16M

Jag vet inte om det är optimalt men det är i alla fall bättre än tidigare.

KPK 2008-02-11 12:32

Funderar på att innan jag går med dedikerad/egen server att försöka koppla ihop flera VPS-konton för bättre skalbarhet (nja) och "load-balancing". Med Xen/VMWare bör det väl vara möjligt att ha den här uppsättningen:

VPS-konto #1 på fysisk maskin A: Apache load-balancer
VPS-konto #2 på fysisk maskin B: Drupal 1
VPS-konto #3 på fysisk maskin C: Drupal 2
VPS-konto #4 på fysisk maskin D: MySQL

Om jag har räknat rätt, bör det här vara ett mycket bättre ekonomiskt alternativ som samtidigt ger en högre kapacitet än att ha en egen dedikerad server (beror ju lite på hur den är konfigurerad). Kan det stämma? Är det här upplägget också möjligt med OpenVZ?

patrikweb 2008-02-11 13:18

Citat:

Originally posted by KPK@Feb 11 2008, 13:32
Funderar på att innan jag går med dedikerad/egen server att försöka koppla ihop flera VPS-konton för bättre skalbarhet (nja) och load-balancing. Med Xen/VMWare bör det väl vara möjligt att ha den här uppsättningen:
VPS-konto #1 på fysisk maskin A: Apache load-balancer
VPS-konto #2 på fysisk maskin B: Drupal 1
VPS-konto #3 på fysisk maskin C: Drupal 2
VPS-konto #4 på fysisk maskin D: MySQL
Om jag har räknat rätt, bör det här vara ett mycket bättre ekonomiskt alternativ som samtidigt ger en högre kapacitet än att ha en egen dedikerad server (beror ju lite på hur den är konfigurerad). Kan det stämma? Är det här upplägget också möjligt med OpenVZ?



Du får ju även tänka att du måste ha minne på alla dom VPS med, att kanske ha 4 VPS med 256-512MB minne lär kosta mer än dedikerad server.

Men om du vet att du blir placerad på flera fysiska VPS servrar så kan prestandan öka självklart.

Men själv brukar jag köra en fysisk lastbalanserare.

KPK 2008-02-11 13:46

Så man kan i regel inte begära att få placering på olika fysisk maskiner? Den faktiska kostnaden hamnar kanske i nivå med en ganska medelmåttig dedikerad server, men min tanke var att man får betydligt mer för pengarna i termer av prestanda? Dessutom behövs kanske inte så mycket RAM för varje enskilt VPS-konto eftersom de kommer att ha en ganska så specifika uppgifter? Lastbalanseraren behöver väl inte så mycket minne? Frågan är också om Drupalservrarna behöver så mycket. Däremot är det kanske klokt att ha en rätt så tilltaget RAM-minne för MySQL-kontot.

Är det någon leverantör som kan acceptera ett dylikt upplägg och dessutom garantera att sprida VPS-kontona över olika fysiska maskiner?

patrikweb 2008-02-11 14:16

Beror på vad olika leverantörer kan erbjuda och hur flexibla dom är, dock bör du ändå ha minst 256MB minne på varje VPS.

Dock så kan du ju lika väl köpa en dedikerad server och själv köra vmware på för att verkligen kunna använda flera core till max.

Björklund 2008-02-11 14:19

Citat:

Originally posted by KPK@Feb 11 2008, 14:46
Så man kan i regel inte begära att få placering på olika fysisk maskiner? Den faktiska kostnaden hamnar kanske i nivå med en ganska medelmåttig dedikerad server, men min tanke var att man får betydligt mer för pengarna i termer av prestanda? Dessutom behövs kanske inte så mycket RAM för varje enskilt VPS-konto eftersom de kommer att ha en ganska så specifika uppgifter? Lastbalanseraren behöver väl inte så mycket minne? Frågan är också om Drupalservrarna behöver så mycket. Däremot är det kanske klokt att ha en rätt så tilltaget RAM-minne för MySQL-kontot.

Är det någon leverantör som kan acceptera ett dylikt upplägg och dessutom garantera att sprida VPS-kontona över olika fysiska maskiner?

Alla VPS-leverantörer borde kunna placera dig på olika fysiska hårdvaror om du beställer flera VPS:er.
Det är ju ingen merkostnad för dom (om de nu inte råkar ha en enda hårdvara :) ).

Du kan köra DNS "round robin" istället för en "dyr" lastbalanserare.

KPK 2008-02-11 15:03

Citat:

Originally posted by patrikweb@Feb 11 2008, 14:18

Du får ju även tänka att du måste ha minne på alla dom VPS med, att kanske ha 4 VPS med 256-512MB minne lär kosta mer än dedikerad server.

Jag vet inte.... vad kostar 4 VPS konton hos dig? 150:-/mån x 4 = 600:- samt startavgift 2000:-.

Dedikerad server med måttlig prestanda? 1250 - 1500:-/mån. Startavgift på 2000:-. Ska jag dessutom köra VMWare så kostar väl det en slant också? 500 USD eller nåt?

Citat:

Men om du vet att du blir placerad på flera fysiska VPS servrar så kan prestandan öka självklart.
Men själv brukar jag köra en fysisk lastbalanserare.

Fysisk lastbalanserare? En sån där multilayer switch? Eller är det någonting annat? Hur mycket kostar inte en sådan? Klart att du har det men för mig handlar det ju om relationen mellan ekonomi och prestanda.

Är det ingen som utnyttjar flera VPS-konton på det sätt som jag har beskrivit?

patrikweb 2008-02-11 15:13

Citat:

Ursprungligen postat av KPK
Citat:

Ursprungligen postat av patrikweb
Du får ju även tänka att du måste ha minne på alla dom VPS med, att kanske ha 4 VPS med 256-512MB minne lär kosta mer än dedikerad server.

Jag vet inte.... vad kostar 4 VPS konton hos dig? 150:-/mån x 4 = 600:- samt startavgift 2000:-.
Dedikerad server med måttlig prestanda? 1250 - 1500:-/mån. Startavgift på 2000:-. Ska jag dessutom köra VMWare så kostar väl det en slant också? 500 USD eller nåt?

Citat:

Men om du vet att du blir placerad på flera fysiska VPS servrar så kan prestandan öka självklart.
Men själv brukar jag köra en fysisk lastbalanserare.


Fysisk lastbalanserare? En sån där multilayer switch? Eller är det någonting annat? Hur mycket kostar inte en sådan? Klart att du har det men för mig handlar det ju om relationen mellan ekonomi och prestanda.
Är det ingen som utnyttjar flera VPS-konton på det sätt som jag har beskrivit?


Har mycket svårt svara på det utan det skulle ses som reklam, dock så står ju priser att läsa på internet. Kan dock säga att man inte tar 2000:- i startavgift för VPS :P Fast det är väl lite logiskt.

Men om man ser på dedikerad server så kan du få dedikerad server med 2-4core och mycket minne för billigare än VPS. Alla fall om du har tänkt köra flera VPS med 256-512MB minne.

Finns Vmware Server som är helt gratis att köra om du inte vill köra ESX för runt $500

En Fysisk lastbalanserare är normalt lite mer än en multilayer switch, och kostnad brukar vara några nollor. Dock så bör ju vettiga leverantörer kunna erbjuda dig en sådan tjänst på sina egna sådana.

Tror inte det är så många som köper flera VPS konton för få ut mer prestanda utan då kör dom en dedikerad server.


Alla tider är GMT +2. Klockan är nu 16:14.

Programvara från: vBulletin® Version 3.8.2
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Svensk översättning av: Anders Pettersson