![]() |
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 Vad säger egentligen det här? Kod:
ersion: 2.5 |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... |
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. |
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, |
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 |
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? |
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. |
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. |
Citat:
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. |
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? |
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.
|
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? |
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 Kod:
Server Software: Apache/2.2.8 |
Citat:
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. |
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. |
Citat:
|
Citat:
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? |
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. |
Citat:
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) |
Citat:
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. |
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 Kod:
|
Citat:
|
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 Kod:
Server Software: Apache/2.2.8 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. |
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. |
Citat:
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? |
Citat:
Kod:
[mysqld] |
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? |
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. |
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? |
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. |
Citat:
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. |
Citat:
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:
Är det ingen som utnyttjar flera VPS-konton på det sätt som jag har beskrivit? |
Citat:
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