HomePhabricator
สรุปปัญหาเว็บล่มและเว็บพัง (Part 1)
16 พฤษภาคม 2561

ปัญหาเว็บพัง

เป็นปัญหาที่เกิดต่อเนื่องมาเมื่อหลายสัปดาห์ก่อน คือเว็บแสดงผลผิดปกติ

สันนิษฐาน 1.

  • คาดว่าเกิดจากกรณีตัวบีบอัด CSS/JS ทำงานผิดพลาด หาไฟล์ในการบีบอัดไม่พบด้วยสาเหตุที่ยังไม่ชัดเจน(อาจเป็นได้ทั้งฮาร์ดแวร์และซอฟท์แวร์) จึงดำเนินการปิดการทำงานฟีเจอร์นี้ (ซึ่งจะส่งผลให้การเข้าเว็บไซต์ช้าลง)
  • หลังดำเนินการปิดฟีเจอร์นี้ไปแล้ว ยังพบปัญหา อีกครั้ง แต่เนื่องจากการบีบอัดถูกปิดลงแล้ว การวิเคราะห์ปัญหาถึงทำได้ง่ายขึ้น จากการวิเคราะห์ปัญหา ทำให้เห็นว่า ระบบเว็บไซต์ทั้งหมด มองไม่เห็นชุดตีมของ Drupal8 ใดๆเลย จึงได้ดำเนินการตรวจสอบคอนฟิกหลายส่วนอีกครั้ง สันนิษฐานของปัญหาน่าจะมาอยู่ที่การแชร์ table key_value ระหว่างเว็บ JOB และ YP ทั้งหมด สันนิษฐานในเทเบิ้ลนี้อาจมีค่าที่ค่าพื้นที่เก็บตีมที่อยู่บนดิสก์ แต่เนื่องจากดิสก็ของเครื่อง JOB และ YP มีโครงสร้างแตกต่างกัน ทำให้ระบบ Drupal8 หาตีมไม่เจอทั้งหมด จึงดำเนินการแยกเทเบิ้ลนี้ออกจากกัน ปัจจุบันหลังจากการดำเนินการดังกล่าว ปัญหาเว็บพัง ยังไม่เกิดขึ้นอีก
  • หากปัญหาเว็บพังไม่เกิดขึ้นแล้ว ทางทีมจะทดสอบนำตัวบีบอัดกลับมาใช้อีกครั้ง

อนึ่งปัญหาเว็บพังนี้ไม่สามารถทำให้เกิดซ้ำในสภาพแวดล้อมอื่นๆได้ และเกิดบรเครื่องจริงเท่านั้น การดำเนินการแก้ไขปัญหาจึงใช้เวลายาวนาน

WARNING: ระยะเวลาที่เว็บพัง เกิดขึ้นเรื่อยๆ แต่ถี่มากขึ้นจนถึงวันพุธที่ 9 พฤษภาคม 2560
NOTE: สถานะ: รอคอนเฟิร์มว่าปัญหาไม่เกิดขึ้นแล้ว

ปัญหาเว็บล่ม

เมื่อเวลาประมาณ 10:10 ของวันนี้ ตัวแจ้งเตือนการทำงานของเว็บ แจ้งว่า เว็บไม่ตอบสนอง (เว็บล่ม) มี SMS แจ้งเตือนหลายครั้ง
จากตัว Monitor ทำให้สามารถระบุปัญหาได้ทันทีว่า เป็นที่ ดาต้าเบส Server

จากการตรวจสอบเบื้องต้นบน Database Server (Maria192)

  • พบปัญหาแสดงผลใน Process Log
root       1108  0.0  0.0 211984  1656 ?        Ss    2017   1:23 /usr/bin/abrt-watch-log -F BUG: WARNING: at WARNING: CPU: INFO: possible recursive locking detected ernel BUG at list_del corruption list_add corruption do_IRQ: stack overflow: ear stack overflow (cur: eneral protection fault nable to handle kernel ouble fault: RTNL: assertion failed eek! page_mapcount(page) went negative! adness at NETDEV WATCHDOG ysctl table check failed : nobody cared IRQ handler type mismatch Machine Check Exception: Machine check events logged divide error: bounds: coprocessor segment overrun: invalid TSS: segment not present: invalid opcode: alignment check: stack segment: fpu exception: simd exception: iret exception: /var/log/messages -- /usr/bin/abrt-dump-oops -xtD
  • และ Log ของ MySQL ขณะ Server มีปัญหาดังนี้
180516 10:07:14 [ERROR] mysqld: Deadlock found when trying to get lock; try restarting transaction
180516 10:07:14 [ERROR] mysqld: Deadlock found when trying to get lock; try restarting transaction
180516 10:07:14 [ERROR] mysqld: Deadlock found when trying to get lock; try restarting transaction
180516 10:07:14 [ERROR] mysqld: Deadlock found when trying to get lock; try restarting transaction
180516 10:07:14 [ERROR] mysqld: Deadlock found when trying to get lock; try restarting transaction
180516 10:07:14 [ERROR] mysqld: Deadlock found when trying to get lock; try restarting transaction
180516 10:07:22 [ERROR] mysqld: Deadlock found when trying to get lock; try restarting transaction
180516 10:07:33 [ERROR] mysqld: Deadlock found when trying to get lock; try restarting transaction
180516 10:07:37 [ERROR] mysqld: Deadlock found when trying to get lock; try restarting transaction
180516 10:07:37 [ERROR] mysqld: Deadlock found when trying to get lock; try restarting transaction
180516 10:07:39 [ERROR] mysqld: Deadlock found when trying to get lock; try restarting transaction

การแก้ไข

1.ได้พยายาม restart MySQL แต่ไม่สำเร็จ จึงดำเนินการ kill process MySQL ทิ้ง การ restart จึงสำเร็จ
2. ปัญหา Process Log อันแรกที่เจอ หลังจากตรวจดูแล้วไ่ม่น่าเกี่ยวข้องอีก และการสืบข้อมูลใน Internet ก็พบว่า ไม่น่าใช่ปัญหาอะไร ประจวบกับ เป็นปัญหาท่ี่แสดงผลมาตั้งแต่ปี 2017 จึงขอข้ามไป
3. จึงเหลือแต่มาดูว่าปัญหา Deadlock เกิดได้อย่างไร  จากการสืบค้นดูวิธีแก้ปัญหา ได้รับทราบว่า เป็นปัญหาที่อาจเกิดขึ้นได้หากมีปริมาณ traffic spike ขึ้นอย่างสูง //(รอการคอนเฟิร์มอีกครั้ง)// มีคำแนะนำให้มีการปรับเปลี่ยนค่าคอนฟิก หรืออัพเกรดโมดูลซอฟท์แวร์บางอย่าง ซึ่งจะต้องใช้เวลาในการทดสอบให้แน่ใจก่อนนำมาใช้จริง

ทางเลือกระยะสั้น

  1. Quick fix => ย้าย Semaphore (Lock Table) จาก InnoDB ไปอยู่บน Memory
  2. Moderated fix => ปรับโมดูลในการแคชจาก Memcache Storage เป็น Memcache API (ซึ่งพึ่งรันบน Drupal8 ได้ไม่นานและ support การ lock บน Memcache)
  3. Plan fix => ปรับโมดูลในการแคชจาก Memcache เป็น Redis ซึ่งเป็นระบบแคชที่ดีกว่า Memcache ทั้งหมดและเคยวางแผนไว้แล้ว แต่ต้องมีการปรับเปลี่ยนมากสุด
WARNING: ระยะเวลาที่เว็บล่ม ช่วงเวลา 10:07-10:22 ของวันที่ 16 พฤษภาคม
NOTE: สถานะ: รอการทดสอบเพื่ออัพเกรดระบบต่อไป

ทางเลือกในแผนระยะยาว

  • เพิ่ม Server MySQL ทำเป็น Cluster เพื่อรองรับการทำงานที่มากขึ้น
  • การนำระบบขึ้น Cloud ทั้งหมดเป็น backup site
  • การแชร์รีซอร์สระหว่างองค์กร CSL/AIS เพื่อเข้ามาดูแล Infrastructure ทั้งหมด

อ้างอิง

Written by vorapoap on May 16 2018, 12:13 PM.
User
Projects
None
Subscribers
None

Event Timeline