วิธีเช็ก CPU steal time บน VPS และปัญหา Noisy Neighbour

สิ่งที่ CPU steal time วัดผลจริง

CPU steal time คือสัดส่วนเวลาที่ virtual CPU ของคุณพร้อมทำงานและไม่มีสิ่งใดต้องรอ แต่ hypervisor กลับจัดสรร physical core ไปให้ guest รายอื่นใช้งานแทน งานของคุณจึงถูกนำไปเข้าคิวไว้และ core ไปทำงานอื่นอยู่ Linux จะนับรอบการทำงานเหล่านั้นแยกออกมาและรายงานเป็น st ซึ่งเป็นวิธีที่คุณใช้แยกแยะระหว่าง "เซิร์ฟเวอร์ของฉันกำลังยุ่ง" กับ "เซิร์ฟเวอร์ของฉันกำลังรอคิว" ออกจากกัน

ความแตกต่างนี้คือเหตุผลทั้งหมดที่มีตัวนับนี้อยู่ เวลาที่ process ของคุณใช้บน CPU จะถูกรายงานเป็น us (user) หรือ sy (system) ส่วนเวลาที่งานถูกบล็อกจากการรอ storage จะถูกรายงานเป็น wa (I/O wait) สำหรับ vCPU (virtual CPU) ที่พร้อมทำงานและอยู่ใน run queue โดยไม่มี I/O ค้างอยู่ แต่ยังไม่สามารถประมวลผลได้ จะถูกรายงานเป็น st ไม่มีสิ่งใดภายในเซิร์ฟเวอร์ของคุณที่สามารถแก้ไขสถานะนี้ได้ เพราะการตัดสินใจจัดตารางเวลาเกิดขึ้นในเลเยอร์ที่ต่ำกว่าคุณ ซึ่งก็คือบน host

เรื่องนี้เป็นผลโดยตรงจาก วิธีการที่ VPS แชร์เครื่อง physical เดียวกัน ระหว่าง guest หลายราย สาเหตุทั่วไปคือเพื่อนบ้าน: guest รายอื่นบน node เดียวกันกำลังทำงานหนัก host จึงต้องแบ่ง core ระหว่างคุณกับเขา แต่ยังมีสาเหตุที่สองที่มักถูกมองข้าม ผู้ให้บริการหลายรายจำกัดการใช้งาน vCPU แบบแชร์ไว้เพียงเศษเสี้ยวของ physical core และบน hypervisor หลายตัว การจำกัดนี้จะถูกนับเป็น steal ภายใน guest ดังนั้นค่า st ที่สูงจึงบอกคุณได้ว่า core ไม่ถูกจัดสรรให้คุณ แต่มันไม่ได้บอกเสมอไปว่าใครเป็นผู้แย่งไปใช้งาน

ที่มาของค่า steal

Kernel ของคุณไม่สามารถวัดค่า steal ได้ด้วยตัวเอง เพราะมันไม่สามารถมองเห็นสถานะของ host ได้ ตัว hypervisor จะเป็นผู้แจ้งค่านี้ให้ทราบ บน KVM ตัว host จะเขียนค่า counter ของแต่ละ vCPU ลงในหน้าหน่วยความจำที่แชร์ไว้กับ guest และ guest จะทำการรวมค่าดังกล่าวหาก kernel ถูกคอมไพล์ด้วย CONFIG_PARAVIRT_TIME_ACCOUNTING ซึ่ง kernel ของทุก distribution ล้วนเปิดใช้งานค่านี้ ส่วน Xen จะรายงานข้อมูลเดียวกันผ่านพื้นที่ runstate ของตน ค่าผลรวมทั้งหมดจะถูกส่งไปยัง userspace ผ่านจุดเดียวเท่านั้น:

head -1 /proc/stat

บรรทัด cpu นั้นประกอบด้วย counter 10 ค่า โดยนับเป็นหน่วย USER_HZ ticks นับตั้งแต่เริ่มบูตเครื่อง ตามลำดับดังนี้: user, nice, system, idle, iowait, irq, softirq, steal, guest, guest_nice ค่า steal คือค่าลำดับที่แปดถัดจาก label เครื่องมือทุกตัวที่ระบุไว้ด้านล่าง ได้แก่ vmstat, top, mpstat และ Prometheus exporter ใดๆ ต่างก็อ่านค่าจาก field เดียวกันนี้แล้วนำตัวอย่างข้อมูลสองชุดมาคำนวณเป็นเปอร์เซ็นต์

ผลลัพธ์ประการหนึ่งมีความสำคัญมากกว่าข้ออื่น หาก hypervisor ไม่ส่งค่า counter ออกมา field ดังกล่าวจะคงค่าเป็นศูนย์ตลอดไป และเครื่องมือทุกตัวที่อ้างอิงค่านี้จะรายงานว่า 0.0 ปกติดี ทั้งที่ในความเป็นจริง host กำลังทำงานหนักเกินขีดจำกัด ทั้ง KVM และ Xen จะส่งค่านี้ออกมา แต่ guest ที่รันบน VMware และ Hyper-V มักจะรายงานค่าเป็นศูนย์เสมอ โปรดตรวจสอบแพลตฟอร์มก่อนที่คุณจะเชื่อถือค่าศูนย์:

systemd-detect-virt

คำสั่งนี้จะแสดงชื่อแพลตฟอร์ม เช่น kvm, xen, vmware หรือ microsoft และแสดง none หากเป็น bare metal ภายใน container คำสั่งจะรายงาน runtime แทน เช่น lxc, docker หรือ podman ซึ่งจะบอกข้อมูลเกี่ยวกับ container ไม่ใช่เครื่องที่รันอยู่เบื้องหลัง บน kvm ค่าศูนย์ถือเป็นหลักฐานที่แท้จริงว่า host กำลังจัดสรรทรัพยากรให้คุณอย่างเหมาะสม แต่บนแพลตฟอร์มที่ไม่เคยเติมค่าลงใน field นี้ ค่าศูนย์ไม่ใช่หลักฐานใดๆ ทั้งสิ้น และคุณต้องประเมินการแย่งชิงทรัพยากร (contention) ด้วยการจับเวลาการทำงานจริงแทน

ฉันจะตรวจสอบ CPU steal time บน VPS ได้อย่างไร

vmstat มาจากแพ็กเกจ procps เครื่องมือนี้มีอยู่บนอิมเมจ VPS ของ Ubuntu และ Debian เกือบทุกตัว แต่อาจไม่มีในอิมเมจคอนเทนเนอร์แบบ minimal บางตัว ดังนั้นให้ติดตั้งก่อนใช้งาน

sudo apt-get update
sudo apt-get install -y procps
vmstat --version
vmstat 1 5

vmstat --version จะแสดงผลลัพธ์หนึ่งบรรทัด เช่น vmstat from procps-ng 4.0.4 หากคำสั่งนี้ทำงานได้ แสดงว่าเครื่องมือถูกติดตั้งไว้แล้วและคุณกำลังอ่านค่าจาก kernel โดยตรง จากนั้น vmstat 1 5 จะทำการสุ่มตัวอย่างวินาทีละหนึ่งครั้ง รวมทั้งหมดห้าครั้ง

procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
 1  0      0 3216484  98304 1284360    0    0     4    18   62  110  3  1 96  0  0  0
 2  0      0 3216232  98304 1284360    0    0     0     0  248  431  6  2 84  0  8  0

ให้มองหาคอลัมน์ st ในบล็อก cpu ทางด้านขวา สำหรับ procps-ng เวอร์ชันปัจจุบันจะมีการพิมพ์คอลัมน์ gu เพิ่มเข้ามาสำหรับ KVM guest time ดังนั้น st จึงกลายเป็นคอลัมน์ที่สองจากขวาแทนที่จะเป็นคอลัมน์สุดท้าย ให้สังเกตที่ชื่อหัวคอลัมน์เป็นหลักเนื่องจากตำแหน่งอาจเปลี่ยนแปลงไปในแต่ละเวอร์ชัน

มีสองนิสัยที่จะช่วยให้การอ่านค่ามีความแม่นยำ บรรทัดข้อมูลแรกคือค่าเฉลี่ยตั้งแต่เริ่มเปิดเครื่อง (boot) ดังนั้นให้ข้ามบรรทัดแรกไปและอ่านบรรทัดถัดจากนั้น และการสุ่มตัวอย่างเพียงครั้งเดียวไม่ใช่การวัดผลที่แท้จริง เนื่องจาก steal time มักเกิดขึ้นเป็นช่วงๆ ให้รัน vmstat 1 60 และเฝ้าสังเกตเป็นเวลาเต็มหนึ่งนาทีก่อนที่จะสรุปผล

top จะรายงานตัวเลขเดียวกันในบรรทัดสรุป %Cpu(s) ในช่องที่ระบุว่า st:

%Cpu(s):  6.2 us,  2.1 sy,  0.0 ni, 83.9 id,  0.0 wa,  0.0 hi,  0.3 si,  7.5 st

หากต้องการรายละเอียดแยกตามคอร์ ให้เพิ่ม sysstat:

sudo apt-get install -y sysstat
mpstat -P ALL 1 5

mpstat จะแสดงผลลัพธ์หนึ่งแถวต่อหนึ่ง CPU พร้อมคอลัมน์ %steal ซึ่งจะแสดงให้เห็นว่า vCPU ทุกตัวได้รับผลกระทบหรือมีเพียงตัวเดียว สำหรับข้อมูลที่จำเป็นในการเปิด support ticket ให้บันทึกตัวอย่างข้อมูลเก็บไว้แทนการอ่านจากหน้าจอเพียงอย่างเดียว:

date -u | tee -a ~/steal.log
mpstat -P ALL 1 5 | tee -a ~/steal.log

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

ตัวเลข steal หมายถึงอะไร

• ค่า 0.0 ที่คงที่ สถานะปกติ หรือแพลตฟอร์มไม่ได้รายงานค่า steal ออกมา ให้ตรวจสอบด้วย systemd-detect-virt ก่อนที่จะสรุปว่าระบบปกติ
• ค่าที่พุ่งสูงขึ้นเล็กน้อยเป็นเวลาไม่กี่วินาที เป็นเรื่องปกติบนโหนดที่ใช้งานร่วมกัน (shared node) อาจเกิดจากการที่เพื่อนบ้านเริ่มงาน build หรือโฮสต์กำลังรันการสำรองข้อมูล
• ค่าที่คงที่ระหว่าง 1 ถึง 5 เปอร์เซ็นต์บนแผนการใช้งานแบบ shared เป็นเรื่องที่คาดการณ์ได้ ราคาที่จ่ายสะท้อนถึงการใช้ CPU ร่วมกับผู้อื่น
• ค่าที่คงที่ระหว่าง 5 ถึง 10 เปอร์เซ็นต์ คุณจะเริ่มวัดผลความล่าช้าได้ ให้เริ่มบันทึกข้อมูลหลักฐานและเปรียบเทียบในช่วงเวลาเดียวกันของแต่ละวัน
• สูงกว่า 10 เปอร์เซ็นต์ติดต่อกันหลายชั่วโมง โหนดมีการใช้งานเกินขีดจำกัดสำหรับภาระงานของคุณ ระดับนี้เป็นเหตุผลที่เพียงพอสำหรับการเปิด support ticket หรือย้ายโฮสต์

ให้ถือว่าช่วงตัวเลขเหล่านี้เป็นแนวทางในการอ่านค่ามากกว่าจะเป็นข้อกำหนดตายตัว เนื่องจากไม่มีผู้ให้บริการรายใดรับประกันค่า steal บนแผนการใช้งานแบบ shared ให้พิจารณาค่าเหล่านี้เทียบกับสิ่งที่คุณรันอยู่ งานประมวลผลแบบ batch ในช่วงกลางคืนอาจรับค่า steal ได้ถึง 15 เปอร์เซ็นต์โดยไม่มีใครสังเกตเห็น แต่สำหรับบริการที่ไวต่อความหน่วง (latency-sensitive) ค่านี้จะปรากฏในค่า p99 ก่อนที่ค่าเฉลี่ยจะดูน่ากังวล ซึ่งเป็นเหตุผลว่าทำไม ภาระงานที่ไวต่อความหน่วง เช่น บอทเทรด จึงควรใช้ dedicated cores

Steal time ส่งผลกระทบต่อคุณอย่างไร?

การคำนวณนั้นสั้นและง่าย หาก CPU ของคุณถูกดึงไปใช้เป็นสัดส่วน s งานที่ต้องใช้ CPU ในปริมาณคงที่จะใช้เวลาบนนาฬิกาจริงนานขึ้นเป็น 1 / (1 - s) เท่า สำหรับงานที่ต้องใช้ CPU 60 วินาที:

[
  {
    "steal_percent": 0,
    "wall_clock_seconds": "60.0"
  },
  {
    "steal_percent": 3,
    "wall_clock_seconds": "61.9"
  },
  {
    "steal_percent": 8,
    "wall_clock_seconds": "65.2"
  },
  {
    "steal_percent": 15,
    "wall_clock_seconds": "70.6"
  },
  {
    "steal_percent": 25,
    "wall_clock_seconds": "80.0"
  },
  {
    "steal_percent": 40,
    "wall_clock_seconds": "100.0"
  }
]

ที่ระดับ 3 เปอร์เซ็นต์ ซึ่งเป็นค่าปกติของแผนการใช้งานแบบ shared งานนั้นจะใช้เวลา 61.9 วินาที แทนที่จะเป็น 60.0 วินาที ซึ่งไม่มีใครเปิด ticket แจ้งปัญหาจากเรื่องนี้ ที่ระดับ 8 เปอร์เซ็นต์ เวลาจะเพิ่มเป็น 65.2 วินาที และที่ระดับ 40 เปอร์เซ็นต์ งานเดียวกันต้องใช้เวลาถึง 100.0 วินาที ส่งผลให้คิวงานที่เคยระบายออกได้ทันเริ่มสะสมตัวมากขึ้นแทน

ค่าเหล่านี้เป็นค่าที่คำนวณขึ้น ไม่ใช่ค่าที่วัดได้จริง แบบจำลองนี้ตั้งสมมติฐานว่ามี thread ที่พร้อมทำงานเพียง thread เดียวและ steal time กระจายตัวอย่างสม่ำเสมอตลอดช่วงเวลา ในความเป็นจริง บริการต่างๆ มักจะรู้สึกแย่กว่าที่กราฟแสดง เพราะช่วงเวลาที่ถูก steal มักจะเกิดขึ้นกลางคันระหว่างการประมวลผลคำขอ ทำให้ทุกสิ่งที่รอคำขอนั้นต้องเสียเวลารอซ้ำอีก เพื่อให้ได้ตัวเลขของคุณเองแทนที่จะใช้สูตรคำนวณ ให้ ทำ benchmark ของ VPS ในช่วงเวลาที่เงียบและช่วงเวลาที่มีการใช้งานหนาแน่น โดยบันทึกค่า st ไว้สำหรับทั้งสองช่วงเวลาดังกล่าว

นี่คือ steal หรือว่าเป็นอย่างอื่นกันแน่?

Steal มักถูกเข้าใจผิดกับอาการอื่นได้ง่าย ให้พิจารณาค่าตัวเลข (counters) เหล่านี้ร่วมกันในบรรทัด vmstat เดียวกัน

• st สูงในขณะที่ r และ us ยังคงต่ำ: โฮสต์ไม่ได้จัดสรรคอร์ให้คุณ นี่คืออาการ steal
• r สูงกว่าจำนวน vCPU ของคุณมาก โดยที่ us สูงและ st ใกล้ศูนย์: คุณกำลังรันงานเกินกว่าที่ CPU ของคุณจะรับไหว ให้เปรียบเทียบ r กับผลลัพธ์ของ nproc นี่คือการใช้งานเกินขีดจำกัด (oversubscription) ของคุณเอง ไม่ใช่ผลกระทบจากเพื่อนบ้าน
• wa สูงในขณะที่ st ใกล้ศูนย์: งานต่างๆ ถูกบล็อกอยู่ที่หน่วยเก็บข้อมูล (storage) ซึ่งเป็นปัญหาที่ต่างออกไปและต้องใช้วิธีแก้ไขที่ต่างกัน
• Load average สูงในขณะที่ st และ us ทั้งคู่ต่ำ: ค่า load ยังนับรวมงานที่ไม่สามารถขัดจังหวะได้ (uninterruptible tasks) ดังนั้นอาการนี้มักชี้ไปที่อุปกรณ์ที่ค้างหรือ network mount ที่ไม่ตอบสนอง มากกว่าจะเป็นปัญหาที่ CPU

แผนบริการแบบ Burstable ควรได้รับการกล่าวถึงเป็นพิเศษ แผนเหล่านี้ให้ยอดเครดิตที่สะสมได้ในขณะที่คุณไม่ได้ใช้งานและจะถูกหักออกเมื่อคุณมีภาระงานสูง เมื่อเครดิตหมดลง ผู้ให้บริการจะจำกัดความเร็วของคุณไว้ที่อัตราพื้นฐาน (baseline rate) ในบางแพลตฟอร์ม การจำกัดความเร็วนี้จะถูกรายงานว่าเป็น steal แต่ในบางแพลตฟอร์มคุณจะไม่เห็นค่านี้จากภายในระบบ และคุณจะได้รับรอบการประมวลผลต่อวินาทีน้อยลงเท่านั้น โปรดอ่านรายละเอียดของแผนบริการก่อนที่จะสรุปว่าปัญหาเกิดจากเพื่อนบ้านที่ใช้ทรัพยากรร่วมกัน

เหตุใดคอนเทนเนอร์จึงรายงานค่า steal time เป็นศูนย์

ค่า steal เป็นคุณสมบัติของเครื่องเสมือน (virtual machine) ไม่ใช่ของคอนเทนเนอร์ที่รันอยู่ภายใน Docker container บน VPS ของคุณใช้ /proc ร่วมกับโฮสต์ ดังนั้นค่า st ที่อ่านได้จากภายในคอนเทนเนอร์จึงเป็นค่า steal ของ VPS ซึ่งเป็นสิ่งที่คุณต้องการทราบ แต่การทำ virtualisation แบบใช้คอนเทนเนอร์ที่ขายเป็นบริการ VPS จะมีพฤติกรรมต่างออกไป เมื่อมีการใช้ lxcfs ค่า /proc/stat ภายในคอนเทนเนอร์จะถูกสังเคราะห์ขึ้นจากการคำนวณของ cgroup ทำให้ค่า steal เป็นศูนย์โดยธรรมชาติ ระบบตรวจสอบ (monitoring stack) ที่ดึงข้อมูลจากภายในเพียงอย่างเดียวจึงอาจแสดงกราฟที่ราบเรียบเป็นศูนย์ ทั้งที่เครื่องฟิสิคัลด้านล่างกำลังขาดแคลนทรัพยากรอย่างหนัก

ภายในคอนเทนเนอร์ ตัวนับที่มีความหมายในลักษณะเดียวกันคือการจำกัดโควตา CPU (CPU quota throttling) สำหรับ cgroup v2:

cat /sys/fs/cgroup/cpu.stat

nr_throttled จะนับรอบการบังคับใช้ที่กลุ่มกระบวนการใช้งาน CPU จนถึงขีดจำกัดโควตา และ throttled_usec จะรวมเวลาทั้งหมดที่กระบวนการถูกระงับการทำงานไว้ ค่า nr_throttled ที่เพิ่มสูงขึ้นหมายความว่ากระบวนการของคุณพร้อมทำงานแต่ไม่ได้รับอนุญาตให้รัน ซึ่งเป็นประสบการณ์เดียวกับค่า steal แต่เกิดจากขีดจำกัดที่คุณกำหนดเอง ให้ตรวจสอบขีดจำกัดของคุณก่อนที่จะโทษโฮสต์ โดยเฉพาะหากคุณ รันบริการใน Docker บน VPS ที่มีการกำหนด CPU limits ไว้ในไฟล์ compose การทำ virtualisation ซ้อนกันจะเพิ่มจุดที่เวลาสูญหายไปอีกหนึ่งแห่ง เนื่องจาก VM ที่อยู่ภายใน VPS ของคุณจะต้องรับภาระทั้งค่า steal ของคุณและค่าความล่าช้าในการจัดตารางเวลาของตัวมันเอง โปรดคำนึงถึงเรื่องนี้หากคุณ รัน nested virtualisation บน VPS

วิธีรับมือกับปัญหา steal ที่เกิดขึ้นอย่างต่อเนื่อง

ไม่มีการตั้งค่าใดภายใน guest ที่จะแก้ไขปัญหา steal ได้ เนื่องจากตัวจัดตารางเวลา (scheduler) ที่ตัดสินใจเรื่องนี้ทำงานอยู่นอก guest การอัปเกรด kernel ก็ไม่ช่วยเช่นกัน: การจัดตารางเวลาที่รับรู้ถึง cache ที่เพิ่มเข้ามาใน Linux kernel 7.2 จะจัดเรียงงานของคุณใหม่บน core ที่คุณได้รับจริงเท่านั้น และไม่สามารถกู้คืนรอบการทำงาน (cycles) ที่เพื่อนบ้านแย่งไปแล้วได้ มีการดำเนินการ 4 อย่างที่ทำได้จริง

รวบรวมหลักฐานก่อน บันทึกเวลาเป็น UTC, ระยะเวลาของแต่ละเหตุการณ์, ความถี่ที่เกิดขึ้นซ้ำ และดูว่า mpstat แสดงให้เห็นว่า vCPU ตัวใดตัวหนึ่งได้รับผลกระทบหรือได้รับผลกระทบทั้งหมด การเก็บตัวอย่าง log ไว้หนึ่งสัปดาห์มีค่ามากกว่าภาพหน้าจอเพียงภาพเดียว

เปิด ticket พร้อมข้อมูลดังกล่าว ถามคำถามโดยตรงสองข้อ: node นี้มีการใช้งานเกินขีดจำกัด (oversubscribed) ในช่วงเวลาเหล่านี้หรือไม่ และสามารถย้าย instance ของฉันได้หรือไม่ ให้แปะผลลัพธ์จาก vmstat และระบุเวลาที่แน่นอน ผู้ให้บริการจะดำเนินการเมื่อมีช่วงเวลาที่พิสูจน์ได้ชัดเจน ส่วน ticket ที่แจ้งเพียงว่าเซิร์ฟเวอร์ช้าจะได้รับคำตอบที่ขอข้อมูลเหล่านี้กลับมา ปริมาณงานที่คุณสามารถส่งต่อให้ผู้ให้บริการได้คือหนึ่งในความแตกต่างเชิงปฏิบัติระหว่าง VPS แบบ managed และ unmanaged

ขอให้ย้าย instance การย้าย guest ไปยัง node ที่มีภาระงานน้อยกว่าเป็นงานปกติของผู้ให้บริการ และมักใช้เวลา reboot เพียงสั้นๆ นี่คือวิธีแก้ไขที่ไม่มีค่าใช้จ่าย และมักจะแก้ปัญหาในกรณีทั่วไปที่ node หนึ่งบังเอิญมีเพื่อนบ้านที่ใช้งานหนักหลายรายพร้อมกัน

จ่ายเงินเพื่อขจัดปัญหาการแย่งชิงทรัพยากร แผนแบบ dedicated vCPU จะสำรอง physical core ไว้สำหรับ instance ของคุณโดยเฉพาะ ทำให้ตัวนับ steal เป็นศูนย์และคงอยู่ที่นั่นตลอดไป แผนนี้มีค่าใช้จ่ายรายเดือนสูงกว่า และเป็นคำตอบที่ตรงไปตรงมาสำหรับภาระงานที่ไม่สามารถยอมรับความแปรปรวนได้ หากวิธีนี้ยังไม่เพียงพอ หรือคุณต้องการแบนด์วิดท์หน่วยความจำไว้ใช้คนเดียว ขั้นตอนถัดไปคือ การใช้ dedicated server แทน VPS

ในระหว่างที่รอการดำเนินการเหล่านี้ ให้ลดผลกระทบจาก steal ลง โดยการรัน worker thread ให้น้อยกว่าจำนวน vCPU ที่คุณมี เนื่องจาก thread ที่ไม่สามารถเข้าถึง core ได้จะเพิ่มเพียงแค่ context switch เท่านั้น ให้ย้ายงานแบบ batch ไปทำในช่วงเวลาที่ node ว่าง ซึ่ง log ของคุณจะบอกได้ว่าช่วงเวลาใด จากนั้นให้วัดผลอีกครั้งด้วยคำสั่งเดิมในช่วงเวลาเดิม เพื่อให้คุณสามารถยืนยันได้ว่าการเปลี่ยนแปลงนั้นได้ผลจริง แทนที่จะใช้วิธีคาดเดา

FAQ

CPU steal time ในระดับปกติสำหรับ VPS คือเท่าใด

ในแผนบริการแบบ shared การที่ค่าพุ่งสูงขึ้นชั่วคราวหรือมีค่าคงที่ต่ำกว่าประมาณ 5 เปอร์เซ็นต์ถือเป็นเรื่องปกติ เนื่องจาก CPU แบบ shared หมายความว่าโฮสต์ต้องแบ่งปัน physical core ให้กับ guest หลายตัว หากค่าพุ่งสูงต่อเนื่องเป็นเลขสองหลักนานหลายชั่วโมงถือว่าไม่ปกติและควรเปิด ticket แจ้งผู้ให้บริการ สำหรับแผนบริการแบบ dedicated vCPU ค่าที่คาดหวังคือ 0.0 ดังนั้นหากพบค่าอื่นถือเป็นความผิดปกติที่ต้องรายงาน ทั้งนี้ควรประเมินตัวเลขดังกล่าวเทียบกับภาระงานของคุณเอง เช่น งาน batch job ที่รันข้ามคืนสามารถรองรับค่า steal ที่สูงได้ ในขณะที่ API ที่ไวต่อความหน่วง (latency-sensitive) ไม่สามารถรองรับได้

การอัปเกรดแผนบริการจะช่วยแก้ปัญหาค่า steal time สูงได้หรือไม่

ไม่เสมอไป การเพิ่มจำนวน vCPU บนโหนด shared เดิมหมายความว่าจะมี virtual CPU จำนวนมากขึ้นที่ต้องแย่งชิง physical core เดิมที่มีอยู่อย่างจำกัด ซึ่งอาจทำให้เปอร์เซ็นต์ของค่า steal ยังคงเท่าเดิม สิ่งที่จะช่วยลดค่า steal ได้คือการจัดสรร dedicated CPU หรือการย้ายไปยังโหนดที่มีภาระงานน้อยกว่า การมีส่วนแบ่งที่ใหญ่ขึ้นบนเครื่องที่งานล้นมือก็ยังคงเป็นเพียงส่วนแบ่งบนเครื่องที่งานล้นมืออยู่ดี

ทำไม VPS ของฉันถึงแสดงค่า steal time เป็น 0 ทั้งที่ทำงานช้าอย่างเห็นได้ชัด

มีสาเหตุทั่วไปอยู่ 2 ประการ ประการแรกคือ hypervisor อาจไม่ได้ส่งค่า counter นี้ออกมา ซึ่งเป็นเรื่องปกติบนแพลตฟอร์ม VMware และ Hyper-V ทำให้ฟิลด์นี้แสดงค่าเป็นศูนย์เสมอไม่ว่าโฮสต์จะทำอะไรก็ตาม ให้รันคำสั่ง systemd-detect-virt เพื่อตรวจสอบว่าคุณใช้งานอยู่บนแพลตฟอร์มใด ประการที่สองคือคอขวดอาจเกิดจากจุดอื่น ให้ตรวจสอบ wa เพื่อดูการรอคอยของ storage เปรียบเทียบ r กับ nproc เพื่อดูภาระงานของคุณเอง และอ่านค่า /sys/fs/cgroup/cpu.stat ภายใน container เพื่อตรวจสอบการจำกัดโควตา (throttling)

ฉันสามารถลดค่า steal time จากภายในเซิร์ฟเวอร์ของฉันเองได้หรือไม่

คุณไม่สามารถเปลี่ยนแปลงการจัดสรรเวลา (scheduling) ของโฮสต์จากภายใน guest ได้ คุณทำได้เพียงลดผลกระทบที่เกิดขึ้นเท่านั้น โดยให้รัน worker thread จำนวนน้อยกว่าจำนวน vCPU ที่คุณมี เพื่อให้งานใน run queue ไม่ต้องรอคอย core ที่ยังไม่ว่างลง ให้ย้ายงานประเภท batch job ไปรันในช่วงเวลาที่โหนดมีภาระงานน้อยกว่า หรือทำ cache ผลลัพธ์เพื่อลดจำนวนคำขอที่ต้องใช้ CPU ส่วนการเปลี่ยนแปลงที่จะช่วยลดค่า steal ได้จริง เช่น การย้ายโหนดหรือการใช้ dedicated core นั้น เป็นสิ่งที่ต้องดำเนินการโดยผู้ให้บริการเท่านั้น