iostat & dmesg

คำสั่ง iostat -xz 1 เป็นเครื่องมือมาตรฐานในการวิเคราะห์ Storage Subsystem & Disk Bottlenecks บน Linux (อยู่ในแพ็กเกจ sysstat)

ความหมายของ Option:

• -x (Extended): แสดงสถิติเชิงลึก เช่น Latency, Queue size, %Utilization
• -z (Omit Inactive): ซ่อน Disk/Partition ที่ไม่มี Activity ในช่วงเวลานั้น (ตัดสัญญาณรบกวน)
• 1: สรุปผลและ Refresh ทุกๆ 1 วินาที

ตัวอย่าง Output จริงของ iostat -xz 1

Plaintext

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           2.10    0.00    1.50   18.40    0.00   78.00

Device            r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm  r_await  w_await   aqu-sz  rareq-sz  wareq-sz  svctm  %util
sda              5.00   45.00     40.00   1250.00     0.00     2.00   0.00   4.26     2.10    18.50     0.85      8.00     27.78   1.80  12.50
nvme0n1       1200.00  850.00  45000.00  32000.00    10.00    15.00   0.83   1.73     0.45     0.82     1.50     37.50     37.65   0.12  24.00
sdb             12.00  180.00     96.00   4500.00     0.00    80.00   0.00  30.77    85.00   140.00    15.20      8.00     25.00   5.10  99.80

ข้อควรระวังในการสัมภาษณ์: Output รอบแรกสุดที่แสดงขึ้นมาคือ “ค่าเฉลี่ยสะสมตั้งแต่เปิดเครื่อง (Since Boot)” ให้ข้ามไปดูรอบที่ 2 เป็นต้นไป ซึ่งเป็นค่า Real-time ของวินาทีนั้นจริง

เจาะลึก 5 ค่าสำคัญที่สุด (The Core Metrics)

เวลาสัมภาษณ์ กรรมการจะดูว่าเรารู้จักค่าหลักที่ใช้ตัดสินว่า “ดิสก์กำลังพังหรือคอขวดหรือไม่” ดังนี้:

1. %util (Device Utilization)

• ความหมาย: สัดส่วนเวลาที่ Disk มีงานทำ (Busy Percentage)
• เกณฑ์ประเมิน:
  • สำหรับ HDD จานหมุน: ถ้า %util > 80-90% แปลว่าดิสก์ตันแล้ว (Saturation)
  • จุดหลอกสัมภาษณ์ (Trap): สำหรับ SSD / NVMe / RAID Array ค่า %util ที่แตะ 100% ไม่ได้แปลว่าดิสก์ทำงานไม่ไหวเสมอไป เพราะ SSD และ Array รองรับ Parallel I/O หลายคิวพร้อมกัน จึงต้องดูค่า await ควบคู่เสมอ

2. r_await และ w_await (หรือ await)

• ความหมาย: เวลาเฉลี่ยรวมตั้งแต่ I/O ถูกส่งเข้ามาต่อคิวใน OS จนกระทั่ง Disk ทำงานเสร็จและตอบกลับ (Queue Time + Service Time) หน่วยเป็น Milliseconds (ms)
• เกณฑ์ประเมิน:
  • NVMe SSD: ควรต่ำกว่า 1 ms
  • SATA SSD: ควรต่ำกว่า 3 – 5 ms
  • HDD จานหมุน: ปกติอยู่ที่ 10 – 20 ms
  • จุดวิกฤต: หากค่านี้พุ่งไปถึง 50 – 100+ ms แปลว่า Application กำลังรอ Disk นานผิดปกติ (I/O Bottleneck แท้จริง)

3. aqu-sz (Average Queue Size)

• ความหมาย: จำนวน Request เฉลี่ยที่กำลังรอคิวส่งเข้า Hardware หรือกำลังประมวลผลอยู่
• เกณฑ์ประเมิน:
  • หากค่านี้สูงขึ้นเรื่อยๆ (เช่น > 5 บนดิสก์เดี่ยว หรือ > 20 บน Array) ร่วมกับ await ที่สูงขึ้น บ่งบอกว่า Hardware ขับงานไม่ทัน เกิดการสะสมของคิวงาน

4. r/s และ w/s (IOPS: Read/Write Requests per Second)

• ความหมาย: ปริมาณ Input/Output Operations ต่อวินาที
• ประโยชน์: ใช้ดู Workload Profile ว่าระบบกำลังเป็นงาน Read-heavy หรือ Write-heavy

5. rkB/s และ wkB/s (Throughput)

• ความหมาย: ปริมาณข้อมูลที่อ่าน/เขียนจริงต่อวินาที (Kilobytes/sec)
• ประโยชน์: นำไปคำนวณขนาด Request Size เฉลี่ย (wareq-sz = Throughput / IOPS) เพื่อแยกว่าเป็น Sequential I/O (ก้อนใหญ่) หรือ Random I/O (ก้อนเล็ก)

รายละเอียดคอลัมน์อื่นๆ ในตาราง

คอลัมน์	ชื่อเต็ม	ความหมายโดยย่อ
rrqm/s / wrqm/s	Read/Write Requests Merged	จำนวน Request ที่ Kernel รวมเข้าด้วยกันก่อนส่งลง Disk เพื่อลดภาระหัวอ่าน
%rrqm / %wrqm	% Requests Merged	สัดส่วนการรวม I/O (ถ้าสูง มักเป็น Sequential Read/Write)
rareq-sz / wareq-sz	Request Size	ขนาดเฉลี่ยของ Request แต่ละรอบ (หน่วยเป็น Kilobytes)
svctm	Service Time	เวลาที่ Hardware ใช้ประมวลผลจริง (ปัจจุบันถูก Deprecated ในระบบใหม่ๆ เพราะค่าคำนวณไม่แม่นยำบน SSD)

ตัวอย่างการตอบคำถามสัมภาษณ์ (Scenario Analysis)

หากกรรมการยื่นตัวเลขของดิสก์ sdb ในตัวอย่างด้านบนมาถาม:

sdb: r/s=12, w/s=180, await=140ms, aqu-sz=15.2, %util=99.8%

โครงสร้างคำตอบระดับ Senior:

*”จากค่าของ sdb ระบบกำลังเผชิญกับ Storage Saturation ชัดเจน ครับ โดยพิจารณาจาก 3 จุดหลัก:

1. %util พุ่งแตะ 99.8% ร่วมกับ aqu-sz อยู่ที่ 15.2 แสดงว่ามีคิวสะสมค้างเติ่งอยู่บนดิสก์ตลอดเวลา
2. w_await สูงถึง 140 ms ซึ่งเกินค่ามาตรฐานของทั้ง SSD และ HDD ไปมาก แอปพลิเคชันที่เขียนข้อมูลลง sdb จะเกิดอาการค้างหรือ Response ช้าแน่นอน
3. ขนาด Request (wareq-sz = 25KB) และ Throughput รวมเพียงประมาณ 4.5 MB/s บ่งชี้ว่าดิสก์ตัวนี้อาจกำลังมีปัญหา Physical Degradation (ดิสก์เสื่อม) หรือเจองาน Random Write จน Controller ทำงานไม่ทัน

ขั้นตอนถัดไป ผมจะใช้ smartctl -a /dev/sdb เพื่อตรวจสอบ Bad Sector หรือ Hardware Error และใช้ pidstat -d 1 เพื่อหาว่า Process ใดเป็นตัวการยิง Write I/O มหาศาลลงดิสก์ลูกนี้ครับ”*

dmesg (Display Message) คือคำสั่งสำหรับอ่านข้อมูลจาก Kernel Ring Buffer ซึ่งเป็นพื้นที่หน่วยความจำที่ Linux Kernel ใช้บันทึก Log ข้อความเหตุการณ์ระดับระบบตั้งแต่เริ่มเปิดเครื่อง (Boot sequence) การตรวจพบ Hardware, การโหลด Driver ไปจนถึง Hardware Failures และ Kernel Panics ขณะระบบกำลังทำงาน

ข้อดีของ Kernel Ring Buffer คือ ยังอ่านได้แม้ Disk หรือ Filesystem จะพังจนเขียน /var/log ไม่ได้

1. Options สำคัญของ dmesg สำหรับใช้งานจริง

• -T (--ctime): แปลงตัวเลขนับวินาทีของ Kernel Timestamp ให้เป็นวันที่และเวลาที่มนุษย์อ่านรู้เรื่อง (สำคัญที่สุด)
  Bashdmesg -T
• -l (--level): กรองดูเฉพาะระดับความรุนแรง (Log Levels: emerg, alert, crit, err, warn)
  Bashdmesg -T -l err,crit
• -w (--follow): เฝ้าดู Log แบบสดๆ เรียลไทม์ (คล้าย tail -f) เหมาะมากเวลาทดสอบเสียบสายแลน เสียบอุปกรณ์ หรือทดสอบโหลดหนัก
  Bashdmesg -Tw

2. เคส Hardware / Kernel Error ยอดฮิตที่พบบ่อยในการสัมภาษณ์

เคสที่ 1: Memory / Process โดนฆ่ากะทันหัน (Out Of Memory – OOM Killer)

เมื่อระบบใช้ RAM จนเกลี้ยง และไม่มี Swap เหลือ Kernel จะเปิดกลไก OOM Killer ขึ้นมาคำนวณคะแนน (badness score) เพื่อสังหาร Process ที่กิน RAM มากที่สุดทันที

• คำสั่งค้นหา:
  Bashdmesg -T | grep -i -E 'oom|invoked oom-killer|killed process'
• ข้อความตัวอย่างที่ปรากฏ:
  Plaintext[Sat Aug 29 14:10:05 2026] Out of memory: Kill process 14205 (mysqld) score 845 or sacrifice child [Sat Aug 29 14:10:05 2026] Killed process 14205 (mysqld) total-vm:8542000kB, anon-rss:6210400kB
• วิธีตอบสัมภาษณ์: ชี้ชัดว่า Process ไม่ได้ Crash จากโค้ดตัวเอง แต่โดน Kernel ส่งสัญญาณ SIGKILL บังคับปิดเพราะ Memory ของระบบหมด

เคสที่ 2: Disk I/O Error / Bad Sector / Filesystem ติด Read-Only

เมื่อดิสก์มีปัญหาทางกายภาพ หัวอ่านสะดุด หรือคอนโทรลเลอร์ไม่ตอบสนอง Kernel จะเริ่มขึ้น Error ระดับ ATA/SCSI และมักจะสั่ง Remount Filesystem เป็น Read-Only (ro) ทันทีเพื่อป้องกันข้อมูลเสียหาย

• คำสั่งค้นหา:
  Bashdmesg -T | grep -i -E 'error|ata|scsi|buffer i/o|sector'
• ข้อความตัวอย่างที่ปรากฏ:
  Plaintext[Sat Aug 29 15:02:11 2026] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 [Sat Aug 29 15:02:11 2026] ata2.00: failed command: READ FPDMA QUEUED [Sat Aug 29 15:02:12 2026] Buffer I/O error on dev sda2, logical block 4581290, async page read [Sat Aug 29 15:02:13 2026] EXT4-fs error (device sda2): Remounting filesystem read-only
• วิธีตอบสัมภาษณ์: อธิบายได้ทันทีว่าเกิดปัญหา Physical Block เสียหาย (Bad Sector) บน sda2 และส่งผลให้ Filesystem เข้า Safe-mode (ro) ต้องเปลี่ยนดิสก์หรือรัน fsck

เคสที่ 3: PCIe / NIC Flapping & Link Drops (การ์ดแลนหรือสายสัญญาณหลุด)

ใช้หาสาเหตุว่าทำไม Network ขาดการเชื่อมต่อไปชั่วคราว หรือการ์ดแลนหลุดออกจาก Bus

• คำสั่งค้นหา:
  Bashdmesg -T | grep -i -E 'eth|link is|down|dropped|reset'
• ข้อความตัวอย่างที่ปรากฏ:
  Plaintext[Sat Aug 29 11:22:45 2026] igb 0000:03:00.0 eth0: NIC Link is Down [Sat Aug 29 11:22:48 2026] igb 0000:03:00.0 eth0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX [Sat Aug 29 11:25:01 2026] pcieport 0000:00:1c.0: AER: Corrected error received: 0000:03:00.0
• วิธีตอบสัมภาษณ์: หากเจอ Link Down/Up ถี่ๆ (Link Flapping) สาเหตุหลักคือสายแลนหลุดหลวม, Switch Port ปลายทางมีปัญหา หรือการ์ดแลน PCIe เกิด Hardware/Driver Crash จนต้อง Reset ตัวเอง

เคสที่ 4: CPU Throttling / Machine Check Exception (MCE)

เกิดจากปัญหาความร้อนเกิน (Overheating) หรือ Hardware ระดับ CPU/Motherboard/RAM ทำงานผิดพลาด

• คำสั่งค้นหา:
  Bashdmesg -T | grep -i -E 'thermal|throttled|mce|hardware error'
• ข้อความตัวอย่างที่ปรากฏ:
  Plaintext[Sat Aug 29 13:45:00 2026] CPU3: Core temperature above threshold, cpu clock throttled [Sat Aug 29 13:45:15 2026] CPU3: Core temperature/speed normal [Sat Aug 29 14:00:22 2026] [Hardware Error]: Machine check events logged [Sat Aug 29 14:00:22 2026] [Hardware Error]: Corrected error, no action required.
• วิธีตอบสัมภาษณ์: ถ้าเจอ Throttled แปลว่าพัดลมระบายความร้อนฮีตซิงก์ใน Data Center มีปัญหา ทำให้ CPU ลดความถี่สัญญาณนาฬิกาลงเพื่อเซฟตัวเอง ส่งผลให้ Server ช้ากะทันหัน ส่วน MCE บ่งบอกถึงความผิดปกติของ RAM Bus หรือ Cache Controller

โครงสร้างคำตอบสรุปสำหรับผู้สัมภาษณ์ (Elevator Pitch)

“เมื่อเซิร์ฟเวอร์เกิดปัญหาเครื่องค้าง บริการดับกะทันหัน หรือ I/O ช้าผิดปกติ คำสั่งแรกๆ ที่ผมจะใช้ตรวจคือ dmesg -T -l err,crit เพราะ Kernel Ring Buffer จะบันทึกปัญหาฮาร์ดแวร์โดยตรงโดยไม่ต้องพึ่งพา Disk Log เช่น การตรวจสอบ OOM Killer ที่สั่งฆ่าโปรเซส, ปัญหา Buffer I/O Error บนดิสก์ที่มี Bad Sector, หรือการ์ดแลนที่มีอาการ Link Flapping ครับ”