როგორ გამორთოთ ნელი შეკითხვის ჟურნალი. შეკითხვის პროფილირება 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 | cut -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 -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> SET GLOBAL slow_query_log = "ON";
mysql> SET GLOBAL slow_query_log_file = "/var/log/mysql/localhost-slow.log";
mysql> SET GLOBAL log_queries_not_using_indexes = "ON";
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> CREATE DATABASE profile_sampling;

mysql> გამოიყენეთ profile_sampling;

mysql> CREATE TABLE მომხმარებლები (id TINYINT PRIMARY KEY AUTO_INCREMENT, სახელი VARCHAR(255));

mysql> INSERT INTO მომხმარებლებს (სახელი) 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> SET GLOBAL 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> SELECT * FROM users WHERE id = 1;

შესრულებული მოთხოვნა უბრალოდ იღებს მონაცემებს და იყენებს ცხრილიდან პირველი გასაღების ინდექსს. ეს მოთხოვნა იყო სწრაფი და იყენებდა ინდექსს, ამიტომ ის არ არის ჩაწერილი ნელი შეკითხვის ჟურნალში. დაბრუნდით დირექტორიაში და დარწმუნდით, რომ შეკითხვის ჟურნალი არ არის შექმნილი. ახლა დაბრუნდით MySQL ფანჯარაში და გაუშვით:

mysql>

ეს შეკითხვა არ იყენებს ინდექსს. ახლა რაღაც მსგავსი უნდა გამოჩნდეს ჟურნალში /var/log/mysql/localhost-slow.log:

# დრო: 140322 13:54:58

profile_sampling-ის გამოყენება;
SET timestamp=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 timestamp=1395521698;
SELECT * FROM users WHERE name = "Jesse";

ეს ჩანაწერი აჩვენებს:

• შეკითხვის შესრულების დრო
• ვინ გამოგზავნა
• რამდენი დრო დასჭირდა მოთხოვნის დამუშავებას?
• სიგრძე
• რამდენი რიგი დააბრუნეს
• რამდენი მწკრივი იყო გარჩეული

ეს სასარგებლოა, რადგან ნებისმიერი მოთხოვნა, რომელიც არღვევს ცვლადებში მითითებულ შესრულების მოთხოვნებს, მთავრდება ჟურნალში. ეს საშუალებას აძლევს დეველოპერს ან ადმინისტრატორს სწრაფად აკონტროლოს მოთხოვნები, რომლებიც არ მუშაობს. გარდა ამისა, შეკითხვის პროფილის მონაცემები დაგეხმარებათ განსაზღვროთ რა გარემოებები იწვევს თქვენი განაცხადის ცუდად შესრულებას.

mysqldumpslow-ის გამოყენება

პროფილირება შეიძლება ჩართული იყოს მონაცემთა ბაზაზე დაფუძნებულ აპლიკაციებში მონაცემთა ზომიერი ნაკადის უზრუნველსაყოფად.

როგორც ჟურნალის ზომა იზრდება, ძნელი ხდება ყველა მონაცემის გაანალიზება და პრობლემური მოთხოვნები შეიძლება ადვილად დაიკარგოს მასში. MySQL გთავაზობთ ინსტრუმენტს სახელწოდებით mysqldumpslow, რომელიც დაგეხმარებათ თავიდან აიცილოთ ეს პრობლემა ნელი მოთხოვნების ჟურნალის გაყოფით. ბინარი დაკავშირებულია MySQL-თან (Linux-ზე), ასე რომ თქვენ შეგიძლიათ უბრალოდ გაუშვათ ბრძანება:

mysqldumpslow -t 5 -s at /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
გვერდიდან P
INNER Join გვერდის ბმულები PL
ON PL.pl_namespace = P.page_namespace
WHERE P.page_namespace = N
…

გამომავალი აჩვენებს შემდეგ მონაცემებს:

• დათვლა: რამდენჯერ დარეგისტრირდა მოთხოვნა.
• დრო: საშუალო და მთლიანი მოთხოვნის დრო (ფრჩხილებში).
• ჩაკეტვა: მაგიდის დაბლოკვის დრო.
• რიგები: დაბრუნებული რიგების რაოდენობა.

ბრძანება გამორიცხავს ციფრულ და სტრიქონების მნიშვნელობებს, ამიტომ იდენტური მოთხოვნები განსხვავებული WHERE პირობებით განიხილება როგორც ერთნაირი. 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> SELECT * FROM INFORMATION_SCHEMA.PROFILING WHERE QUERY_ID=#;

ბრძანება დააბრუნებს ცხრილს:

STATE არის ნაბიჯი მოთხოვნის შესრულების პროცესში და DURATION არის დრო, რომელიც სჭირდება ამ ნაბიჯის დასრულებას წამებში. ეს არ არის ძალიან სასარგებლო ინსტრუმენტი, მაგრამ ის დაგეხმარებათ განსაზღვროთ შეკითხვის შესრულების რომელი ნაწილი იწვევს ყველაზე მეტ შეყოვნებას.

შენიშვნაშენიშვნა: ეს ინსტრუმენტი არ უნდა იქნას გამოყენებული საწარმოო გარემოში.

შეკითხვის ჟურნალის ნელი შესრულება

რჩება მხოლოდ იმის გარკვევა, თუ როგორ მოქმედებს ნელი შეკითხვის ჟურნალი შესრულებაზე. ზოგადად, უსაფრთხოა ნელი შეკითხვის ჟურნალის გაშვება საწარმოო გარემოში; არც CPU და არც I/O არ უნდა დაზარალდეს. თუმცა, თქვენ უნდა გქონდეთ ჟურნალის ზომის მონიტორინგის სტრატეგია, რათა დარწმუნდეთ, რომ ჟურნალი არ გახდება ძალიან დიდი ფაილური სისტემა. გარდა ამისა, საწარმოო გარემოში შეკითხვის ნელი ჟურნალის გაშვებისას, თქვენ უნდა დააყენოთ long_query_time 1-ზე ან უფრო მაღალზე.

დასკვნა

შეკითხვის ნელი ჟურნალი დაგეხმარებათ პრობლემური მოთხოვნების იდენტიფიცირებაში და შეკითხვის საერთო შესრულების შეფასებაში. ამავდროულად, დეველოპერს შეუძლია მიიღოს დეტალური გაგება, თუ როგორ მუშაობს აპლიკაცია MySQL მოთხოვნები. Mysqldumpslow ინსტრუმენტი საშუალებას გაძლევთ მართოთ ნელი შეკითხვის ჟურნალები და მარტივად ჩართოთ ისინი თქვენს განვითარების პროცესში. პრობლემური მოთხოვნების იდენტიფიცირებით, შეგიძლიათ შეკითხვის დამუშავების ოპტიმიზაცია, შესრულების გასაუმჯობესებლად.

კონცეფცია

სერვერის ჟურნალი (ლოგის ფაილები, სერვერის ჟურნალი)- სერვერზე შენახული ფაილები, რომლებიც შეიცავს სისტემის ინფორმაციასერვერები, ასევე ვებ რესურსის ვიზიტორის შესახებ ყველა შესაძლო მონაცემის აღრიცხვა.

ჟურნალები გამოიყენება სისტემის ადმინისტრატორების მიერ ვიზიტორების გასაანალიზებლად, მომხმარებელთა გარკვეული ჯგუფების ქცევის ნიმუშების შესწავლა, ასევე მათ შესახებ სხვადასხვა ინფორმაციის მოპოვება, როგორიცაა: გამოყენებული ბრაუზერი, IP მისამართი, მონაცემები კლიენტის გეოგრაფიული მდებარეობის შესახებ და მრავალი სხვა. ანალიზის გარდა, ამ გზით შეგიძლიათ გაიგოთ საიტზე არასანქცირებული წვდომის შესახებ, უფრო ზუსტად გაიგოთ, თუ ვისი გაკეთდა ეს და გადაიტანოთ მონაცემები. ამ შემთხვევაშიშესაბამის ორგანოებს.

ჟურნალის ფაილში არსებული მონაცემები, მისი სუფთა სახით, გაუგებარი იქნება ჩვეულებრივი მომხმარებლებისთვის, რომლებიც ამ ყველაფერში დაინახავენ მხოლოდ სიმბოლოების ერთობლიობას გაუგებარი თანმიმდევრობით. მაგრამ ამისთვის სისტემის ადმინისტრატორებიდა ვებ დეველოპერები, ეს არის სრულიად იკითხებადი ტექსტი და საკმაოდ სასარგებლო ინფორმაცია.

ყოველ ჯერზე, როცა კლიენტი წვდება ვებ რესურსს, ერთდროულად რამდენიმე მოვლენა ტრიალებს, რომელთა თანმიმდევრობაზეც ვისაუბრებთ.

1. გვერდის მოთხოვნის გაკეთება.ბრაუზერის ხაზში მისამართს შეყვანისას, ან როცა მიჰყვებით აქტიურ ვებ ბმულს, მაგალითად, საძიებო სისტემის შედეგების გვერდიდან, ბრაუზერი ეძებს და უერთდება სერვერს, რომელზეც მდებარეობს გვერდი და აკეთებს მოთხოვნას. ამავდროულად, ის გადასცემს შემდეგ ინფორმაციას სერვერზე:
- კლიენტის კომპიუტერის IP მისამართი, რომელიც ითხოვს გვერდს (პროქსი სერვერის გამოყენების შემთხვევაში, თქვენი პროქსის IP მისამართი);
- მომხმარებლის მიერ მოთხოვნილი ინტერნეტ გვერდის მისამართი (IP მისამართი);
- ზუსტი დრო და თარიღი, როდესაც მოხდა მოთხოვნა;
- მონაცემები კლიენტის ფაქტობრივი მდებარეობის შესახებ (თუ გამოიყენება პროქსი სერვერი, მაშინ ფაქტობრივი მარიონეტული მისამართი);
- ინფორმაცია კლიენტის მიერ გამოყენებული ბრაუზერის შესახებ (სახელი, ვერსია და ა.შ.);
- მონაცემები ვებ გვერდის შესახებ, საიდანაც კლიენტმა გადაიტანა.

2. მოთხოვნილი მონაცემების გადაცემა.მოთხოვნილი მონაცემები (ვებ გვერდი, ფაილები, ქუქიები და ა.შ.) გადადის სერვერიდან მომხმარებლის კომპიუტერში.

3. ჩაწერეთ სერვერის ჟურნალში.ყოველივე ამის შემდეგ, ხდება ჟურნალის ჩანაწერი, რომელიც მიუთითებს ყველა მონაცემზე, რომელიც გამოჩნდა ბოლო ორ მოვლენაში. ეს არის მთელი ინფორმაცია, რომელიც გაგზავნილია პირველ პუნქტში, ისევე როგორც ინფორმაცია გადაცემული მონაცემების შესახებ.

როგორ ვნახოთ სერვერის ჟურნალი

ჟურნალის ფაილები ინახება ფაილში წვდომა.logარ აქვს მნიშვნელობა რა ტიპის ვებ სერვერს იყენებთ (Apache, Nginx, squid proxy და ა.შ.) ეს ფაილიარის ტექსტური დოკუმენტი, რომლის თითოეულ სტრიქონზე წერია ერთი მიმართვა. ჩაწერის ფორმატებში წვდომა.logსაკმაოდ ბევრი, მაგრამ ყველაზე პოპულარული კომბინირებულია, რომელშიც ჩანაწერს აქვს შემდეგი ფორმა და თანმიმდევრობა:

კოდი: %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)"

ჟურნალების ხელით წაკითხვას საკმაოდ დიდი დრო და ძალისხმევა დასჭირდება. ამიტომ, გამოცდილი ვებოსტატები იყენებენ სპეციალურ პროგრამულ უზრუნველყოფას, სახელწოდებით "Log File Analyzers". ისინი აანალიზებენ ყველა მონაცემს, რომლის წაკითხვაც საკმაოდ რთულია ადამიანისთვის და აწარმოებენ სტრუქტურირებულ მონაცემებს. ეს არის პროგრამები, როგორიცაა: ანალოგი, WebAnalizer, Webalizer, Awstats, Webtrends და ა.შ.სპეციალური ტიპები პროგრამული უზრუნველყოფასაკმაოდ ბევრი, მათ შორის არის როგორც ფასიანი, ასევე უფასო პროგრამები. ამიტომ, დარწმუნებული ვარ, რომ ყველა იპოვის თავის გემოვნებას.

სად ვიპოვოთ საიტის ჟურნალები

თუ თქვენ გაქვთ რეგულარული ჰოსტინგი, მაშინ, სავარაუდოდ, მოგიწევთ მისწეროთ თქვენს ჰოსტერს და მოითხოვოთ ჟურნალები მისგან. ასევე, საკმაოდ ხშირად შეგიძლიათ მათი მოთხოვნა ჰოსტინგის პანელის მეშვეობით. სხვადასხვა მასტერები ამას განსხვავებულად აკეთებენ. მაგალითად, ჩემი ჰოსტერისგან მოთხოვნის მიზნით, უბრალოდ დააწკაპუნეთ მთავარი გვერდიპანელები:

შეცდომების ჟურნალი error.log

შეცდომა.log- ფაილი, რომელშიც ასევე ინახება ჟურნალები. მაგრამ არა ვიზიტორები, არამედ შეცდომები, რომლებიც მოხდა სერვერზე. როგორც ეს ხდება წვდომა.log, ფაილის თითოეული ხაზი პასუხისმგებელია ერთ შეცდომაზე, რომელიც მოხდა. ჩაწერა ხორციელდება ისეთი ინფორმაციის გათვალისწინებით, როგორიცაა: შეცდომის წარმოშობის ზუსტი თარიღი და დრო, IP მისამართი, რომელზედაც იყო შეცდომა, შეცდომის ტიპი, ასევე მისი წარმოშობის მიზეზი.

დასკვნა

ჟურნალები საკმაოდ ძლიერი და ინფორმაციული ინსტრუმენტია სამუშაოდ. მაგრამ დღესდღეობით ისინი შეიცვალა ისეთი ინსტრუმენტებით, როგორიცაა Yandex.Metrica, Google Analyticsდა ა.შ., რითაც ამარტივებს ჩვენს ცხოვრებას. თუმცა, თუ გეგმავთ განვითარებას, ზრდას და რაიმე ახლის სწავლას, რა თქმა უნდა გირჩევთ, უკეთ გაეცნოთ ამ თემას.

მოვლენების ჟურნალი არის პირველი და უმარტივესი ინსტრუმენტი სისტემის სტატუსის დასადგენად და შეცდომების იდენტიფიცირებისთვის. MySQL-ში ოთხი ძირითადი ჟურნალია:

• შეცდომის ჟურნალი— სტანდარტული შეცდომების ჟურნალი, რომელიც გროვდება სერვერის მუშაობის დროს (დაწყებისა და გაჩერების ჩათვლით);
• ორობითი ჟურნალი- მონაცემთა ბაზის მოდიფიკაციის ყველა ბრძანების ჟურნალი, რომელიც საჭიროა რეპლიკაციისთვის და სარეზერვო ასლისთვის;
• ზოგადი შეკითხვის ჟურნალი- ძირითადი შეკითხვის ჟურნალი;
• ნელი შეკითხვის ჟურნალი- ნელი მოთხოვნების ჟურნალი.

შეცდომების ჟურნალი

ეს ჟურნალი შეიცავს ყველა შეცდომას, რომელიც მოხდა სერვერის მუშაობის დროს, მათ შორის კრიტიკული შეცდომები, ასევე გაჩერება, სერვერის ჩართვა და გაფრთხილებები. ეს არის ის, სადაც თქვენ უნდა დაიწყოთ სისტემის უკმარისობის შემთხვევაში. ნაგულისხმევად, ყველა შეცდომა გამოდის კონსოლში (stderr), ასევე შეგიძლიათ შეცვალოთ შეცდომები syslog-ში (ნაგულისხმევი Debian-ზე) ან ცალკე ჟურნალის ფაილში:

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

# შეცდომები დაიწერება mysql_error.log-ში

ჩვენ გირჩევთ, რომ ჩართული იყოს ეს ჟურნალი შეცდომების სწრაფად იდენტიფიცირებისთვის. და იმის გასაგებად, თუ რას ნიშნავს ესა თუ ის შეცდომა, MySQL-ს აქვს შეცდომის პროგრამა:

Shell> perrror 13 64 OS შეცდომის კოდი 13: ნებართვა უარყოფილია OS შეცდომის კოდი 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 ზოგადი_ლოგი = 1

# მოიცავს ჟურნალს და მიუთითებს ფაილის ადგილმდებარეობას

თქვენ ასევე შეგიძლიათ ჩართოთ/გამორთოთ ის, სანამ MySQL სერვერი მუშაობს:

SET GLOBAL general_log = "ჩართვა"; SET GLOBAL general_log = "OFF";

# თქვენ არ გჭირდებათ სერვერის გადატვირთვა მის გამოსაყენებლად

ნელი მოთხოვნის ჟურნალი

ჟურნალი სასარგებლოა ნელი, ანუ არაეფექტური მოთხოვნების იდენტიფიცირებისთვის. წაიკითხეთ მეტი ში ამ სტატიას.

ჟურნალების ნახვა

Debian-ზე (Ubuntu) ჟურნალების სანახავად თქვენ უნდა გაუშვათ:

# შეცდომის ჟურნალის კუდი -f /var/log/syslog #Query log tail -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 შეკუმშოს გაზიარებული სკრიპტები postrotate test -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 მომხმარებელი? # თუ ეს მოხდა და არ არის შეცდომა, გთხოვთ შეატყობინოთ ხარვეზის შესახებ. #if ps cax | grep -q mysqld; მაშინ if killall -q -s0 -umysql mysqld; შემდეგ გამოდით 1 fi სხვა $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.

შესამოწმებლად, შეასრულეთ შემდეგი ბრძანებები:

პს-ეფ | grep bin/mysqld | cut -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> SET GLOBAL log_queries_not_using_indexes = "ON"; 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 მომხმარებლებს (სახელი) 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> SET GLOBAL 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> SELECT * FROM users WHERE id = 1;

ჩვენი მოთხოვნა იყენებს პირველადი გასაღების ინდექსს ცხრილიდან. მოთხოვნა ძალიან სწრაფად მუშავდება ინდექსის გამოყენებით, ამიტომ ის არ უნდა აისახოს ჟურნალში. გთხოვთ გაითვალისწინოთ, რომ ჟურნალის ფაილი არ უნდა შექმნილიყო.

ახლა გააკეთე შემდეგი:

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

აქ ჩვენ არ გამოვიყენეთ ინდექსები. ჩვენ ახლა უნდა ვნახოთ ეს მოთხოვნა ჟურნალში:

Sudo cat /var/log/mysql/localhost-slow.log # დრო: 140322 13:54:58 # მომხმარებელი@მასპინძელი: root @ localhost # შეკითხვის_დრო: 0.000303 ჩაკეტვის_დრო: 0.000090 რიგები_გაგზავნილი: 1 Rows_10 profileed SET timestamp=1395521698; SELECT * FROM users WHERE name = "Jesse";

მოდით შევხედოთ სხვა მაგალითს. აწიეთ ზოლი პასუხში ხაზების რაოდენობაზე და განახორციელეთ შემდეგი მოთხოვნა:

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 timestamp=1395521698; SELECT * FROM users WHERE name = "Jesse";

აქ ჩვენ ვხედავთ:

• დრო, როდესაც მოთხოვნა დაიწყო
• მომხმარებელი, რომელმაც გააკეთა მოთხოვნა
• სამუშაო საათების მოთხოვნა
• დაბლოკვის ხანგრძლივობა
• არჩეული რიგების რაოდენობა
• გაანალიზებული ხაზების რაოდენობა

ეს მონაცემები ძალიან სასარგებლოა, რადგან მისი დახმარებით შეგვიძლია ვიპოვოთ და აღმოვფხვრათ სისტემის შენელების მიზეზი. ასევე, MySQL დეველოპერს ან ადმინისტრატორს ყოველთვის შეეძლება ნახოს პრობლემური მოთხოვნები და მინდა აღვნიშნო, რომ აქ მათი პოვნა ბევრად უფრო სწრაფია, ვიდრე სწავლით. პროგრამის კოდიაპლიკაციები. გრძელვადიანი პროფილირებით, თქვენ შეგიძლიათ აკონტროლოთ სამუშაო პირობები დაბალი სიჩქარით.

mysqldumpslow-ის გამოყენება

ჟურნალი მუდმივად იწერს მონაცემებს, როგორც წესი, ის წერს ბევრად მეტს, ვიდრე იკითხება მისგან. ზე დიდი ზომისჟურნალი, მისი წაკითხვა პრობლემური ხდება. MySQL მოიცავს ხელსაწყოს სახელწოდებით mysqldumpslow, რომელიც ეხმარება ჟურნალის მთლიანობის შენარჩუნებაში. თავად პროგრამა კომბინირებულია MySQL-თან (ჩართულია Linux სისტემები). მის გამოსაყენებლად, შეასრულეთ საჭირო ბრძანება და გადაიტანეთ გზა ჟურნალის ფაილისკენ:

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

არსებობს რამდენიმე პარამეტრი, რომელიც დაგეხმარებათ ბრძანების გამომავალი პერსონალურად მორგებაში. ქვემოთ მოცემულ მაგალითში ჩვენ ვნახავთ ბოლო ხუთ მოთხოვნას დალაგებულ საშუალო ხანგრძლივობის მიხედვით. შედეგად, ჟურნალის კითხვა ბევრად უფრო მოსახერხებელი ხდება. (გამომავალი შეცვლილია ჟურნალის რეალური მნიშვნელობების საჩვენებლად):

რაოდენობა: 2 დრო=68,34 წმ (136 წმ) ჩაკეტვა=0,00 წმ (0 წმ) რიგები=39892974.5 (79785949), root@localhost SELECT PL.pl_title, P.page_title გვერდიდან P INNER JOIN pagelinks PL_pagenamespacespace = WHERE 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 STATE DURATION 1 დაწყებული 0.000046 2 შემოწმების ნებართვა 0.000005 3 გახსნის ცხრილი 0.000036

სახელმწიფო- ნაბიჯი მოთხოვნის შესრულების პროცესში, ხანგრძლივობა- ნაბიჯის ხანგრძლივობა წამებში. ეს ინსტრუმენტი არც თუ ისე ხშირად გამოიყენება, მაგრამ ზოგჯერ ის შეიძლება იყოს ძალიან სასარგებლო შეკითხვის ნელი შესრულების მიზეზის დასადგენად.

სვეტების დეტალური აღწერა:

ნაბიჯების დეტალური აღწერა:

შენიშვნა: ეს ინსტრუმენტი არ უნდა იქნას გამოყენებული სერვერის წარმოების რეჟიმში, გარდა კონკრეტული მოთხოვნების ანალიზისა.

შეკითხვის ჟურნალის ნელი შესრულება

ბოლო კითხვა არის ის, თუ როგორ ახდენს პროფილირება გავლენას სერვერის მუშაობაზე მთლიანობაში. სერვერის წარმოების რეჟიმში, თქვენ შეგიძლიათ უსაფრთხოდ გამოიყენოთ ასეთი შესვლა, ეს არ უნდა იმოქმედოს არც CPU-ზე და არც I/O-ზე. თუმცა, ღირს ყურადღება მიაქციოთ ჟურნალის ფაილის ზომას, ის არ უნდა გახდეს ძალიან დიდი. გამოცდილებიდანაც მინდა აღვნიშნო, რომ long_query_time ცვლადის მნიშვნელობის დაყენება 1 წამზე ან უფრო მაღალზე.

მნიშვნელოვანი: არ უნდა გამოიყენოთ პროფილირების ხელსაწყო - SET პროფილირება = 1 - ყველა მოთხოვნის ჩასაწერად, ე.ი. არ არის რეკომენდებული general_log ცვლადის გამოყენება პროდუქტის რეჟიმში და მძიმე დატვირთვის დროს.

დასკვნა

შეკითხვის პროფილირება ძალიან დაგეხმარებათ პრობლემური მოთხოვნის იზოლირებაში და საერთო შესრულების შეფასებაში. დეველოპერს ასევე შეუძლია შეისწავლოს როგორ მუშაობს მისი აპლიკაციის MySQL მოთხოვნები. mysqldumpslow ინსტრუმენტი გეხმარებათ შეკითხვის ჟურნალების ნახვასა და დამუშავებაში. პრობლემური მოთხოვნების იდენტიფიცირების შემდეგ, რჩება მხოლოდ მათი დარეგულირება მაქსიმალური შესრულებისთვის.