วิธีเช็ก 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) ที่อยู่ในสถานะพร้อมทำงาน (runnable) อยู่บน run queue โดยไม่มี I/O ค้างอยู่ แต่ยังไม่สามารถประมวลผลได้ จะถูกรายงานเป็น st ไม่มีสิ่งใดภายในเซิร์ฟเวอร์ของคุณที่จะแก้ไขสถานะนี้ได้ เพราะการตัดสินใจจัดสรรเวลา CPU เกิดขึ้นในเลเยอร์ที่ต่ำกว่าคุณ ซึ่งก็คือบน host

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

ฉันจะตรวจสอบ 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 counter จริงๆ จากนั้น vmstat 1 5 จะทำการสุ่มตัวอย่างวินาทีละหนึ่งครั้ง รวมทั้งหมด 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 ในช่วงเวลาที่คุณสงสัย ข้อมูลในไฟล์จะช่วยให้คุณสามารถระบุช่วงเวลาที่เกิดปัญหาได้อย่างแม่นยำ 10 นาที แทนการแจ้งผู้ให้บริการเพียงว่า "รู้สึกว่าระบบช้าเมื่อคืนนี้"

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

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

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

Steal time สร้างภาระต้นทุนให้คุณเท่าไร?

การคำนวณนั้นสั้นและง่าย หากสัดส่วน s ของเวลา CPU ของคุณถูกดึงไปใช้ งานที่ต้องใช้ 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-plan งานนั้นจะใช้เวลา 61.9 วินาที แทนที่จะเป็น 60.0 วินาที ซึ่งไม่มีใครเปิดตั๋วแจ้งปัญหาจากเรื่องนี้ แต่ที่ระดับ 8 เปอร์เซ็นต์ เวลาจะเพิ่มเป็น 65.2 วินาที และที่ระดับ 40 เปอร์เซ็นต์ งานเดียวกันจะต้องใช้เวลาถึง 100.0 วินาที ส่งผลให้คิวงานที่เคยระบายออกได้ทันกลับเริ่มสะสมตัวขึ้นแทน

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

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

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

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

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

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

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

ภายในคอนเทนเนอร์ ตัวนับที่มีความหมายเดียวกันคือ 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 แบบซ้อนทับ (layered virtualisation) จะเพิ่มจุดที่เวลาอาจสูญหายไปอีกหนึ่งแห่ง เนื่องจาก VM ที่อยู่ภายใน VPS ของคุณจะต้องแบกรับทั้งค่า steal ของคุณและค่าความล่าช้าในการจัดตารางเวลาของตัวมันเอง โปรดคำนึงถึงเรื่องนี้หากคุณ รัน nested virtualisation บน VPS

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

ไม่มีการตั้งค่าใดภายใน guest ที่จะแก้ไขปัญหา steal ได้ เนื่องจากตัวจัดตารางเวลา (scheduler) ที่ตัดสินใจเรื่องนี้ทำงานอยู่นอก guest มี 4 แนวทางที่ทำได้จริง

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

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

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

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

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

FAQ

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

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

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

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

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

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

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

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