บทนำ

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

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

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

บริบท

ก่อนที่เราจะดำดิ่งสู่การซ่อมแซมหน่วยความจำรั่ว เราต้องการบริบทบางอย่างเกี่ยวกับโครงสร้างพื้นฐานของ Elli และจุดที่หน่วยความจำรั่วเกิดขึ้นตั้งแต่แรก

เหนือสิ่งอื่นใด Elli เป็นผู้ดำเนินการจุดชาร์จ เรามีหน้าที่รับผิดชอบในการเชื่อมต่อสถานีชาร์จ (CSs) กับแบ็กเอนด์ของเราและควบคุมผ่านโปรโตคอลOCPP เอาล่ะ ลูกค้าของเราสามารถชาร์จ EV ได้ที่สถานีส่วนตัวหรือสถานีสาธารณะ CSs เชื่อมต่อกับระบบของเราผ่านทาง WebSockets เรารองรับการเชื่อมต่อผ่าน TLS หรือTLS ร่วมกัน (mTLS) ระหว่าง TLS CS จะตรวจสอบใบรับรองเซิร์ฟเวอร์ของเราและรับรองว่าเชื่อมต่อกับแบ็กเอนด์ของ Elli ด้วย mTLS เรายังยืนยันว่า CS มีใบรับรองไคลเอ็นต์ที่ออกโดยเรา

ในด้านการเชื่อมต่อ เซิร์ฟเวอร์ที่เขียนด้วย Node.js มีหน้าที่ดูแลล อจิก การอัปเกรดจาก HTTP เป็น WebSockets และรักษาสถานะของการเชื่อมต่อ มีการปรับใช้ในคลัสเตอร์ Kubernetes และจัดการโดยHorizontal Pod Autoscaler (HPA) ตามหลักการแล้ว HPA จะติดตามปริมาณการรับส่งข้อมูลและปรับขนาดพ็อดขึ้นหรือลงตามนั้น

เรารักษาการเชื่อมต่อ TCP ถาวรและยาวนานหลายหมื่นรายการจากสถานีชาร์จไปพร้อม ๆกัน สิ่งนี้ทำให้เกิดความซับซ้อนและแตกต่างอย่างมากจากบริการ RESTful ทั่วไป เมตริกพร็อกซีที่ติดตามโหลดคือการใช้หน่วยความจำ เนื่องจากสะท้อนถึงจำนวนของการเชื่อมต่อที่สร้างขึ้น และตรรกะของแอปพลิเคชันไม่ต้องการการคำนวณมากมาย พ็อดของเรามีอายุยืนยาว และการปรับขนาดผ่านหน่วยความจำทำให้เราสังเกตเห็นว่าจำนวนพ็อดเพิ่มขึ้นอย่างช้าๆ สำหรับจำนวนการเชื่อมต่อที่คงที่ เรื่องสั้นสั้นๆ เราพบการรั่วไหลของหน่วยความจำ

การประเมินผลกระทบ

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

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

เมื่อพ็อดไม่สามารถรองรับทราฟฟิกเพิ่มเติมได้ ต้องขอบคุณโพรบความพร้อมของ Kubernetes พ็อดจะหยุดรับทราฟฟิกเพิ่มเติมแต่ยังคงให้บริการการเชื่อมต่อที่สร้างไว้ พ็อดที่ให้บริการการเชื่อมต่อแบบ X อาจจบลงด้วยความสามารถเพียงเล็กน้อยเท่านั้นเนื่องจากการรั่วไหล โดยไม่ทำให้เกิดการหยุดชะงักในฝั่งลูกค้า ซึ่งหมายความว่าเราสามารถดูดซับแรงกระแทกได้อย่างง่ายดายเพียงแค่หมุนพ็อดให้มากขึ้น

การสืบสวน

ตอนนี้สำหรับการเจาะลึกทางเทคนิคที่แท้จริงในการรั่วไหลของหน่วยความจำ

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

ไพรเมอร์อย่างรวดเร็วสำหรับหน่วยความจำ JS

ตัวแปรใน JavaScript (และภาษาโปรแกรมอื่นๆ ส่วนใหญ่) จะถูกจัดเก็บไว้ในสองที่: สแต็กและฮีป สแต็กมักจะเป็นพื้นที่ต่อเนื่องของหน่วยความจำที่จัดสรรบริบทในเครื่องสำหรับแต่ละฟังก์ชันที่เรียกใช้งาน กองเป็นขอบเขตที่ใหญ่กว่ามากในการจัดเก็บทุกอย่างที่จัดสรรแบบไดนามิก การแยกนี้มีประโยชน์ในการทำให้การดำเนินการปลอดภัยยิ่งขึ้นจากความเสียหาย (สแต็กได้รับการปกป้องมากกว่า) และรวดเร็วกว่า (ไม่จำเป็นต้องมีการรวบรวมขยะแบบไดนามิกของเฟรมสแต็ก การจัดสรรเฟรมใหม่อย่างรวดเร็ว)

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

แหล่งที่มา:https://glebbahmutov.com/blog/javascript-stack-size/

ถ่ายภาพกองจากพ็อดการผลิต | กองสแนปชอตและการทำโปรไฟล์

ความคาดหวัง

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

ผลลัพธ์

การรับฮีปดัมพ์จากพ็อดที่ใช้ไป 90% ส่งผลให้ช่วง 100MB แต่ละพ็อดขอ RAM ประมาณ 1.5GB และฮีปน้อยกว่า 10% ของหน่วยความจำที่จัดสรร มันดูน่าสงสัย…

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

วัตถุ TLSSocket ตรงกับสถานะของแอปพลิเคชัน ย้อนกลับไปที่การสังเกตครั้งแรก heapdump เป็นลำดับความสำคัญน้อยกว่าการใช้หน่วยความจำ เราคิดว่า: " นี่ไม่ถูกต้อง เรากำลังดูผิดที่ เราต้องถอยออกมาหนึ่งก้าว”

นอกจากนี้ เรายังจัดทำโปรไฟล์แอปพลิเคชันผ่านCloud Profilerที่นำเสนอโดย GCP เราสนใจที่จะดูว่าออบเจกต์ถูกจัดสรรอย่างไรเมื่อเวลาผ่านไปและอาจระบุการรั่วไหลของหน่วยความจำได้

การได้รับฮีปดัมพ์จะบล็อกเธรดหลักและอาจทำให้แอปพลิเคชันหยุดทำงาน ตรงกันข้ามกับสิ่งนี้ ตัวสร้างโปรไฟล์สามารถเก็บไว้ในการผลิตโดยมีค่าใช้จ่ายเพียงเล็กน้อย

Cloud Profiler เป็นเครื่องมือสร้างโปรไฟล์แบบต่อเนื่องที่ออกแบบมาสำหรับแอปพลิเคชันที่ทำงานบน Google Cloud เป็นเครื่องสร้างโปรไฟล์ทางสถิติหรือการสุ่มตัวอย่างที่มีค่าใช้จ่ายต่ำและเหมาะสำหรับสภาพแวดล้อมการผลิต

แม้ว่าผู้จัดทำโปรไฟล์ช่วยให้เราเข้าใจผู้เช่ากองนี้ แต่ก็ยังไม่ได้ให้เบาะแสแก่เราในการสอบสวน ตรงกันข้ามกลับผลักไสเราให้ไปไม่ถูกทาง

การแจ้งเตือนสปอยเลอร์: อย่างไรก็ตามผู้สร้างโปรไฟล์ได้ให้ข้อมูลที่มีค่าแก่เราในระหว่างเหตุการณ์ที่เกิดขึ้นในการผลิตซึ่งเราระบุและแก้ไขการรั่วไหลของหน่วยความจำที่รุนแรง แต่นั่นเป็นเพียงเรื่องราวสำหรับเวลาอื่น

สถิติการใช้หน่วยความจำ

เราต้องการข้อมูลเชิงลึกที่มากขึ้นเกี่ยวกับการใช้หน่วยความจำ เราสร้างแดชบอร์ดสำหรับเมตริกทั้งหมดที่process.memoryUsage()มีให้

heapTotal และheapUsedหมายถึงการใช้หน่วยความจำของV8

ภายนอกหมายถึงการใช้หน่วยความจำของวัตถุ C++ ที่เชื่อมโยงกับวัตถุ JavaScript ที่จัดการโดยV8

rss หรือ Resident Set Sizeคือจำนวนพื้นที่ว่างในอุปกรณ์หน่วยความจำหลัก (นั่นคือ เซ็ตย่อยของหน่วยความจำที่จัดสรรทั้งหมด) สำหรับกระบวนการ รวมถึงอ็อบเจ็กต์และโค้ด C++ และ JavaScript ทั้งหมด

arrayBuffers หมายถึงหน่วยความจำที่จัดสรรให้กับArrayBuffersและSharedArrayBuffersรวมถึง Node.js Buffersทั้งหมด ซึ่งรวมอยู่ในมูลค่าภายนอกด้วย เมื่อใช้ Node.js เป็นไลบรารีแบบฝัง ค่านี้อาจเป็น 0 เนื่องจากการจัดสรรสำหรับArrayBuffersอาจไม่ถูกติดตามในกรณีนั้น

ดังที่เราเห็นก่อนหน้านี้ เราได้รับสแน็ปช็อตฮีปประมาณ 100MB จากคอนเทนเนอร์ที่มีการใช้หน่วยความจำมากกว่า 1 GB หน่วยความจำที่เหลือถูกจัดสรรไว้ที่ไหน? มาดูกัน

เรารู้อะไรบ้างจนถึงตอนนี้? RSS กำลังเติบโตฮีปและภายนอกมีเสถียรภาพซึ่งนำเราไปสู่สแต็ค นี่อาจหมายถึงเมธอดที่ถูกเรียกใช้และไม่เคยออก ซึ่งนำไปสู่การโอเวอร์โฟลว์ของสแต็ก อย่างไรก็ตาม สแต็กต้องไม่เกินร้อย MB ณ จุดนี้ เราได้ทดสอบในสภาพแวดล้อมที่ไม่ได้ใช้งานจริงกับสถานีหลายพันแห่งแล้ว แต่ไม่ได้รับผลลัพธ์ใดๆ

ตัวจัดสรรหน่วยความจำ

ในขณะที่ระดมสมอง เราถือว่าหน่วยความจำมีการกระจายตัว: หน่วยความจำบางส่วนได้รับการจัดสรรแบบไม่ต่อเนื่อง ซึ่งนำไปสู่หน่วยความจำขนาดเล็กที่ไม่สามารถใช้สำหรับการจัดสรรใหม่ได้ ในกรณีของเรา แอปพลิเคชันทำงานเป็นเวลานานและมีการจัดสรรและให้อิสระมากมาย การกระจายตัวของหน่วยความจำเป็นข้อกังวลที่ถูกต้องในกรณีเหล่านี้ Google อย่างกว้างขวางนำเราไปสู่ ปัญหาของ GitHub ซึ่งผู้คนประสบกับสถานการณ์เดียวกันกับเรา มีการสังเกตรูปแบบเดียวกันของหน่วยความจำรั่ว และสอดคล้องกับสมมติฐานของเรา

เราตัดสินใจที่จะใส่ตัวจัดสรรหน่วยความ จำอื่นเพื่อทดสอบ และเราเปลี่ยนจากmuslเป็นjemalloc เราไม่พบผลลัพธ์ที่มีความหมาย ณ จุดนี้ เรารู้ว่าเราต้องหยุดพัก เราต้องคิดแนวทางใหม่ทั้งหมด

เป็นไปได้ไหมที่การรั่วไหลจะปรากฏบนการเชื่อมต่อ mTLS เท่านั้น

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

เราไม่ได้คำนึงถึงว่าสถานีของเราสามารถเชื่อมต่อผ่าน TLS หรือ mTLS การทดสอบครั้งแรกของเรารวมสถานี TLS แต่ไม่ใช่ mTLS และเหตุผลนั้นง่ายมาก: เราไม่สามารถสร้างสถานี mTLS และใบรับรองไคลเอ็นต์ที่เกี่ยวข้องได้อย่างง่ายดาย เหตุการณ์ล่าสุดกระตุ้นให้เราลดรัศมีการระเบิดให้เหลือน้อยที่สุดและแบ่งความรับผิดชอบของแอปพลิเคชันเพื่อให้การปรับใช้แต่ละครั้งจัดการการรับส่งข้อมูล TLS และ mTLS แยกกัน ยูเรก้า! หน่วยความจำรั่วจะปรากฏในพ็อด mTLS ของเราเท่านั้น ในขณะที่ TLS หน่วยความจำจะเสถียร

เราจะไปจากที่นี่ที่ไหน?

เราตัดสินใจว่ามีสองทางเลือก: (1) ไปยังผู้ต้องสงสัยคนต่อไปของเรา — ไลบรารีที่จัดการงานโครงสร้างพื้นฐานคีย์สาธารณะทั้งหมด ตลอดจนการเรียกซ้ำที่เป็นไปได้ในเส้นทางรหัสนั้น (2) หรืออยู่กับมันจนกว่าเราจะทำงานใหม่ บริการของเราโดยสิ้นเชิง

ในระหว่างการตรวจสอบการรั่วไหลของหน่วยความจำ เราได้แจ้งหัวข้อที่คาดไม่ถึงมากมายซึ่งเกี่ยวข้องกับบริการที่ได้รับผลกระทบ เมื่อคำนึงถึงการรั่ว ไหลของหน่วยความจำและทุกอย่างที่เราค้นพบเราจึงตัดสินใจปรับปรุงแนวบริการของเราและแบ่งความรับผิดชอบของบริการ โฟลว์การตรวจสอบสิทธิ์และการให้สิทธิ์ของ CS จะถูกมอบหมายให้กับบริการใหม่ และเราจะใช้เครื่องมือที่เหมาะสมสำหรับจัดการงาน PKI

สรุป

การปรับปรุงการปรับขนาดของเราเผยให้เห็นว่าเรามีหน่วยความจำรั่วซึ่งอาจไม่มีใครสังเกตเห็นในช่วงระยะเวลาหนึ่ง การจัดลำดับความสำคัญของลูกค้าและการประเมินผลกระทบของการรั่วไหลเป็นอันดับแรกและสำคัญที่สุด จากนั้นเราก็สามารถกำหนดขั้นตอนการสอบสวนของเราได้เนื่องจากเราตระหนักว่าไม่มีผลกระทบต่อลูกค้า เราเริ่มต้นด้วยจุดที่มองเห็นได้ชัดเจนที่สุดเมื่อวินิจฉัยการรั่วไหลของหน่วยความจำ ซึ่งก็คือฮีป อย่างไรก็ตามการวิเคราะห์กองแสดงให้เราเห็นว่าเรากำลังดูผิดที่ ต้องการเงื่อนงำเพิ่มเติมและกระบวนการ API ของV8ทำให้เราได้รับสิ่งนั้นอย่างแน่นอน ในผลลัพธ์แรกที่เราได้รับ หน่วยความจำรั่วปรากฏใน RSS ในที่สุด จากการวิเคราะห์ข้อมูลทั้งหมดที่รวบรวมได้ เราสงสัยว่าหน่วยความจำมีการแตกกระจาย

การเปลี่ยนตัวจัดสรรหน่วยความจำไม่ได้ทำให้สถานการณ์ดีขึ้น แต่การเปลี่ยนแนวทางของเราและแบ่งปริมาณงานระหว่าง TLS และ mTLS ช่วยให้เราจำกัดเส้นทางโค้ดที่ได้รับผลกระทบให้แคบลง

ผลลัพธ์สุดท้ายของการสอบสวนของเราคืออะไร?

แผนของเราในการปรับปรุงความสามารถในการขยายขนาดควบคู่ไปกับการจัดการกับการรั่วไหลของหน่วยความจำ ทำให้เราตัดสินใจแยกบริการและเขียนบริการใหม่เพื่อดูแลโฟลว์การเชื่อมต่อ CS โดยแยกจากข้อมูลเฉพาะของ CS อื่นๆ

เราได้แก้ไขหน่วยความจำรั่วหรือไม่?

เวลาจะบอก แต่ฉันจะบอกว่าการสอบสวนมีมากกว่านั้น ประสบการณ์ในการตรวจสอบการรั่วไหลช่วยให้เราเติบโตในฐานะนักพัฒนาและบริการของเราเพื่อใช้สถาปัตยกรรมที่ยืดหยุ่นและปรับขนาดได้มากขึ้น

ประเด็นสำคัญและการเรียนรู้

• แม้ว่าความท้าทายด้านวิศวกรรมจะนำผู้คนมารวมกัน เราเล่นปิงปองกับวิศวกรนอกทีมของเรา
• ทำให้เรามีแรงจูงใจที่จะคิดใหม่เกี่ยวกับบริการ ซึ่งนำไปสู่สถาปัตยกรรมที่ปรับขนาดได้มากขึ้น
• ถ้ามันปวด มันต้องให้ความสนใจของคุณ อย่าเพิกเฉย

• https://nodejs.org/en/docs/guides/diagnostics/memory/using-heap-snapshot/
• เปิดใช้งานการดีบักระยะไกลไปยังพ็อดผ่านการส่งต่อพอร์ต:https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/
• https://developers.google.com/cast/docs/debugging/remote_debugger

หากคุณสนใจที่จะค้นหาข้อมูลเพิ่มเติมเกี่ยวกับวิธีการทำงานของเรา โปรดสมัครสมาชิกบล็อก Elli Mediumและเยี่ยมชมเว็บไซต์ของบริษัทของเราที่elli.eco ! เจอกันคราวหน้า!

เกี่ยวกับผู้เขียน

Thanos Amoutziasเป็นวิศวกรซอฟต์แวร์ เขาพัฒนาระบบการจัดการสถานีชาร์จของ Elli และขับเคลื่อนหัวข้อ SRE เขามีความกระตือรือร้นในการสร้างบริการที่เชื่อถือได้และนำเสนอผลิตภัณฑ์ที่มีประสิทธิภาพ คุณสามารถค้นหาเขาได้บน LinkedInและใน ️

เครดิต: ขอบคุณเพื่อนร่วมงานทุกคนที่ตรวจสอบและให้ข้อเสนอแนะเกี่ยวกับบทความ!