дома › Образование › Профилирање на прашања во MySQL. Што се „дневниците на серверот“, како да ги прегледате дневниците на серверот Mysql, дневниците за пребарување

Профилирање на прашања во MySQL. Што се „дневниците на серверот“, како да ги прегледате дневниците на серверот Mysql, дневниците за пребарување

Профилирањето на прашањата за MySQL е корисна техника за анализа на севкупните перформанси на апликациите базирани на бази на податоци. Кога се развиваат средни до големи апликации, обично има стотици барања распоредени низ голема база на кодови, а базата на податоци обработува многу прашања во секунда. Без профилирање на барање, станува многу тешко да се одреди локацијата и причините за појава тесни грлаапликации. Овој туторијал опишува некои корисни техники за профилирање на барања користејќи ги вградените алатки на MySQL.

MySQL бавен дневник за пребарување

MySQL бавниот дневник за пребарување (или бавен дневник за пребарување) е дневник каде што MySQL испраќа бавни и потенцијално проблематични прашања.

Оваа функција доаѓа со MySQL, но стандардно е оневозможена. MySQL одредува кои барања треба да бидат вклучени во овој дневник со помош на специјални променливи кои ви дозволуваат да го профилирате барањето врз основа на барањата за изведба на апликацијата. Вообичаено, прашањата за кои е потребно подолго време да се обработат и прашањата кои имаат неточни индекси се внесуваат во овој дневник.

Профилирање на променливи

Основните променливи на серверот за конфигурирање на бавниот дневник за пребарување на MySQL се:

slow_query_log глобално
slow_query_log_file глобална
long_query_time глобално/сесија
log_queries_not_using_indexes глобални
min_examined_row_limit глобална/сесија

slow_query_log – логичка променлива за овозможување или оневозможување на бавниот дневник за пребарување.

slow_query_log_file – апсолутна патека на датотеката за евиденција за барање. Директориумот на датотеки мора да биде во сопственост на корисникот mysqld и да има соодветни дозволи за читање и пишување. Демонот на mysql најверојатно ќе биде стартуван како mysql, но за да бидете сигурни, извршете ја командата во терминал на Linux:

ps -ef | grep bin/mysqld | сече -d" " -f1

На излезот ќе се прикаже тековниот корисник и корисникот mysqld.

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

long_query_time – време во секунди за проверка на должината на барањето. Ако вредноста е 5, ќе се евидентираат сите барања на кои им се потребни повеќе од 5 секунди за обработка.
log_queries_not_using_indexes – Булова вредност која одредува дали прашањата што не користат индекси треба да се евидентираат. Кога се анализира, ваквите прашања се важни.
min_examined_row_limit – го дефинира минималниот број на редови што треба да се анализираат. Со вредност од 1000, сите барања што анализираат помалку од 1000 редови ќе бидат игнорирани.

Променливите на серверот MySQL може да се постават во конфигурациската датотека MySQL или динамично да се користат кориснички интерфејсили MySQL командна линија. Ако променливите се поставени во конфигурациската датотека, тие ќе останат кога серверот ќе се рестартира, но серверот мора да се рестартира за да се активираат. Конфигурациската датотека MySQL обично се наоѓа во /etc/my.cnf или /etc/mysql/my.cnf. За да ја пронајдете конфигурациската датотека, внесете (можеби ќе треба да го проширите вашето пребарување во други root директориуми):

најдете /etc -име my.cnf
најдете /usr -name my.cnf

Откако ќе ја пронајдете конфигурациската датотека, додајте ги потребните променливи во делот:

….
бавно барање-лог = 1
slow-query-log-file = /var/log/mysql/localhost-slow.log
long_query_time = 1
log-queries-not-using-indexes

За да стапат на сила промените, треба да го рестартирате серверот. Ако промените треба веднаш да се активираат, поставете ги променливите динамички:

mysql> SET GLOBAL slow_query_log = „ВКЛУЧЕНО“;
mysql> SET GLOBAL slow_query_log_file = "/var/log/mysql/localhost-slow.log";
mysql> ПОСТАВЕТЕ ГЛОБАЛНИ log_queries_not_using_indexes = „ВКЛУЧЕНО“;
mysql> SET SESSION long_query_time = 1;
mysql> SET SESSION min_examined_row_limit = 100;

За да ги проверите вредностите на променливите:

mysql> ПОКАЖИ ГЛОБАЛНИ ПРОМЕНЛИВИ КАКО „slow_query_log“;
mysql> ПРИКАЖИ ПРОМЕНЛИВИ НА СЕСИЈАТА КАКО „long_query_time“;

Една од недостатоците на динамичкото менување на променливите на MySQL е тоа што променливите ќе се изгубат кога серверот ќе се рестартира. Затоа, сите важни променливи што треба да се зачуваат треба да се додадат во датотеката.

Генерирање на барање за профилирање

Сега сте запознаени со поставките за бавниот дневник за пребарување. Обидете се да генерирате податоци за пребарување за профилирање.

Забелешка: Примерот даден овде беше извршен на примерок од MySQL кој работи без конфигурирани бавни дневници за пребарување. Овие тест барања може да се извршат преку GUIили командна линија MySQL.

При следење на дневникот на бавни барања, корисно е да се отворат два терминални прозорци: една врска за испраќање MySQL изјави, а вториот е за прегледување на дневникот за барања.

Најавете се на серверот MySQL користејќи ја конзолата како корисник со SUPER ADMIN привилегии. За да започнете, креирајте тест база на податоци и табела, додајте лажни податоци на нив и овозможете бавно евидентирање на барања.

Забелешка: Идеално, овој пример најдобро е да се извршува во средина без други апликации кои користат MySQL за да се избегне преполнување на дневникот за прашања.

$> mysql -u -p
mysql> КРЕИРАЈ БАЗА НА ПОДАТОЦИ profile_sampling;

mysql> КОРИСТЕТЕ profile_sampling;

mysql> CREATE TABLE корисници (id TINYINT PRIMARY KEY AUTO_INCREMENT, име VARCHAR(255));

mysql> INSERT INTO users (име) VALUES („Walter“), („Skyler“), („Jesse“), („Hank“), („Walter Jr.“), („Marie“), („Saul "), ("Густаво"), ("Хектор"), ("Мајк");

mysql> SET GLOBAL slow_query_log = 1;

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

mysql> ПОСТАВЕТЕ ГЛОБАЛНИ log_queries_not_using_indexes = 1;

mysql> SET long_query_time = 10;

mysql> SET min_examined_row_limit = 0;

Сега имате тест база на податоци и табела со некои податоци. Бавниот дневник за пребарување е овозможен. Намерно го поставивме времето за обработка на барањата на високо и ја оневозможивме проверката на бројот на редови. За да го видите дневникот, внесете:

cd /var/log/mysql
ls -l

Засега, не треба да има дневник на бавни барања во папката, бидејќи овој моментнемаше барања. Ако таков дневник веќе постои, тоа значи дека базата на податоци веќе наишла на бавни барања бидејќи сте ја овозможиле поддршката за дневникот за бавни барања. Ова може да ги искриви резултатите од овој пример. Вратете се во табулаторот MySQL и стартувајте:

mysql> КОРИСТЕТЕ profile_sampling;
mysql> ИЗБЕРИ * ОД корисници КАДЕ ИД = 1;

Извршеното барање едноставно ги повлекува податоците и го користи индексот на првиот клуч од табелата. Ова барање беше брзо и користеше индекс, така што не е заведено во дневникот за бавно пребарување. Вратете се во директориумот и проверете дали не е создаден дневник за прашања. Сега вратете се во прозорецот MySQL и стартувајте:

mysql>

Ова барање не користи индекс. Сега нешто како ова треба да се појави во дневникот /var/log/mysql/localhost-slow.log:

# Време: 140322 13:54:58

користете profile_sampling;
SET временски печат=1395521698;

Уште еден пример. Зголемете го минималниот број на редови за анализа и испратете барање како ова:

mysql> SET min_examined_row_limit = 100;
mysql> SELECT * FROM users WHERE name = "Walter";

Податоците нема да се додадат во дневникот бидејќи за време на барањето беа анализирани помалку од 100 редови.

Забелешка: Ако податоците не се додадени во дневникот, треба да проверите неколку фактори. Прво проверете ги дозволите на директориумот во кој е креиран дневникот. Мора да биде во сопственост на корисникот/групата mysqld и да има привилегии chmod 755. Потоа треба да проверите дали има други поставки за бавно барање на серверот што ги надминуваат вашите поставки. Ресетирајте ги стандардните за да ги отстраните сите бавни променливи за барање од конфигурациската датотека и да го рестартирате серверот. Можете исто така динамички да ги поставите глобалните променливи на нивните стандардни вредности. Ако правите промени динамично, одјавете се и повторно најавете се на MySQL за да ги ажурирате поставките.

Анализирање на податоци за профилирање на прашања

Размислете за следните податоци:

# Време: 140322 13:54:58
#Корисник@домаќин: root@localhost
# Време_прашање: 0,000303 Време_заклучување: 0,000090 Испратени_редови: 1 Испитани_редови: 10
користете profile_sampling;
SET временски печат=1395521698;
ИЗБЕРИ * ОД корисници WHERE име = „Џеси“;

Овој запис прикажува:

Време на извршување на барањето
Кој го испрати
Колку време беше потребно да се обработи барањето?
Должина
Колку редови беа вратени
Колку редови беа анализирани

Ова е корисно бидејќи секое барање што ги прекршува барањата за изведба наведени во променливите завршува во дневникот. Ова му овозможува на развивачот или администраторот брзо да ги следи барањата што не функционираат. Дополнително, податоците за профилирање на барања може да ви помогнат да одредите кои околности предизвикуваат вашата апликација да работи лошо.

Користење на mysqldumpslow

Профилирањето може да се вклучи во апликациите базирани на бази на податоци за да се обезбеди умерен проток на податоци.

Како што расте големината на дневникот, станува тешко да се анализираат сите податоци, а проблематичните прашања може лесно да се изгубат во нив. MySQL нуди алатка наречена mysqldumpslow, која помага да се избегне овој проблем со разделување на дневникот на бавните барања. Бинарната е поврзана со MySQL (на Linux), така што можете едноставно да ја извршите командата:

mysqldumpslow -t 5 -s на /var/log/mysql/localhost-slow.log

Командата може да прифати различни параметри за да го прилагоди нејзиниот излез. Горенаведениот пример ќе ги прикаже првите 5 прашања подредени по просечно време на барање. Таквите низи се почитливи и исто така се групирани по барање.

Број: 2 Време=68,34 секунди (136 сек.) Заклучување=0,00 сек. (0 сек.) Редови=39892974,5 (79785949), root@localhost
ИЗБЕРЕТЕ PL.pl_title, P.page_title
ОД страната П
ВНАТРЕШЕН ПРИКЛУЧУВАЊЕ на страници PL
ON PL.pl_namespace = P.page_namespace
КАДЕ P.page_namespace = Н
…

Излезот ги прикажува следните податоци:

Брои: колку пати барањето е евидентирано.
Време: просечно и вкупно време на барање (во заграда).
Заклучување: време за заклучување на масата.
Редови: бројот на вратени редови.

Командата ги исклучува нумеричките и стринговите вредности, така што идентичните барања со различни КАДЕ услови се третираат како исти. Алатката mysqldumpslow ја елиминира потребата постојано да се прегледува дневникот на бавните барања, наместо тоа да ви овозможи да извршувате редовни автоматски проверки. Опциите на командата mysqldumpslow ви дозволуваат да извршите сложени изрази.

Барање дефект

Друга алатка за профилирање што треба да се има на ум е Алатката за сложени прашања за распаѓање. Тоа ви овозможува да идентификувате проблематични прашања во бавниот дневник за пребарување и да го извршите во MySQL. Прво треба да го овозможите профилирањето и потоа да го извршите барањето:

mysql> SET SESSION профилирање = 1;
mysql> КОРИСТЕТЕ profile_sampling;
mysql> SELECT * FROM users WHERE name = "Jesse";
mysql> ПРИКАЖИ ПРОФИЛИ;

Откако ќе се овозможи профилирањето, SHOW PROFILES ќе прикаже табела што го поврзува Query_ID со изразот SQL. Најдете го Query_ID што одговара на актуелното барање и извршете го следното барање (заменете го # со вашиот Query_ID):

mysql> ИЗБЕРИ * ОД INFORMATION_SCHEMA.ПРОФИЛИРАЊЕ КАДЕ QUERY_ID=#;

Командата ќе врати табела:

SEQ	ДРЖАВА	ВРЕМЕТРАЕЊЕ
1	почнувајќи	0.000046
2	проверка на дозволите	0.000005
3	отварање на маси	0.000036
…	…	…

STATE е чекор во процесот на извршување на барањето, а DURATION е времето потребно за да се заврши тој чекор во секунди. Не е многу корисна алатка, но може да помогне да се одреди кој дел од извршувањето на барањето предизвикува најмногу латентност.

ЗабелешкаЗабелешка: Оваа алатка не треба да се користи во производна средина.

Бавна изведба на дневникот за пребарување

Останува само да дознаеме како бавниот дневник за пребарување влијае на перформансите. Општо земено, безбедно е да се извршуваат бавни дневници за пребарување во производствена средина; Ниту процесорот, ниту влезот/излезот не треба да бидат засегнати. Сепак, треба да имате стратегија за следење на големината на дневникот за да се осигурате дека дневникот не станува премногу голем за датотечен систем. Дополнително, кога извршувате бавен дневник за барање во производна средина, треба да поставите long_query_time на 1 или повисоко.

Заклучок

Бавниот дневник за барања може да ви помогне да ги идентификувате проблематичните прашања и да ја оцените севкупната изведба на барањето. Во исто време, развивачот може да добие детално разбирање за тоа како функционира апликацијата MySQL пребарувања. Алатката mysqldumpslow ви овозможува да управувате со бавните дневници за пребарување и лесно да ги вклучите во вашиот развојен процес. Со идентификување на проблематични прашања, можете да ја оптимизирате обработката на барањата за да ги подобрите перформансите.

Тагови:

Дневниците на настани се првата и наједноставната алатка за одредување на статусот на системот и идентификување на грешки. Постојат четири главни дневници во MySQL:

Дневник на грешки— стандарден дневник за грешки што се собира додека работи серверот (вклучувајќи старт и стоп);
Бинарен дневник— дневник на сите команди за модификација на базата, потребни за репликација и резервни копии;
Општ дневник за прашања— главен дневник за прашања;
Бавен дневник за пребарување- дневник на бавни барања.

Дневник на грешки

Овој дневник ги содржи сите грешки што се случиле додека работи серверот, вклучувајќи критични грешки, како и исклучување на серверот, стартување на серверот и предупредувања. Ова е местото каде што треба да започнете во случај на дефект на системот. Стандардно, сите грешки се пренесуваат во конзолата (stderr), исто така можете да ги евидентирате грешките во syslog (стандардно на Debian) или во посебна датотека за евиденција:

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

# Грешките ќе бидат запишани на mysql_error.log

Препорачуваме да го задржите овој дневник вклучен за брзо да ги идентификувате грешките. И за да разбереме што значи оваа или онаа грешка, MySQL ја има алатката за грешка:

Шел> грешка 13 64 Код за грешка на ОС 13: Недостасувана дозвола Код за грешка на ОС 64: Машината не е на мрежата

# Го објаснува значењето на кодовите за грешки

Бинарен (ака бинарен) дневник

Сите команди за промена на базата на податоци се запишуваат во бинарниот дневник, корисни за репликацијаи закрепнување.

Се вклучува вака:

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

# Ја означува локацијата, животниот век и максимална големинадатотека

Забележете дека ако нема да го зголемите системот и да имплементирате толеранција на грешки, тогаш подобро е да не го овозможите бинарниот дневник. Тоа е интензивно на ресурси и ги намалува перформансите на системот.

Дневник на барање

Овој дневник ги содржи сите примени SQL прашања и информации за врските со клиентот. Може да биде корисно за анализа и оптимизација на индекси, како и за идентификување на погрешни прашања:

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

# Го вклучува дневникот и ја означува локацијата на датотеката

Можете исто така да го вклучите/оневозможите додека работи серверот MySQL:

ПОСТАВЕТЕ ГЛОБАЛЕН general_log = „ВКЛУЧЕНО“; SET GLOBAL general_log = „ИСКЛУЧЕНО“;

# Не треба да го рестартирате серверот за да го користите

Бавен дневник за барања

Дневникот е корисен за идентификување бавни, односно неефикасни прашања. Прочитајте повеќе во Оваа статија.

Преглед на дневници

За да ги видите дневниците на Debian (Ubuntu) треба да извршите:

# Опашка за евиденција на грешка -f /var/log/syslog #Одна за евиденција на барање -f /var/log/mysql/mysql.log # Пријавете бавни барањаопашка -f /var/log/mysql/mysql-slow.log

# Ако дневниците не се наведени посебно, тие се наоѓаат во /var/lib/mysql

Ротација на дневник

Не заборавајте да ги компресирате (архивирате, ротирате) датотеките за дневници за да заземаат помалку простор на серверот. За да го направите ова, користете ја алатката логротираатсо уредување на конфигурациската датотека /etc/logrotate.d/mysql-server:

# - Ставив сè во еден блок и додадов споделени скрипти, така што mysql добива # flush-logs"d само еднаш. # Во спротивно, бинарните дневници автоматски ќе се зголемуваат за n пати секој ден. # - Дневникот за грешки е застарен, пораките сега одат во syslog./var/log/mysql.log /var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log( дневна ротација 7 missingok создаде 640 mysql adm компресира споделени скрипти постротат тест -x /usr/bin/mysqladmin || излез 0 # Ако ова не успее, проверете го debian.conf! MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf" if [ -z "`$MYADMIN ping 2>/dev/null`" ]; тогаш # Навистина нема mysqld или поточно недостасува корисник на debian-sys-maint? # Ако ова се случи и не е грешка, пријавете грешка. #ако пс какс | grep -q mysqld; тогашако killall -q -s0 -umysql mysqld; потоа излезете од 1 фи друго $MYADMIN flush-logs fi endscript )

# Ги компресира и архивира потребните дневници, ги чисти датотеките

Дневник на DDL

MySQL исто така одржува дневник за јазикот на податоци. Собира податоци од операции како DROP_TABLE и ALTER_TABLE. Дневникот се користи за опоравување од неуспеси што се случиле за време на таквите операции. DDL Log е бинарна датотека и не е наменета да ја чита корисникот, затоа немојте да ја менувате или бришете.

Најважниот

Секогаш вклучете го дневникот за грешки, користете го дневникот за пребарување за да ја проверите врската на апликацијата со базата на податоци, да ги проверувате барањата и работата. Дневникот на бавни барања е корисен за оптимизирање на перформансите на MySQL.

Профилирање на прашања во Mysqlсе користи за оценување на перформансите на вашата апликација. Кога развивате средни до големи апликации, треба да се справите со стотици барања дистрибуирани низ вашиот код кои се извршуваат секоја секунда. Без техники за профилирање на прашања, може да биде многу тешко да се открие што предизвикува влошување на перформансите на вашата апликација.

Што е бавниот дневник за пребарување во MySQL?

MySQL Slow Query Log - дневник кој ги означува бавните и потенцијално проблематичните барања. MySQL стандардно ја поддржува оваа функционалност, но таа е оневозможена. Со поставување на одредени променливи на серверот, можеме да одредиме за кои барања сме заинтересирани. Најчесто, ни требаат прашања за кои е потребно одредено време за да се пополнат или прашања кои не ги обработуваат правилно индексите.

Поставување на променливи за профилирање

Главни променливи за поставување на дневникот за прашања:

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

Коментар: G - глобални променливи, S - системски променливи

slow_query_log - булова вредност вклучувајќи и дневник
slow_query_log_file - апсолутна патека до датотеката за евиденција. Сопственикот на директориумот мора да биде корисник mysqld, а директориумот мора да ги има правилните дозволи за читање и пишување. Најчесто mysql демонот работи како корисник mysql.

За да проверите, извршете ги следните команди:

Ps-ef | grep bin/mysqld | сече -d" " -f1

Излезот од командата ќе ви го даде името на тековниот корисник и корисникот mysqld. Пример за поставување на директориумот /var/log/mysql:

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

long_query_time - време во секунди за проверка на времетраењето на барањето. На пример, со вредност од 5, секое барање кое трае повеќе од 5 секунди ќе биде евидентирано.
log_queries_not_using_indexes - булова вредност, овозможува зачувување на барања кои не користат индекси. Ваквите прашања се многу важни во анализата.
min_examined_row_limit - ја одредува минималната вредност за бројот на податочни редови што треба да се анализираат. Вредноста од 1000 ќе ги игнорира барањата што враќаат помалку од 1000 редови на вредности.

Овие променливи може да се постават во конфигурациската датотека MySQL, динамички преку MySQL GUI или MySQL командната линија. Ако променливите се наведени во конфигурациската датотека, серверот ќе ги инсталира следниот пат кога ќе започне. Обично оваа датотека се наоѓа на /etc, /usr, /etc/my.cnf или /etc/mysql/my.cnf. Еве ги командите за пребарување на конфигурациската датотека (понекогаш треба да го проширите пребарувањето во други root директориуми):

Најдете /etc -name my.cnf најдете /usr -name my.cnf

Кога ќе ја пронајдете датотеката, додајте ги бараните променливи во делот:

; ... slow-query-log = 1 slow-query-log-file = /var/log/mysql/localhost-slow.log long_query_time = 1 log-queries-not-using-indexes ; тука не е потребно значење

Промените ќе стапат на сила само следниот пат кога ќе го стартувате MySQL; ако треба динамички да ги менувате параметрите, користете други методи за поставување променливи:

Mysql> SET GLOBAL slow_query_log = „ВКЛУЧЕНО“; mysql> SET GLOBAL slow_query_log_file = "/var/log/mysql/localhost-slow.log"; mysql> ПОСТАВЕТЕ ГЛОБАЛНИ log_queries_not_using_indexes = „ВКЛУЧЕНО“; mysql> SET SESSION long_query_time = 1; mysql> SET SESSION min_examined_row_limit = 100;

Можете да ги проверите вредностите на променливите на следниов начин:

Mysql> ПОКАЖИ ГЛОБАЛНИ ПРОМЕНЛИВИ КАКО „slow_query_log“; mysql> ПРИКАЖИ ПРОМЕНЛИВИ НА СЕСИЈАТА КАКО „long_query_time“;

Главниот недостаток на динамичната инсталација е тоа што вредностите ќе се изгубат кога ќе започне системот. Се препорачува да се наведат важни параметри во конфигурацијата MySQL.

Белешката: Синтакса за динамичко поставување параметри преку Команда SETи користењето на конфигурациската датотека е малку поинакво, на пример slow_query_log / slow-query-log . Целосен опис на синтаксата ќе најдете во официјалната документација за DBMS. Форматот Option-File се користи за конфигурациската датотека, System Variable Name - имиња на променливи при динамично поставување на вредностите.

Генерирање податоци за профилирање на барања

Ги разгледавме главните точки за поставување на профилирање, сега ќе ги создадеме прашањата што не интересираат. Овој пример се користеше на активен MySQL сервер без никакви прелиминарни поставки за дневник. Примерочните барања може да се стартуваат и преку командните алатки MySQL GUI и DBMS. При следење на дневникот на бавните барања, вообичаено е да се отворат два прозорци со поврзување: едниот за извршување на прашања, другиот за прегледување на дневникот.

$> mysql -u -p mysql> КРЕИРАЈ БАЗА НА ПОДАТОЦИ profile_sampling; mysql> КОРИСТЕТЕ profile_sampling; mysql> CREATE TABLE корисници (id TINYINT PRIMARY KEY AUTO_INCREMENT, име VARCHAR(255)); mysql> INSERT INTO users (име) VALUES („Walter“), („Skyler“), („Jesse“), („Hank“), („Walter Jr.“), („Marie“), („Saul "), ("Густаво"), ("Хектор"), ("Мајк"); mysql> SET GLOBAL slow_query_log = 1; mysql> SET GLOBAL slow_query_log_file = "/var/log/mysql/localhost-slow.log"; mysql> ПОСТАВЕТЕ ГЛОБАЛНИ log_queries_not_using_indexes = 1; mysql> SET long_query_time = 10; mysql> SET min_examined_row_limit = 0;

Сега имаме база на податоци со податоци од тестот. Започнавме профилирање, но намерно ги поставивме времето на одговор и бројот на линии да бидат мали. За да го видите дневникот, користете ја командата:

Cd /var/log/mysql ls -l

Теоретски, датотеката за евиденција сè уште не треба да постои, бидејќи не сме направиле барања до базата на податоци. Ако постои, тоа значи дека профилирањето било конфигурирано порано, а тоа може да ги наруши резултатите од примерот. Стартувај во конзолата:

Mysql> КОРИСТЕТЕ profile_sampling; mysql> ИЗБЕРИ * ОД корисници КАДЕ ИД = 1;

Нашето барање го користи индексот на примарен клуч од табелата. Барањето се обработува многу брзо со помош на индексот, па затоа не треба да се рефлектира во дневникот. Ве молиме имајте предвид дека датотеката за евиденција не требаше да биде креирана.

Сега направете го следново:

Mysql> SELECT * FROM users WHERE name = "Jesse";

Тука не користевме индекси. Сега треба да го видиме ова барање во дневникот:

Судо мачка /var/log/mysql/localhost-slow.log # Време: 140322 13:54:58 # Корисник@домаќин: root @ localhost # Време_пребарување: 0.000303 Време_заклучување: 0.000090 Редови_испратени: 1 Rows_10 use; SET временски печат=1395521698; ИЗБЕРИ * ОД корисници WHERE име = „Џеси“;

Ајде да погледнеме друг пример. Подигнете ја лентата на бројот на линии во одговорот и извршете го следново барање:

Mysql> SET min_examined_row_limit = 100; mysql> SELECT * FROM users WHERE name = "Walter";

Барањето нема да се одрази во дневникот, бидејќи не надминавме 100 линии во одговорот на барањето.

Белешката: Ако податоците не се прикажани во дневникот, тогаш пред сè треба да ги земете предвид следните фактори. Првиот е правата на директориумот каде што е зачувана датотеката за евиденција. Групата и корисникот мора да одговараат на корисникот mysqld, правата мора да бидат chmod 755. Второ, профилирањето можеби било претходно конфигурирано. Отстранете ги сите постоечки вредности на променливите за профилирање од конфигурациската датотека и рестартирајте го серверот или поставете ги динамичките променливи. Ако сте користеле динамички метод, ќе излезете и ќе се најавите назад во конзолата MySQL.

Анализа на податоци за профилирање на барања

Размислете за горенаведениот пример:

# Време: 140322 13:54:58 # Корисник@Домаќин: root @ localhost # Време_прашање: 0.000303 Време_заклучување: 0.000090 Испратени редови: 1 Редови_испитани: 10 користете земање_профили; SET временски печат=1395521698; ИЗБЕРИ * ОД корисници WHERE име = „Џеси“;

Овде гледаме:

Време кога е започнато барањето
Корисникот кој го направил барањето
Барања за работно време
Времетраење на заклучување
Број на избрани редови
Број на анализирани линии

Овие податоци се многу корисни, бидејќи со нивна помош можеме да ја пронајдеме и елиминираме причината за забавување на системот. Исто така, развивачот или администраторот на MySQL секогаш ќе може да гледа проблематични прашања и би сакал да забележам дека нивното наоѓање овде е многу побрзо отколку со проучување на кодот на апликацијата. Со долгорочно профилирање, можете да ги следите работните услови со мала брзина.

Користење на mysqldumpslow

Дневникот постојано снима податоци; по правило, пишува многу повеќе отколку што се чита од него. На голема големиналог, читањето станува проблематично. MySQL вклучува алатка наречена mysqldumpslow која помага да се одржи интегритетот на дневникот. Самата програма е комбинирана со MySQL (вклучено Линукс системи). За да го користите, следете потребната командаи пренесете ја патеката до датотеката за евиденција:

Судо mysqldumpslow -t 5 -s на /var/log/mysql/localhost-slow.log

Постојат голем број на параметри кои ви помагаат да го прилагодите излезот на командата. Во примерот подолу ќе ги видиме последните пет барања подредени по просечно времетраење. Како резултат на тоа, читањето на дневникот станува многу поудобно. (излезот е изменет за да ги прикаже вистинските вредности на дневникот):

Број: 2 Време=68,34 сек. (136 сек.) Заклучување=0,00 сек. (0 сек.) Редови=39892974.5 (79785949), root@localhost ИЗБЕРЕТЕ PL.pl_title, P.page_title ОД страницата P ВНАТРЕШНО ПРИДРУЖЕТЕ линкови на страницата PL_pagenamespacespace=PL. КАДЕ P.page_namespace = N ...

Она што го гледаме:

Број - број на појавувања на барањето во дневникот
Време - просечно и вкупно време на барање
Заклучување - време за заклучување на масата
Редови - Број на избрани редови

Командата исклучува нумерички и стринг податоци за пребарување, што значи дека барањата со иста клаузула WHERE ќе се сметаат за исти. Благодарение на оваа алатка, не мора постојано да го гледате дневникот. Поради големиот број командни параметри, можете да го сортирате излезот како што сакате. Исто така, има развој на трета страна со слична функционалност, на пример pt-query-digest.

Барање дефект

Треба да обрнете внимание на друга алатка која ви овозможува да разложувате сложени прашања. Најчесто треба да направите барање од дневникот и потоа да го извршите директно во конзолата MySQL. Прво треба да го овозможите профилирањето и потоа да го извршите барањето:

Mysql> SET SESSION профилирање = 1; mysql> КОРИСТЕТЕ profile_sampling; mysql> SELECT * FROM users WHERE name = "Jesse"; mysql> ПРИКАЖИ ПРОФИЛИ;

Откако ќе се овозможи профилирање, SHOW PROFILES ќе прикаже табела што ги поврзува Query_ID и SQL изразот. Најдете го соодветниот Query_ID и извршете го следново барање (заменете го # со вашиот Query_ID):

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

Пример излез:

SEQ СОСТОЈБА ВРЕМЕТРАЕЊЕ 1 почнувајќи 0,000046 2 дозволи за проверка 0,000005 3 табели за отворање 0,000036

ДРЖАВА- чекор во процесот на извршување на барање, ВРЕМЕТРАЕЊЕ- времетраење на чекорот во секунди. Оваа алатка не се користи многу често, но понекогаш може да биде исклучително корисна во одредувањето на причината за бавните перформанси на барањето.

Детален опис на колоните:

Детален опис на чекорите:

Белешката: Оваа алатка не треба да се користи во режим на производство на сервер, освен за анализа на одредени прашања.

Бавна изведба на дневникот за пребарување

Последното прашање е како профилирањето влијае на перформансите на серверот како целина. Во режимот на производство на серверот, можете сосема безбедно да користите такво логирање; тоа не треба да влијае ниту на процесорот, ниту на I/O. Сепак, вреди да се обрне внимание на големината на датотеката за евиденција; таа не треба да стане премногу голема. Исто така, би сакал да забележам од искуство дека поставувањето на вредноста на променливата long_query_time на 1 секунда или повисока.

Важно: Не треба да ја користите алатката за профилирање - SET profiling = 1 - за снимање на сите барања, т.е. Не се препорачува да се користи променливата general_log во режим на производ и при големи оптоварувања.

Заклучок

Профилирањето на барања може многу да ви помогне во изолирањето на проблематичното барање и проценката на севкупните перформанси. Програмерот исто така може да проучи како функционираат MySQL барањата на неговата апликација. Алатката mysqldumpslow ви помага да ги прегледувате и обработувате дневниците за барања. Откако ќе ги идентификувате проблематичните прашања, останува само да ги подесите за максимални перформанси.

Концепт

Дневници на сервери (датотеки за евиденција, дневник на сервер)- датотеки складирани на серверот кои содржат системски информации на серверот, како и евидентирање на сите можни податоци за посетителот на веб-ресурсот.

Дневниците ги користат системските администратори за да ги анализираат посетителите, проучување на моделите на однесување на одредени групи корисници, како и добивање на различни информации за нив, како што се: користениот прелистувач, IP адресата, податоци за географската локација на клиентот и многу повеќе. Покрај анализата, на овој начин можете да дознаете за неовластен пристап до страницата, попрецизно да дознаете кој точно го направил и да пренесете податоци за овој случај до соодветните органи.

Податоците во лог датотеката, во чиста форма, нема да бидат разбирливи за обичните корисници, кои во сето ова ќе видат само збир на знаци во неразбирлив редослед. Но за системски администратории веб програмери, ова е многу читлив текст и доста корисни информации.

Редоследот на настаните

Секој пат кога клиентот пристапува до веб-ресурс, се активираат неколку настани одеднаш, за чија низа ќе зборуваме.

1. Изработка на барање за страница.Кога внесувате адреса во линијата на прелистувачот или кога следите активна веб-врска, на пример, од страница со резултати од пребарувачот, прелистувачот пребарува и се поврзува со серверот на кој се наоѓа страницата и поднесува барање за тоа. Во исто време, ги пренесува следните информации до серверот:
- IP адреса на клиентскиот компјутер што ја бара страницата (ако користите прокси-сервер, IP адресата на вашиот прокси);
- адреса на Интернет страницата што ја бара корисникот (IP адреса);
- точното време и датум кога е поднесено барањето;
- податоци за вистинската локација на клиентот (ако се користи прокси-сервер, тогаш вистинската адреса на прокси);
- информации за прелистувачот што го користи клиентот (име, верзија, итн.);
- податоци за веб-страницата од која клиентот префрлил.

2. Пренос на бараните податоци.Бараните податоци (веб-страница, датотеки, колачиња, итн.) се пренесуваат од серверот на компјутерот на корисникот.

3. Напишете во дневникот на серверот.После сè, се појавува запис во дневникот, што ги означува сите податоци што се појавија во изминатите два настани. Ова се сите информации испратени во првиот став, како и информации за пренесените податоци.

Како да ги видите дневниците на серверот

Датотеките за дневници се зачувани во датотека пристап.логбез разлика каков тип на веб-сервер користите (Apache, Nginx, squid proxy-сервер, итн.) Оваа датотека е текстуален документ, на секој ред од кој е напишан по еден приговор. Формати за снимање во пристап.логдоста, но најпопуларниот е комбиниран, во кој записот ја има следната форма и низа:

Код: %h %l %u %t \"%r\" %>s %b \"%(Referer)i\" \"%(User-Agent)i\"
Каде:

%h- хост/IP адреса од која е поднесено барањето;
%t- време на барање до серверот и временската зона на серверот;
%r- верзија, содржина и вид на барање;
%s- HTTP статусен код;
%b- бројот на бајти испратени од серверот;
% (Референт)- URL извор на барањето;
% (Корисник-агент)- HTTP заглавие, со информации за барањето (апликација на клиентот, јазик и сл.);
% (домаќин)- името на виртуелниот хост до кој се пристапува.

Кога ќе завршите, оваа линија изгледа отприлика вака:

127.0.0.1 - - "GET /index.php HTTP/1..0 (компатибилен; MSIE 7.0; Windows NT 5.1)"

Рачното читање дневници ќе потрае доста време и напор. Затоа, искусните веб-администратори користат специјален софтвер наречен „Анализатори на датотеки за евиденција“. Тие ги анализираат сите податоци, што е доста тешко за луѓето да ги прочитаат, и произведуваат структурирани податоци. Тоа се програми како што се: Аналоген, WebAnalizer, Webalizer, Awstats, Webtrends, итн.Видови специјални софтвердоста, меѓу нив има како платени програмии бесплатно. Затоа, сигурен сум дека секој ќе најде нешто по свој вкус.

Каде да се најдат дневници на сајтови

Ако имате редовен хостинг, тогаш најверојатно ќе треба да му пишете на вашиот хостер и да побарате дневници од него. Исто така, доста често, можете да ги побарате преку хостинг панелот. Различни хостери го прават тоа поинаку. На пример, за да побарате од мојот хостер, само кликнете на почетна страницапанели:

Ако имате пристап до системски папкисервер, тогаш можете да ги најдете дневниците на /etc/httpd/logs/access_logво 99 случаи од 100.

Грешка во дневникот на грешки.лог

Грешка.лог- датотека во која се чуваат и дневници. Но, не посетители, туку грешки што се случија на серверот. Како што е случајот со пристап.лог, секоја линија од датотеката е одговорна за една грешка што се појавила. Снимањето се врши земајќи ги предвид таквите информации како што се: точниот датум и време на настанување на грешката, IP адресата на која е издадена грешката, видот на грешката, како и причината за нејзиното појавување.

Заклучок

Дневниците се доста моќна и информативна алатка за работа. Но, во денешно време тие се заменети со алатки како што се Yandex.Metrica, Google Analytics итн., а со тоа ни го олеснуваат животот. Меѓутоа, доколку планирате да се развивате, да растете и да научите нешто ново, секако препорачувам подобро да ја запознаете оваа тема.

Популарни во категоријата: