WN

WN (https://www.wn.se/forum/index.php)
-   Serversidans teknologier (https://www.wn.se/forum/forumdisplay.php?f=4)
-   -   mysql problem (https://www.wn.se/forum/showthread.php?t=4973)

fabian 2004-12-13 21:13
Har sagt det förut, men säger det igen.

Jag har problem med min SQL server. Den tar ofta upp 99.9% CPU power, hela servern blir slö.

Det är en p4 2.8 ghz, 1 gb ram, som i princip bara kör Apache och mysql.

Är i desperat behov av hjälp att hitta flaskhalsen i mitt system. Här är "Körningsinformation" från sql servern, skall det se ut såhär?

http://www.6y.se/sqlserver.gif

anders.n 2004-12-13 22:09
18 frågor i sekunden är väl relativt mycket, beroende på hur tunga frågorna är.. Dock, i genomsnitt 5K per fråga låter mycket.. men, jag har ingen koll alls på sådan statistik..

Du borde kolla upp möjligheten att använda cache på serversidan (otroligt trevligt), och kontrollera vilka dina "tyngsta" frågor är, och se om du kan optimera dem.. (inte returnera onödiga kolumner, använda TOP om du bara är intresserade av vissa resultat, index, kolla runt med analyze/check/explain, etc, etc, etc)

fabian 2004-12-13 22:34
Vad innebär "Avbrutna" uppkopplingar?

Skall verkligen så stor del av alla uppkopplingar vara avbrutna?

Robert 2004-12-13 23:46
Citat:
Originally posted by anders.n@Dec 13 2004, 23:09
använda TOP om du bara är intresserade av vissa resultat, index, kolla runt med analyze/check/explain, etc, etc, etc)
btw, TOP minskar storleken på recordsetet men ökar på tiden det tar att köra queryn (dock minimalt). Beror lite på vart du vill optimera iofs.

Kanske ska se över dina joins, ev bryta ut vissa data i nya tabeller, speciellt om de söks i via LIKE '% då ett index inte är till någon nytta.

grazzy 2004-12-14 00:52
uhh.. index gör väl nytta med like??

SkyNet 2004-12-14 08:15
Körningsinformationen som du skickade med ger inte så mycket information, men 18 queries/sekund är inte alls mycket.

Skulle jag optimera skulle jag börja med att;

a) Ladda hem mytop från http://jeremy.zawodny.com/mysql/mytop/ för att kolla vilka queries som körs samt hur lång tid de tar.
B) Slå på log-slow-queries + long_query_time=5 i my.cnf (antar att du kör MySQL 4.x ?).
c) Definitivt använda query cachen.

Sedan kan man ha en lång utläggning om olika inställningar i konfigurationen osv. Du kan även kolla vilka tabeller som används mest, går dessa att optimera? Kanske det inte går, utan du behöver mer minne i servern, tuggar den mycket swap minne?

zoran 2004-12-14 09:11
Citat:
Originally posted by fabian@Dec 13 2004, 23:34
Vad innebär "Avbrutna" uppkopplingar?

Skall verkligen så stor del av alla uppkopplingar vara avbrutna?
*vild gissning*

Du struntar i att använda mysql_close() i sina hack?

*/vild gissning*

En sak som bidrar till "hastigheten" är att använda persistenta uppkopplingar. (Då behöver du inte mysql_close())

En annan sak är om man använder PHP5 är att använda mysqli-funktionerna istället för mysql och däribland mysqli_prepare() för sina mest frekventa querys.

/Zoran

fabian 2004-12-14 17:32
Citat:
Ursprungligen postat av zoran
Citat:
Ursprungligen postat av fabian
Vad innebär "Avbrutna" uppkopplingar?

Skall verkligen så stor del av alla uppkopplingar vara avbrutna?
*vild gissning*

Du struntar i att använda mysql_close() i sina hack?

*/vild gissning*

En sak som bidrar till "hastigheten" är att använda persistenta uppkopplingar. (Då behöver du inte mysql_close())

En annan sak är om man använder PHP5 är att använda mysqli-funktionerna istället för mysql och däribland mysqli_prepare() för sina mest frekventa querys.

/Zoran
Nej, det är mysql_close() överallt. Ändrade dock nyss till mysql_pconnect, men har fortfarande kvar mysql_close() i koden, borde jag ta bort det?

fabian 2004-12-14 17:39
Citat:
Originally posted by SkyNet@Dec 14 2004, 09:15
Körningsinformationen som du skickade med ger inte så mycket information, men 18 queries/sekund är inte alls mycket.

Skulle jag optimera skulle jag börja med att;

a) Ladda hem mytop från http://jeremy.zawodny.com/mysql/mytop/ för att kolla vilka queries som körs samt hur lång tid de tar.
B) Slå på log-slow-queries + long_query_time=5 i my.cnf (antar att du kör MySQL 4.x ?).
c) Definitivt använda query cachen.

Sedan kan man ha en lång utläggning om olika inställningar i konfigurationen osv. Du kan även kolla vilka tabeller som används mest, går dessa att optimera? Kanske det inte går, utan du behöver mer minne i servern, tuggar den mycket swap minne?
Får en ENORM logfil med slow_queries...

Citat:

# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 18 *Lock_time: 0 *Rows_sent: 0 *Rows_examined: 26506
SELECT * FROM commenttable WHERE name='2493' ORDER BY id DESC LIMIT 2;
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 18 *Lock_time: 0 *Rows_sent: 2 *Rows_examined: 22482
SELECT * FROM commenttable WHERE name='2607' ORDER BY id DESC LIMIT 2;
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 18 *Lock_time: 0 *Rows_sent: 0 *Rows_examined: 26506
SELECT * FROM commenttable WHERE name='3815' ORDER BY id DESC LIMIT 2;
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 18 *Lock_time: 0 *Rows_sent: 0 *Rows_examined: 26506
SELECT * FROM commenttable WHERE name='18490' ORDER BY id DESC LIMIT 2;
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 18 *Lock_time: 0 *Rows_sent: 0 *Rows_examined: 26506
SELECT * FROM commenttable WHERE name='17112' ORDER BY id DESC LIMIT 2;
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 18 *Lock_time: 0 *Rows_sent: 2 *Rows_examined: 13301
SELECT * FROM commenttable WHERE name='122' ORDER BY id DESC LIMIT 2;
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 18 *Lock_time: 0 *Rows_sent: 0 *Rows_examined: 26506
SELECT * FROM commenttable WHERE name='8664' ORDER BY id DESC LIMIT 2;
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 26 *Lock_time: 0 *Rows_sent: 1 *Rows_examined: 26506
SELECT * FROM commenttable WHERE name='20057' ORDER BY id DESC LIMIT 2;
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 15 *Lock_time: 0 *Rows_sent: 1 *Rows_examined: 26506
SELECT * FROM commenttable WHERE name='92' ORDER BY id DESC LIMIT 2;
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 18 *Lock_time: 0 *Rows_sent: 3 *Rows_examined: 11036
select url, id from imagetable where name = 'sandra i (y)' order by average desc;
SELECT id FROM imagetable WHERE status = 'active';
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 619 Lock_time: 611 Rows_sent: 11021 Rows_examined: 11035
SELECT id FROM imagetable WHERE status = 'active';
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 619 Lock_time: 611 Rows_sent: 11021 Rows_examined: 11035
SELECT id FROM imagetable WHERE status = 'active';
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 560 Lock_time: 552 Rows_sent: 11021 Rows_examined: 11035
SELECT id FROM imagetable WHERE status = 'active';
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 558 Lock_time: 550 Rows_sent: 11021 Rows_examined: 11035
SELECT id FROM imagetable WHERE status = 'active';
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 555 Lock_time: 547 Rows_sent: 11021 Rows_examined: 11035
SELECT id FROM imagetable WHERE status = 'active';
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 551 Lock_time: 543 Rows_sent: 10 Rows_examined: 12549
SELECT name, id, url, MAX(average) as average, total FROM imagetable WHERE category = 'Tjejer' and total >= 20 and status = 'active' group
by name order by average DESC LIMIT 0,10;
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 529 Lock_time: 521 Rows_sent: 11021 Rows_examined: 11035
SELECT id FROM imagetable WHERE status = 'active';
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 522 Lock_time: 514 Rows_sent: 11021 Rows_examined: 11035
SELECT id FROM imagetable WHERE status = 'active';
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 605 Lock_time: 597 Rows_sent: 11021 Rows_examined: 11035
SELECT id FROM imagetable WHERE status = 'active';
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 600 Lock_time: 592 Rows_sent: 11021 Rows_examined: 11035
SELECT id FROM imagetable WHERE status = 'active';
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 634 Lock_time: 626 Rows_sent: 11021 Rows_examined: 11035
SELECT id FROM imagetable WHERE status = 'active';
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 625 Lock_time: 617 Rows_sent: 11021 Rows_examined: 11035
SELECT id FROM imagetable WHERE status = 'active';
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 605 Lock_time: 597 Rows_sent: 11021 Rows_examined: 11035
SELECT id FROM imagetable WHERE status = 'active';
# Query_time: 384 Lock_time: 376 Rows_sent: 11019 Rows_examined: 11036
SELECT id FROM imagetable WHERE status = 'active';
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 383 Lock_time: 375 Rows_sent: 10 Rows_examined: 12684
SELECT name, id, url, MAX(average) as average, total FROM imagetable WHERE category = 'Tjejer' and status = 'active' group by name order b
y id DESC LIMIT 60,10;
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 381 Lock_time: 374 Rows_sent: 11019 Rows_examined: 11036
SELECT id FROM imagetable WHERE status = 'active';
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 374 Lock_time: 367 Rows_sent: 10 Rows_examined: 12674
SELECT name, id, url, MAX(average) as average, total FROM imagetable WHERE category = 'Tjejer' and status = 'active' group by name order b
y id DESC LIMIT 50,10;
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 370 Lock_time: 363 Rows_sent: 10 Rows_examined: 16509
SELECT name, id, url, MAX(average) as average, total FROM imagetable WHERE status = 'active' and total >= 20 group by name order by averag
e DESC LIMIT 0,10;
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 369 Lock_time: 362 Rows_sent: 10 Rows_examined: 16519
SELECT name, id, url, MAX(average) as average, total FROM imagetable WHERE status = 'active' and total >= 20 group by name order by averag
e DESC LIMIT 10,10;
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 367 Lock_time: 360 Rows_sent: 10 Rows_examined: 11866
SELECT name, id, url, MAX(average) as average, total FROM imagetable WHERE category = 'Nakna killar' and status = 'active' group by name o
rder by id DESC LIMIT 0,10;
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 367 Lock_time: 360 Rows_sent: 10 Rows_examined: 16519
SELECT name, id, url, MAX(average) as average, total FROM imagetable WHERE status = 'active' and total >= 20 group by name order by averag
e DESC LIMIT 10,10;
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 363 Lock_time: 356 Rows_sent: 10 Rows_examined: 12700
SELECT name, id, url, MAX(average) as average, total FROM imagetable WHERE category = 'Tjejer' and total >= 20 and status = 'active' group
by name order by average DESC LIMIT 150,10;
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 361 Lock_time: 354 Rows_sent: 11019 Rows_examined: 11036
SELECT id FROM imagetable WHERE status = 'active';
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 359 Lock_time: 352 Rows_sent: 10 Rows_examined: 11059
SELECT name, id, url, MAX(average) as average, total FROM imagetable WHERE category = 'Naken.ORG' and total >= 20 and status = 'active' gr
oup by name order by average DESC LIMIT 0,10;
# User@Host: fabmos[fabmos] @ localhost []
Där är ett litet utkast ur den... är det någor speciellt jag skall leta efter?

David 2004-12-14 18:37
Citat:
Originally posted by fabian@Dec 14 2004, 18:39
Där är ett litet utkast ur den... är det någor speciellt jag skall leta efter?
Du skulle ju kunna använda något endaste litet index NÅGONSTANS... :lol: Du har ju full table scans överallt!

fabian 2004-12-14 18:39
Citat:
Ursprungligen postat av David
Citat:
Ursprungligen postat av fabian
Där är ett litet utkast ur den... är det någor speciellt jag skall leta efter?
Du skulle ju kunna använda något endaste litet index NÅGONSTANS... :lol: Du har ju full table scans överallt!
Det här med mysql är inte riktigt min grej (som ni kanske har förstått).

Har du lust att förklara idiotenkelt? Eller ge ett konkret exempel?

David 2004-12-14 18:54
Citat:
Originally posted by fabian@Dec 14 2004, 19:39
Har du lust att förklara idiotenkelt? Eller ge ett konkret exempel?
Jag skulle föreslå att du läser en bok om databashantering, det här är riktigt grundläggande grejer. Jag orkar inte gå igenom det är jag rädd, finns mycket att läsa på internet.

kullervo 2004-12-14 19:49
Citat:
Ursprungligen postat av David
Citat:
Ursprungligen postat av fabian
Har du lust att förklara idiotenkelt? Eller ge ett konkret exempel?
Jag skulle föreslå att du läser en bok om databashantering, det här är riktigt grundläggande grejer. Jag orkar inte gå igenom det är jag rädd, finns mycket att läsa på internet.
Jag rekomenderar MySQL-manualen också. Den är riktigt bra.

zoran 2004-12-14 21:00
Citat:
Originally posted by fabian@Dec 14 2004, 18:32
Nej, det är mysql_close() överallt. Ändrade dock nyss till mysql_pconnect, men har fortfarande kvar mysql_close() i koden, borde jag ta bort det?
Ja det borde du. Mysql_close() fungerar inte ens på persistenta koppel om jag inte missminner mig helt.

/Zoran

zoran 2004-12-14 21:02
Citat:
Originally posted by David@Dec 14 2004, 19:54
Jag skulle föreslå att du läser en bok om databashantering, det här är riktigt grundläggande grejer. Jag orkar inte gå igenom det är jag rädd, finns mycket att läsa på internet.
Dessutom verkar det som att han skulle ha rätt mycket nytta av "Improved mysql functions", bla mysqli_prepare().

/Zoran

grazzy 2004-12-14 23:19
Det står att du har en locktime som nästan är lika hög som hela frågetiden, det innebär att dina läsningar blir fördröjda av att någon skriver till tabellen.

Detta kan lösas genom att du kör low priority på updates / inserts, då körs selects före dem. Och som sagt, gör om name till en intistället och skapa index.

SkyNet 2004-12-14 23:45
Citat:
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 18 *Lock_time: 0 *Rows_sent: 0 *Rows_examined: 26506
SELECT * FROM commenttable WHERE name='17112' ORDER BY id DESC LIMIT 2;
Om man tar ovanstående som exempel så har du troligen inte något index satt på 'namn' eftersom den måste leta igenom alla radera i tabellen trots att den bara ska hämta två stycken rader.

Citat:
# User@Host: fabmos[fabmos] @ localhost []
# Query_time: 619 *Lock_time: 611 *Rows_sent: 11021 *Rows_examined: 11035
SELECT id FROM imagetable WHERE status = 'active';
Databasfrågor som tar över 10 minuter att köra dödar servern rätt snabbt. Om inte annat så har användaren ledsnat för länge länge sedan. Här skulle jag istället för 'active' använda mig av '1' eftersom det tar mindre plats och är lättare att indexera för MySQL. Den här frågan ska du koncentrera dig på först.

Generellt kan man säga att du bör i möjligaste mån ha index på de kolumner som du vill använda som urval (exempel: WHERE gender = '1')

Lär dig lite mer saker om just tabellstrukturen och vad som är bäst att göra där. Antingen söker du via Google eller så kikar du på http://forums.devshed.com där du kan hitta det mesta och även få hjälp med frågor.

SkyNet 2004-12-14 23:50
Citat:
Originally posted by fabian@Dec 13 2004, 23:34
*vild gissning*
Du struntar i att använda mysql_close() i sina hack?
*/vild gissning*
Använder man mysql_connect() i sina program som är bra skriva så behöver man inte mysql_close() eftersom uppkopplingen automatiskt stängs när php-scriptet avslutas. Problemet med hans program är att databasfrågor drar ut så på tiden att de avbryts...

Robert 2004-12-15 13:08
Citat:
Originally posted by grazzy@Dec 14 2004, 01:52
uhh.. index gör väl nytta med like??
exempel "LIKE '%apa%' " tvingar ju db'n att lik förbenat snurra igenom allt data i kolumnen, oavsett om en index har förberett kolumnen i sorterad ordning etc.

taddis 2004-12-15 15:06
Ett tips är att börja med att normalisera din databas.
Googlade en snabbis o hittade detta:

http://www.gslis.utexas.edu/~l384k11w/normstep.html

grazzy 2004-12-15 18:59
Citat:
Ursprungligen postat av Robert
Citat:
Ursprungligen postat av grazzy
uhh.. index gör väl nytta med like??
exempel "LIKE '%apa%' " tvingar ju db'n att lik förbenat snurra igenom allt data i kolumnen, oavsett om en index har förberett kolumnen i sorterad ordning etc.
Mjaa..

http://dev.mysql.com/doc/mysql/en/CREATE_INDEX.html

Citat:

Because most names usually differ in the first 10 characters, this index should not be much slower than an index created from the entire name column. Also, using partial columns for indexes can make the index file much smaller, which could save a lot of disk space and might also speed up INSERT operations!
Det där tolkar jag som att det gör nytta att indexera även textfält, det är klart att det aldrig blir lika effektivt som med en integer. Jag skulle tippa på att dom gör om indextexten till ett hashvärde som sedan lagras i en hashtabell.

Tex:
Kod:
hash_value pekare_till_värde
123        1,2,3
321        4,5,6
När då tex värdena i 1,2,3 får hashvärdet "123" och värdena i 4,5,6 får hashvärdet "321", det är då mycket snabbare att söka i detta index än att söka i hela tabellen.

Robert 2004-12-15 19:19
Citat:
Ursprungligen postat av grazzy
Citat:
Originally posted by -Robert@Dec 15 2004, 14:08
Citat:
Ursprungligen postat av grazzy
uhh.. index gör väl nytta med like??
exempel "LIKE '%apa%' " tvingar ju db'n att lik förbenat snurra igenom allt data i kolumnen, oavsett om en index har förberett kolumnen i sorterad ordning etc.

Mjaa..

http://dev.mysql.com/doc/mysql/en/CREATE_INDEX.html

Citat:

Because most names usually differ in the first 10 characters, this index should not be much slower than an index created from the entire name column. Also, using partial columns for indexes can make the index file much smaller, which could save a lot of disk space and might also speed up INSERT operations!
Det där tolkar jag som att det gör nytta att indexera även textfält, det är klart att det aldrig blir lika effektivt som med en integer. Jag skulle tippa på att dom gör om indextexten till ett hashvärde som sedan lagras i en hashtabell.

Tex:
Kod:
hash_value *pekare_till_värde
123 * * * * * * * 1,2,3
321 * * * * * * * 4,5,6
När då tex värdena i 1,2,3 får hashvärdet "123" och värdena i 4,5,6 får hashvärdet "321", det är då mycket snabbare att söka i detta index än att söka i hela tabellen.
Jupp, men en LIKE med texten inuti den sökbara datan kan ju inte få ett hashvärde...det finns liksom inget att gå efter. Söker man efter %apa% i data som ser ut som "min fina apa Gustav" så spelar indexeringen ingen roll...såtillvida inte alla tänkbara kombinationer av av datat är indexerat (hemska tanke). Så har jag fått lära mig iaf... =)

grazzy 2004-12-15 20:15
Det stämmer rimligen eftersom man anger längden på indexet.

Robert 2004-12-15 20:44
Citat:
Originally posted by grazzy@Dec 15 2004, 21:15
Det stämmer rimligen eftersom man anger längden på indexet.
...men inte då du har ett % framför söksträngen :rolleyes:

zoran 2004-12-16 00:05
Citat:
Originally posted by taddis@Dec 15 2004, 16:06
Ett tips är att börja med att normalisera din databas.
Googlade en snabbis o hittade detta:

http://www.gslis.utexas.edu/~l384k11w/normstep.html
Om man nu ska läsa något om databaser så vill jag rekomendera den överlägsna och mycket kompetenta kursen av Thomas Padron McCarthy på:

http://www.ida.liu.se/~tompa/databaser/


/Zoran

taddis 2004-12-16 10:27
Citat:
Ursprungligen postat av zoran
Citat:
Ursprungligen postat av taddis
Ett tips är att börja med att normalisera din databas.
Googlade en snabbis o hittade detta:

http://www.gslis.utexas.edu/~l384k11w/normstep.html
Om man nu ska läsa något om databaser så vill jag rekomendera den överlägsna och mycket kompetenta kursen av Thomas Padron McCarthy på:

http://www.ida.liu.se/~tompa/databaser/


/Zoran
Den sidan var bättre ja. Skoj att du nämnar just Thomas Padron McCarthy då jag faktiskt hade honom i mina databaskurser. Du också?

zoran 2004-12-17 00:33
Citat:
Ursprungligen postat av taddis
Citat:
Originally posted by -zoran@Dec 16 2004, 01:05
Citat:
Ursprungligen postat av taddis
Ett tips är att börja med att normalisera din databas.
Googlade en snabbis o hittade detta:

http://www.gslis.utexas.edu/~l384k11w/normstep.html
Om man nu ska läsa något om databaser så vill jag rekomendera den överlägsna och mycket kompetenta kursen av Thomas Padron McCarthy på:

http://www.ida.liu.se/~tompa/databaser/


/Zoran

Den sidan var bättre ja. Skoj att du nämnar just Thomas Padron McCarthy då jag faktiskt hade honom i mina databaskurser. Du också?
Nej, tyvärr har jag inte haft det privilegiet ännu. Däremot känner jag honom från LysKOM.

/Zoran


Alla tider är GMT +2. Klockan är nu 13:41.

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