FAQ |
Kalender |
![]() |
#1 | |||
|
||||
Mycket flitig postare
|
Hej,
Jag slår i taket ibland mot mySql (max_connections) och undrar om någon har erfarenhet av hur högt man bör/kan sätta detta värde. Nu står det på default (100). Antar att risken finns att att jag sänker maskinen istället om jag ökar detta för mycket !? |
|||
![]() |
![]() |
![]() |
#2 | ||
|
|||
Mycket flitig postare
|
Tyvärr, kan jag inte hjälpa dig med förslag på värde. Det beror väl ganska mycket på din hårdvara så du får nog experimentera. Eller ange hårdvara och hoppas på att någon annan har liknande.
Dock är ju min första undring varför den slår i taket. Vad är orsaken till det? Har du verkligen så många besökare på så kort tid att antalet connections tar slut? vad är det för sajt? I de allra flesta fall beror din typ av problem på att man inte stänger connections på ett korrekt sätt och därför tar de slut. Således löser du inte problemet med ett högre värde, du bara fördröjer det. |
||
![]() |
![]() |
![]() |
#3 | |||
|
||||
Mycket flitig postare
|
Nu kanske jag är ute och cyklar... men detta (stängning) sköts väl automatiskt (kör php) !?
Det jag mycket väl kan ha är några slow-queries som givetvis håller en connection onödigt länge. Men jag jobbar på den saken... Sidan är ett hobby projekt som heter djur.nu (http://www.djur.nu). Som mest har vi haft c:a 200 aktiva användare (räknat inom en 5 minutersperiod) |
|||
![]() |
![]() |
![]() |
#4 | ||
|
|||
Klarade millennium-buggen
|
Testa slå på persistant connections istället, så återanvänder du anslutningarna => drar mindre kraft dessutom (kan ge lite luriga buggar om du använder temporära tabeller, så passa dig lite där).
Annars kan du testa sänka interactive_timeout och wait_timeout i my.cnf så att det inte ligger massa anslutningar och väntar. Edit: jag skriver som vanligt vad jag tänker och inte vad jag menar ![]() |
||
![]() |
![]() |
![]() |
#5 | ||
|
|||
Mycket flitig postare
|
Jo connections skall ju stängas av PHP (om du inte använder persistenta connections).
200 aktiva användare på 5 minuter är ju fel siffra. det hela hänger ju på hur många samtidiga requests du har. personligen är jag mer benägen att misstänka långsamma querys (som du tydligen har) framför att ngn mysql-tweakning verkligen behövs. Dessutom har väl apache en inställning för max antal requests som samtidigt kan hanteras... |
||
![]() |
![]() |
![]() |
#6 | |||
|
||||
Flitig postare
|
max connections slår i taket även på persistenta, det har vi råkat ut för flera gånger. Tror vi höjde värdet till 250 och sen kom aldrig det problemet tillbaka, men kolla man graferna så pekade de på mellan 100-150 samtida connections med persistena.
Burken i fråga var en rackserver 2.8, 1gb minne... Dvs. en "halvbra", men inget vidunder direkt. Vi ändrade sedan och tog BORT persistenta, mot vanlig med mysql_close (var bara att ändra på ett ställe i koden då alla frågor mot databasen går via samma funktion) och nu ser graferna MYCKET trevligare ut. Mellan 10-15 samtida connections istället... |
|||
![]() |
![]() |
![]() |
#7 | |||
|
||||
Mycket flitig postare
|
Starweb: Ok, det bör betyda att mysql är "sega" med att stänga förbindelsen efter sig (i alla fall med default konfigureringen), omman inte gör det "aktivt".
Jo jag förstår att 200 aktiva inte visar samtidiga databasanrop - hade bara ingen bättre siffra - det var för att ge en ungefärlig bil av hur det ser ut. Du har säkert rätt eg0master, det är bäst att börja med att lägga krut på att optimera mina querys. |
|||
![]() |
![]() |
![]() |
#8 | |||
|
||||
Mycket flitig postare
|
Ta en titt i slow query-loggen. Den avslöjar ganska lätt vilken/vilka querys som är sega.
http://dev.mysql.com/doc/mysql/en/slow-query-log.html |
|||
![]() |
![]() |
![]() |
#9 | |||
|
||||
Bara ett inlägg till!
|
Man kan även ställa in så att slow query log loggar frågor som inte använder sig av index fullt ut.
|
|||
![]() |
![]() |
![]() |
#10 | |||
|
||||
Mycket flitig postare
|
Tack alla
![]() |
|||
![]() |
![]() |
Svara |
|
|