นักพัฒนาจำนวนมากขึ้นเรื่อยๆ กำลังประสบปัญหาประสิทธิภาพที่สำคัญเมื่อทำงานกับ repository ของ Git และ package manager อย่าง pnpm บน macOS ปัญหาดูเหมือนจะเกิดจากวิธีที่ระบบไฟล์ APFS ของ Apple จัดการไฟล์ขนาดเล็กจำนวนมาก ทำให้เกิดคอขวดที่อาจทำให้งานพัฒนาทั่วไปช้าลงอย่างเจ็บปวด
ปัญหานี้เด่นชัดมากจนนักพัฒนาได้สร้าง benchmark repository เฉพาะเพื่อทดสอบและบันทึกปัญหาประสิทธิภาพเหล่านี้ การทดสอบมุ่งเน้นไปที่การดำเนินการทั่วไปสองอย่างที่นักพัฒนาทำทุกวัน คือ การล้าง Git repository และการติดตั้ง package dependency การดำเนินการเหล่านี้เกี่ยวข้องกับการสร้าง อ่าน และลบไฟล์ขนาดเล็กหลายพันไฟล์ ซึ่งเป็นประเภทของ workload ที่ดูเหมือนจะกระตุ้นปัญหาประสิทธิภาพของ APFS
Time Machine Snapshot สร้าง Overhead เพิ่มเติม
หนึ่งในตัวการหลักดูเหมือนจะเป็น APFS snapshot ที่สร้างโดย Time Machine ทุกครั้งที่ระบบสำรองข้อมูลทำงาน มันจะสร้าง snapshot ของระบบไฟล์ทั้งหมด ซึ่งเพิ่ม overhead อย่างมากให้กับการดำเนินการไฟล์ สิ่งนี้เป็นปัญหาเฉพาะสำหรับ workflow การพัฒนาที่เกี่ยวข้องกับการสร้างและลบไฟล์บ่อยๆ
ระบบ snapshot สร้างพายุที่สมบูรณ์แบบของปัญหาประสิทธิภาพ เมื่อนักพัฒนาทำงานกับ Git repository หรือติดตั้ง package พวกเขากำลังสร้างและลบไฟล์หลายพันไฟล์ การดำเนินการแต่ละอย่างเหล่านี้ต้องถูกติดตามโดยระบบ snapshot ทำให้เกิดงานเพิ่มเติมสำหรับระบบไฟล์
APFS snapshot: คุณสมบัติที่ช่วยให้ระบบไฟล์สามารถจับภาพสถานะของไฟล์ ณ จุดเวลาใดเวลาหนึ่ง ใช้โดย Time Machine สำหรับการสำรองข้อมูล
การดำเนินการ Parallel I/O ประสบปัญหาบน APFS
ปัญหาสำคัญอีกประการหนึ่งคือวิธีที่ APFS จัดการการดำเนินการ input/output แบบขนานในไดเรกทอรีเดียวกัน ซึ่งแตกต่างจากระบบไฟล์อื่นๆ ที่สามารถจัดการ process หลายตัวที่อ่านและเขียนไฟล์พร้อมกันได้อย่างมีประสิทธิภาพ APFS ดูเหมือนจะมีปัญหากับ workload ประเภทนี้ สิ่งนี้สร้างคอขวดเมื่อเครื่องมือพัฒนาสมัยใหม่พยายามเร่งการดำเนินการโดยทำงานกับหลายไฟล์พร้อมกัน
ปัญหานี้รุนแรงเป็นพิเศษเพราะทั้ง Git และ package manager อย่าง npm และ pnpm ได้รับการออกแบบให้ทำงานกับหลายไฟล์แบบขนาน เมื่อเครื่องมือเหล่านี้พบคอขวดของระบบไฟล์ ประโยชน์ด้านประสิทธิภาพจากการประมวลผลแบบขนานจะถูกยกเลิกอย่างสมบูรณ์
ปัจจัยเปรียบเทียบประสิทธิภาพ:
- ปัญหาของ APFS : ภาระเพิ่มเติมจาก snapshot การคอขวดของ parallel I/O การล็อค directory
- ปัญหาของ Windows : ตัวกรองระบบไฟล์ การสแกนของ Windows Defender ความเข้ากันได้ของชื่อไฟล์ 8.3
- ข้อได้เปรียบของ Linux : การจัดการ parallel I/O ที่ดีกว่า การดำเนินการระบบไฟล์ในพื้นหลังที่น้อยกว่า
- การทดสอบการดำเนินการ: การทำความสะอาด repository ของ Git การติดตั้ง package manager การดำเนินการไฟล์จำนวนมาก
วิธีแก้ไขชั่วคราวให้ผลลัพธ์ที่หลากหลาย
นักพัฒนาได้ค้นพบวิธีแก้ไขชั่วคราวหลายวิธี แม้ว่าแต่ละวิธีจะมีข้อแลกเปลี่ยน บางคนแยกไดเรกทอรีพัฒนาของตนออกจากการสำรองข้อมูล Time Machine ซึ่งสามารถปรับปรุงประสิทธิภาพได้ แต่จะลบไฟล์สำคัญออกจากการป้องกันการสำรองข้อมูล คนอื่นๆ หันไปใช้ virtual machine ของ Linux หรือ Docker container แม้ว่าวิธีการนี้อาจแนะนำ overhead ด้านประสิทธิภาพของตัวเอง
ฉันแยก node_modules และโฟลเดอร์ dependency อื่นๆ ออกจากการสำรองข้อมูล แต่โปรเจกต์เป็นสิ่งสำคัญที่ฉันต้องการ ฉันอาจมี repo ออนไลน์ แต่มักจะมี branch ในเครื่องที่ฉันต้องการให้สำรองข้อมูลโดยอัตโนมัติ
วิธีแก้ไขชั่วคราวที่รุนแรงที่สุดเกี่ยวข้องกับการใช้ RAM disk หรือระบบไฟล์เฉพาะภายใน virtual machine เพื่อหลีกเลี่ยง APFS ทั้งหมด แม้ว่าจะมีประสิทธิภาพ แต่โซลูชันเหล่านี้ต้องการความรู้ทางเทคนิคอย่างมากและอาจทำให้ workflow การพัฒนาซับซ้อนขึ้น
วิธีแก้ปัญหาชั่วคราวทั่วไปสำหรับปัญหาประสิทธิภาพระบบไฟล์ของ macOS:
- ยกเว้นไดเรกทอรีการพัฒนาจากการสำรองข้อมูล Time Machine
- ใช้เครื่องเสมือน Linux สำหรับงานพัฒนา
- ใช้ RAM disk สำหรับการดำเนินการไฟล์ชั่วคราว
- ใช้ Docker กับ OverlayFS (แม้ว่าจะอาจมีภาระเพิ่มเติมของตัวเอง)
- กำหนดค่าการยกเว้นซอฟต์แวร์รักษาความปลอดภัยสำหรับไดเรกทอรีการพัฒนา
Windows และ Linux แสดงประสิทธิภาพที่ดีกว่า
การทดสอบเปรียบเทียบเผยให้เห็นว่าการดำเนินการที่คล้ายกันบนระบบ Windows และ Linux เสร็จสิ้นเร็วกว่าบน macOS อย่างมาก สิ่งนี้บ่งชี้ว่าปัญหาเฉพาะเจาะจงกับวิธีที่ macOS จัดการการดำเนินการระบบไฟล์ มากกว่าที่จะเป็นปัญหาของเครื่องมือพัฒนาเอง
อย่างไรก็ตาม สถานการณ์ไม่ได้ชัดเจนทั้งหมด ระบบ Windows ยังสามารถประสบปัญหาประสิทธิภาพเมื่อซอฟต์แวร์รักษาความปลอดภัยหรือตัวกรองระบบไฟล์ทำงานอยู่ ความแตกต่างที่สำคัญคือสิ่งเหล่านี้มักสามารถกำหนดค่าหรือปิดใช้งานชั่วคราวได้ ในขณะที่ลักษณะประสิทธิภาพของ APFS ถูกสร้างเข้าไปในระบบไฟล์เอง
ผลกระทบที่กว้างขึ้นต่อการพัฒนา
ปัญหาประสิทธิภาพเหล่านี้มากกว่าแค่ความไม่สะดวก พวกมันกำลังส่งผลกระทบต่อผลิตภาพของนักพัฒนาในทางที่วัดได้ การดำเนินการง่ายๆ ที่ควรใช้เวลาเป็นวินาทีสามารถยืดเยื้อเป็นนาที และการ build ที่ซับซ้อนหรือการติดตั้ง dependency สามารถช้าลงจนห้ามใจ
ปัญหานี้เน้นให้เห็นความตึงเครียดที่กว้างขึ้นระหว่างแนวทางปฏิบัติการพัฒนาสมัยใหม่และการออกแบบระบบไฟล์ เครื่องมือพัฒนาในปัจจุบันได้รับการปรับให้เหมาะสมสำหรับการทำงานกับไฟล์ขนาดเล็กหลายพันไฟล์แบบขนาน แต่ระบบไฟล์ไม่จำเป็นต้องได้รับการออกแบบโดยมี use case นี้เป็นลำดับความสำคัญ เมื่อ workflow การพัฒนายังคงพัฒนาต่อไป ประสิทธิภาพระบบไฟล์สำหรับ workload เฉพาะเหล่านี้จึงมีความสำคัญมากขึ้น
Package manager: เครื่องมืออย่าง npm, pnpm และ yarn ที่ดาวน์โหลดและจัดการ software dependency สำหรับโปรเจกต์พัฒนาโดยอัตโนมัติ
อ้างอิง: disk-perf-git-and-pnpm