ทำไมเราต้องรอ I / O

เป็นที่ทราบกันดีอยู่แล้วว่าการทำงานของดิสก์ช้าและเรารู้สาเหตุที่ทำให้การทำงานช้า ดังนั้นคำถามที่นี่คือเหตุผลที่เราต้องรอ I / O หรือทำไมมีสิ่งเช่น IOWait ฯลฯ

ฉันหมายถึงฉันสังเกตเห็นว่าเมื่อคุณทำงาน I / O บางส่วนในพื้นหลังโดยทั่วไปคอมพิวเตอร์ของคุณจะช้าลงมากฉันสังเกตว่าโดยเฉพาะอย่างยิ่งเมื่อใช้ Linux ถ้าคุณทำภารกิจ I / O อีกต่อไป ระบบปฏิบัติการเกือบจะไม่สามารถใช้งานได้จนกว่าจะเสร็จสิ้น

ที่จริงฉันยังพบหัวข้อนี้ในบทความมีตัวอย่าง:

การรอ I / O คือ 12.1% เซิร์ฟเวอร์นี้มี 8 คอร์ (ผ่าน cat / proc / cpuinfo) สิ่งนี้อยู่ใกล้กับ (1/8 คอร์ = 0.125)

โดยพื้นฐานแล้วมันหมายความว่ามันทำให้คอมพิวเตอร์ช้าลงมากทำไมล่ะ? ฉันหมายถึงตกลงตอนนี้คอมพิวเตอร์ทั่วไปมีอย่างน้อย 2 คอร์บางครั้ง 4 หรือบางครั้งพวกเขามีมากขึ้นเพราะการทำไฮเปอร์เธรดหรืออะไรแบบนั้น แต่ตอนนี้คำถามคือทำไม CPU ถึงต้องอยู่ที่นั่นจริง ๆ แล้วไม่ได้ทำอะไรอย่างอื่นนอกจากแค่รอ IO? ฉันหมายถึงความคิดพื้นฐานหรือสถาปัตยกรรมของกระบวนการจัดการตอนนี้ฉันไม่รู้ว่ามันเป็นระบบปฏิบัติการที่รับผิดชอบเรื่องนั้นหรือไม่ก็ลงไปในส่วนของฮาร์ดแวร์ แต่ควรทำให้ซีพียูต้องรอหรือ ตรวจสอบเป็นประจำในขณะที่ปฏิบัติงานอื่น ๆ อีกมากมายจริง ๆ แล้วกลับไปที่กระบวนการ IO เมื่อพร้อม แน่นอนถ้านั่นเป็นงานที่ยากและซีพียูต้องรอทำไม isn ' จัดการกับฮาร์ดแวร์ได้อย่างมีประสิทธิภาพมากกว่างั้นเหรอ? เช่นมีมินิซีพียูบางชนิดที่เพิ่งจะรอและส่งข้อมูลส่วนเล็ก ๆ ไปยังซีพียูตัวจริงทันทีที่มันกลับไปที่กระบวนการดังนั้นกระบวนการจะทำซ้ำและเราจะไม่มี จริง ๆ แล้วอุทิศซีพียูคอร์ทั้งหมดสำหรับกระบวนการคัดลอกข้อมูล ... หรือฉันจะเป็นคนที่ควรคิดค้นสิ่งนี้และได้รับรางวัลโนเบลสำหรับสิ่งนั้น? : S

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

โครงร่าง I / O ที่คุณกำลังอธิบายอยู่ในปัจจุบันใช้ในคอมพิวเตอร์

ทำไมซีพียูถึงต้องอยู่ที่นั่นจริง ๆ แล้วไม่ทำอะไรอย่างอื่นนอกจากรอแค่ IO เท่านั้น

นี่คือที่ง่ายที่สุดที่เป็นไปได้วิธีการ I / O: โปรแกรม I / O ระบบฝังตัวจำนวนมากและไมโครโปรเซสเซอร์ระดับต่ำสุดมีเพียงคำสั่งอินพุตเดียวและคำสั่งเอาต์พุตเดียว โปรเซสเซอร์จะต้องดำเนินการตามลำดับขั้นตอนที่ชัดเจนสำหรับตัวละครทุกตัวที่อ่านหรือเขียน

แต่มันควรจะเป็นไปได้ที่ cpu จะรอหรือตรวจสอบเป็นประจำในขณะที่ปฏิบัติงานอื่น ๆ มากมายและกลับไปที่กระบวนการ IO เมื่อพร้อม

คอมพิวเตอร์ส่วนบุคคลจำนวนมากมีโครงร่าง I / O อื่น ๆ แทนที่จะรอเป็นวงแคบเพื่อให้อุปกรณ์พร้อมใช้งาน ( กำลังรอไม่ว่าง ) CPU จะเริ่มต้นอุปกรณ์ I / O เพื่อขอให้สร้างการขัดจังหวะเมื่อเสร็จสิ้น ( I / O ขับเคลื่อนโดยขัดจังหวะ )

แม้ว่า I / O ที่ถูกอินเตอร์รัปต์จะเป็นไปข้างหน้า (เมื่อเทียบกับ I / O ที่ตั้งโปรแกรมไว้) แต่ก็ต้องการการขัดจังหวะสำหรับตัวละครทุกตัวที่ส่งและมีราคาแพง ...

เช่นมีมินิซีพียูบางชนิดที่เพิ่งจะรอและส่งข้อมูลส่วนเล็ก ๆ ไปยังซีพียูตัวจริงทันทีที่มันกลับไปที่กระบวนการดังนั้นกระบวนการจะทำซ้ำและเราจะไม่มี เพื่ออุทิศจริง cpu core ทั้งหมดสำหรับกระบวนการคัดลอกข้อมูล ...

การแก้ปัญหาต่าง ๆ อยู่ที่การมีคนอื่นทำงาน! :-)

คอนโทรลเลอร์ / ชิป DMA (การเข้าถึงหน่วยความจำโดยตรง) อนุญาตให้ใช้ I / O ที่ตั้งโปรแกรมไว้ แต่ให้มีคนอื่นทำ!

ด้วย DMA CPU จะต้องเริ่มต้นการลงทะเบียนไม่กี่ครั้งและมีอิสระที่จะทำอย่างอื่นจนกว่าการถ่ายโอนจะเสร็จสิ้น (และการขัดจังหวะจะเพิ่มขึ้น)

แม้ว่า DMA จะไม่ฟรีทั้งหมด: อุปกรณ์ความเร็วสูงสามารถใช้บัสหลายรอบสำหรับการอ้างอิงหน่วยความจำและการอ้างอิงอุปกรณ์ ( การขโมยรอบ ) และ CPU ต้องรอ (ชิป DMA มีลำดับความสำคัญของบัสที่สูงกว่าเสมอ)

การรอ I / O คือ 12.1% เซิร์ฟเวอร์นี้มี 8 คอร์ (ผ่าน cat / proc / cpuinfo) สิ่งนี้อยู่ใกล้กับ (1/8 คอร์ = 0.125)

ฉันคิดว่ามาจาก: ทำความเข้าใจกับดิสก์ I / O - คุณควรกังวลเมื่อใด

มันไม่แปลกเลย: ระบบ (mySQL) ต้องดึงข้อมูลทุกแถวก่อนจัดการข้อมูลและไม่มีกิจกรรมอื่น ๆ

ที่นี่ไม่มีปัญหาสถาปัตยกรรมคอมพิวเตอร์ / ระบบปฏิบัติการ มันเป็นเพียงแค่การตั้งค่าตัวอย่าง

ส่วนใหญ่อาจเป็นปัญหาการปรับ RDBMS หรือปัญหาการสืบค้น SQL (ดัชนีหายไป, แผนแบบสอบถามไม่ถูกต้อง, แบบสอบถามไม่ถูกต้อง ... )

เป็นไปได้ที่จะเขียนแบบอะซิงโครนัส IO ที่คุณบอกให้ระบบปฏิบัติการส่งดิสก์อ่าน / เขียนแล้วไปทำอย่างอื่นแล้วตรวจสอบภายหลังว่าทำเสร็จหรือไม่ มันไกลจากใหม่ วิธีที่เก่ากว่าใช้เธรดอื่นสำหรับ IO

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

นอกจากนี้ยังง่ายต่อการตั้งโปรแกรมเมื่อคุณคิดว่าทุกอย่างกำลังบล็อก IO

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

การอ่านลูปทั่วไปเป็นตัวอย่างที่ดี

//variables that the loop uses
char[1024] buffer;
while((read = fread(buffer, 1024, 1, file))>0){
    //use buffer
}

มิฉะนั้นคุณจะต้องบันทึกสถานะของฟังก์ชั่นปัจจุบัน (โดยปกติจะอยู่ในรูปของ callback + userData pointer) และส่งมัน + identifier ของการดำเนินการอ่านกลับไปที่select()ลูปประเภท หากการดำเนินการเสร็จสิ้นจะทำการแมปตัวระบุของการดำเนินการอ่านกับตัวเรียกกลับ + ข้อมูลและเรียกใช้การเรียกกลับด้วยข้อมูลของการดำเนินการที่เสร็จสมบูรณ์

void callback(void* buffer, int result, int fd, void* userData){
    if(result<=0){
    //done, free buffer and continue to normal processing
    }
    //use buffer

    int readID = async_read(fd, buffer, userData->buff_size);
    registerCallback(readId, callback, userData);
}

นอกจากนี้ยังหมายความว่าทุกฟังก์ชั่นที่สามารถจบลงด้วยการอ่าน async นั้นจะต้องสามารถจัดการกับความต่อเนื่องของ async ได้ นั่นคือการเปลี่ยนแปลงที่ไม่สำคัญในโปรแกรมส่วนใหญ่คุณถามคนที่พยายามเข้าสู่ async C # เกี่ยวกับเรื่องนั้น

อย่างไรก็ตาม IO แบบซิงโครนัสกับ IO แบบอะซิงโครนัสไม่ใช่สาเหตุของการชะลอตัวทั่วไป การสลับหน้าในยังเป็นการดำเนินการที่ต้องรอ IO ตัวกำหนดตารางเวลาจะสลับไปยังโปรแกรมอื่นที่ไม่ได้กำลังรอ IO หากมีอยู่ ( รอ IO คือเมื่อตัวประมวลผลไม่ได้ทำงานและมีการดำเนินการ IO ที่ค้างอยู่ )

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

กล่าวอีกนัยหนึ่งคอขวดจริงอาจอยู่ในฮาร์ดแวร์แทนที่จะเป็นซอฟต์แวร์

มีความเชื่อว่าการประมวลผลของสิ่งอื่น ๆ ในขณะที่รอ I / O ค่อนข้างคล่องตัวใกล้เคียงกับความคล่องตัวมากที่สุด เมื่อคุณเห็นว่าคอมพิวเตอร์ของคุณกำลังรอ I / O เพียง 12.1% ของเวลานั่นหมายความว่าในความเป็นจริงแล้วมันก็ทำสิ่งอื่น ๆ มากมายในแบบคู่ขนาน ถ้ามันต้องรอ I / O โดยไม่ทำอะไรเลยมันจะรอ 99.9% ของเวลานั่นคือวิธีที่ I / O นั้นช้า

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

แก้ไข:

การหาวิธีแก้ไขปัญหาของวิธีการทำสิ่งอื่น ๆ ในขณะที่ทำ I / O นั้นเป็นสิ่งที่น่าชื่นชมเพราะในขณะเดียวกันก็จะเป็นวิธีแก้ปัญหาของวิธีการทำสิ่งอื่น ๆ ในขณะที่ไม่ได้ใช้งาน เพลงยอดเยี่ยมที่น่าจะเป็นเพราะมันหมายความว่าคุณจะหางานทำเพื่อให้คอมพิวเตอร์ของคุณทำในขณะที่มันไม่มีเลย

คุณจะเห็นว่านี่คือสิ่งที่เกิดขึ้น: คอมพิวเตอร์ของคุณกำลังนั่ง 99.99% ของเวลาไม่ทำอะไรเลย เมื่อคุณให้สิ่งที่ต้องทำมันจะไปและทำ หากทำเช่นนั้นจะต้องรอ I / O อยู่ที่นั่นและรอ หากมีสิ่งอื่นที่ต้องทำขณะทำ I / O ก็ทำเช่นนั้นเช่นกัน แต่ถ้ามันไม่มีสิ่งอื่นที่จะทำนอกเหนือจาก I / O ก็ต้องนั่งตรงนั้นและรอให้ I / O นั้นเสร็จ ไม่มีวิธีการแก้ไขที่นอกเหนือจากการลงทะเบียนใน SETI @ Home

ระบบปฏิบัติการ (เว้นแต่เป็นระบบฝังตัวในระดับต่ำมากหรือบางสิ่งที่แปลกใหม่ในทำนองเดียวกัน) ได้ดูแลสิ่งนี้อยู่แล้ว: หากแอปพลิเคชันของคุณต้องรอ I / O มันจะปิดกั้น I / O นั้นโดยปกติแล้วเธรดหรือแอปพลิเคชันอื่น ๆ คล่องแคล่ว. ตัวกำหนดตารางเวลาจะตัดสินใจว่าจะเลือกอันไหน

เฉพาะในกรณีที่ไม่มีเธรดหรือแอปพลิเคชันอื่นซึ่งอาจทำงานได้ว่าคุณกำลังรอเวลาสะสม ในบทความที่คุณยกมา (ขอบคุณ @manlio สำหรับลิงก์) นั่นคือคุณมี 12.1% ที่รออยู่และไม่ได้ใช้งาน 87.4% ซึ่งหมายความว่าหนึ่งคอร์กำลังรอให้ I / O ดำเนินการในขณะที่ส่วนที่เหลือไม่ได้ทำอะไรเลย เลย ให้บางสิ่งบางอย่างกับระบบทำสิ่งที่ดีกว่าหลาย ๆ อย่างและเปอร์เซ็นต์การรอจะลดลง

หนึ่งในเป้าหมายสูงสุดของการออกแบบแอพพลิเคชั่นในปัจจุบันคือทำให้มั่นใจได้ว่าแม้จะมีแอพพลิเคชั่นเพียงตัวเดียวที่ทำงานอยู่และแม้ว่าแอพพลิเคชั่นเดียวนั้นจะรอ I / O อยู่ก็ตาม เธรดเป็นหนึ่งในแนวทางนี้โดยไม่มีการปิดกั้น I / O อื่น แต่มันขึ้นอยู่กับประเภทของงานที่คุณทำไม่ว่าคุณจะทำอะไรได้จริงๆโดยไม่ต้องใช้ข้อมูลที่คุณรออยู่

เมื่อใช้ Linux หากคุณทำภารกิจ I / O อีกต่อไประบบปฏิบัติการจะใช้งานไม่ได้จนกว่าจะเสร็จสิ้น

โดยทั่วไปแล้วจะบ่งบอกถึงสถานการณ์ I / O ที่ถูกผูกไว้ ฉันกล้าพูดว่าระบบไม่ได้ช้าเพราะประมวลผล CPU ไม่เพียงพอ มีโอกาสมากที่จะช้าเพราะบางสิ่งขึ้นอยู่กับข้อมูลจาก HDD ซึ่งไม่ว่างในขณะนั้น นี่อาจเป็นแอปพลิเคชันที่คุณต้องการเรียกใช้ แต่ต้องโหลดไฟล์ที่ปฏิบัติการได้ไฟล์ไลบรารีไอคอนฟอนต์และทรัพยากรอื่น ๆ อาจเป็นแอปพลิเคชั่นที่คุณใช้งานอยู่ แต่มีการสลับหน่วยความจำส่วนหนึ่งและตอนนี้จำเป็นต้องสลับที่อีกครั้งเพื่อดำเนินการต่อ อาจเป็น daemon บางตัวด้วยเหตุผลใดเหตุผลหนึ่งหรืออย่างอื่นคิดว่าไม่เพียง แต่ต้องเขียนบรรทัดลงในไฟล์บันทึก แต่จริงๆแล้วจะล้างไฟล์บันทึกนั้นก่อนตอบคำขอบางอย่าง

คุณสามารถใช้เครื่องมือต่าง ๆiotopเพื่อดูว่าความจุของ I / O นั้นถูกจัดสรรไปยังกระบวนการอย่างไรและioniceเพื่อกำหนดลำดับความสำคัญของ I / O สำหรับกระบวนการ ตัวอย่างเช่นบนเครื่องเดสก์ท็อปคุณสามารถจำแนกการประมวลผลข้อมูลจำนวนมากทั้งหมดไปยังidleคลาสการกำหนดตารางเวลาเพื่อให้ขณะที่บางแอปพลิเคชันแบบอินเทอร์แอคทีฟต้องการแบนด์วิดธ์ I / O การประมวลผลจำนวนมาก

มันขึ้นอยู่กับรหัสแอปพลิเคชันของคุณ ฉันคิดว่ารหัสของคุณทำงานบน Linux

คุณสามารถใช้มัลติเธรด (เช่น POSIX pthreads ) เพื่อให้เธรดที่มีขอบเขตการคำนวณทำการคำนวณบางส่วนในขณะที่เธรดที่ผูกกับ IO อื่นกำลังทำ IO (และกำลังรออยู่) คุณยังสามารถให้แอปพลิเคชันของคุณทำงานหลาย กระบวนการในการสื่อสารกับการสื่อสารระหว่างกระบวนการ (IPC) ดูท่อ (7) , FIFO (7) , ซ็อกเก็ต (7) , ยูนิกซ์ (7) , shm_overview (7) , sem_overview (7) , mmap (2) , eventfd (2)และอ่านการเขียนโปรแกรม Linux ขั้นสูงฯลฯ ....

คุณสามารถใช้IO ที่ไม่บล็อกเช่น pass O_NOBLOCKto open (2) etc etc etc ... ; จากนั้นคุณจะต้องสำรวจ (2)และ / หรือใช้SIGIO สัญญาณ (7) ... และจัดการEWOULDBLOCKข้อผิดพลาดจากการอ่าน (2)ฯลฯ ...

คุณสามารถใช้ POSIX อะซิงโครนัส IO ดูaio (7)

สำหรับการเข้าถึงไฟล์คุณสามารถให้คำแนะนำกับแคชของหน้าเว็บเช่นด้วยmadvise (2)หลังจากmmap (2)และposix_fadvise (2) ; ดู Linux readahead ที่เฉพาะเจาะจง(2)

แต่ในที่สุดคุณก็จะไปถึงคอขวดของฮาร์ดแวร์ (รถบัส, RAM, ฯลฯ ... ) ดูที่ionice (1)

ฉันเพิ่มมุมมองอื่นนอกเหนือจากที่อื่นอาจเป็นการโต้แย้ง:

ปัญหาทั่วไปของระบบปฏิบัติการ Linux ปกคลุมด้วยวัตถุฉนวนโดยเฉพาะ (ค้นหา "Linux mouse lag") Windows ไม่มีปัญหานี้ ฉันมีบูตคู่ Windows 7 และ Linux Mint แม้ในขณะที่ใช้งานดิสก์ใน Windows แต่ Windows ก็ยังทำงานช้า แต่เมาส์ก็เคลื่อนไหวได้ตามปกติ ใน Linux ตรงกันข้ามมันไม่ได้รู้สึกว่าเลอะและบางครั้งเม้าส์อาจล่าช้าแม้ในขณะที่ท่องเว็บตามปกติ

อาจเป็นเพราะปรัชญาและประวัติศาสตร์ที่แตกต่างกันของทั้งสองระบบ Windows มาจากจุดเริ่มต้นที่ออกแบบมาสำหรับผู้ใช้ทั่วไประบบปฏิบัติการกราฟิกแบบหลัก และสำหรับผู้ใช้ Windows พฤติกรรมของระบบที่ไม่ราบรื่นและการหยุดเมาส์เป็นการส่งสัญญาณว่ามีบางอย่างผิดปกติ ดังนั้นโปรแกรมเมอร์ของ Microsoft จึงทำงานอย่างหนักเพื่อออกแบบระบบทั้งหมดเพื่อลดขนาดเคสให้เล็กที่สุดเมื่อระบบรู้สึกช้า ในทางตรงกันข้าม Linux ไม่ใช่ระบบกราฟิกเริ่มแรกเดสก์ท็อปเป็นเพียงบุคคลที่สามเพิ่มเติมที่นี่ และลีนุกซ์ถูกออกแบบมาเพื่อแฮกเกอร์เป็นหลักโดยใช้บรรทัดคำสั่ง ทำสิ่งต่าง ๆ ให้สำเร็จตามหลักปรัชญา Linux ไม่ได้ออกแบบมาเพื่อการทำงานที่ราบรื่นในใจความรู้สึกไม่สำคัญที่นี่

หมายเหตุ: ฉันไม่ได้บอกว่า Windows ดีกว่า Linux ฉันบอกว่าพวกเขามีปรัชญาโดยรวมที่แตกต่างกันซึ่งในสภาพแวดล้อมที่ซับซ้อนสามารถนำไปสู่พฤติกรรม / ความรู้สึกระดับสูงที่แตกต่างกันของระบบเหล่านี้