[KPK]

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:

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?

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]

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]

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]

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]

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]

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]

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]

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]

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]

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.