Score:0

การหยุดทำงานบนอินสแตนซ์ EC2

ธง cn

เมื่อเร็ว ๆ นี้ฉันมีปัญหากับอินสแตนซ์ EC2 ไซต์ที่ทำงานอยู่ที่นั่นไม่สามารถใช้งานได้เป็นเวลา 2 ชั่วโมง:

การใช้งาน CPU ในสัปดาห์ที่ผ่านมา:

ส่วนที่เหลือเป็นเวลาที่เกิดขึ้น:

เดอะ ระบบ วารสาร ประมาณช่วงนั้น

ฉันเห็นอะไรที่นั่น? เมื่อเวลาประมาณ 20:31 น. ดูเหมือนว่าสิ่งต่างๆ จะช้าลง:

การดำเนินงานของงานต่อนาทีที่กำหนดไว้สำหรับ 20:30 น. ล่าช้าเป็น 20:31 นาทีถัดไป ข้ามการเรียกใช้งาน

งาน (คร่อม) ล้มเหลวในการเริ่มต้น

12 มกราคม 21:31:29 ip-172-xx-x-xx.xx-yy-z.compute.internal chronyd[24287]: ตรวจพบการข้ามเวลาไปข้างหน้า!
12 มกราคม 21:33:21 ip-172-xx-x-xx.xx-yy-z.compute.internal chronyd[24287]: ไม่สามารถซิงโครไนซ์ได้: ไม่มีแหล่งที่เลือกได้

เดอะ dhclient เส้นๆมักจะมาพร้อมกันแต่สมัยนั้นจะเป็นแบบนี้

12 มกราคม 20:46:21 ip-172-xx-x-xx.xx-yy-z.compute.internal dhclient[3066]: DHCPREQUEST บน eth0 ถึง 172.xx.x.xx พอร์ต 67 (xid=0x7cb0e02d)
12 มกราคม 20:46:22 ip-172-xx-x-xx.xx-yy-z.compute.internal dhclient[3066]: DHCPACK จาก 172.xx.x.xx (xid=0x7cb0e02d)
12 มกราคม 21:06:23 ip-172-xx-x-xx.xx-yy-z.compute.internal dhclient[3066]: ผูกพันกับ 172.yy.y.yy - ต่ออายุใน 354 วินาที

อีกด้วย:

12 มกราคม 21:47:22 ip-172-xx-x-xx.xx-yy-z.compute.internal dhclient[3066]: ผูกพันกับ 172.yy.y.yy - ต่ออายุใน -554 วินาที

และดูเหมือนว่าเวลา 21:47 น. ทุกอย่างจะกลับมาเป็นปกติ

เดอะ นักเทียบท่า คอนเทนเนอร์ที่ทำงานอยู่ที่นั่นเริ่มต้นใหม่ ฉันจำได้ว่าบันทึกของพวกเขาเริ่มใกล้ 22.00 น. อาจเป็นเวลา 21:47 น.

เดอะ ซิสแตต บันทึก (/var/log/sa/sar12):

07:00:01 น. ทั้งหมด 3.77 0.00 0.53 0.00 0.53 0.00 0.11 0.00 0.00 95.05
07:00:01 น. 0 4.22 0.00 0.54 0.01 0.45 0.00 0.11 0.00 0.00 94.68
07:00:01 น. 1 3.33 0.00 0.53 0.00 0.61 0.00 0.10 0.00 0.00 95.43
07:10:01 น. ทั้งหมด 3.47 0.00 0.52 0.00 0.54 0.00 0.13 0.00 0.00 95.34
07:10:01 น. 0 4.01 0.00 0.53 0.00 0.48 0.00 0.10 0.00 0.00 94.88
07:10:01 น. 1 2.93 0.00 0.52 0.01 0.60 0.00 0.15 0.00 0.00 95.80
07:20:01 น. ทั้งหมด 1.89 0.00 0.47 0.00 0.46 0.00 0.10 0.00 0.00 97.08
07:20:01 น. 0 1.54 0.00 0.46 0.00 0.39 0.00 0.10 0.00 0.00 97.50
07:20:01 น. 1 2.24 0.00 0.48 0.00 0.53 0.00 0.10 0.00 0.00 96.65
07:30:01 น. ทั้งหมด 1.37 0.00 0.47 0.00 0.42 0.00 0.09 0.00 0.00 97.65
07:30:01 น. 0 1.55 0.00 0.46 0.00 0.36 0.00 0.08 0.00 0.00 97.54
07:30:01 น. 1 1.18 0.00 0.48 0.00 0.47 0.00 0.10 0.00 0.00 97.77
07:40:01 น. ทั้งหมด 1.32 0.00 0.47 0.00 0.41 0.00 0.10 0.00 0.00 97.71
07:40:01 น. 0 1.46 0.00 0.46 0.00 0.33 0.00 0.09 0.00 0.00 97.66
07:40:01 น. 1 1.18 0.00 0.47 0.00 0.48 0.00 0.10 0.00 0.00 97.77
07:50:01 น. ทั้งหมด 1.36 0.00 0.48 0.00 0.41 0.00 0.10 0.00 0.00 97.65
07:50:01 น. 0 1.14 0.00 0.45 0.00 0.33 0.00 0.11 0.00 0.00 97.96
07:50:01 น. 1 1.58 0.00 0.50 0.00 0.50 0.00 0.09 0.00 0.00 97.33
08:00:01 น. ทั้งหมด 2.17 0.00 0.52 0.01 0.52 0.00 0.12 0.00 0.00 96.66
08:00:01 น. 0 2.26 0.00 0.49 0.01 0.45 0.00 0.13 0.00 0.00 96.67
08:00:01 น. 1 2.08 0.00 0.55 0.01 0.60 0.00 0.12 0.00 0.00 96.65
08:10:01 น. ทั้งหมด 3.47 1.35 2.41 0.08 0.58 0.00 0.15 0.00 0.00 91.96
08:10:01 น. 0 3.28 1.11 2.38 0.07 0.50 0.00 0.15 0.00 0.00 92.51
08:10:01 น. 1 3.66 1.58 2.45 0.09 0.66 0.00 0.15 0.00 0.00 91.40

08:10:01 PM CPU %usr %nice %sys %iowait %steal %irq %soft %guest %gnice %ไม่ได้ใช้งาน
08:20:01 น. ทั้งหมด 1.73 0.00 0.54 0.07 0.48 0.00 0.10 0.00 0.00 97.07
08:20:01 น. 0 1.94 0.00 0.58 0.07 0.40 0.00 0.10 0.00 0.00 96.90
08:20:01 น. 1 1.52 0.00 0.51 0.08 0.55 0.00 0.11 0.00 0.00 97.23
09:50:02 น. ทั้งหมด 2.11 0.11 50.63 43.63 0.09 0.00 0.02 0.00 0.00 3.41
09:50:02 น. 0 3.34 0.09 15.85 77.19 0.07 0.00 0.02 0.00 0.00 3.45
09:50:02 น. 1 0.93 0.12 83.90 11.54 0.11 0.00 0.02 0.00 0.00 3.37
22:00:01 น. ทั้งหมด 2.11 0.00 0.43 2.61 0.35 0.00 0.07 0.00 0.00 94.42
22:00:01 น. 0 1.87 0.00 0.45 2.73 0.25 0.00 0.07 0.00 0.00 94.63
22:00:01 น. 1 2.36 0.00 0.42 2.50 0.45 0.00 0.07 0.00 0.00 94.20
22:10:01 น. ทั้งหมด 0.80 0.00 0.33 0.00 0.29 0.00 0.06 0.00 0.00 98.52
22:10:01 น. 0 0.82 0.00 0.31 0.00 0.20 0.00 0.07 0.00 0.00 98.59
22:10:01 น. 1 0.77 0.00 0.35 0.00 0.37 0.00 0.06 0.00 0.00 98.45
22:20:01 น. ทั้งหมด 0.85 0.00 0.35 0.00 0.29 0.00 0.07 0.00 0.00 98.44
22:20:01 น. 0 0.85 0.00 0.34 0.00 0.21 0.00 0.07 0.00 0.00 98.53
22:20:01 น. 1 0.86 0.00 0.36 0.00 0.37 0.00 0.06 0.00 0.00 98.35
22:30:01 น. ทั้งหมด 1.41 0.00 0.38 0.00 0.33 0.00 0.08 0.00 0.00 97.79
22:30:01 น. 0 1.13 0.00 0.36 0.00 0.25 0.00 0.07 0.00 0.00 98.18
22:30:01 น. 1 1.69 0.00 0.40 0.00 0.42 0.00 0.09 0.00 0.00 97.40
22:40:01 น. ทั้งหมด 0.98 0.00 0.35 0.00 0.29 0.00 0.06 0.00 0.00 98.32
22:40:01 น. 0 0.70 0.00 0.33 0.00 0.22 0.00 0.06 0.00 0.00 98.69
22:40:01 น. 1 1.25 0.00 0.36 0.00 0.35 0.00 0.07 0.00 0.00 97.96
22:50:01 น. ทั้งหมด 0.65 0.00 0.34 0.00 0.28 0.00 0.06 0.00 0.00 98.68
22:50:01 น. 0 0.80 0.00 0.34 0.00 0.20 0.00 0.05 0.00 0.00 98.61
22:50:01 น. 1 0.50 0.00 0.34 0.00 0.35 0.00 0.06 0.00 0.00 98.75

มีช่องว่างระหว่าง 8:20 ถึง 9:50 และเฉพาะเวลา 9:50 เท่านั้นที่เราเห็นการโหลด (ไม่ได้ใช้งาน 3%)

สิ่งที่เกี่ยวข้องกับที่นี่ เมื่อวันที่ 4 มกราคม ฉันเปิดใช้งานการซิงโครไนซ์เวลา (timedatectl set-ntp จริง) เนื่องจากมีการชดเชย 15 นาที:

นาฬิการะบบผิดไป -910.996745 วินาที

มันคือ t3a.medium ตัวอย่าง. และฉันเชื่อว่าข้อกำหนดด้านเครดิตนั้นไม่จำกัดอยู่แล้ว อย่างน้อยนั่นคือสิ่งที่ฉันเห็นในวันถัดไป อย่างไรก็ตามยอดเครดิตไม่แตะพื้น

คุณช่วยอธิบายได้ไหม ฉันจะตรวจสอบอะไรได้บ้าง

พูดตามตรง ฉันไม่มั่นใจว่าไม่ได้เกิดจากไซต์หรือส่วนประกอบอย่างใดอย่างหนึ่ง แต่ฉันไม่พบปัญหาดังกล่าว

ยูพีดี ปัญหาอาจเกิดจากหน่วยความจำรั่วในหนึ่งในคอนเทนเนอร์ อย่างน้อยหลังจากทำให้มันทำงาน โนโกกิริ งานในกระบวนการที่แยกจากกัน หน่วยความจำหยุดเติบโต และไม่มีเหตุการณ์ที่คล้ายคลึงกันจนถึงตอนนี้

Tim avatar
gp flag
Tim
อาจไม่ใช่คำตอบในกรณีนี้ แต่ฉันเคยเห็นอินสแตนซ์ของ Windows หยุดทำงานสำหรับ Windows Updates ในอดีต Windows Update บน EC2 บางครั้งอาจค่อนข้างช้า
Score:1
ธง jp

ดูเหมือนว่าอินสแตนซ์ของคุณหยุดชั่วคราว/ถูกระงับเนื่องจากปัญหาบางอย่างกับโฮสต์จริงที่ใช้งานอินสแตนซ์ EC2 ของคุณ โปรดจำไว้ว่า SLA ระดับอินสแตนซ์ EC2 คือ 99.5% คุณอาจต้องการเปิดใช้งานการตรวจสอบสำหรับ ตรวจสอบสถานะสำหรับอินสแตนซ์ของคุณ และ การกู้คืนอัตโนมัติ.

cn flag
จากบันทึก `sysstat` ดูเหมือนว่าถูกหยุดชั่วคราว/ถูกระงับ แต่นั่นเป็นเพราะงาน `sa1` ไม่สามารถเริ่มได้ในช่วงเวลานั้น หากคุณดูที่บันทึก `systemd` ไม่มีการระบุว่าถูกระงับ ฉันได้เพิ่ม [ไฟล์อื่น](https://gist.github.com/x-yuri/e13937c2d32e1a48ce76f756fce395f5#file-timestamps-txt) ในส่วนสำคัญที่คุณสามารถดูการประทับเวลาสำหรับช่วงเวลาที่ควรถูกระงับ สำหรับการตรวจสอบสถานะ เมตริก `StatusCheckFailed*` จะเป็น 0 ตั้งแต่ก่อนเกิดเหตุ...
cn flag
...และในแง่หนึ่ง ความผิดอาจตกอยู่ที่ตัวฉันเอง แต่ในตอนนี้ยังไม่มีผู้เยี่ยมชมมากนัก และไม่น่าจะมีอะไรมาทำลายด้วยวิธีนี้ได้ อย่างน้อยฉันก็ไม่พบปัญหาดังกล่าว ในทางกลับกัน ฉันไม่แน่ใจว่าไม่ได้เกิดจากไซต์หรือส่วนประกอบอย่างใดอย่างหนึ่ง คุณมีเหตุการณ์ดังกล่าวหรือไม่ โดยเฉพาะอย่างยิ่งเหตุการณ์ที่ AWS UI บอกคุณว่าไม่มีอะไรเสียหาย
jp flag
อินสแตนซ์สูญเสียการเชื่อมต่อเครือข่ายในเวลาประมาณ 20:30 น. (เป็น NetworkOut แบบแบนบนกราฟ) จากนั้นปัญหาบนโฮสต์อาจถูกตรวจพบโดยอัตโนมัติ และอินสแตนซ์ถูกระงับและย้ายไปยังโฮสต์ทางกายภาพอื่นระหว่าง 21:12 ถึง 21:31 (เมื่อเวลากระโดด ตรวจพบ)
cn flag
โปรดทราบว่าการจราจร [ไม่เคยไปถึง](https://i.imgur.com/Dm797xi.png) เป็นศูนย์ แต่ (อย่างน้อย) ฉันไม่แน่ใจว่ามันวัดอะไรกันแน่ จึงฟังดูเป็นไปได้ นอกจากนี้ยังอธิบายการข้ามเวลาไปข้างหน้า นั่นเป็นคำอธิบายที่ดีที่สุดจนถึงตอนนี้ :) แม้ว่าจะไม่ได้อธิบายว่าทำไมการตรวจสอบสถานะจึงไม่มีใครสังเกตเห็น

โพสต์คำตอบ

คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา