Linux ที่มีหน่วยความจำ 256GB / 48 Cores - เครื่องเริ่มการฟาดฟัน / สำลักโดยมีหน่วยความจำเหลืออยู่มากมาย

12

เครื่อง: Dell r815, CentOS 5.4, RAM 256GB, 4 x 12 คอร์

เรามีแอปพลิเคชั่นที่มีไฟล์ 275GB มันทำหน้าที่แทนข้อมูล 20GB ต่อครั้งนั่นคือมันสลับบิตไปรอบ ๆ และแทนที่มันในไฟล์เดียวกัน ทั้งหมดนี้ทำงานได้ดี

มีการส่งครั้งสุดท้ายที่อ่านไฟล์ทั้งหมดแล้วทำการเรียงลำดับในกลุ่มข้อมูลขนาด 20GB และส่งออกไปยังไฟล์ใหม่ทั้งหมด

กระบวนการนี้ดูเหมือนว่าจะทำงานได้ไม่นานและจะมีการล้างข้อมูลออกจากดิสก์ประมาณ 50GB หลังจากนี้บางสิ่งบางอย่างเครื่อง WHOLE เริ่มหลุดออกมา

คำสั่งง่ายๆเช่นps -ef, ls -alวางสายนานและแสดงว่ารับ CPU 100% (ซึ่งเป็นเพียงแกนเดียว)

เมื่อดูสถิติของหน่วยความจำtopฉันเห็นว่ามันใช้ RAM ขนาด 120GB (ฟรี 128GB) และมี 120GB ภายใต้ส่วน "แคช"

มีใครเคยเห็นพฤติกรรมแบบนี้มาก่อนหรือไม่ กระบวนการเดียวกันนี้ทำงานได้ดีบนเครื่องที่มีหน่วยความจำ 64GB ดังนั้นฉันคิดว่ามันเกี่ยวข้องกับการติดตั้ง RAM ที่ฉันมีในเครื่อง

(อย่างที่เราพูดไปผมกำลังทดสอบกับเครื่องนี้ด้วยทั้งหมดยกเว้น 64GB เพื่อตัดปัญหาฮาร์ดแวร์)

ฉันอาจจะหายตัวไปจาก vm params /etc/sysctrl.confบ้างไหม?

ขอบคุณ!

linux centos memory

— aspitzer
แหล่งที่มา

ดิสก์กำลังทำอะไรอยู่ .. คุณกำลังเข้าสู่แดนนรก ????

— Arenstar

เคอร์เนล 64 บิต / แอป / etc? คุณพูดถึงซีพียู 100% ค่าเฉลี่ยของโหลดเมื่อมันเกิดขึ้นมันเป็นแอพมัลติเธรด (มันจะไม่ใช้โปรเซสเซอร์ทั้งหมดถ้าไม่) สิ่งที่ vmstat 4 บอกคุณ (io / cpu โดยเฉพาะ)

— coredump

สิ่งนี้เช่น "ps" คือ 100% cpu เกิน 4800% (เพราะ 48 cores) - ดังนั้น io หรือสิ่งที่ถูกปิดกั้นส่วนใหญ่ ค่าเฉลี่ยของการโหลดบนกล่องจะเหมือนกับ 5. ดิสก์ซึ่งเป็นสถานะ

— โซลิด

เครื่องไม่ได้ทำการแลกเปลี่ยนเลย

— aspitzer

1

ใช่ .. ใช้งานด้วย 64gb ตอนนี้ ควรทราบภายในหนึ่งชั่วโมงหากเกี่ยวข้องกับจำนวน mem ทั้งหมดในเครื่อง

— aspitzer

12

คำถามของคุณทำให้ฉันนึกถึงสิ่งที่ฉันอ่านเมื่อเร็ว ๆ นี้:

http://jcole.us/blog/archives/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/

สิ่งนี้กล่าวถึงวิธีที่ NUMA มีสถาปัตยกรรม (เช่นคุณอาจพบว่าระบบ 48 แกน AMD) ส่งผลกระทบต่อการจัดสรรหน่วยความจำและการสลับเปลี่ยน ฉันไม่รู้ว่านี่คือสิ่งที่คุณกำลังเจอหรือไม่ แต่มันฟังดูเหมือนกันมากพอที่จะคุ้มค่ากับการอ่าน

แม้ว่ามันจะไม่ใช่คำตอบมันก็ทำให้การอ่านมีเสน่ห์

— larsks
แหล่งที่มา

1

ดูเหมือนจะเป็นคำถามที่คุ้มค่าสำหรับปัญหานี้ และมันเป็นการอ่านที่มหัศจรรย์

— coredump

1

นั่นคือการอ่านที่ดีและซ็อกเก็ต 4 อัน, RAM 256Gb = 64Gb ต่อโหนดและดูเหมือนว่าจะเป็นที่ที่คุณประสบปัญหาซึ่งทำซ้ำสถานการณ์ในเอกสารอย่างแน่นอน

— Mark Henderson

12

ดังนั้นนี่จึงเป็นข้อผิดพลาดของเคอร์เนลใน 64bit Centos 5.4 และ 64 บิต Fedora 14. หลังจากที่ฉันติดตั้ง Centos 5.5 แล้วปัญหาก็หายไป

ขออภัยฉันไม่มีคำตอบที่ดีกว่าสำหรับทุกคน ...

— aspitzer
แหล่งที่มา

1

เฮ้ชายถ้านั่นคือสิ่งที่ได้รับการแก้ไขนั่นคือสิ่งที่ได้รับการแก้ไข ทำเครื่องหมายด้วยตัวคุณเองเพื่อให้คนอื่นสามารถเรียนรู้จากความยากลำบากของคุณ :-)

— mfinni

0

คุณสามารถลองเพิ่มบรรทัดใน /etc/sysctl.conf เพื่อระบุว่า swap นั้นจะใช้เมื่อจำเป็นจริงๆเท่านั้น

swappiness = 0

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

— NginUS
แหล่งที่มา

มีการตั้งค่าไว้แล้ว ... แต่อย่างที่ฉันได้กล่าวไปแล้วว่ามี 128GB ฟรี - ดังนั้นจึงไม่ตีปัญหาการแลกเปลี่ยนใด ๆ

— aspitzer

0

พื้นที่ชั่วคราวของคุณอยู่ที่ไหน บ่อยครั้งที่มันอยู่ใน tempfs Tempfs ดึงพื้นที่จากหน่วยความจำที่สำรองไว้โดย swap space ดังนั้นหากคุณจบลงด้วยสิ่งที่มากเกินไปใน tempfs มันจะทริกเกอร์ swap I / O

เมื่อพิจารณาถึงขนาดของข้อมูลที่คุณกำลังผสานฉันคาดว่าจะมีความรวดเร็วเมื่อคุณเข้าสู่การรวมขั้นสุดท้าย

การกระจายที่เก็บข้อมูล swap ของคุณในหลาย ๆ ดิสก์อาจช่วยได้

— BillThor
แหล่งที่มา

0

แม้ว่าคุณจะไม่ได้กดปุ่มแลกเปลี่ยนคุณอาจยังคงถูกผูกไว้กับ I / O ข้อมูล ls แนะนำสิ่งนี้

ฉันจะดูผลลัพธ์ของdstat -dfการแสดงสถิติดิสก์หรือdstat -af(ใช่มันจะเป็นคอลัมน์ bajillion กว้างนี่คือสิ่งที่เกิดขึ้นเมื่อคุณมี 48 คอร์และแสดงการใช้งาน CPU ในพวกเขาทั้งหมด) ถ้าคุณต้องการที่จะเห็นมันทั้งหมด

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

— Slartibartfast
แหล่งที่มา