trace route mot MySql-server

[dick_a]

Tänker jag rätt nu? Jag har problem med långa svarstider ibland när data ska hämtas eller läggas till i en MySql-databas. Själva hemsidan (med php-skripten) ligger på en server och MySql-databasen på en annan. Supporten ber mig forska i detta och göra en "trace route" mot databasservern. Själv tycker jag att det verkar vara helt meningslöst. Det är väl skripten som ligger på deras web-server som anropar deras databas-server. Jag har väl aldrig någon direkt koppling med databasservern, utan endast med web-servern eller? 

[.M]

Stämmer. För att din trace ska ge relevanta resultat så måste du göra den från webservern till databas-servern.

[Thomas Tydal]

Jag tvivlar starkt på att svarstiderna skulle ha något med nätverket att göra. Mer troligt har det med hur databastabellerna och frågorna ser ut. Om du t.ex. har MyISAM-tabeller så har de ju table-locking, dvs medan något läggs in i tabellen så är den helt låst och alla som ska hämta något därifrån måste vänta. Och om någon håller på att hämta medan något ska läggas in, ja då kan det inte börja läggas in förrän alla som började hämta innan har hämtat klart. Och alla nytillkommande hämtningar pausas tills datat är inlagt.

 

Har du MyISAM och det förekommer att data läggs in eller ändras, byt till InnoDB.

 

Om det skulle vara så att det tar lång tid att hämta data så kan det vara så att frågorna behöver formuleras om på ett smartare sätt, så de hämtar datat snabbare, oftast innebär det att man sätter upp något annat index eller kanske till och med skapar en ny tabell.

 

Om du kan ansluta till databasen, eller har en möjlighet att ställa frågor via något webbgränssnitt så kika på följande:

 

SHOW PROCESSLIST; (visar vilka frågor som behandlas just nu, hur många sekunder de har varit igång och vilken status de har. Har du en massa frågor som har status "locked" så har du förklaringen till väntetiderna där. "Locked" innebär ju just att databasen inte gör något med den frågan, utan den väntar bara).

 

EXPLAIN följt av en SQL-fråga visar hur databasen kommer att behandla frågan, hur många rader den behöver söka igenom i respektive tabell och om något index används.

[dick_a]

Oj! Mycket nytt och bra där, tack! ....men om vi säger så här; att när en enkel fråga i 99 fall av hundra går på mindre än en tusendels sekund så kan den samma ta 20 sekunder vid ett annat tillfälle. Känns som orimlig tid även om tabellen skulle vara låst för tillfället. Kan ju också tillägga att det i stort sett aldrig är mer än en användare inne och jobbar mot databasen och att domänen ligger på en server hos ipeer och att kontot är av den typ där flera domäner delar på en fysisk server. Finns det med denna information något att tillägga eller justera med tanke på ditt tidigare svar.

[.M]

Om flera olika kunder använder samma databasserver så kan det mycket väl vara så att någon annan kund har gjort något korkat.

 

Ponera till exempel att en kund har en databas med log-information och någon gång eller några gånger per dygn gör ett stort jobb för att hämta ut spännande information ur dessa loggar.

 

Då skulle du uppleva det som att helt plötsligt så går din databas långsamt för att sedan piggna till och fungera jättefint.