პატარა მოთხოვნები მუშაობს, დიდები ვერ ხერხდება: რომელი პაკეტის ზომაა?
SQL Server-ის დრაივერის პაკეტები, MySQL-ის შეტყობინების ზღვრები და IP მარშრუტის MTU სხვადასხვა ერთეულია. ზომაზე დამოკიდებული ჩავარდნა მათ ურთიერთშემცვლელს არ ხდის.
პატარა მოთხოვნები ბრუნდება, დიდები კიდება ან ვარდება, და პირველი ინსტინქტი ისაა, რომ პაკეტის ზომაში რაღაც არ არის რიგზე. ეს ინსტინქტი ჩვეულებრივ სწორია და თითქმის ყოველთვის არასწორ ფენას უმიზნებს. სამი პარამეტრი იზიარებს სიტყვა პაკეტს და ზომავს სამ დაუკავშირებელ რამეს: მონაცემთა ბაზის დრაივერის სატრანსპორტო შეფუთვას, მონაცემთა ბაზის სერვერის შეტყობინების ზღვარს და IP მარშრუტის გადაცემის მაქსიმალურ ერთეულს. ერთის რეგულირება მეორის გამოწვეული სიმპტომის გამოსასწორებლად ის გზაა, რომლითაც ხუთწუთიანი პრობლემა ერთკვირიან რეგულირებად იქცევა. ქვემოთ მოცემული თანმიმდევრობა ყველაზე ნაკლებ დროს მართმევს.
სამი ფენა, ერთი საერთო სიტყვა
ქვემოთ ყოველი სტრიქონი სხვადასხვა მფლობელის მქონე სხვადასხვა ერთეულია და არც ერთზე არ შეიძლება მსჯელობა სხვებისგან. მონაცემთა ბაზის შეტყობინებას შეუძლია მოიცვას ბევრი TCP სეგმენტი და ბევრი IP პაკეტი, ამიტომ მისი დასაშვები ზომის გაზრდა მარშრუტს არ აფართოებს, და დრაივერის პარამეტრის შემცირება არ არის იგივე ოპერაცია, რაც ინტერფეისის MTU-ის შეცვლა. სიტყვა სამ სხვადასხვა კონფიგურაციის ფაილში გვხვდება, ამიტომ მისი ძებნა სამ დაუკავშირებელ პასუხს აბრუნებს. ჯერ წაიკითხეთ შეცდომის ტექსტი, შემდეგ გადაწყვიტეთ, რომელი ფაილი გახსნათ.
| Setting or observation | Unit it describes |
|---|---|
| SQL Server client network packet setting | The provider's transport packaging for that connection |
| MySQL communication packet limit | A database message, such as one statement, row or replication event |
| IP path MTU | The largest IP packet the path carries without fragmentation handling |
სანამ კონფიგურაციის ფაილს გახსნით, ჩაწერეთ, რომელ ფენას ეკუთვნის წარუმატებელი ოპერაცია. შეცდომის ტექსტი ჩვეულებრივ ამას ამბობს, და სწორედ ის ნაწილი გამოტოვებენ ხალხი.
ვიდრე მის პარამეტრს შეცვლით, დაადგინეთ პროვაიდერი
SQL Server-ისთვის ჩაწერეთ აპლიკაცია, დრაივერის ან პროვაიდერის სახელი, ვერსია და ეფექტური კავშირის კონფიგურაცია. დიაგნოსტიკურ სკრიპტს და დესკტოპ აპლიკაციას შეუძლია იმავე სერვერს მიაღწიოს სხვადასხვა პროვაიდერის მეშვეობით, ამიტომ ერთს რომ ეხმარება, მეორეზე არაფერს ამტკიცებს. პროვაიდერების ნაგულისხმევი მნიშვნელობები განსხვავდება, და კავშირის სტრიქონის მსგავსი სახელის ველი არ არის მტკიცებულება, რომ ყოველი პროვაიდერი მას ერთნაირად განმარტავს.
ნუ შეცვლით მხარდაჭერილ დრაივერს ძველით მხოლოდ იმიტომ, რომ ძველი გადაწყვეტა მის სინტაქსს იყენებდა. მიმდინარე დოკუმენტაცია არ მოუწოდებს ახალ განვითარებას ამ ძველ კომპონენტებზე, და მათი შეზღუდვების მემკვიდრეობით მიღება ცუდი გარიგებაა ერთი პარამეტრისთვის.
შეტყობინების უარყოფა მარშრუტის გაჩერება არ არის
MySQL 8.4-ში კომუნიკაციური პაკეტის დოკუმენტაცია აღწერს ძალიან დიდი განცხადების, სტრიქონის ან ორობითი ლოგის მოვლენის უარყოფას მოქმედი ზღვრის მიმართ, და შეიძლება მნიშვნელოვანი იყოს როგორც კლიენტის, ისე სერვერის ზღვარი. ეს უარყოფაა მონაცემთა ბაზის ფენაზე, არა მტკიცება, რომ ქსელმა უნდა ატაროს უზარმაზარი IP პაკეტი. წაიკითხეთ ფაქტობრივი შეცდომა და პრობლემური შეტყობინების ფორმა: ბევრი პატარა სტრიქონისგან შედგენილი დიდი შედეგი განსხვავებული შემთხვევაა ერთი უზარმაზარი სტრიქონისგან, და ისინი სხვადასხვანაირად ვარდება.
MariaDB-ის ინსტალაციებს სჭირდებათ საკუთარი ვერსიის დოკუმენტირებული ზღვრები და დიაგნოსტიკა. MySQL-ის ნაგულისხმევი მნიშვნელობების MariaDB-ზე კოპირება დამატებითი ნაბიჯებით გამოცნობაა.
როგორ გამოიყურება მარშრუტის მტკიცებულება სინამდვილეში
მარშრუტის ზომის პრობლემას საკუთარი თითის ანაბეჭდი აქვს: განმეორებადი ზომაზე დამოკიდებული სატრანსპორტო ჩავარდნა გარკვეულ მარშრუტსა და მისამართების ოჯახზე, გვირაბის დამატებითი ხარჯის ჩართვით და აღმოჩენის უკუკავშირით, რომელიც ისე იქცევა, როგორც მარშრუტი უშვებს. მხოლოდ დროის ამოწურვა არ განასხვავებს მას ნელი მოთხოვნისგან, დრაივერის ხარვეზისგან ან სერვერის მხრიდან ზღვრისგან, და დროის ამოწურვის MTU პრობლემის მტკიცებულებად მიჩნევა თავდაჯერებულად არასწორ ფენაზე გგზავნით.
თუ მარშრუტს მაინც ამოწმებთ, დანიშნულება, ანგარიში და დატვირთვა უცვლელად დაიტოვეთ, რომ ერთადერთი ცვლადი იყოს ზომა, რომელსაც იკვლევთ. ტესტი, რომელშიც სამი რამ შეიცვალა, არაფერს გიყვებათ იმაზე, რომელი იყო მნიშვნელოვანი.
შეცვალეთ ერთი დოკუმენტირებული ცვლადი, შემდეგ ჩაწერეთ ის
დანიშნულება, ანგარიში, პროვაიდერი და დატვირთვა მუდმივად დაიტოვეთ, ჩაწერეთ საწყისი მნიშვნელობა, გამოიყენეთ ერთი მხარდაჭერილი ცვლილება და ჩაწერეთ შედეგი. უფრო მცირე პარამეტრი, რომელიც ერთ ტესტს ალაგებს, სასარგებლო მტკიცებულებაა იმ გამოცდილი სტეკის შესახებ; ის არ არის უნივერსალური ოპტიმუმი და არ ადგენს, რამ გამოიწვია საწყისი ჩავარდნა. ეს სხვადასხვა მტკიცებაა და მხოლოდ პირველს უჭერს მხარს ერთი ექსპერიმენტი.
გადაწყვიტეთ გამოვლენილი ზღვარი მისივე ფენაზე, შემდეგ ჩაწერეთ, რომელი ფენა იყო. სწორედ ჩანაწერი უშლის ხელს შემდეგ ადამიანს დრაივერის რეგულირებაში, რადგან პრობლემა მარშრუტი იყო.