Kom ihåg mig?
Home Menu

Menu


Höga värden mysql, optimering hur?

 
Ämnesverktyg Visningsalternativ
Oläst 2013-04-14, 14:22 #1
olsserik olsserik är inte uppkopplad
Flitig postare
 
Reg.datum: Jul 2007
Inlägg: 300
olsserik olsserik är inte uppkopplad
Flitig postare
 
Reg.datum: Jul 2007
Inlägg: 300
Standard Höga värden mysql, optimering hur?

Hej,
Har en virtuell cloud server med Ubuntu 12.04, 8GB RAM, 4 cores som jag kör en phpbb sajt på. Lokal MySQL.

Men som ni ser på bilden nedan av top (den svarta) så drar mysqld en hel del kraft. Jag har optimerat tabellerna nyligen. Har även en del röda siffror i körningsvariablarna i phpmyadmin (kolla andra bilden nedan).

Detta är värden från när 200 användare är online, ca.

Delar av my.cnf ser ut såhär:

key_buffer = 128M
max_allowed_packet = 16M
thread_stack = 192K
thread_cache_size = 8
myisam-recover = BACKUP
max_connections = 300
table_open_cache = 1000
tmp_table_size = 32M
max_heap_table_size = 32M
query_cache_limit = 4M
query_cache_size = 128M
max_allowed_packet = 16M
key_buffer = 16M

Är det någon som kan komma med några tips så vore jag ytterst tacksam!
Bifogade bilder
Filtyp: jpg top1.jpg (98.4 KB, 21 visningar)
Filtyp: jpg red-variables-phpmyadm.jpg (98.0 KB, 19 visningar)
olsserik är inte uppkopplad   Svara med citatSvara med citat
Oläst 2013-04-14, 14:31 #2
MusikMixen MusikMixen är inte uppkopplad
Bara ett inlägg till!
 
Reg.datum: Feb 2008
Inlägg: 1 527
MusikMixen MusikMixen är inte uppkopplad
Bara ett inlägg till!
 
Reg.datum: Feb 2008
Inlägg: 1 527
Vet inte om den kan hjälpa dig, men testa och se.
http://tools.percona.com
MusikMixen är inte uppkopplad   Svara med citatSvara med citat
Oläst 2013-04-14, 16:54 #3
Björklunds avatar
Björklund Björklund är inte uppkopplad
Mycket flitig postare
 
Reg.datum: Jul 2006
Inlägg: 594
Björklund Björklund är inte uppkopplad
Mycket flitig postare
Björklunds avatar
 
Reg.datum: Jul 2006
Inlägg: 594
Svårt att bara titta på värden så, men de är iaf inte helt fel.
Kör mysqltuner med jämna mellanrum. https://github.com/rackerhacker/MySQLTuner-perl
Björklund är inte uppkopplad   Svara med citatSvara med citat
Oläst 2013-04-14, 22:24 #4
olsserik olsserik är inte uppkopplad
Flitig postare
 
Reg.datum: Jul 2007
Inlägg: 300
olsserik olsserik är inte uppkopplad
Flitig postare
 
Reg.datum: Jul 2007
Inlägg: 300
Hej och tack för tipsen.
Jag körde mysqltunern men den visade inte på några stora grejer.

log slow queries var inte påslaget, funderar på att slå på det och se om det kan ge något.

Är det fler som har tips så tages de emot tacksamt!
olsserik är inte uppkopplad   Svara med citatSvara med citat
Oläst 2013-04-14, 22:47 #5
Clarence Clarence är inte uppkopplad
Administratör
 
Reg.datum: Jan 2003
Inlägg: 1 974
Clarence Clarence är inte uppkopplad
Administratör
 
Reg.datum: Jan 2003
Inlägg: 1 974
Det ser ut som att ditt problem kan vara att du har många frågor som inte är bra indexerade eller där för omfattande selects görs. Två alternativ för att se över det:

- Gå igenom de sidor som laddas flest gånger. Kör EXPLAIN på alla frågor där och se vilka som läser alldeles för många rader. Lätt gjort, du behöver inga specialverktyg. Men mer tidskrävande att faktiskt vara säker på att man kommit åt de värsta frågorna.

- Slå på slow_query_log och sätt den på 0 sekunder en timme eller så. Sen kan du köra pt-query-digest på slow_query-loggen och få fram vilka frågor som är i störst behov av optimering. Riktigt effektivt då du får frågorna som tar mest kraft överst färdigt med ett explain-kommando.

Slår du på slow_query-log till exempelvis 2-10 sekunder är det förvisso bra i drift. Men allt som oftast rör det sig om många frågor som har en lägre exekverings-tid än så var och en för sig.
Clarence är inte uppkopplad   Svara med citatSvara med citat
Oläst 2013-04-15, 00:26 #6
Nerix Nerix är inte uppkopplad
Flitig postare
 
Reg.datum: Oct 2010
Inlägg: 398
Nerix Nerix är inte uppkopplad
Flitig postare
 
Reg.datum: Oct 2010
Inlägg: 398
Problemet med MySQL är att databasen inte är trådad per default (till skillnad från te.x Postgresql). Detta betyder att långsamtgående queries blockar alla andra queries, vilket kan ställa till problem.

Jag skulle försökt få MySQL att köras på flera kärnor, på så sätt kan du lastbalansera din applikation. Själv hade jag detta problem för ett projekt. La ner några dagar på att byta över till pg.

Så här såg övergången ut för mig del.



EDIT: Ser även att MySQL endast använder ~4% ram. 50% vore mer rimligt.

Senast redigerad av Nerix den 2013-04-15 klockan 00:33
Nerix är inte uppkopplad   Svara med citatSvara med citat
Oläst 2013-04-15, 09:50 #7
Clarence Clarence är inte uppkopplad
Administratör
 
Reg.datum: Jan 2003
Inlägg: 1 974
Clarence Clarence är inte uppkopplad
Administratör
 
Reg.datum: Jan 2003
Inlägg: 1 974
Citat:
Ursprungligen postat av Nerix Visa inlägg
Problemet med MySQL är att databasen inte är trådad per default (till skillnad från te.x Postgresql). Detta betyder att långsamtgående queries blockar alla andra queries, vilket kan ställa till problem.

Jag skulle försökt få MySQL att köras på flera kärnor, på så sätt kan du lastbalansera din applikation. Själv hade jag detta problem för ett projekt. La ner några dagar på att byta över till pg.

Så här såg övergången ut för mig del.



EDIT: Ser även att MySQL endast använder ~4% ram. 50% vore mer rimligt.
MySQL liksom pgSQL är trådade men vad du beskriver beror på arkiktekturen för låsningar snarare än trådningen. En mysqld-process har inga problem att effektivt utnyttja ett par kärnor, men liksom med pgSQL, MSSQL eller Oracle skalar den inte linjärt efter X kärnor.

MySQL liksom pgSQL har olika typer av låsningar för olika typer av operationer. Eftersom MySQL nu använder InnoDB som default så har båda två en väldigt lik låsmodell. Med MyISAM däremot så har du en tabelllåsning för writes istället för rad-låsning för InnoDB och pgSQL.

Vilket databassystem som är snabbare för en viss applikation är väldigt olika. Den största skillnaden i prestanda mellan PgSQL och MySQL kommer av att PgSQLs query optimerare är mycket mer kompetent (om än MySQLs förbättras) och för sämre optimerade queries ofta kan prestera bättre. Men det gäller också XtraDB eller MariaDB för vissa typer av queries och last.

Gällande 4% ram så tror jag inte det gör så stor skillnad att öka på det utifrån siffrorna som visats här. Skulle han däremot använda InnoDB skulle det säkerligen både öka prestandan och få större behov av RAM (se föregående talare ... )
Clarence är inte uppkopplad   Svara med citatSvara med citat
Oläst 2013-04-15, 08:36 #8
pelmereds avatar
pelmered pelmered är inte uppkopplad
Har WN som tidsfördriv
 
Reg.datum: May 2010
Inlägg: 1 342
pelmered pelmered är inte uppkopplad
Har WN som tidsfördriv
pelmereds avatar
 
Reg.datum: May 2010
Inlägg: 1 342
Kör du InnoDB eller MyISAM?

Om du kör MyISAM kan du testa att byta till InnoDB(se dock till att göra en backup på hela databasen först!). Sedan kan du testa att höja innodb buffer pool till kanske 4 GB.

Hjälper inte det måste du dyka ner i koden pch optimera dina queries eller lägga på någon applikationscache för att avlasta databasen, t.ex. Memcache eller Redis.
pelmered är inte uppkopplad   Svara med citatSvara med citat
Svara


Aktiva användare som för närvarande tittar på det här ämnet: 1 (0 medlemmar och 1 gäster)
 

Regler för att posta
Du får inte posta nya ämnen
Du får inte posta svar
Du får inte posta bifogade filer
Du får inte redigera dina inlägg

BB-kod är
Smilies är
[IMG]-kod är
HTML-kod är av

Forumhopp


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

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