Profileringsspørringer i MySQL. Hva er "serverlogger", hvordan ser du Mysql-serverlogger, spørringslogger

MySQL-spørringsprofilering er en nyttig teknikk for å analysere den generelle ytelsen til databasebaserte applikasjoner. Når man utvikler mellomstore til store applikasjoner, er det typisk hundrevis av spørringer spredt over en stor kodebase, og databasen behandler mange spørringer per sekund. Uten spørringsprofilering blir det svært vanskelig å fastslå plasseringen og årsakene til forekomsten flaskehalser applikasjoner. Denne opplæringen beskriver noen nyttige spørringsprofileringsteknikker ved å bruke MySQLs innebygde verktøy.

MySQL sakte spørringslogg

MySQL sakte spørringslogg (eller treg spørringslogg) er en logg der MySQL sender trege og potensielt problematiske spørringer.

Denne funksjonen kommer med MySQL, men er deaktivert som standard. MySQL bestemmer hvilke spørringer som skal inkluderes i denne loggen ved hjelp av spesielle variabler som lar deg profilere spørringen basert på ytelseskravene til applikasjonen. Vanligvis blir søk som tar lengre tid å behandle og søk som har feil indekser lagt inn i denne loggen.

Profileringsvariabler

De grunnleggende servervariablene for å konfigurere MySQL sakte spørringslogg er:

slow_query_log global
slow_query_log_file global
long_query_time global/session
log_queries_not_using_indexes global
min_examined_row_limit global/session

slow_query_log – en boolsk variabel for å aktivere eller deaktivere den trege spørringsloggen.

slow_query_log_file – absolutt bane til spørringsloggfilen. Filkatalogen må eies av mysqld-brukeren og ha passende lese- og skrivetillatelser. Mysql-demonen vil mest sannsynlig startes som mysql, men for å være sikker, kjør kommandoen i en Linux-terminal:

ps -ef | grep bin/mysqld | kutt -d" " -f1

Utdataene vil vise gjeldende bruker og mysqld-bruker.

cd /var/log
mkdir mysql
chmod 755 mysql
chown mysql:mysql mysql

• long_query_time – tid i sekunder for å sjekke søkelengden. Hvis verdien er 5, vil alle forespørsler som tar mer enn 5 sekunder å behandle, logges.
• log_queries_not_using_indexes – En boolsk verdi som bestemmer om spørringer som ikke bruker indekser skal logges. Når man analyserer, er slike spørsmål viktige.
• min_examined_row_limit – definerer minimum antall rader som skal analyseres. Med en verdi på 1000 vil alle søk som analyserer færre enn 1000 rader bli ignorert.

MySQL-servervariabler kan settes i MySQL-konfigurasjonsfilen eller dynamisk ved hjelp av brukergrensesnitt eller MySQL-kommandolinjen. Hvis variabler er angitt i konfigurasjonsfilen, vil de vedvare når serveren startes på nytt, men serveren må startes på nytt for å aktivere dem. MySQL-konfigurasjonsfilen er vanligvis plassert i /etc/my.cnf eller /etc/mysql/my.cnf. For å finne konfigurasjonsfilen, skriv inn (det kan hende du må utvide søket til andre rotkataloger):

finn /etc -name my.cnf
finn /usr -name my.cnf

Når du har funnet konfigurasjonsfilen, legg til de nødvendige variablene i seksjonen:

….
slow-query-log = 1
slow-query-log-file = /var/log/mysql/localhost-slow.log
long_query_time = 1
log-queries-not-using-indexes

For at endringene skal tre i kraft, må du starte serveren på nytt. Hvis endringer må aktiveres umiddelbart, still inn variablene dynamisk:

mysql> SET GLOBAL slow_query_log = "PÅ";
mysql> SET GLOBAL slow_query_log_file = "/var/log/mysql/localhost-slow.log";
mysql> SET GLOBAL log_queries_not_using_indexes = "PÅ";
mysql> SET SESSION long_query_time = 1;
mysql> SET SESSION min_examined_row_limit = 100;

Slik kontrollerer du variabelverdier:

mysql> VIS GLOBALE VARIABLER SOM "slow_query_log";
mysql> VIS ØKTVARIABLER SOM "long_query_time";

En av ulempene med å dynamisk endre MySQL-variabler er at variablene vil gå tapt når serveren startes på nytt. Derfor bør alle viktige variabler som må lagres legges til filen.

Generering av en profileringsforespørsel

Nå er du kjent med innstillingene for treg spørringslogg. Prøv å generere spørringsdata for profilering.

Merk: Eksemplet gitt her ble kjørt på en MySQL-forekomst som kjører uten at noen trege spørringslogger er konfigurert. Disse testspørringene kan kjøres via GUI eller kommandolinje MySQL.

Når du overvåker loggen over trege forespørsler, er det nyttig å åpne to terminalvinduer: en tilkobling for sending MySQL-uttalelser, og den andre er for å vise forespørselsloggen.

Logg inn på MySQL-serveren ved å bruke konsollen som en bruker med SUPER ADMIN-rettigheter. For å komme i gang, opprett en testdatabase og tabell, legg til dummy-data og aktiver langsom spørringslogging.

Merk: Ideelt sett kjøres dette eksemplet best i et miljø uten andre applikasjoner som bruker MySQL for å unngå rot i spørringsloggen.

$> mysql -u -p
mysql> CREATE DATABASE profile_sampling;

mysql> USE profile_sampling;

mysql> CREATE TABLE-brukere (id TINYINT PRIMARY KEY AUTO_INCREMENT, navn VARCHAR(255));

mysql> INSERT INTO brukere (navn) VERDIER ("Walter"),("Skyler"),("Jesse"),("Hank"),("Walter Jr."),("Marie"),("Saul") "),("Gustavo"),("Hector"),("Mike");

mysql> SET GLOBAL slow_query_log = 1;

mysql> SET GLOBAL slow_query_log_file = "/var/log/mysql/localhost-slow.log";

mysql> SET GLOBAL log_queries_not_using_indexes = 1;

mysql> SET long_query_time = 10;

mysql> SET min_examined_row_limit = 0;

Nå har du en testdatabase og en tabell med noen data. Sakte spørringslogg er aktivert. Vi satte bevisst inn forespørselsbehandlingstiden til høy og deaktiverte radtellingskontrollen. For å se loggen, skriv inn:

cd /var/log/mysql
ls -l

Foreløpig skal det ikke være en logg over trege forespørsler i mappen, siden dette øyeblikket det var ingen forespørsler. Hvis en slik logg allerede eksisterer, betyr dette at databasen allerede har støtt på trege spørringer siden du aktiverte støtte for den trege spørringsloggen. Dette kan skjeve resultatene av dette eksemplet. Gå tilbake til MySQL-fanen og kjør:

mysql> USE profile_sampling;
mysql> SELECT * FRA brukere WHERE id = 1;

Den utførte spørringen henter ganske enkelt dataene og bruker indeksen til den første nøkkelen fra tabellen. Denne spørringen var rask og brukte en indeks, så den er ikke registrert i den trege spørringsloggen. Gå tilbake til katalogen og kontroller at ingen spørringslogg er opprettet. Gå nå tilbake til MySQL-vinduet og kjør:

mysql>

Denne spørringen bruker ikke en indeks. Nå skal noe slikt dukke opp i loggen /var/log/mysql/localhost-slow.log:

# Tid: 140322 13:54:58

bruk profile_sampling;
SET timestamp=1395521698;

Et eksempel til. Øk minimumsantallet av rader for å analysere og send en forespørsel som dette:

mysql> SET min_examined_row_limit = 100;
mysql> SELECT * FRA brukere WHERE name = "Walter";

Dataene vil ikke bli lagt til i loggen fordi mindre enn 100 rader ble analysert under forespørselen.

Merk: Hvis dataene ikke er lagt til loggen, må du kontrollere flere faktorer. Kontroller først tillatelsene til katalogen der loggen er opprettet. Den må eies av mysqld-brukeren/gruppen og ha chmod 755-privilegier. Du bør da sjekke om det er andre trege spørringsinnstillinger på serveren som overstyrer innstillingene dine. Tilbakestill standardinnstillingene for å fjerne alle trege forespørselsvariabler fra konfigurasjonsfilen og start serveren på nytt. Du kan også dynamisk sette globale variabler til standardverdiene. Hvis du gjør endringer dynamisk, logg ut og logg inn på MySQL igjen for å oppdatere innstillingene.

Analyse av spørringsprofileringsdata

Vurder følgende data:

# Tid: 140322 13:54:58
#User@Host: root@localhost
# Spørretid: 0,000303 Låsetid: 0,000090 Rader_sendt: 1 Rader_undersøkt: 10
bruk profile_sampling;
SET timestamp=1395521698;
SELECT * FRA brukere WHERE name = "Jesse";

Denne oppføringen viser:

• Utførelsestid for spørring
• Hvem sendte den
• Hvor lang tid tok det å behandle forespørselen?
• Lengde
• Hvor mange rader ble returnert
• Hvor mange rader ble analysert

Dette er nyttig fordi enhver forespørsel som bryter ytelseskravene spesifisert i variablene havner i loggen. Dette lar en utvikler eller administrator raskt spore opp forespørsler som ikke fungerer. I tillegg kan spørringsprofileringsdata hjelpe deg med å finne ut hvilke omstendigheter som gjør at applikasjonen din gir dårlige resultater.

Bruker mysqldumpslow

Profilering kan inkluderes i databasebaserte applikasjoner for å sikre moderat dataflyt.

Etter hvert som loggstørrelsen vokser, blir det vanskelig å analysere alle dataene, og problematiske spørringer kan lett gå seg vill i den. MySQL tilbyr et verktøy kalt mysqldumpslow, som hjelper til med å unngå dette problemet ved å dele opp loggen med trege spørringer. Binæren er koblet til MySQL (på Linux), så du kan ganske enkelt kjøre kommandoen:

mysqldumpslow -t 5 -s på /var/log/mysql/localhost-slow.log

Kommandoen kan godta ulike parametere for å tilpasse utdataene. Eksemplet ovenfor viser de 5 beste søkene sortert etter gjennomsnittlig spørretid. Slike strenger er mer lesbare og er også gruppert etter forespørsel.

Antall: 2 Tid=68,34s (136s) Lås=0,00s (0s) Rader=39892974,5 (79785949), root@localhost
VELG PL.pl_tittel, P.side_tittel
FRA side P
INNER JOIN sidelenker PL
PÅ PL.pl_namespace = P.side_namespace
WHERE P.page_namespace = N
…

Utgangen viser følgende data:

• Antall: hvor mange ganger forespørselen ble logget.
• Tid: gjennomsnittlig og total forespørselstid (i parentes).
• Lås: bordlåsetid.
• Rader: Antall rader som returneres.

Kommandoen ekskluderer numeriske verdier og strengverdier, så identiske spørringer med forskjellige WHERE-betingelser behandles som det samme. Mysqldumpslow-verktøyet eliminerer behovet for å kontinuerlig gjennomgå loggen over trege spørringer, i stedet lar deg utføre vanlige automatiske kontroller. Kommandoalternativene mysqldumpslow lar deg kjøre komplekse uttrykk.

Be om sammenbrudd

Et annet profileringsverktøy å huske på er Complex Query Breakdown Tool. Den lar deg identifisere problematiske spørringer i den trege spørringsloggen og kjøre den i MySQL. Først må du aktivere profilering og deretter kjøre spørringen:

mysql> SET SESSION profiling = 1;
mysql> USE profile_sampling;
mysql> SELECT * FRA brukere WHERE name = "Jesse";
mysql> VIS PROFILER;

Når profilering er aktivert, vil SHOW PROFILES vise en tabell som assosierer Query_ID med SQL-uttrykket. Finn Query_ID som tilsvarer spørringen som kjører, og kjør følgende spørring (erstatt # med Query_ID):

mysql> SELECT * FRA INFORMATION_SCHEMA.PROFILING WHERE QUERY_ID=#;

Kommandoen vil returnere en tabell:

SEQ	STAT	VARIGHET
1	starter	0.000046
2	sjekke tillatelser	0.000005
3	åpning av bord	0.000036
…	…	…

STATE er et trinn i spørringskjøringsprosessen, og DURATION er tiden det tar å fullføre dette trinnet på sekunder. Det er ikke veldig nyttig verktøy, men det kan bidra til å avgjøre hvilken del av spørringskjøringen som forårsaker mest ventetid.

Merk Merk: Dette verktøyet skal ikke brukes i et produksjonsmiljø.

Treg ytelse for spørringslogg

Alt som gjenstår er å finne ut hvordan den trege spørringsloggen påvirker ytelsen. Generelt er det trygt å kjøre trege spørringslogger i et produksjonsmiljø; Verken CPU eller I/O skal påvirkes. Du bør imidlertid ha en strategi for å overvåke loggstørrelse for å sikre at loggen ikke blir for stor for filsystem. I tillegg, når du kjører en treg spørringslogg i et produksjonsmiljø, bør du sette long_query_time til 1 eller høyere.

Konklusjon

En langsom spørringslogg kan hjelpe deg med å identifisere problematiske spørringer og evaluere den generelle søkeytelsen. Samtidig kan utvikleren få en detaljert forståelse av hvordan applikasjonen yter MySQL-spørringer. Mysqldumpslow-verktøyet lar deg administrere trege spørringslogger og enkelt integrere dem i utviklingsprosessen din. Ved å identifisere problematiske spørringer kan du optimalisere spørringsbehandlingen for å forbedre ytelsen.

Tagger:

Hendelseslogger er det første og enkleste verktøyet for å bestemme systemstatus og identifisere feil. Det er fire hovedlogger i MySQL:

• Feil logg— standard feillogg som samles inn mens serveren kjører (inkludert start og stopp);
• Binær logg— en logg over alle databasemodifikasjonskommandoer, nødvendig for replikering og sikkerhetskopiering;
• Generell spørrelogg— hovedspørringslogg;
• Logg for sakte spørringer— logg over trege forespørsler.

Feil logg

Denne loggen inneholder alle feil som oppstod mens serveren kjørte, inkludert kritiske feil, samt serveravslutninger, serveroppstarter og advarsler. Det er her du bør starte i tilfelle systemfeil. Som standard sendes alle feil ut til konsollen (stderr), du kan også logge feil til syslog (standard på Debian) eller en separat loggfil:

Log_error=/var/log/mysql/mysql_error.log

# Feil vil bli skrevet til mysql_error.log

Vi anbefaler å holde denne loggen aktivert for raskt å identifisere feil. Og for å forstå hva denne eller den feilen betyr, har MySQL feilverktøyet:

Shell> perror 13 64 OS-feilkode 13: Tillatelse nektet OS-feilkode 64: Maskinen er ikke på nettverket

# Forklarer betydningen av feilkoder

Binær (aka binær) logg

Alle databasemodifikasjonskommandoer er registrert i den binære loggen, nyttig for replikering og bedring.

Den slår seg på slik:

Log_bin = /var/log/mysql/mysql-bin.log expire_logs_days = 5 max_binlog_size = 500M

# Indikerer plassering, levetid og maksimal størrelse fil

Vær oppmerksom på at hvis du ikke skal skalere systemet og implementere feiltoleranse, er det bedre å ikke aktivere den binære loggen. Det er ressurskrevende og reduserer systemytelsen.

Forespørselslogg

Denne loggen inneholder alle mottatte SQL-spørringer og informasjon om klienttilkoblinger. Kan være nyttig for indeksanalyse og optimalisering, i tillegg til å identifisere feilsøkende søk:

General_log_file = /var/log/mysql/mysql.log general_log = 1

# Inkluderer loggen og angir filplasseringen

Du kan også aktivere/deaktivere den mens MySQL-serveren kjører:

SET GLOBAL general_log = "PÅ"; SET GLOBAL general_log = "AV";

# Du trenger ikke å starte serveren på nytt for å bruke den

Sakte forespørselslogg

Loggen er nyttig for å identifisere langsomme, det vil si ineffektive spørringer. Les mer i denne artikkelen.

Viser logger

For å se logger på Debian (Ubuntu) må du kjøre:

# Feillogghale -f /var/log/syslog #Query log tail -f /var/log/mysql/mysql.log # Logg trege forespørsler hale -f /var/log/mysql/mysql-slow.log

# Hvis loggene ikke er spesifisert separat, er de plassert i /var/lib/mysql

Logg rotasjon

Ikke glem å komprimere (arkivere, rotere) loggfiler slik at de tar mindre plass på serveren. For å gjøre dette, bruk verktøyet logrotere ved å redigere konfigurasjonsfilen /etc/logrotate.d/mysql-server:

# - Jeg la alt i én blokk og la til delte skripter, slik at mysql får # flush-logs"d bare én gang. # Ellers ville de binære loggene automatisk øke med n ganger hver dag. # - Feilloggen er foreldet, meldinger går til syslog nå./var/log/mysql.log /var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log(daglig roter 7 missingok opprett 640 mysql adm komprimer delte skript etterroter test -x /usr/bin/mysqladmin || exit 0 # Hvis dette mislykkes, sjekk debian.conf! MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf" if [ -z "`$MYADMIN ping 2>/dev/null`" ]; deretter # Virkelig ingen mysqld eller snarere en manglende debian-sys-maint-bruker? # Hvis dette skjer og ikke er en feil, vennligst rapporter en feil. #if ps cax | grep -q mysqld; deretter if killall -q -s0 -umysql mysqld; deretter avslutt 1 fi else $MYADMIN flush-logs fi endscript )

# Komprimerer og arkiverer nødvendige logger, renser filer

DDL-logg

MySQL opprettholder også en dataspråklogg. Den samler inn data fra operasjoner som DROP_TABLE og ALTER_TABLE. Loggen brukes til å gjenopprette feil som oppstod under slike operasjoner. DDL-logg er en binær fil og er ikke ment å leses av brukeren, så ikke modifiser eller slett den.

Det viktigste

Slå alltid på feilloggen, bruk spørringsloggen for å sjekke applikasjonens tilkobling til databasen, sjekke spørringer og drift. Loggen over trege spørringer er nyttig for å optimalisere MySQL-ytelsen.

Profileringsspørringer i Mysql brukes til å evaluere ytelsen til applikasjonen din. Når du utvikler mellomstore til store applikasjoner, må du håndtere hundrevis av forespørsler fordelt på koden din som utføres hvert sekund. Uten spørringsprofileringsteknikker kan det være svært vanskelig å finne ut hva som gjør at applikasjonens ytelse lider.

Hva er den trege spørringsloggen i MySQL?

MySQL Slow Query Log - en logg som flagger langsomme og potensielt problematiske spørringer. MySQL støtter denne funksjonaliteten som standard, men den er deaktivert. Ved å angi visse servervariabler kan vi spesifisere hvilke forespørsler vi er interessert i. Oftest trenger vi spørringer som krever en viss tid å fullføre, eller spørringer som ikke behandler indekser riktig.

Stille inn profileringsvariabler

Hovedvariabler for å sette opp spørringsloggen:

Slow_query_log G slow_query_log_file G long_query_time G / S log_queries_not_using_indexes G min_examined_row_limit G / S

Kommentar: G - globale variabler, S - systemvariabler

• slow_query_log - boolsk verdi inkludert logg
• slow_query_log_file - absolutt bane til loggfilen. Eieren av katalogen må være en bruker mysqld, og katalogen må ha de riktige lese- og skrivetillatelsene. Oftest kjører mysql-demonen som bruker mysql.

For å sjekke, kjør følgende kommandoer:

Ps-ef | grep bin/mysqld | kutt -d" " -f1

Utdataene fra kommandoen vil gi deg navnet på gjeldende bruker og mysqld-brukeren. Eksempel på oppsett av /var/log/mysql-katalogen:

Cd /var/log sudo mkdir mysql sudo chmod 755 mysql sudo chown mysql:mysql mysql

• long_query_time - tid i sekunder for å sjekke spørringens varighet. For eksempel, med en verdi på 5, vil hver forespørsel som varer i mer enn 5 sekunder bli logget.
• log_queries_not_using_indexes - boolsk verdi, gjør det mulig å lagre spørringer som ikke bruker indekser. Slike spørsmål er svært viktige i analyse.
• min_examined_row_limit - spesifiserer minimumsverdien for antall datarader som skal analyseres. En verdi på 1000 vil ignorere søk som returnerer mindre enn 1000 rader med verdier.

Disse variablene kan settes i MySQL-konfigurasjonsfilen, dynamisk gjennom MySQL GUI eller MySQL-kommandolinjen. Hvis variablene er spesifisert i konfigurasjonsfilen, vil serveren installere dem neste gang den starter. Vanligvis er denne filen plassert på /etc, /usr, /etc/my.cnf eller /etc/mysql/my.cnf. Her er kommandoene for å søke etter konfigurasjonsfilen (noen ganger bør du utvide søket til andre rotkataloger):

Finn /etc -name my.cnf finn /usr -name my.cnf

Når du finner filen, legg til de nødvendige variablene i delen:

; ... slow-query-log = 1 slow-query-log-file = /var/log/mysql/localhost-slow.log long_query_time = 1 log-queries-not-using-indexes ; ingen mening nødvendig her

Endringene trer i kraft bare neste gang du starter MySQL; hvis du trenger å endre parametere dynamisk, bruk andre metoder for å angi variabler:

Mysql> SET GLOBAL slow_query_log = "PÅ"; mysql> SET GLOBAL slow_query_log_file = "/var/log/mysql/localhost-slow.log"; mysql> SET GLOBAL log_queries_not_using_indexes = "PÅ"; mysql> SET SESSION long_query_time = 1; mysql> SET SESSION min_examined_row_limit = 100;

Du kan sjekke verdiene til variabler som følger:

Mysql> VIS GLOBALE VARIABLER SOM "slow_query_log"; mysql> VIS ØKTVARIABLER SOM "long_query_time";

Den største ulempen med en dynamisk installasjon er at verdiene vil gå tapt når systemet starter. Det anbefales å spesifisere viktige parametere i MySQL-konfigurasjonen.

Notatet: Syntaks for dynamisk innstilling av parametere via SET kommando og bruk av konfigurasjonsfilen er litt annerledes, for eksempel slow_query_log / slow-query-log . Du finner en fullstendig beskrivelse av syntaksen i den offisielle DBMS-dokumentasjonen. Option-File-formatet brukes for konfigurasjonsfilen, System Variable Name - variabelnavn når du setter verdier dynamisk.

Generering av data for spørringsprofilering

Vi har gått gjennom hovedpunktene for å sette opp profilering, nå skal vi lage spørringene som interesserer oss. Dette eksemplet ble brukt på en kjørende MySQL-server uten noen foreløpige logginnstillinger. Eksempelspørringer kan startes både gjennom MySQL GUI og DBMS kommandoverktøy. Når du overvåker loggen over trege spørringer, er det vanlig å åpne to vinduer med en tilkobling: ett for å kjøre spørringer, det andre for å se loggen.

$> mysql -u -p mysql> CREATE DATABASE profile_sampling; mysql> USE profile_sampling; mysql> CREATE TABLE-brukere (id TINYINT PRIMARY KEY AUTO_INCREMENT, navn VARCHAR(255)); mysql> INSERT INTO brukere (navn) VERDIER ("Walter"),("Skyler"),("Jesse"),("Hank"),("Walter Jr."),("Marie"),("Saul") "),("Gustavo"),("Hector"),("Mike"); mysql> SET GLOBAL slow_query_log = 1; mysql> SET GLOBAL slow_query_log_file = "/var/log/mysql/localhost-slow.log"; mysql> SET GLOBAL log_queries_not_using_indexes = 1; mysql> SET long_query_time = 10; mysql> SET min_examined_row_limit = 0;

Nå har vi en database med testdata. Vi lanserte profilering, men vi satte bevisst svartid og antall linjer til å være lite. For å se loggen bruk kommandoen:

Cd /var/log/mysql ls -l

I teorien burde ikke loggfilen eksistere ennå, siden vi ikke har gjort spørringer til databasen. Hvis den eksisterer, betyr det at profilering ble konfigurert tidligere, og dette kan forvrenge resultatene av eksemplet. Kjør i konsollen:

Mysql> USE profile_sampling; mysql> SELECT * FRA brukere WHERE id = 1;

Søket vårt bruker Primærnøkkelindeksen fra tabellen. Forespørselen ble behandlet veldig raskt ved hjelp av indeksen, så den skal ikke gjenspeiles i loggen. Vær oppmerksom på at loggfilen ikke skal ha blitt opprettet.

Gjør nå følgende:

Mysql> SELECT * FRA brukere WHERE name = "Jesse";

Her brukte vi ikke indekser. Vi skal nå se denne forespørselen i loggen:

Sudo cat /var/log/mysql/localhost-slow.log # Tid: 140322 13:54:58 # User@Host: root @ localhost # Query_time: 0.000303 Lock_time: 0.000090 Rows_sent: 1 Rows_use profiled_sampling; SET timestamp=1395521698; SELECT * FRA brukere WHERE name = "Jesse";

La oss se på et annet eksempel. Hev linjen på antall linjer i svaret og kjør følgende spørring:

Mysql> SET min_examined_row_limit = 100; mysql> SELECT * FRA brukere WHERE name = "Walter";

Forespørselen vil ikke bli reflektert i loggen, siden vi ikke overskred 100 linjer i svaret på forespørselen.

Notatet: Hvis dataene ikke vises i loggen, må du først og fremst vurdere følgende faktorer. Den første er rettighetene til katalogen der loggfilen er lagret. Gruppen og brukeren må samsvare med mysqld-brukeren, rettighetene må være chmod 755. For det andre kan profilering ha blitt konfigurert tidligere. Fjern eventuelle eksisterende profileringsvariabelverdier fra konfigurasjonsfilen og start serveren på nytt eller still inn variablene dynamisk. Hvis du brukte den dynamiske metoden, vil du avslutte og logge på MySQL-konsollen igjen.

Analyse av spørringsprofileringsdata

Tenk på eksemplet ovenfor:

# Tid: 140322 13:54:58 # Bruker@Vert: root @ lokalvert # Spørretid: 0.000303 Låsetid: 0.000090 Rader_sendt: 1 Rader_undersøkt: 10 bruk profilprøvetaking; SET timestamp=1395521698; SELECT * FRA brukere WHERE name = "Jesse";

Her ser vi:

• Tidspunktet da forespørselen ble startet
• Brukeren som sendte forespørselen
• Forespørsler om åpningstider
• Lås varighet
• Antall valgte rader
• Antall linjer som er analysert

Disse dataene er veldig nyttige, siden vi med dens hjelp kan finne og eliminere årsaken til systemnedgangen. Dessuten vil en MySQL-utvikler eller -administrator alltid kunne se problematiske spørsmål, og jeg vil merke at det er mye raskere å finne dem her enn å studere applikasjonskoden. Med langsiktig profilering kan du overvåke driftsforholdene ved lav hastighet.

Bruker mysqldumpslow

Loggen registrerer hele tiden data; som regel skriver den mye mer enn det som leses fra den. På stor størrelse logg, blir det problematisk å lese den. MySQL inkluderer et verktøy kalt mysqldumpslow som hjelper til med å opprettholde loggintegritet. Selve programmet er kombinert med MySQL (på Linux-systemer). For å bruke den, følg den nødvendige kommandoen og gi den banen til loggfilen:

Sudo mysqldumpslow -t 5 -s på /var/log/mysql/localhost-slow.log

Det er en rekke parametere som hjelper deg med å tilpasse kommandoutgangen. I eksemplet nedenfor vil vi se de siste fem forespørslene sortert etter gjennomsnittlig varighet. Som et resultat blir det mye mer praktisk å lese loggen. (utdata endret for å vise faktiske loggverdier):

Antall: 2 Tid=68,34s (136s) Lås=0,00s (0s) Rader=39892974,5 (79785949), root@localhost VELG PL.pl_title, P.page_title FRA side P INNER JOIN sidekoblinger PL ON PL.pl_namespace = P.pl_namespace WHERE P.page_namespace = N ...

Hva vi ser:

• Antall - antall forekomster av forespørselen i loggen
• Tid - gjennomsnittlig og total forespørselstid
• Lås - bordlåsetid
• Rader - Antall valgte rader

Kommandoen ekskluderer numeriske og strengspørringsdata, noe som betyr at spørringer med samme WHERE-klausul vil bli betraktet som de samme. Takket være dette verktøyet trenger du ikke hele tiden å se på loggen. På grunn av det store antallet kommandoparametere kan du sortere utdataene som du ønsker. Det er også tredjepartsutviklinger med lignende funksjonalitet, for eksempel pt-query-digest.

Be om sammenbrudd

Du bør ta hensyn til et annet verktøy som lar deg bryte ned komplekse søk. Oftest må du ta en spørring fra loggen og deretter kjøre den direkte i MySQL-konsollen. Først må du aktivere profilering og deretter kjøre spørringen:

Mysql> SET SESSION-profilering = 1; mysql> USE profile_sampling; mysql> SELECT * FRA brukere WHERE name = "Jesse"; mysql> VIS PROFILER;

Etter å ha aktivert profilering vil SHOW PROFILES vise en tabell som kobler sammen Query_ID og SQL-uttrykk. Finn den tilsvarende Query_ID og kjør følgende spørring (erstatt # med din Query_ID):

Mysql> SELECT * FRA INFORMATION_SCHEMA.PROFILING WHERE QUERY_ID=#;

Eksempel utgang:

SEKV STAT VARIGHET 1 starter 0,000046 2 sjekketillatelser 0,000005 3 åpningstabeller 0,000036

STAT- et trinn i prosessen med å utføre en forespørsel, VARIGHET- trinnvarighet i sekunder. Dette verktøyet brukes ikke så ofte, men noen ganger kan det være ekstremt nyttig for å finne årsaken til treg søkeytelse.

Detaljert beskrivelse av kolonnene:

Detaljert beskrivelse av trinnene:

Notatet: Dette verktøyet skal ikke brukes i serverproduksjonsmodus, bortsett fra for å analysere spesifikke spørringer.

Treg ytelse for spørringslogg

Det siste spørsmålet er hvordan profilering påvirker ytelsen til serveren som helhet. I produksjonsmodusen til serveren kan du ganske trygt bruke slik logging; det skal ikke påvirke verken CPU eller I/O. Det er imidlertid verdt å være oppmerksom på størrelsen på loggfilen; den bør ikke bli uoverkommelig stor. Jeg vil også merke av erfaring at å sette verdien av long_query_time-variabelen til 1 sekund eller høyere.

Viktig: Du bør ikke bruke profileringsverktøyet - SET profiling = 1 - for å registrere alle forespørsler, dvs. Det anbefales ikke å bruke general_log-variabelen i produktmodus og under tung belastning.

Konklusjon

Søkeprofilering kan hjelpe deg mye med å isolere den problematiske spørringen og vurdere den generelle ytelsen. Utvikleren kan også studere hvordan MySQL-spørringene til applikasjonen hans fungerer. Mysqldumpslow-verktøyet hjelper deg med å vise og behandle spørringslogger. Etter å ha identifisert problematiske søk, gjenstår det bare å justere dem for maksimal ytelse.

Konsept

Serverlogger (loggfiler, serverlogg)- filer lagret på serveren som inneholder systeminformasjon om serveren, samt logging av alle mulige data om den besøkende på nettressursen.

Logger brukes av systemadministratorer til å analysere besøkende, studere atferdsmønstrene til visse grupper av brukere, samt innhente forskjellig informasjon om dem, for eksempel: nettleseren som brukes, IP-adressen, data om klientens geografiske plassering og mye mer. I tillegg til analyse kan du på denne måten finne ut om uautorisert tilgang til nettstedet, finne ut mer nøyaktig hvem som har laget det, og overføre data om denne saken til de aktuelle myndighetene.

Dataene i loggfilen, i sin rene form, vil ikke være forståelig for vanlige brukere, som vil se i alt dette bare et sett med tegn i en uforståelig rekkefølge. Men for systemadministratorer og webutviklere, dette er en veldig lesbar tekst og ganske nyttig informasjon.

En rekke hendelser

Hver gang en klient får tilgang til en nettressurs, utløses flere hendelser samtidig, sekvensen som vi vil snakke om.

1. Foreta en sideforespørsel. Når du skriver inn en adresse i nettleserlinjen, eller når du følger en aktiv nettlenke, for eksempel fra en resultatside i en søkemotor, søker og kobler nettleseren til serveren som siden er plassert på og sender en forespørsel om det. Samtidig overfører den følgende informasjon til serveren:
- IP-adressen til klientdatamaskinen som ber om siden (hvis du bruker en proxy-server, IP-adressen til proxyen din);
- adressen til Internett-siden som brukeren ber om (IP-adresse);
- nøyaktig tid og dato da forespørselen ble gjort;
- data om den faktiske plasseringen til klienten (hvis en proxy-server brukes, da den faktiske proxy-adressen);
- informasjon om nettleseren som brukes av klienten (navn, versjon, etc.);
- data om nettsiden som klienten overførte fra.

2. Overføring av de forespurte dataene. De forespurte dataene (webside, filer, informasjonskapsler osv.) overføres fra serveren til brukerens datamaskin.

3. Skriv til serverloggen. Etter alt oppstår en loggoppføring, som indikerer alle dataene som dukket opp i de to siste hendelsene. Dette er all informasjonen som sendes i første ledd, samt informasjon om de overførte dataene.

Slik viser du serverlogger

Loggfiler lagres i en fil tilgang.logg uansett hvilken type webserver du bruker (Apache, Nginx, squid proxy server, etc.) Denne filen er tekstdokument, på hver linje hvorav en anke er skrevet. Opptaksformater i tilgang.logg ganske mye, men den mest populære er kombinert, der oppføringen har følgende form og sekvens:

Kode: %h %l %u %t \"%r\" %>s %b \"%(Referer)i\" \"%(User-Agent)i\"
Hvor:

%h- vert/IP-adresse som forespørselen ble gjort fra;
%t- tidspunktet for forespørselen til serveren og serverens tidssone;
%r- versjon, innhold og type forespørsel;
%s- HTTP-statuskode;
%b- antall byte sendt av serveren;
%(henviser)- URL-kilde for forespørselen;
%(Bruker agent)- HTTP-header, med informasjon om forespørselen (klientapplikasjon, språk, etc.);
%(Vert)- navnet på den virtuelle verten som er tilgjengelig.

Når du er ferdig, ser denne linjen omtrent slik ut:

127.0.0.1 - - "GET /index.php HTTP/1..0 (kompatibel; MSIE 7.0; Windows NT 5.1)"

Å lese logger manuelt vil ta ganske mye tid og krefter. Derfor bruker erfarne webmastere spesiell programvare kalt "Log File Analyzers". De analyserer alle dataene, noe som er ganske vanskelig for mennesker å lese, og produserer strukturerte data. Dette er programmer som: Analog, WebAnalizer, Webalizer, Awstats, Webtrends, etc. Typer spesielle programvare ganske mye, blant dem er det like betalte programmer, og gratis. Derfor er jeg sikker på at alle vil finne noe de liker.

Hvor finner du nettstedslogger

Hvis du har vanlig hosting, må du mest sannsynlig skrive til hosteren din og be om logger fra ham. Også ganske ofte kan du be om dem gjennom vertspanelet. Ulike hostere gjør det forskjellig. For eksempel, for å be om fra hosteren min, klikker du bare på hjemmeside paneler:

Hvis du har tilgang til systemmapper server, så finner du loggene på /etc/httpd/logs/access_log i 99 tilfeller av 100.

Feillogg error.log

Feil logg- en fil der logger også oppbevares. Men ikke besøkende, men feil som oppsto på serveren. Som tilfellet er med tilgang.logg, er hver linje i filen ansvarlig for én feil som oppstod. Opptaket utføres under hensyntagen til informasjon som: eksakt dato og klokkeslett for feilen, IP-adressen som feilen ble utstedt til, typen feil, samt årsaken til at den oppsto.

Konklusjon

Logger er et ganske kraftig og informativt verktøy å jobbe med. Men i dag erstattes de av verktøy som Yandex.Metrica, Google Analytics, etc., og gjør dermed livene våre enklere. Men hvis du planlegger å utvikle deg, vokse og lære noe nytt, anbefaler jeg absolutt at du blir bedre kjent med dette temaet.