มีหลายเหตุผลที่ memory leak อาจเกิดขึ้นบน Ubuntu แต่โชคดีที่มันชัดเจนเมื่อเกิดขึ้น โค้ดที่มีบั๊กมักเป็นสาเหตุหลัก เนื่องจากโปรแกรมเมอร์อาจไม่ได้ตรวจสอบให้แน่ใจว่าหน่วยความจำที่ไม่จำเป็นแล้วถูกปล่อยคืน หากคุณติดตั้ง unstable packages หรือคอมไพล์โค้ดจาก source เอง คุณอาจเจอ memory leaks เพราะเหตุนี้ คุณอาจเริ่มสังเกตเห็นเพราะแอปพลิเคชันบ่นว่า out of memory ขณะที่คุณมี RAM ติดตั้งมากพอ
หากคุณกังวลเกี่ยวกับ memory leak ลองพิมพ์ free ซ้ำๆ ในเทอร์มินัล หากคุณเห็นการใช้งาน RAM เพิ่มขึ้นอย่างรวดเร็ว คุณได้ตรวจพบ memory leak แล้ว หากคุณได้ข้อผิดพลาด bash: Not enough Memory ขณะที่เปิดแค่เทอร์มินัลหรือ virtual console คุณเกือบแน่นอนว่ากำลังเผชิญกับ memory leak บาง leak อาจลี้ลับกว่า แต่ Ubuntu และ spin-offs ต่างๆ มีเครื่องมือและแพ็กเกจช่วยตรวจจับได้
การตรวจจับ Memory Leaks ใน Ubuntu
เนื่องจากเครื่องมือตรวจจับ memory leak ส่วนใหญ่ทำงานบน CLI prompt จึงไม่สำคัญว่าคุณใช้ Ubuntu รุ่นไหน ควรทำงานได้ใน Unity terminal, virtual console ของ Ubuntu Server, lxterm ของ Lubuntu, Konsole ของ Kubuntu หรือ Xfce ใน Xubuntu ลองทำงานง่ายๆ เช่น sudo -s พิมพ์รหัสผ่านเพื่อเริ่มต้น
ควรได้ root shell หากทำถูกต้อง แต่อาจก่อให้เกิด memory error หาก leak รุนแรงเกินไป หากคุณเข้าถึง root shell ได้ ให้ลองพิมพ์ echo 3 > /proc/sys/vm/drop_caches กด Enter แล้วพิมพ์ exit ลองรัน free หรือ free -m อีกครั้งดูว่าช่วยปล่อยหน่วยความจำได้หรือไม่
บางโปรแกรมเมอร์โต้แย้งว่าไม่มีประโยชน์ที่จะบังคับ Kernel drop caches เพราะควรถูก flush และ reclaim อัตโนมัติเมื่อต้องการ physical memory เพิ่ม อย่างไรก็ตาม การ force flush จะทำให้ประสิทธิภาพระบบลดลง จำไว้ว่านี่เพียงแค่การทดสอบ หลังจาก reboot ระบบ Linux Kernel จะสร้าง memory caches ใหม่เหมือนเดิม
บางคนเสนอให้เพิ่มบรรทัด sync; sudo echo 3 > /proc/sys/vm/drop_caches ลงในสคริปต์ที่ cron รันเป็นประจำ แต่นี่ทำลายวัตถุประสงค์ของ memory caching เอง หน่วยความจำว่างก็คือ RAM ที่ไม่ได้ใช้ หมายถึงข้อมูลต้องโหลดจากอุปกรณ์จัดเก็บ electromechanical หรือ NAND ที่ช้ากว่า ไม่ว่าจะเร็วแค่ไหน ก็ไม่เร็วเท่า RAM ดังนั้น คุณควรแก้ memory leaks แต่ไม่ควรยุ่งกับระบบ cache หลังตั้งค่า optimal แล้ว
หากคุณตัดสินใจว่ามี memory leak ต่อเนื่องที่เกิดเป็นระยะขณะใช้เครื่อง และไม่สามารถระบุสาเหตุเฉพาะได้ แต่ยังมี CLI access ให้ลองรันคำสั่ง top ควรให้รายการกระบวนการที่ทำงานอยู่
หาก Ubuntu ให้ข้อผิดพลาดแปลกๆ เกี่ยวกับ top ให้ลอง busybox top แทนเพื่อเข้าถึงเวอร์ชันง่ายกว่า เมื่อได้รายการ ให้ดูคอลัมน์ %MEM หรือคล้ายๆ เพื่อดูว่าแอปพลิเคชันไหนถูกจัดสรรหน่วยความจำมากที่สุด แม้คุณจะบันทึก PID และสั่ง kill ไปที่ PID นั้น มันจะเพียงบังคับปิดแอปพลิเคชัน หน่วยความจำที่ใช้อาจยังไม่ถูกปล่อยคืนหลังจากนั้น แม้จะลองทำก็คุ้มค่า
หากคุณพบแอปพลิเคชันที่ใช้หน่วยความจำมาก กด q เพื่อออกจาก top แล้วลอง kill #### ด้วยหมายเลข PID จากหน้าจอก่อนหน้า กระบวนการระบบไม่ควรถูก kill แบบนี้ และไม่ควร kill อะไรที่คุณมีงาน未บันทึก คิดว่านี่คล้ายกับการ kill ผ่าน Ctrl+Alt+Del task list ซึ่งก็ใช้สำหรับกระบวนการเดียวกันได้
เมื่อคุณพบโปรแกรมที่มีปัญหานี้ซ้ำๆ คุณสามารถกำหนดค่าเพื่อป้องกันพฤติกรรมนี้ในอนาคต แต่ละโปรแกรมจะต้องมีวิธีแก้ไขต่างกัน ซึ่งเกินขอบเขตของการตรวจจับ memory leaks เพียงอย่างเดียว
หากคุณไม่ได้แค่ troubleshoot แอปพลิเคชัน แต่ทำงานกับโค้ดจริงๆ มีทางเลือกอื่นอีก Ubuntu และ derivative ต่างๆ นำเสนอ C routines ชื่อ membarrier, memusage และ memusagestat สำหรับการเขียนโปรแกรม
ใช้ man membarrier, man memusage หรือ man memusagestat เพื่อดู manual pages ของ Linux Programmer's Manual สำหรับ routines สำคัญเหล่านี้ หากมีการอัปเกรดในเวอร์ชันไลบรารีในอนาคตเมื่อ Ubuntu รุ่นใหม่ออก การเปลี่ยนแปลงจะถูกระบุที่นี่เสมอ
หากคุณต้องการเนื้อหาแบบกราฟิก memusagestat มีตัวเลือกบันทึกการแสดงกราฟิกของการใช้หน่วยความจำเป็นไฟล์ PNG ทำให้เป็นคุณสมบัติที่น่าสนใจสำหรับผู้เขียน utilities ด้วย เนื่องจากสามารถใช้สร้างแอปพลิเคชันที่ตรวจสอบ memory leaks เป็นประจำ
คุณอาจต้องการติดตั้ง memprof ซึ่งเป็นเครื่องมือสำหรับ profiling การใช้หน่วยความจำเพื่อช่วยหา memory leaks มันสร้างโปรไฟล์เกี่ยวกับปริมาณหน่วยความจำที่แต่ละฟังก์ชันในโปรแกรมที่คุณเขียนจัดสรร มันยังสามารถสแกนหน่วยความจำที่มีอยู่เพื่อหาบล็อกที่จัดสรรแล้วแต่ไม่มีการอ้างอิงจริงอีกต่อไป มันทำได้โดยการ pre-load ไลบรารีเพื่อ override คุณสมบัติการจัดสรรหน่วยความจำของ C library มาตรฐาน
หากคุณวางแผนใช้ ตรวจสอบให้แน่ใจว่าลบบรรทัด include memprof ออกจากจุดเริ่มต้นของโค้ดก่อนเผยแพร่ ใช้เพื่อให้แน่ใจว่าไม่มี leaks แต่ไม่ควรกลายเป็น dependency หากคุณแพ็กเกจโค้ดและเผยแพร่ใน repository
ABOUT THE AUTHOR
Kevin Arrows
Kevin Arrows เป็นผู้เชี่ยวชาญด้านเทคโนโลยีที่มีประสบการณ์มากกว่าหนึ่งทศวรรษ เขาถือใบรับรอง Microsoft Certified Technology Specialist (MCTS) และมีความหลงใหลในการติดตามข่าวสารเทคโนโลยีล่าสุด Kevin เขียนบทความมากมายเกี่ยวกับหัวข้อเทคโนโลยีหลากหลาย แสดงให้เห็นถึงความเชี่ยวชาญในด้านการพัฒนาซอฟต์แวร์ ความปลอดภัยไซเบอร์ และการคอมพิวติ้งบนคลาวด์ ผลงานของเขาได้รับการยอมรับและเคารพจากเพื่อนร่วมงาน และเขาได้รับการขนานนามว่าสามารถอธิบายแนวคิดทางเทคนิคที่ซับซ้อนได้อย่างชัดเจนและกระชับ
