ตัวอธิบายไฟล์เปิดสูงสุดที่ใช้ได้จริง (ulimit -n) สำหรับระบบที่มีปริมาณสูง

เมื่อเร็ว ๆ นี้เราเริ่มโหลดการทดสอบแอปพลิเคชันของเราและสังเกตว่าไฟล์นั้นไม่มีตัวอธิบายไฟล์หลังจากผ่านไปประมาณ 24 ชั่วโมง

เรากำลังเรียกใช้ RHEL 5 ใน Dell 1955:

CPU: 2 x Dual Core 2.66GHz 4MB 5150/1333FSB RAM: 8GB RAM HDD: ฮาร์ดไดรฟ์ SATA 2 x 160GB 2.5 "

ฉันตรวจสอบขีด จำกัด ตัวให้คำอธิบายไฟล์และตั้งไว้ที่ 1024 พิจารณาว่าแอปพลิเคชันของเราอาจมีการเชื่อมต่อขาเข้าประมาณ 1,000 ครั้งรวมถึงการเชื่อมต่อขาออก 1,000 ครั้งดูเหมือนจะค่อนข้างต่ำ ไม่ต้องพูดถึงไฟล์จริงใด ๆ ที่ต้องเปิด

ความคิดแรกของฉันคือการเพิ่มพารามิเตอร์ ulimit -n เพียงไม่กี่คำสั่งจากนั้นทำการทดสอบอีกครั้ง แต่ฉันอยากรู้ว่าการตั้งค่าตัวแปรนี้สูงเกินไปหรือไม่

มีวิธีปฏิบัติที่ดีที่สุดในการตั้งค่านี้นอกเหนือจากการหาว่าตัวอธิบายไฟล์จำนวนเท่าใดซอฟต์แวร์ของเราสามารถเปิดตามทฤษฎีได้หรือไม่?

ข้อ จำกัด เหล่านี้มาจากเวลาที่ผู้ใช้ "ปกติ" หลายคน (ไม่ใช่แอป) จะแชร์เซิร์ฟเวอร์และเราต้องการวิธีในการปกป้องพวกเขาจากการใช้ทรัพยากรมากเกินไป

มันต่ำมากสำหรับเซิร์ฟเวอร์ที่มีประสิทธิภาพสูงและโดยทั่วไปเราตั้งให้เป็นจำนวนที่สูงมาก (24k หรือมากกว่านั้น) หากคุณต้องการตัวเลขที่สูงกว่าคุณต้องเปลี่ยนตัวเลือก sysctl file-max (จำกัด โดยทั่วไปคือ 40k บน Ubuntu และ 70k บน rhel)

การตั้งค่า ulimit:

# ulimit -n 99999

Sysctl ไฟล์สูงสุด:

#sysctl -w fs.file-max=100000

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

คุณทำได้เสมอ

cat /proc/sys/fs/file-nr

ระหว่างสถานการณ์ 'โหลดสูง' เพื่อดูว่ามีไฟล์ descriptor จำนวนเท่าใดที่ใช้งานอยู่

ค่าสูงสุด - ขึ้นอยู่กับว่าคุณกำลังทำอะไร

หาก file descriptors เป็น tcp sockets ฯลฯ คุณมีความเสี่ยงในการใช้หน่วยความจำจำนวนมากสำหรับบัฟเฟอร์ซ็อกเก็ตและเคอร์เนลวัตถุอื่น ๆ หน่วยความจำนี้จะไม่สามารถถอดเปลี่ยนได้

แต่อย่างอื่นไม่ในหลักการจะไม่มีปัญหา ศึกษาเอกสารของเคอร์เนลเพื่อลองหาจำนวนหน่วยความจำเคอร์เนลที่จะใช้และ / หรือทดสอบ

เรารันเซิร์ฟเวอร์ฐานข้อมูลที่มีตัวอธิบายไฟล์ ~ 10k เปิด (ส่วนใหญ่เป็นไฟล์ดิสก์จริง) โดยไม่มีปัญหาใหญ่ แต่เป็น 64- บิตและมี ram มากมาย

การตั้งค่า ulimit นั้นเป็นแบบต่อกระบวนการ แต่ก็มีข้อ จำกัด ทั้งระบบเช่นกัน (32k ฉันคิดว่าเป็นค่าเริ่มต้น)

ฉันไม่ได้ตระหนักถึงการปฏิบัติที่ดีที่สุดใด ๆ เป็นการส่วนตัว มันค่อนข้างเป็นอัตวิสัยขึ้นอยู่กับฟังก์ชั่นระบบ

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

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

นี่เป็นคำถามข้อหนึ่งที่ฉันตอบได้ดีที่สุดกับ "ทดสอบในสภาพแวดล้อมการพัฒนา" ฉันจำได้หลายปีที่ผ่านมาซันรู้สึกกระวนกระวายใจเมื่อคุณทำสิ่งนี้ แต่ไม่ประหม่า ตอนนี้มันมีขีด จำกัด ที่ 1024 ดังนั้นฉันก็แปลกใจเล็กน้อยที่เห็นว่าตอนนี้มันเหมือนกันสำหรับ Linux ดูเหมือนว่ามันควรจะสูงกว่านี้

ฉันพบลิงค์ต่อไปนี้เกี่ยวกับการศึกษาเมื่อฉันค้นหาคำตอบสำหรับคำถามของคุณ: http://www.netadmintools.com/art295.html

และอันนี้ก็ยัง: https://stackoverflow.com/questions/1212925/on-linux-set-maximum-open-files-to-unlimited-possible