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