ความรู้ก่อนเรียน: ควรรู้ว่า CPU ประมวลผลคำสั่ง, RAM เก็บข้อมูลระหว่างทำงาน และ Storage เก็บข้อมูลระยะยาว หากยังไม่คุ้น ให้ทบทวนหัวข้อ 31–35 ก่อน
PATH 01 · พื้นฐานคอมพิวเตอร์และภาพรวม AI
คำตอบสั้น: ระบบปฏิบัติการหรือ Operating System (OS) คือชั้นกลางที่รับคำขอจากแอป ตรวจสิทธิ์ จัดสรร CPU และ Memory จัดการ File, Network และอุปกรณ์ แล้วส่งผลลัพธ์กลับมาโดยไม่ให้ทุกโปรแกรมควบคุมฮาร์ดแวร์แข่งกันเอง
ถ้า Hardware คือห้องครัว OS คือผู้จัดการครัวที่แบ่งเตา พื้นที่เก็บของ อุปกรณ์ และสิทธิ์ให้หลายทีมทำงานพร้อมกัน Windows, macOS, Linux, Android และ iOS มีหน้าตาและนโยบายต่างกัน แต่ทุกระบบต้องตอบโจทย์เดียวกัน: ใครใช้ทรัพยากรอะไร เมื่อไร นานเท่าไร และภายใต้สิทธิ์ใด
SHIRO ชวนจำภาพนี้ไว้: แอป “ขอบริการ” จาก OS ผ่านประตูที่กำหนดไว้ ส่วน Kernel เป็นผู้ตัดสินใจและประสานงานกับ Driver กับฮาร์ดแวร์
อ่านจบบทนี้ คุณจะทำอะไรได้
- แยกบทบาทของ Application, System Call, Kernel, Driver และ Hardware ได้
- อธิบายความต่างระหว่าง Program, Process และ Thread ได้
- ตามเส้นทางการเปิดไฟล์หนึ่งครั้ง ตั้งแต่คลิกจนเห็นข้อมูลบนหน้าจอได้
- เชื่อมอาการเครื่องช้า โปรแกรมค้าง หรือ Permission denied กับทรัพยากรที่เกี่ยวข้องได้
- ใช้ Task Manager, Activity Monitor หรือ System Monitor เก็บหลักฐานก่อนแก้ปัญหาได้
OS คือทั้งผู้จัดการทรัพยากรและผู้ให้บริการพื้นฐาน
โปรแกรมไม่ได้ถือ CPU, RAM หรือ Storage เป็นของตัวเองอย่างถาวร มันส่งคำขอให้ OS จัดสรรทรัพยากรช่วงหนึ่ง พร้อมเงื่อนไข เช่น เปิดไฟล์แบบอ่านอย่างเดียว ขอ Memory เพิ่ม หรือส่งข้อมูลไปยังปลายทางเครือข่าย OS จึงมีสองบทบาทพร้อมกัน
Resource manager
แบ่งเวลา CPU, พื้นที่ Memory, คิว I/O และ Bandwidth ให้หลายงาน โดยพยายามรักษาความลื่นไหลและความยุติธรรมตามนโยบายของระบบ
Abstraction provider
เปลี่ยนฮาร์ดแวร์ซับซ้อนให้เป็นแนวคิดที่แอปใช้ได้ เช่น File, Process, Socket และ Virtual Memory
Protection boundary
ตรวจตัวตนและสิทธิ์ แยกพื้นที่ของ Process และจำกัดสิ่งที่ Code ทั่วไปทำกับ Kernel หรืออุปกรณ์ได้
เพราะมี Abstraction แอปจึงเปิดไฟล์ด้วย Path โดยไม่ต้องรู้ว่าบิตอยู่ตำแหน่งใดบน SSD และส่งข้อมูลผ่าน Socket โดยไม่ต้องสั่งชิปเครือข่ายทีละ Register
จากผู้ใช้ถึงฮาร์ดแวร์มีหลายชั้น
เส้นแบ่งระหว่าง User Space กับ Kernel Space สำคัญมาก แอปทั่วไปไม่ควรอ่าน Memory ของ Kernel หรือสั่งอุปกรณ์ได้โดยตรง เพราะความผิดพลาดเล็กน้อยอาจล้มทั้งระบบ System Call จึงทำหน้าที่เหมือนประตูตรวจเอกสาร: รูปแบบคำขอต้องถูกต้องและผู้ขอต้องมีสิทธิ์
Kernel ไม่ใช่ทั้ง OS แต่เป็นแกนสิทธิ์สูงของ OS
คำว่า OS ในชีวิตประจำวันครอบคลุม Kernel, Driver, Service เบื้องหลัง, Library, เครื่องมือดูแลระบบ และส่วนติดต่อผู้ใช้ ส่วน Kernel คือแกนที่ทำงานด้วยสิทธิ์สูง ควบคุม Scheduling, Memory, I/O, File System, Network และกลไกความปลอดภัยพื้นฐาน
System Call ไม่ได้แปลว่าทุกครั้งต้องช้าอย่างมีนัยสำคัญ แต่การข้ามขอบเขตและเข้าถึง I/O มีต้นทุน ดังนั้น Library และ OS จึงใช้ Buffer, Cache, Batch และ Asynchronous I/O เพื่อลดการรอที่ไม่จำเป็น
OS จัดการอะไรบ้าง และอาการผิดปกติบอกอะไร
| ทรัพยากร | งานของ OS | สัญญาณที่สังเกตได้ | คำถามแรก |
|---|---|---|---|
| CPU | จัดตาราง Thread, Priority และ Core | CPU สูงต่อเนื่อง พัดลมแรง UI หน่วง | Process ใดใช้ CPU และเป็นงานคำนวณจริงหรือวนผิดปกติ |
| Memory | จัด Page, Virtual Address Space, Cache และ Swap | RAM ใกล้เต็ม Swap สูง สลับแอปช้า | Working set โตเพราะงานจริง Cache หรือ Memory leak |
| Storage / File | Path, Metadata, Permission, Buffer และ File System | Disk 100% เปิดไฟล์ช้า Queue ยาว | เป็นไฟล์เล็กจำนวนมาก งานต่อเนื่อง หรือพื้นที่ใกล้เต็ม |
| Device | Driver, Interrupt, Buffer และ Power state | อุปกรณ์หาย ค้าง หรือทำงานหลังอัปเดตไม่ได้ | Driver, Cable, Permission หรือ Hardware เป็นสาเหตุ |
| Network | Protocol stack, Socket, Port, Route และ Firewall | เชื่อมต่อไม่ได้ Latency สูง Packet loss | ปัญหาอยู่ที่แอป เครื่อง เครือข่ายภายใน หรือปลายทาง |
Program, Process และ Thread เป็นคนละมุมของงาน
Program คือไฟล์คำสั่งที่ยังไม่จำเป็นต้องทำงาน เมื่อเปิด Program ระบบสร้าง Process ซึ่งมี Virtual Memory, Handle/File descriptor, สิทธิ์ และสถานะของตัวเอง ภายใน Process มีอย่างน้อยหนึ่ง Thread เป็นสายคำสั่งที่ Scheduler ส่งให้ CPU ประมวลผล
Program
แบบพิมพ์เขียวหรือไฟล์ที่เก็บอยู่บน Storage ยังไม่กินเวลา CPU จนกว่าจะถูกเรียกใช้
Process
ขอบเขตทรัพยากรและการป้องกัน หนึ่งแอปอาจสร้างหลาย Process เพื่อแยกงานหรือจำกัดความเสียหาย
Thread
ลำดับการทำงานภายใน Process หลาย Thread แชร์ทรัพยากรบางส่วน จึงต้องประสานการเข้าถึงข้อมูลร่วมกัน
การแยก Process ช่วยลดความเสียหาย แต่ไม่ใช่กำแพงสมบูรณ์ โปรแกรมยังสื่อสารผ่าน Pipe, Socket, Shared Memory หรือกลไก IPC อื่นที่ OS อนุญาต ข้อมูลที่ข้ามขอบเขตจึงยังต้องตรวจสอบ
Scheduling ทำให้หลายงานดูเหมือนเกิดพร้อมกัน
บนเครื่องที่มีงานมากกว่า Core, Scheduler สลับ Thread เข้าและออกจาก CPU อย่างรวดเร็ว เมื่อสลับงาน OS ต้องบันทึกสถานะของ Thread เดิมและโหลดสถานะของ Thread ใหม่ กระบวนการนี้เรียกว่า Context Switch
Context Switch จำเป็น แต่ถ้าเกิดถี่เกินไป งานจริงจะได้น้อยลงเพราะระบบเสียเวลาไปกับการสลับ ค่าการใช้ CPU สูงจึงไม่ได้แปลว่า “ทำงานที่มีประโยชน์สูง” เสมอ ต้องดู Run queue, Wait time, Thread count และ Timeline ร่วมกัน
Priority เป็นนโยบายช่วยตัดสินใจ ไม่ใช่คำสัญญาว่า Thread นั้นจะได้ CPU ทันทีตลอดเวลา เพราะยังมี Interrupt, I/O wait, Core availability และข้อจำกัดพลังงานร่วมด้วย
Virtual Memory ทำให้แต่ละ Process เห็นพื้นที่ของตัวเอง
แต่ละ Process มองเห็น Address Space เสมือนของตัวเอง OS และฮาร์ดแวร์ Memory Management Unit แปลง Address เหล่านั้นไปยัง Physical Memory พร้อมตรวจสิทธิ์ การออกแบบนี้ช่วยแยก Process และเปิดทางให้ระบบย้าย Page ที่ไม่ค่อยใช้ไปยังพื้นที่ Swap หรือ Page file เมื่อจำเป็น
อย่างไรก็ตาม Swap ไม่ใช่ RAM เพิ่มแบบฟรี เพราะ Storage ช้ากว่า RAM มาก หาก Working set ของงานเกิน RAM จนต้องย้าย Page เข้าออกถี่ ๆ จะเกิดภาวะ Thrashing: เครื่องดูเหมือนยุ่งมากแต่ความคืบหน้าจริงน้อยลง
เวลาสงสัยปัญหา Memory ให้ดูอย่างน้อย
- Memory usage ของทั้งระบบและของ Process เป้าหมาย
- แนวโน้มการใช้ Memory ว่าเพิ่มแล้วคงที่ หรือเพิ่มไม่หยุด
- Swap/Page file activity และ Storage latency
- Cache ที่ระบบอาจคืนให้แอปได้เมื่อจำเป็น
- เหตุการณ์ Out-of-memory หรือ Process ถูกปิด
File System และ Driver ซ่อนรายละเอียดของอุปกรณ์
File System จัดชื่อ Path, Directory, Metadata, Permission และตำแหน่งของข้อมูล ส่วน Driver แปลคำขอทั่วไปจาก Kernel ให้เป็นคำสั่งเฉพาะของ Storage, GPU, Network adapter, Keyboard หรือ Printer
คำสั่ง “อ่านไฟล์” จึงไม่ใช่การหยิบบิตทันที OS อาจตรวจ Permission, ตรวจ Cache, หา Block, สร้างคำขอ I/O, รอ Interrupt จากอุปกรณ์ แล้วค่อยปลุก Thread ที่รออยู่ หากไฟล์อยู่ใน Cache การอ่านอาจเร็วมาก; หากต้องอ่าน Storage จริง Latency จะสูงขึ้นหลายลำดับ
ตัวอย่าง: เมื่อกดเปิดไฟล์หนึ่งครั้ง
- ส่วนติดต่อผู้ใช้รับ Click แล้วส่ง Event ให้แอป
- แอปแปลง Event เป็นคำขอเปิด Path ด้วย Mode เช่น อ่านอย่างเดียว
- Library เรียก System Call เพื่อขอให้ Kernel เปิดไฟล์
- Kernel ตรวจ Path, Permission และ File System ที่รับผิดชอบ
- หากข้อมูลอยู่ใน Page cache ระบบใช้ข้อมูลนั้นได้เลย; หากไม่มีจึงส่ง I/O ผ่าน Driver ไป Storage
- เมื่อข้อมูลพร้อม OS ปลุก Thread ที่รอและส่ง Handle หรือข้อมูลกลับให้ Process
- แอป Decode/Parse ข้อมูล แล้วขอให้ระบบแสดงผลบนหน้าจอ
จุดช้าอาจอยู่ที่แอป, Antivirus, File System, Storage, Memory pressure หรือ Driver ไม่ใช่ CPU เสมอ การตามเส้นทางทีละชั้นช่วยตั้งสมมติฐานที่ตรวจได้แทนการเดา
BEGIN WITH THE WORKFLOW
กรณีศึกษา: เมษาเปิดโปรเจกต์ AI แล้วเครื่องค้างเป็นช่วง ๆ
เมษาเห็น CPU 35% จึงคิดว่า CPU ช้า แต่ Task Manager แสดง Memory 94%, Disk Active time 100% และแอปสลับหน้าต่างช้ามาก เมื่อปิด Dataset viewer อาการดีขึ้นชั่วคราว
หลักฐาน
- RAM ใกล้เต็มหลังโหลด Dataset
- Disk queue สูงพร้อม Page file activity
- CPU ไม่ได้เต็มทุก Core
- อาการเกิดตอนสลับแอปหรือโหลดไฟล์ชุดใหม่
แบบจำลอง
Working set รวมเกิน RAM ทำให้ OS ย้าย Page เข้าออก Storage บ่อย CPU จึงรอข้อมูล แม้ตัวเลข CPU ไม่เต็ม เครื่องกลับตอบสนองช้า
การทดลองที่ปลอดภัย
- บันทึก Baseline ของ RAM, Swap/Page file, Disk latency และเวลาที่ใช้เปิดโปรเจกต์
- ปิดแอปที่กิน Memory แต่ไม่จำเป็น แล้วทดสอบซ้ำ
- ลดขนาด Batch หรือจำนวนไฟล์ที่เปิดพร้อมกัน แล้ววัดใหม่
- เปลี่ยนทีละตัวแปรเพื่อแยกว่า Memory pressure หรือ Storage เป็นคอขวดหลัก
บทเรียนสำคัญคือ OS แสดงอาการของคอขวดผ่านหลาย Metric การอ่านเพียงเปอร์เซ็นต์ CPU ค่าเดียวอาจพาไปซื้ออุปกรณ์ผิดชิ้น
สิทธิ์ การแยก Process และ Update เป็นส่วนของความปลอดภัย
Least Privilege
ให้ผู้ใช้และ Process มีสิทธิ์เท่าที่จำเป็น ลดขอบเขตความเสียหายเมื่อ Code ผิดพลาดหรือถูกโจมตี
Isolation
แยก Virtual Memory และขอบเขต Process ไม่ให้แก้ข้อมูลของกันและกันโดยตรง
Authentication
ยืนยันว่าใครกำลังขอทรัพยากร ก่อนใช้ Permission และ Policy ตัดสินใจ
Patch
อัปเดต OS และ Driver เพื่อลดช่องโหว่ พร้อม Backup และแผนย้อนกลับสำหรับระบบสำคัญ
Audit
เก็บ Log และเหตุการณ์เพื่ออธิบายว่าอะไรเกิดขึ้น เมื่อไร และภายใต้บัญชีใด
Human decision
OS บังคับกติกาได้ แต่คนยังต้องกำหนดสิทธิ์ ตรวจแหล่งที่มาของ Software และทดสอบการกู้คืน
การรันทุกอย่างด้วยสิทธิ์ Administrator/Root อาจทำให้ปัญหาบางอย่าง “หาย” แต่แลกกับขอบเขตความเสียหายที่กว้างขึ้น ควรแก้ Permission ให้ตรงทรัพยากรและงานแทนการยกระดับทั้งโปรแกรมโดยไม่จำเป็น
ความเข้าใจผิดที่พบบ่อย และวิธีตรวจ
“OS คือหน้าตา Desktop”
หน้าตาเป็นเพียงชั้นหนึ่ง ตรวจโดยดูว่า Server ที่ไม่มี Desktop ยังมี Kernel, Process, Memory, File และ Network management ครบ
“CPU 100% แปลว่าเครื่องเสีย”
อาจเป็นงานคำนวณที่ใช้ทรัพยากรเต็มอย่างตั้งใจ ตรวจว่า Throughput เพิ่ม งานเดินหน้า อุณหภูมิอยู่ในเกณฑ์ และ Process ที่ใช้ CPU เป็นตัวที่คาดไว้หรือไม่
“RAM ว่างเยอะยิ่งดีเสมอ”
OS ใช้ RAM ว่างเป็น Cache เพื่อเร่งงานได้ สิ่งสำคัญคือ Memory pressure, Swap activity และความสามารถในการคืน Cache เมื่อแอปต้องการ
“Permission denied แก้ด้วยการรันเป็น Admin”
ควรถามก่อนว่า Process ต้องเข้าถึงทรัพยากรนั้นจริงหรือไม่ เจ้าของไฟล์และสิทธิ์ถูกต้องหรือไม่ และมีวิธีให้สิทธิ์เฉพาะจุดหรือไม่
“อัปเดต Driver ใหม่สุดย่อมดีที่สุดทุกเครื่อง”
เวอร์ชันใหม่อาจแก้ Bug แต่ก็อาจเปลี่ยนพฤติกรรม ทดสอบกับ Workflow จริง เก็บจุดย้อนกลับ และดู Release notes ของผู้ผลิต
WORKSHEET
OS Request Journey Card
เลือกเหตุการณ์หนึ่งอย่าง เช่น เปิดไฟล์ ส่งภาพไปพิมพ์ หรือเปิดหน้าเว็บ แล้วกรอกการ์ดนี้จากสิ่งที่สังเกตได้จริง
- User action: ผู้ใช้ทำอะไร และเวลาเริ่มต้นคือเมื่อไร
- Application: Process/Thread ใดรับงาน
- System service: คำขอเกี่ยวกับ File, Memory, Network หรือ Device
- Kernel/Driver: ชั้นใดน่าจะตรวจสิทธิ์ จัดคิว หรือรอ I/O
- Evidence: Metric, Log หรือ Timeline ใดสนับสนุนสมมติฐาน
- Safe experiment: จะเปลี่ยนตัวแปรใดเพียงหนึ่งอย่าง
- Result: เวลารวมและอาการเปลี่ยนไปอย่างไร
- Decision: สมมติฐานเดิมควรคงไว้ ปรับ หรือปฏิเสธ
Insight Gate
คุณพร้อมเรียนต่อเมื่ออธิบายเส้นทาง Application → System Call → Kernel → Driver/Hardware → Result ได้ และชี้หลักฐานได้ว่าคอขวดอยู่ที่ CPU, Memory, File/Storage, Network หรือ Device โดยไม่อาศัย Metric เดียว
แบบทดสอบความเข้าใจ 5 ข้อ
บทสรุป: OS ทำให้หลายโปรแกรมแบ่งเครื่องเดียวกันได้อย่างเป็นระบบ
ระบบปฏิบัติการซ่อนรายละเอียดฮาร์ดแวร์ไว้หลังบริการมาตรฐาน จัดตาราง Thread แยก Virtual Memory จัด File ควบคุม Network และ Device พร้อมตรวจสิทธิ์ Kernel เป็นแกนสิทธิ์สูง ขณะที่แอปอยู่ใน User Space และขอใช้บริการผ่าน System Call
เมื่อเครื่องช้า ค้าง หรือเข้าถึงทรัพยากรไม่ได้ ให้ตามเส้นทางคำขอและดูหลักฐานหลายมิติ: CPU, Memory pressure, Storage latency, Network, Driver, Permission และ Timeline วิธีนี้ช่วยแยกอาการออกจากสาเหตุและลดการแก้ปัญหาแบบเดา
SUMMARY INFOGRAPHIC
ภาพสรุป: จากผู้ใช้และแอป ผ่าน System Call สู่ Kernel และทรัพยากรของเครื่อง
เรียนต่ออย่างมีทิศทาง
นำ OS Request Journey Card ไปทดลองกับเหตุการณ์จริงหนึ่งอย่าง แล้วไปต่อหัวข้อ 37 เพื่อเจาะลึกว่า File, Folder และ Permission ทำงานร่วมกับผู้ใช้และ Process อย่างไร
ดู Learning Pack PATH 01 ทั้งชุด →แหล่งอ้างอิงและบันทึกบรรณาธิการ
- Linux Kernel Documentation — เอกสารแกนระบบ, Subsystem และการบริหารทรัพยากร
- Linux Kernel User-space API Guide — ขอบเขตการสื่อสารระหว่าง User Space กับ Kernel
- Microsoft Learn — Processes and Threads — Process, Thread และ Scheduling บน Windows
- Microsoft Learn — Windows Memory Space — User mode, Kernel mode และ Virtual Address Space
- Apple Developer Archive — Kernel Architecture Overview — สถาปัตยกรรม Kernel และบริการระบบ
ขอบเขต: รายละเอียด System Call, Scheduler, Memory policy, Permission และ Driver แตกต่างตาม OS และเวอร์ชัน บทเรียนนี้อธิบายแบบจำลองร่วมเพื่อใช้คิดและวิเคราะห์ ไม่ใช้แทนเอกสารเฉพาะแพลตฟอร์ม
ตรวจข้อเท็จจริงและทบทวนภาษาไทย: 11 สิงหาคม 2026 · AI Encyclopedia หัวข้อ 36 · PATH 01
