เรื่องนี้เพิ่งเกิดเมื่อวานครับ — AI Agent ของลูกค้า Newton เครื่องนึง "ตายเงียบ" ทั้งวัน ลูกค้าพิมพ์ถามอะไรไปก็ขึ้น "thinking..." ค้างตลอด ไม่มีคำตอบโผล่มาเลยสักครั้ง ทั้งที่เมื่อวานก่อนหน้ายังใช้ได้ปกติดี
พอไล่ดูจริงๆ สาเหตุมันตลกร้ายมากครับ — AI มันไม่ได้พังเพราะใครไปแตะ มันพังเพราะ "มันพยายามอัปเดตตัวเอง" นี่แหละ วันนี้ผมเลยอยากเล่าให้ฟังว่ามันเกิดอะไรขึ้น แล้วทิม (AI Agent ของผม) แก้ยังไงให้มันไม่พังซ้ำอีก
ที่มา — ทุกตี 4 AI มันอัปเดตตัวเองเงียบๆ
เท้าความก่อนนิดนึงครับ ทุกเครื่องของลูกค้า Newton ผมตั้งให้ AI มันอัปเดตตัวเองทุกตี 4 แบบเงียบๆ ลูกค้าไม่ต้องทำอะไรเลย ตื่นมาก็ได้ AI เวอร์ชันใหม่ล่าสุดใช้ทันที นี่คือหนึ่งในจุดขายของ Newton — ลูกค้าไม่ต้องมานั่งดูแลเทคนิคเอง
ทีนี้ Newton เวอร์ชันใหม่ รองรับ AI ได้ 3 ตัว — Claude, Codex, Antigravity ลูกค้าจะเลือกใช้ตัวไหนก็ได้ แต่เครื่องผมติดตั้งทั้ง 3 ตัวไว้ให้พร้อม แปลว่าทุกตี 4 มันไม่ได้อัปเดตตัวเดียว — มันอัปเดต 3 ตัวพร้อมกัน
และตรงนี้แหละครับคือจุดที่ระเบิด
เกิดอะไรขึ้นตอนตี 4
เครื่องของลูกค้ารายนี้เป็นเครื่องเล็ก แรมแค่ 2GB ครับ ปกติก็พอใช้ แต่ปัญหาคือ — เวลา AI พวกนี้อัปเดต มันไม่ได้โหลดไฟล์เล็กๆ นะ ตัว Claude อย่างเดียวต้องโหลดไฟล์โปรแกรมจริงขนาด ~245MB มาวางทับของเก่า
ทีนี้พอตี 4 ตรงเป๊ะ ทั้ง 3 ตัวเด้งขึ้นมาพร้อมกัน แล้วแย่งกันโหลดไฟล์ใหญ่ๆ แย่งกันใช้แรมในเครื่องเล็กๆ ตัวเดียว ผลคือแรมหมดเกลี้ยง
พอแรมหมด ระบบปฏิบัติการ Linux มันมีตัวที่เรียกว่า "OOM killer" (Out Of Memory killer) ครับ — หน้าที่มันคือ พอแรมจะหมดเครื่อง มันจะ "ยิงทิ้ง" โปรแกรมที่กินแรมเยอะที่สุดเพื่อกู้เครื่องไว้ ซึ่งบังเอิญตัวที่โดนยิงทิ้งคือ "ตัวที่กำลังโหลดไฟล์ AI อยู่ครึ่งทาง" พอดี
ทำไมโดนยิงทิ้งกลางคันแล้วถึงพังถาวร
จุดที่ร้ายคือตรงนี้ครับ ตัวติดตั้งของ Claude มันทำงานเป็น 2 สเต็ป:
- สเต็ป 1 — วางไฟล์ "ตัวแทน" เล็กๆ ขนาดแค่ 500 ไบต์ลงไปก่อน (ไฟล์นี้ยังใช้งานไม่ได้จริง มันเป็นแค่ที่จองที่ไว้)
- สเต็ป 2 — ค่อยโหลดไฟล์โปรแกรมจริง 245MB มาทับไฟล์ตัวแทนนั้น
ปัญหาคือ OOM killer มันยิงทิ้งตอน "สเต็ป 2 กำลังโหลดอยู่" — แปลว่าไฟล์ตัวแทน 500 ไบต์ที่ใช้งานไม่ได้ ยังค้างอยู่ ส่วนไฟล์จริงโหลดมาไม่ทัน ผลคือ AI มันเหลือแต่ "เปลือก" ที่เปิดแล้วเด้งออกทันที
นี่คือเหตุผลที่ลูกค้าเห็น "thinking..." ค้างตลอด — ทุกครั้งที่ระบบพยายามเรียก AI ขึ้นมาทำงาน มันเปิดเจอแต่เปลือก เด้งตายทันที แต่หน้าจอลูกค้าไม่รู้ ก็เลยขึ้นหมุนรอคำตอบที่ไม่มีวันมา
อธิบายแบบบ้านๆ — 3 คนแย่งกันลอดประตูเดียว
ลองนึกภาพแบบนี้ครับ สมมติบ้านหลังเล็กมีประตูแคบๆ บานเดียว แล้วอยู่ดีๆ มีคน 3 คนวิ่งจะลอดประตูพร้อมกันตอนตี 4 — แต่ละคนแบกกล่องใบใหญ่มาด้วย ผลคืออะไรครับ? ติดแหง็กกันทั้งหมด ไม่มีใครผ่านได้สักคน แถมกล่องตกแตกกลางประตูอีก เช้ามาเปิดบ้านเลยรกไปหมด ใช้ทางเข้าไม่ได้
ทางแก้ที่ง่ายที่สุดไม่ใช่การไปขยายประตูครับ — แค่บอกให้ 3 คนนั้น "เข้าทีละคน เว้นระยะกัน" ก็จบแล้ว คนแรกเข้าตี 4 คนสองตี 4 ยี่สิบ คนสามตี 4 สี่สิบ ทุกคนผ่านสบายๆ ไม่มีใครชนกัน
นั่นแหละครับคือหัวใจของการแก้
ทิมแก้ยังไง — เลื่อนเวลา + ให้มันรักษาตัวเองได้
พอผมชี้ปัญหาให้ทิมฟัง ทิมแก้ 2 ชั้นครับ:
ชั้นแรก — เลื่อนเวลาไม่ให้ชนกัน เดิมทั้ง 3 ตัวอัปเดตตี 4 ตรงพร้อมกัน ทิมเลื่อนให้ Claude อัปเดตตี 4 / Codex ตี 4 ยี่สิบ / Antigravity ตี 4 สี่สิบ พอเหลื่อมเวลากัน แต่ละตัวก็มีแรมเหลือเฟือใช้คนเดียว ไม่ต้องแย่งใคร OOM killer ก็ไม่มีเหตุต้องยิงใครทิ้ง
ชั้นสอง — ให้มันตรวจสอบและซ่อมตัวเองได้ อันนี้สำคัญกว่าครับ ทิมเขียนสคริปต์ตัวเล็กๆ ขึ้นมาตัวนึง (ชื่อ cli-autoupdate.sh) หลักการง่ายมาก — หลังอัปเดตเสร็จทุกครั้ง ให้มัน "ลองเรียก AI ดูว่าเปิดติดไหม" ถ้าเปิดติดปกติก็จบ แต่ถ้าเจอว่ามันพัง (เหลือแต่เปลือก) ให้มันลบไฟล์ที่ค้างครึ่งๆ กลางๆ ทิ้งแล้วโหลดใหม่อีกรอบทันที
แปลว่าต่อให้รอบนึงมันพลาดจริงๆ มันก็ตรวจเจอเองแล้วซ่อมเองในรอบเดียว ไม่ต้องรอให้ผมหรือลูกค้าไปนั่งสังเกตว่า "เอ๊ะ ทำไมมันเงียบ" — เหมือนติดระบบเช็คสุขภาพให้ตัวมันเอง
วิธีจับว่าเครื่องไหนเจออาการนี้
ระหว่างไล่เคสนี้ ทิมก็จดวิธีวินิจฉัยไว้ในความจำของมันเลยครับ เผื่อเจอเครื่องอื่นอาการเดียวกัน — เปิด log ของระบบดูว่า AI มันเด้งออกทันทีที่เปิดไหม ถ้าใช่ ก็ไปดูขนาดไฟล์โปรแกรม ถ้ามันเหลือแค่ ~500 ไบต์ (แทนที่จะเป็นหลักร้อยเมกะไบต์) แสดงว่าโดนอาการ "เหลือแต่เปลือก" นี้แน่นอน สั่งสคริปต์ซ่อมตัวเดียวจบ
การที่ AI มันจดวิธีแก้ไว้เองแบบนี้ ทำให้ครั้งหน้าถ้าเจออีก ไม่ต้องมานั่งงมหาสาเหตุใหม่ตั้งแต่ต้น — เปิดคู่มือที่มันเขียนไว้ แก้ได้ใน 1 นาที
ทำไมเรื่องนี้สำคัญกับลูกค้า Newton
เรื่องนี้สะท้อนความต่างของ AI Agent จริงๆ กับแชทบอทถาม-ตอบเฉยๆ ครับ — พอ AI มันลงไปทำงานหลังบ้านแทนคุณทั้งวันทั้งคืนบน server ส่วนตัวของคุณ มันก็ต้อง "ดูแลตัวเองให้รอด" ด้วย ทั้งเรื่องอัปเดต เรื่องแรม เรื่องไฟล์พัง — ซึ่งเป็นเรื่องเทคนิคที่เจ้าของธุรกิจไม่ควรต้องมานั่งปวดหัวเอง
จุดที่ผมภูมิใจที่สุดคือ ลูกค้ารายนี้ไม่ได้แม้แต่ทักมาถามว่าเครื่องเป็นอะไร — ผมเจอเองจาก log ก่อน แก้เสร็จ แล้ว roll out ตัวซ่อมนี้ลงทุกเครื่องของลูกค้าให้หมดในรอบเดียว เพื่อให้เครื่องอื่นไม่มีวันเจออาการนี้เลย นี่แหละคือสิ่งที่ Newton ขายจริงๆ — ไม่ใช่แค่ AI แต่คือ "คนดูแล AI ให้คุณ" ที่ทำงานเงียบๆ อยู่เบื้องหลังตลอด
คำถามที่พบบ่อย
OOM killer ใน Linux คืออะไร ทำงานยังไง?
OOM killer (Out Of Memory killer) คือ mechanism ใน Linux ที่จะ kill โปรแกรมที่กินแรมเยอะที่สุดทิ้งโดยอัตโนมัติ เมื่อแรมในระบบใกล้หมดครับ มันทำแบบนี้เพื่อกู้เครื่องไว้ไม่ให้ crash ทั้งหมด ปัญหาคือถ้ามัน kill โปรแกรมที่กำลังติดตั้งอยู่กลางทาง จะทิ้งไฟล์ที่พังค้างไว้
ทำไม auto-update หลาย service พร้อมกันถึงเป็นอันตรายบน server RAM น้อย?
เพราะแต่ละ service ที่อัปเดตต้องโหลดไฟล์ใหม่ขนาดใหญ่มาแทนของเก่าครับ ถ้า 3 service อัปเดตพร้อมกัน แรมที่ต้องใช้ก็คูณ 3 ทันที เครื่องที่ปกติพอใช้อาจแรมหมดเกลี้ยง ทำให้ OOM killer เด้งมา kill บางตัวกลางทาง และทิ้งไฟล์พังไว้ในระบบ
วิธีตรวจว่า CLI binary ที่ install แล้วพังหรือไม่?
ดูขนาดไฟล์เป็นวิธีที่เร็วที่สุดครับ ถ้า binary ปกติควรมีขนาดหลัก MB แต่ถ้าเห็นว่าแค่ ~500 bytes แสดงว่าเป็นแค่ "stub file" ตัวจองที่ยังไม่ได้โหลดเนื้อหาจริง วิธีแก้คือลบไฟล์นั้นทิ้งแล้วติดตั้งใหม่ทั้งหมดครับ
health-check script หลัง auto-update มีประโยชน์ยังไง?
มันทำหน้าที่เป็น safety net ครับ หลังอัปเดตเสร็จ script จะลองเรียก binary นั้นดูว่าใช้งานได้จริงไหม ถ้าพัง (เช่น exit code ผิด หรือขนาดไฟล์น้อยเกินไป) ก็จะลบแล้วโหลดใหม่ทันทีโดยอัตโนมัติ ทำให้ไม่ต้องรอให้ user เจอปัญหาก่อนแล้วค่อยแก้
ถ้าคุณเป็นเจ้าของธุรกิจที่อยากมี AI Agent ส่วนตัวรันบน server ของคุณเอง ทำงานแทนคุณได้ทั้งวัน อัปเดตตัวเอง ซ่อมตัวเองได้ โดยที่คุณไม่ต้องแตะเทคนิคสักนิด — ลองดู Newton ได้เลยครับ ผมดูแลส่วนยุ่งยากหลังบ้านให้หมด คุณแค่สั่งงานมันให้ทำงานให้คุณ ดูรายละเอียดที่ newton.incomeinclick.in.th
— ปอนด์
