WORDPRESS网站500、502、503、504错误的4大罪魁祸首

რამდენიმე WordPress ვებსაიტს ვმართავ და ერთხელ 502 შეცდომის გამო ერთ დღეში 800-ზე მეტი ვიზიტი დავკარგე. სამდღიანი ძიების შემდეგ აღმოვაჩინე, რომ დამნაშავე შეუმჩნეველ ადგილას იმყოფებოდა.

ყველამ, ვინც WordPress ვებსაიტს მართავს, იცის, რომ ყველაზე იმედგაცრუებული არა ტრაფიკის ნაკლებობაა, არამედ ის, როდესაც ვებსაიტი მოულოდნელად მიუწვდომელი ხდება და ეკრანზე ისეთი გაუგებარი შეცდომები ჩნდება, როგორიცაა 500, 502, 503 და 504.

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

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

სინამდვილეში, ეს ასე რთული არ უნდა იყოს. უამრავ ხაფანგში გაბმის შემდეგ აღმოვაჩინე, რომ WP website 5xx შეცდომების 80% ამ 4 დამნაშავეს ვერ გაექცევა. თითოეული მათგანი კარგად არის დაფარული, მაგრამ მას შეუძლია ადვილად გაანადგუროს თქვენი ვებსაიტი.

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

დამნაშავე #1: WP-CRON არ იყო გამორთული, ფაქტობრივად, ვებსაიტზე „ფარული ენერგიის გადინება“ დამონტაჟდა.

ბევრმა არ იცის, რომ WordPress-ს აქვს ჩაშენებული დაგეგმილ დავალებების ფუნქცია, სახელწოდებით WP-CRON, რომელიც სტანდარტულად ჩართულია.

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

მაგრამ იცოდით, რომ ეს, ერთი შეხედვით, სასარგებლო ფუნქცია სინამდვილეში სერვერების გათიშვისა და 5xx შეცდომების გამომწვევი ნომერ პირველი დამნაშავეა?

WP-CRON განსხვავდება სერვერის მშობლიური Cron-ისგან. ის პროაქტიულად არ მუშაობს, არამედ აქტიურდება მომხმარებლის ვიზიტებით. ყოველ ჯერზე, როდესაც მომხმარებელი ეწვევა თქვენს ვებსაიტს, ის ფარულად შეასრულებს /wp-cron.php ფაილს, რათა შეამოწმოს, არის თუ არა რაიმე დაგეგმილი შესასრულებელი დავალება.

ეს ნიშნავს, რომ თქვენს ვებსაიტზე შემოსული თითოეული ვიზიტორი „დამატებით ტვირთს“ ქმნის და რაც უფრო მეტი ვიზიტორი გყავთ, მით უფრო მძიმე ხდება ტვირთი.

ადრე მქონდა ვებსაიტი, რომელსაც დღეში ათასზე მეტი ვიზიტორი ჰყავდა. როდესაც WP-CRON არ იყო გამორთული, სერვერის CPU-ს დატვირთვა ხშირად 80%-ზე მეტს აღწევდა და ყოველდღიურად სულ მცირე ორი 503 შეცდომა ხდებოდა, რის გამოც ვიზიტორები შეცდომის გვერდზე გადამისამართდებოდნენ, როგორც კი მასზე დააწკაპუნებდნენ.

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

GitHub-ის დოკუმენტაციაში ნათლად არის მითითებული: „მოულოდნელი HTTP პასუხის კოდი: 500 ან უფრო მაღალი, ეს ნიშნავს, რომ თქვენს სერვერზე მოხდა შეცდომა, რომელიც ხელს უშლის cron spawner-ის გაშვებას“. ეს ნიშნავს, რომ როდესაც WP-CRON ვერ ფუნქციონირებს სწორად, ეს გამოიწვევს სერვერის შეცდომას 500 ან უფრო მაღალი მნიშვნელობით.

სწორი მიდგომაა ნაგულისხმევი WP-CRON-ის გამორთვა და სერვერის მშობლიური დაგეგმილი დავალებების გამოყენება. ეს უზრუნველყოფს დაგეგმილი დავალებების ნორმალურად შესრულებას და ამავდროულად შეამცირებს სერვერის დატვირთვას.

თუ თქვენი სერვერი მხარს უჭერს curl ბრძანებას, შეგიძლიათ პირდაპირ დაამატოთ დაგეგმილი დავალება, როგორიცაა ეს (შეცვალეთ თქვენი ვებსაიტის დომენის მიხედვით):

*/15 * * * * curl https://www. 你的域名/wp-cron.php?doing_wp_cron > /dev/null 2>&1

ეს ბრძანება ასრულებს WP-CRON დავალებას ყოველ 15 წუთში, რაც შესაფერისია მცირე და საშუალო ზომის ვებსაიტების უმეტესობისთვის; თუ თქვენს ვებსაიტს აქვს ხშირი დაგეგმილი დავალებები, ასევე შეგიძლიათ გამოიყენოთ ეს:

*/5 * * * * curl https://www. 你的域名/wp-cron.php?doing_wp_cron > /dev/null 2>&1

WP-CRON-ის გამორთვისა და სერვერზე დაგეგმილი დავალებების დაყენების შემდეგ, სერვერის CPU-ს დატვირთვა 30%-ზე დაბლა დაეცა და მთელი თვის განმავლობაში 503 შეცდომა არ დაფიქსირებულა. ვიზიტორების შეკავების მაჩვენებელიც 18%-ით გაიზარდა.

დამნაშავე ნომერი მეორე: CRON-ის განმეორებითი დაგეგმილი დავალებები და დანამატის დეინსტალაციის შემდეგ დარჩენილი ფაილები არსებითად ვებსაიტზე „ნაგვის“ დატოვებაა.

WP-CRON პრობლემის გადაჭრა არ ნიშნავს, რომ შეგიძლიათ მშვიდად იყოთ; არსებობს ფარული ნაკლი, რომელსაც ბევრი ვებსაიტის მფლობელი ვერ ამჩნევს.

ეს ნიშნავს, რომ CRON-ის დაგეგმილი დავალებები განმეორებით მუშაობს, ან დარჩენილი დაგეგმილი დავალებები კვლავ ფარულად მუშაობს მოდულის დეინსტალაციის შემდეგ.

ოდესმე გქონიათ მსგავსი რამ: წაშალეთ სარეზერვო ასლის მოდული, მაგრამ აღმოაჩინეთ, რომ სერვერი მაინც ავტომატურად ქმნის სარეზერვო ასლს ყოველდღე, ან თუნდაც აჩვენებს სარეზერვო ასლის შექმნის წარუმატებლობის შეტყობინებას, რაც საბოლოოდ იწვევს 500 შეცდომას?

ეს გამოწვეულია მოდულიდან დარჩენილი დაგეგმილი დავალებებით.

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

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

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

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

თუმცა, გამოსავალი არსებობს: WP-Crontrol მოდული იდეალურად უმკლავდება ამას. ეს არის WordPress-ის მიერ რეკომენდებული Cron-ის დავალებების მართვის ოფიციალური ინსტრუმენტი, რომელიც საშუალებას გაძლევთ პირდაპირ backend-ში ნახოთ, შეცვალოთ და წაშალოთ ყველა დაგეგმილი დავალება.

WordPress-ის დანამატის აღწერილობის თანახმად, WP-Crontrol-ს შეუძლია „ყველა დაგეგმილი cron მოვლენის ნახვა, რედაქტირება, წაშლა, პაუზა, განახლება და დაუყოვნებლივ გაშვება“. სხვა სიტყვებით რომ ვთქვათ, მას შეუძლია ყველა დაგეგმილი დავალების ნახვა და დუბლიკატი ან არასწორი დავალებების წაშლა. მისი გამოყენება ძალიან მარტივია და არ საჭიროებს კოდის ერთი სტრიქონის დაწერას.

ამ დანამატის პრობლემების გადასაჭრელად გამოყენების შემდეგ, წავშალე 8 დუბლიკატი დავალება და 5 დანამატის ნარჩენი დავალება და ვებსაიტის რეაგირების სიჩქარე პირდაპირ 40%-ით გაუმჯობესდა. 504 შეცდომა აღარასდროს განმეორებულა.

გაფრთხილება: დავალებების წაშლისას, ყურადღებით შეამოწმეთ და თავიდან აიცილეთ WordPress-ის დაგეგმილი ძირითადი დავალებების შემთხვევით წაშლა, როგორიცაა „wp_version_check“ (ვერსიის შემოწმება). შემთხვევითმა წაშლამ შეიძლება ხელი შეუშალოს ვებსაიტის სწორად განახლებას.

მიუხედავად იმისა, რომ WP-Crontrol დანამატს შეუძლია ხელით წაშალოს დუბლიკატი ან არასწორი დავალებები, ის მოითხოვს ხელით ჩარევას, რაც იდეალური არ არის...

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

🔗WordPress ვებსაიტის დაჩქარების რჩევები: ავტომატურად წაშალეთ არასწორი CRON დაგეგმილი დავალებები

დამნაშავე #3: ზედმეტი მონაცემთა ბაზები WordPress-ში

WordPress-ში, 500 შეცდომის ერთ-ერთი მიზეზი მონაცემთა ბაზის რეზერვირებაა, განსაკუთრებით გარკვეული დანამატების მიერ გენერირებული დიდი მონაცემთა ცხრილები.

WP ოპტიმიზაციის დანამატის გამოყენებისას აღმოვაჩინე, რომ ზოგიერთი მონაცემთა ცხრილი არანორმალურად დიდი იყო, განსაკუთრებით Wordfence-ის კონფიგურაციის ცხრილი (wfconfig) .

პრობლემის ანალიზი

• wfconfig-ს მონაცემთა ცხრილების სერიოზული ჭარბი რაოდენობა აქვს.ის ადრე ერთხელ გაიწმინდა, მაგრამ ძალიან სწრაფად გამოჩნდა.
• ნაგულისხმევი შენახვის ძრავის პრობლემებიWordfence-ის კონფიგურაციის ცხრილი იყენებს სტანდარტულ InnoDB ძრავას, რომელიც დროთა განმავლობაში ასობით მბ ზედმეტი მონაცემების დაგროვებას გამოიწვევს.
• გავლენა შესრულებაზემონაცემთა ცხრილების ზომამ შეიძლება ადვილად მიაღწიოს ასობით მბ-ს, რაც იწვევს ვებსაიტის ჩატვირთვის სიჩქარის შემცირებას და 500 შეცდომასაც კი.

გამოსავალი

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

HestiaCP-ის გამოყენებით MariaDB-ის ნაგულისხმევი შენახვის ძრავის MyISAM-ზე შეცვლის ინსტრუქციისთვის , გთხოვთ, იხილოთ შემდეგი სახელმძღვანელო:

როგორ შევცვალოთ MariaDB-ის ნაგულისხმევი შენახვის ძრავა MyISAM-ით HestiaCP-ში? მარტივი, ერთსაფეხურიანი გადაწყვეტა!

მეოთხე დამნაშავე: მოდულის/თემის განახლების შემდეგ დაშვებული შეცდომები ვებსაიტზე „არაორდინალური ოპერაციის“ ჩატარებას ჰგავს.

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

მაგრამ სიმართლე საპირისპიროა; 5xx-ის მრავალი შეცდომა გამოწვეულია დანამატების ან თემების განახლებით.

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

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

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

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

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

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

ბევრმა ადამიანმა არ იცის, როგორ დააბრუნოს ძველი ვერსია, თუმცა ფაილების ხელით ჩამოტვირთვა ან ატვირთვა საჭირო არ არის; WP Rollback მოდული ამას აადვილებს.

WordPress-ის აღწერილობის თანახმად, WP Rollback დანამატს შეუძლია „სწრაფად და მარტივად დააბრუნოს ნებისმიერი თემა ან დანამატი wordpress.org-დან ნებისმიერ წინა (ან უფრო ახალ) ვერსიაზე, ყოველგვარი ხელით უსიამოვნების გარეშე“. სხვა სიტყვებით რომ ვთქვათ, მას შეუძლია დააბრუნოს დანამატები ან თემები ნებისმიერ წინა ვერსიაზე ერთი დაწკაპუნებით, რთული ოპერაციების გარეშე, რაც დამწყებთათვის მის გამოყენებას აადვილებს.

მას შემდეგ, რაც ჩემი ბოლო პლაგინის განახლება წარუმატებელი აღმოჩნდა, WP Rollback-ის გამოყენებით ერთი დაწკაპუნებით დავბრუნდი წინა ვერსიაზე. ვებსაიტი ჩვეულ რეჟიმში მხოლოდ 30 წამში დაბრუნდა და მონაცემები არ დაკარგულა.

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

დასკვნა: დაეუფლეთ ამ 3 პუნქტს, რათა სრულად დაემშვიდობოთ WP ვებსაიტის 5xx შეცდომებს.

WordPress ვებსაიტის გაშვებისას, 500, 502, 503 და 504 შეცდომები „დაბრკოლებას“ ჰგავს, ერთი შეხედვით პრობლემურია, მაგრამ ძირითადი მიზეზი სინამდვილეში საკმაოდ ნათელია - საქმე იმაში არ არის, რომ სერვერი გაუმართავია და არც ვებსაიტის პროგრამას აქვს რაიმე სერიოზული პრობლემა, არამედ ის, რომ ჩვენ გამოგვრჩა სამი დეტალი: WP-CRON, ნარჩენი დაგეგმილი დავალებები და დანამატის/თემის განახლებები.

როგორც WordPress ვებსაიტის მფლობელის, თავიდან შეცდომებით გადატვირთული ყოფნის შემდეგ, სანამ ახლა უკვე შემიძლია სწრაფად მოვაგვარო ყველა 5xx შეცდომა, ყველაზე მნიშვნელოვანი დასკვნა ის არის, რომ ვებსაიტის სტაბილური ფუნქციონირება არ არის დამოკიდებული „ცხენის გაქცევის შემდეგ საჯინიბოს კარის ჩაკეტვაზე“, არამედ „პრევენცია უკეთესია, ვიდრე განკურნება“.

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

მნიშვნელოვანია გვესმოდეს, რომ ვებსაიტისთვის „სტაბილურობა“ ძირითადი კონკურენტული უპირატესობაა. ერთი 5xx შეცდომა შეიძლება გამოიწვიოს ვიზიტორების 10%-ის დაკარგვა, ხოლო მრავალჯერადმა შეცდომამ შეიძლება საძიებო სისტემებში რეიტინგის დაცემაც კი გამოიწვიოს, რაც თქვენს ყველა წინა SEO ძალისხმევას ფუჭად გაფლანგვას გამოიწვევს.

როგორც ამბობენ, „ათასი მილის სიგრძის ჯებირი შეიძლება ჭიანჭველას ორმოს გაარღვიოს“. WP website 5xx შეცდომები არასდროს ჩნდება მოულოდნელად, არამედ მცირე პრობლემების დაგროვების შედეგია - WP-CRON-ის გამოუყენებელი ნაწილი, დაგეგმილი ამოცანების ნარჩენი ნაწილი და ნაჩქარევი განახლების ოპერაციები. ეს, ერთი შეხედვით, უმნიშვნელო „ჭიანჭველას ორმოები“ საბოლოოდ გაანადგურებს მთელი ვებსაიტის „ჯებირს“.

ჭეშმარიტად ეფექტური ოპერაციები პრობლემების ჩანასახშივე აღმოფხვრას ნიშნავს.

1. გამორთეთ ნაგულისხმევი WP-CRON და შეცვალეთ იგი სერვერზე დაფუძნებული დაგეგმილი დავალებით;
2. რეგულარულად გამოიყენეთ WP-Crontrol განმეორებადი და ნარჩენი დაგეგმილი დავალებების გასასუფთავებლად;
3. დანამატების ან თემების განახლებამდე აუცილებლად შექმენით თქვენი მონაცემების სარეზერვო ასლი და შეცდომების შემთხვევაში დაუყოვნებლივ გააუქმეთ ეს ვერსია.

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

თქვენი ვებსაიტის ყოველი სტაბილური დატვირთვა და ვიზიტორის ყოველი ყოფნა დროთა განმავლობაში თქვენს მიერ დაგროვილი ღირებული აქტივია.

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

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