Linux Cgroups v2 Performance Tuning เพิ่มความเร็ว — คู่มือฉบับสมบูรณ์ 2026 | SiamCafe Blog

Linux Cgroups v2 คืออะไร และทำไมการปรับแต่งจึงสำคัญกับประสิทธิภาพเซิร์ฟเวอร์

Linux Cgroups v2 (Control Groups เวอร์ชันสอง) คือกลไกระดับเคอร์เนลที่ใช้จัดสรรและจำกัดทรัพยากรของระบบ เช่น หน่วยประมวลผล หน่วยความจำ ดิสก์ และแบนด์วิดท์เครือข่าย ให้กับกระบวนการหรือกลุ่มกระบวนการแต่ละชุด

ในปี 2026 แทบทุกสแตกเทคโนโลยีสมัยใหม่ ไม่ว่าจะเป็น Docker, Kubernetes, systemd หรือระบบคอนเทนเนอร์อื่น ๆ ล้วนวางรากฐานอยู่บน cgroups v2 ทั้งสิ้น การเข้าใจและปรับแต่งมันให้ถูกวิธีจึงเป็นทักษะที่แยกคนทำระบบธรรมดาออกจากคนที่ทำระบบได้ระดับโปรดักชันจริง เพราะเมื่อเซิร์ฟเวอร์เครื่องเดียวต้องรับภาระหลากหลายงานพร้อมกัน กลไกนี้คือเส้นแบ่งเขตแดนที่ทำให้แต่ละงานอยู่ร่วมกันได้อย่างสงบสุขโดยไม่แย่งทรัพยากรกันจนพังทลาย

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

ความต่างสำคัญระหว่าง v2 กับ v1 คือ v2 ใช้โมเดลลำดับชั้นเดียว (unified hierarchy) ทำให้การจัดการทรัพยากรทุกชนิดอยู่ภายใต้โครงสร้างเดียวกัน ลดความซ้ำซ้อน และมีคอนเซ็ปต์ใหม่อย่าง No Internal Process Constraint ที่บังคับว่ากระบวนการอยู่ได้เฉพาะโหนดปลายสุดของต้นไม้ลำดับชั้นเท่านั้น ทำให้การคำนวณการจัดสรรทรัพยากรแม่นยำและคาดเดาได้มากขึ้น อีกทั้งรองรับ Pressure Stall Information ที่ช่วยให้เราวัดความแรงกดดันของทรัพยากรได้แบบเรียลไทม์ ซึ่งเป็นเครื่องมือวินิจฉัยที่ทรงพลังกว่าการดูเปอร์เซ็นต์การใช้งานแบบเดิม เพราะเปอร์เซ็นต์การใช้งานบอกเราว่าทรัพยากรถูกใช้เท่าไร แต่ไม่ได้บอกว่ามีกระบวนการใดต้องหยุดรอทรัพยากรนานแค่ไหน ซึ่งตัวหลังต่างหากที่คือสาเหตุของอาการช้าจริง

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

ระบบปฏิบัติการรุ่นใหม่อย่าง Ubuntu 22.04 ขึ้นไป และ Rocky Linux 9 ขึ้นไป เปิดใช้งาน cgroups v2 เป็นค่าเริ่มต้นแล้ว ผ่าน systemd

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

stat -fc %T /sys/fs/cgroup/ systemd-cgls systemd-cgtop

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

โครงสร้างของ cgroups v2 อยู่ที่ไดเรกทอรี /sys/fs/cgroup/ โดยแต่ละกลุ่มจะเป็นโฟลเดอร์ที่มีไฟล์ควบคุมหลายตัว ไฟล์ที่ใช้บ่อยที่สุดในการปรับแต่งประสิทธิภาพมีดังนี้

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

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

sudo mkdir /sys/fs/cgroup/myapp echo "+cpu +memory" | sudo tee /sys/fs/cgroup/cgroup.subtree_control echo "1500000 1000000" | sudo tee /sys/fs/cgroup/myapp/cpu.max echo 2G | sudo tee /sys/fs/cgroup/myapp/memory.max echo $$ | sudo tee /sys/fs/cgroup/myapp/cgroup.procs

ขั้นตอนที่คนมักลืมคือบรรทัด cgroup.subtree_control ต้องเปิดคอนโทรลเลอร์ที่จะใช้ก่อนเสมอ ไม่อย่างนั้นไฟล์ cpu.max หรือ memory.max จะไม่ปรากฏในกลุ่มลูกที่สร้างใหม่ อีกจุดที่ควรสังเกตคือเมื่อคุณเขียนหมายเลขกระบวนการของเชลล์ปัจจุบันลงใน cgroup.procs คำสั่งทุกอย่างที่รันหลังจากนั้นจะอยู่ภายใต้ข้อจำกัดของกลุ่มนั้นทันที ซึ่งเป็นวิธีที่สะดวกในการทดสอบว่าข้อจำกัดที่ตั้งไว้มีผลจริงหรือไม่ ลองรันสคริปต์ที่กินหน่วยความจำจนเกินเพดานแล้วดูว่าเกิดอะไรขึ้น จะเข้าใจพฤติกรรมของเคอร์เนลได้ลึกกว่าการอ่านเอกสารร้อยหน้า

เทคนิคปรับแต่งซีพียูและหน่วยความจำให้ได้ประสิทธิภาพสูงสุด

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

สำหรับซีพียู พารามิเตอร์ที่สำคัญที่สุดคือ cpu.max ซึ่งรับค่าสองตัวคือโควตาและช่วงเวลา ตัวอย่างเช่น "500000 100000" หมายความว่ากลุ่มนี้ใช้ซีพียูได้ 5 คอร์ (500000 ไมโครวินาที ต่อทุก ๆ 100000 ไมโครวินาที) การตั้งค่านี้ช่วยป้องกันปัญหาหนึ่งกระบวนการกินซีพียูทั้งเครื่อง แต่ก็มีข้อควรระวัง ถ้าค่าโควตาต่ำเกินไปจะเกิดอาการหน่วงจังหวะ ทำให้แอปพลิเคชันช้าลงแบบไม่มีเหตุผลชัดเจน เราตรวจสอบได้จากไฟล์ cpu.stat โดยดูค่า nrthrottled และ throttledusec ถ้าค่าสูงขึ้นเรื่อย ๆ แปลว่าตั้งโควตาต่ำเกินจำเป็น

ประเด็นที่ละเอียดอ่อนกว่านั้นคือช่วงเวลาใน cpu.max ค่าเริ่มต้น 100000 ไมโครวินาทีหรือหนึ่งร้อยมิลลิวินาที หมายความว่าเคอร์เนลจะบังคับโควตาเป็นช่วง ๆ ทุกร้อยมิลลิวินาที สำหรับงานที่วัดเวลาตอบสนองระดับมิลลิวินาทีอย่างบอทเทรด การถูกหยุดพักกึ่งหนึ่งรอบโควตาอาจสร้างอาการกระตุกที่สังเกตได้ วิธีบรรเทาคือยืดช่วงเวลาให้ยาวขึ้น เช่น ตั้งเป็น "1000000 1000000" เพื่อให้ได้คอร์เฉลี่ยหนึ่งตัวแต่บังคับเป็นรอบวินาทีละครั้ง การกระจายเวลาจะราบรื่นขึ้น แม้จะแลกมาด้วยความละเอียดของการบังคับที่ลดลงก็ตาม ผมใช้เทคนิคนี้กับกระบวนการที่รับข้อมูลราคาแบบเรียลไทม์และได้ผลดีมาก

นอกจาก cpu.max แล้ว cpu.weight ก็เป็นเครื่องมือที่ทรงพลังแต่ถูกใช้น้อยเกินไป มันไม่ได้จำกัดเพดาน แต่กำหนดสัดส่วนที่แต่ละกลุ่มจะได้รับเมื่อทรัพยากรมีไม่พอ กลุ่มที่ไม่ใช้งานหนักจะยกโควตาที่ไม่ได้ใช้ให้กลุ่มอื่นโดยอัตโนมัติ ทำให้การใช้ทรัพยากรโดยรวมมีประสิทธิภาพกว่าการจำกัดแบบแข็งทุกกลุ่ม กฎข้อหนึ่งที่ผมยึดคือจำกัดแบบแข็งไว้เฉพาะกับงานที่เราไม่ไว้ใจพฤติกรรม ส่วนงานที่เขียนเองและวัดพฤติกรรมได้ ใช้น้ำหนักควบคุมก็เพียงพอและยืดหยุ่นกว่ามาก

ด้านหน่วยความจำ ผมเคยเจอกรณีบอทเทรดถูกสังหารกลางวันสำคัญเพราะตั้ง memory.max ต่ำเกินไปโดยไม่มีเพดานอ่อน ตั้งแต่นั้นมาผมจะตั้งทั้งคู่เสมอ และเฝ้าดูค่า memory.events เพื่อนับจำนวนครั้งที่เกิดการสังหารกระบวนการ ถ้าค่า oom_kill ในไฟล์นี้เพิ่มขึ้นแม้แต่ครั้งเดียวก็ถือว่าเป็นเหตุการณ์สำคัญที่ต้องสืบสวนทันที ไม่ใช่เรื่องที่ปล่อยผ่านได้ เพราะการถูกสังหารกลางคันอาจทำให้ข้อมูลเสียหายหรือสถานะของโปรแกรมผิดพลาดโดยที่ไม่มีใครรู้ตัว

นอกจากนี้ควรใช้ Pressure Stall Information ผ่านไฟล์ memory.pressure และ cpu.pressure เพื่อดูว่ากระบวนการต้องหยุดรอทรัพยากรนานแค่ไหน ถ้าค่า full หรือ some ในหน่วยไมโครวินาทีสูงผิดปกติ แสดงว่ากลุ่มนั้นกำลังขาดแคลนทรัพยากรจริง ๆ แม้เปอร์เซ็นต์การใช้งานโดยรวมจะยังไม่เต็มก็ตาม เครื่องมือนี้ให้ข้อมูลที่ตรงประเด็นกว่าการดูยอดใช้งานเฉย ๆ มาก เพราะมันวัดสิ่งที่เกิดขึ้นกับประสบการณ์ของแอปพลิเคชันโดยตรง คืออาการหยุดรอ ซึ่งเป็นสาเหตุที่ผู้ใช้รู้สึกว่าระบบช้า ไม่ใช่ตัวเลขเปอร์เซ็นต์ที่แดชบอร์ดแสดง

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

การปรับแต่งผ่าน systemd วิธีที่ยั่งยืนที่สุดสำหรับงานโปรดักชัน

แม้เราจะแก้ไฟล์ใน /sys/fs/cgroup/ ได้โดยตรง แต่การตั้งค่าจะหายไปหลังรีบูต และการจัดการด้วยมือบนเครื่องที่รันบริการหลายสิบตัวแทบเป็นไปไม่ได้ ทางออกที่ดีที่สุดคือใช้ systemd ซึ่งรวมความสามารถของ cgroups v2 เข้ากับระบบบริการอย่างเนียนตา ข้อดีของการปรับแต่งผ่าน systemd ไม่ได้มีแค่ความคงอยู่หลังรีบูตเท่านั้น แต่ยังรวมถึงการบันทึกประวัติการเปลี่ยนแปลง การควบคุมสิทธิ์ผ่านคำสั่งเดียว และการที่ค่าทั้งหมดถูกเก็บในไฟล์ที่อ่านเข้าใจง่าย ซึ่งสามารถเก็บในระบบควบคุมเวอร์ชันและทำซ้ำได้บนเซิร์ฟเวอร์เครื่องอื่นทันที นี่คือหลักการโครงสร้างพื้นฐานในรูปแบบรหัสที่ทุกทีมจริงจังควรปฏิบัติ

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

[Unit] Description=My Trading Dashboard API After=network.target

[Service] Type=simple ExecStart=/opt/myapp/bin/server CPUQuota=300% CPUWeight=800 MemoryMax=4G MemoryHigh=3600M TasksMax=512 IOWriteMax=/dev/sda 50M Restart=on-failure

[Install] WantedBy=multi-user.target

สังเกตว่าคุณสมบัติของ systemd เป็นภาษามนุษย์มากกว่า คำสั่ง CPUQuota=300% แปลเป็น cpu.max ของ cgroups โดยอัตโนมัติ คำสั่ง MemoryHigh=3600M คือเพดานอ่อน และ MemoryMax=4G คือกำแพงแข็ง ส่วน TasksMax แปลเป็น pids.max การตั้งค่า TasksMax มีความสำคัญมากกว่าที่คิด เพราะกระบวนการที่มีข้อผิดพลาดแบบสร้างเธรดไม่รู้จบสามารถพังทั้งเครื่องได้ถ้าไม่จำกัดจำนวนกระบวนการไว้ ผมเคยเห็นเครื่องทั้งเครื่องค้างเพราะสคริปต์หลุดลูปแล้วแตกกระบวนการจนหมดตารางกระบวนการของระบบ ทำให้แม้แต่คำสั่งฆ่ากระบวนการก็รันไม่ได้

หลังแก้ไฟล์ให้รัน sudo systemctl daemon-reload และ sudo systemctl restart myapp เรายังสามารถปรับค่าทรัพยากรแบบสด ๆ โดยไม่ต้องรีสตาร์ตบริการผ่านคำสั่ง systemctl set-property เช่น sudo systemctl set-property myapp.service MemoryMax=6G ซึ่งเหมาะกับการจูนในช่วงเวลาเร่งด่วน เช่น ตอนมีข่าวสำคัญทางเศรษฐกิจที่ทำให้ทราฟฟิกพุ่ง หรือตอนรันงานประมว

คำถามที่พบบ่อย

จะตรวจสอบได้อย่างไรว่าระบบ Linux ของฉันรองรับและเปิดใช้งาน cgroups v2 แล้ว?

วิธีที่ง่ายที่สุดคือรันคำสั่ง `stat -fc %T /sys/fs/cgroup/` ในเทอร์มินัล หากผลลัพธ์ออกมาเป็น `cgroup2fs` แปลว่าระบบของคุณพร้อมใช้งาน cgroups v2 เรียบร้อยแล้ว ระบบปฏิบัติการรุ่นใหม่อย่าง Ubuntu 22.04 ขึ้นไป และ Rocky Linux 9 ขึ้นไป เปิดใช้งาน cgroups v2 เป็นค่าเริ่มต้นผ่าน systemd ซึ่งทำหน้าที่จัดการลำดับชั้นของกลุ่มทรัพยากรให้อัตโนมัติ นอกจากนี้คุณยังสามารถใช้คำสั่ง `systemd-cgls` เพื่อดูลำดับชั้นของกลุ่มทรัพยากรทั้งหมดในรูปแบบต้นไม้ และ `systemd-cgtop` ที่แสดงการใช้ทรัพยากรแบบเรียลไทม์ของแต่ละกลุ่ม เรียงลำดับจากตัวที่กินทรัพยากรมากที่สุด ซึ่งเป็นเครื่องมือที่มีประโยชน์มากสำหรับการจับตัวการที่กินทรัพยากรจนกระทบกระบวนการอื่นได้ภายในไม่กี่วินาที

ความแตกต่างระหว่าง memory.max กับ memory.high คืออะไร และควรตั้งค่าอย่างไร?

ไฟล์ `memory.max` คือกำแพงแข็ง เมื่อกระบวนการใช้หน่วยความจำเกินค่าที่กำหนด เคอร์เนลจะสังหารกระบวนการทันทีด้วยกลไก OOM (Out of Memory) ที่ปลดปล่อยหน่วยความจำอัตโนมัติ ส่วน `memory.high` คือเพดานอ่อน เมื่อการใช้งานเกินค่านี้ เคอร์เนลจะบีบให้กระบวนการลดการใช้งานผ่านการคืนหน้าข้อมูลลงพื้นที่สลับ (swap) และการลดแคช ทำให้ระบบช้าลงแต่กระบวนการยังทำงานต่อได้โดยไม่ถูกฆ่าทิ้ง แนวทางการออกแบบที่ดีคือตั้งเพดานอ่อน (memory.high) ไว้ต่ำกว่ากำแพงแข็ง (memory.max) ประมาณสิบถึงสิบห้าเปอร์เซ็นต์ เพื่อให้ระบบมีเวลาค่อย ๆ ลดแรงกดดันหน่วยความจำก่อนที่จะถึงจุดที่ต้องสังหารกระบวนการจริง ๆ ซึ่งช่วยป้องกันการหยุดทำงานโดยไม่คาดคิดในสภาพแวดล้อมโปรดักชัน

cgroups v2 ต่างจาก v1 อย่างไร และทำไม v2 จึงดีกว่าสำหรับการปรับแต่งประสิทธิภาพ?

ความต่างสำคัญที่สุดคือ cgroups v2 ใช้โมเดลลำดับชั้นเดียว (unified hierarchy) ทำให้การจัดการทรัพยากรทุกชนิด ไม่ว่าจะเป็นซีพียู หน่วยความจำ ดิสก์ หรือเครือข่าย อยู่ภายใต้โครงสร้างเดียวกัน ลดความซ้ำซ้อนเมื่อเทียบกับ v1 ที่ต้องจัดการแต่ละทรัพยากรแยกกัน อีกทั้ง v2 มีคอนเซ็ปต์ใหม่อย่าง No Internal Process Constraint ที่บังคับให้กระบวนการอยู่ได้เฉพาะโหนดปลายสุดของต้นไม้ลำดับชั้นเท่านั้น ทำให้การคำนวณการจัดสรรทรัพยากรแม่นยำและคาดเดาได้มากขึ้น ที่สำคัญคือ v2 รองรับ Pressure Stall Information (PSI) ที่ช่วยวัดความแรงกดดันของทรัพยากรแบบเรียลไทม์ ซึ่งทรงพลังกว่าการดูเปอร์เซ็นต์การใช้งานแบบเดิม เพราะเปอร์เซ็นต์บอกเพียงว่าทรัพยากรถูกใช้เท่าไร แต่ PSI บอกได้ว่ามีกระบวนการใดต้องหยุดรอทรัพยากรนานแค่ไหน ซึ่งเป็นสาเหตุที่แท้จริงของอาการช้า

การใช้ cgroups v2 ช่วยแก้ปัญหาการแย่งทรัพยากรระหว่างงานหลายอย่างบนเซิร์ฟเวอร์เครื่องเดียวได้อย่างไร?

เมื่อเซิร์ฟเวอร์เครื่องเดียวต้องรับภาระหลายงานพร้อมกัน เช่น บอทเทรด เว็บเซิร์ฟเวอร์ และงานประมวลผลข้อมูลหนัก ๆ ปัญหาที่พบบ่อยคือกระบวนการหนึ่งกินท

แนะนำเพิ่มเติม

🎯 เปิดบัญชี XM Forex → สมัคร

📱 แอป iCafeFX → ดาวน์โหลด

📊 สัญญาณฟรี → รับสัญญาณ

📚 คู่มือเทรด → SiamCafeBook

🤝 สมัคร Partner XM → pipaffiliates.com/c?c=72816&l=th&p=6