การใช้งาน CPU สูงของ MySQL [ปิด]

191

ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้

ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นไปตามหัวข้อสำหรับ Stack Overflow

ปิดให้บริการใน8 ปีที่ผ่านมา

เมื่อเร็ว ๆ นี้ซีพียูเซิร์ฟเวอร์ของฉันสูงมาก

ค่าเฉลี่ยของโหลด CPU 13.91 (1 นาที) 11.72 (5 นาที) 8.01 (15 นาที) และไซต์ของฉันมีปริมาณการใช้เพิ่มขึ้นเล็กน้อย

หลังจากรันคำสั่งด้านบนฉันเห็นว่า MySQL ใช้ CPU 160%!

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

mysql cpu-usage

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

การเชื่อมต่อแบบต่อเนื่องเป็นเกือบเสมอไม่ได้เป็นสิ่งที่เหมาะสมกับการใช้งาน

— jason

ฉันจะถอดมันออกแล้วดูความแตกต่างเพราะฉันจำไม่ได้ว่าซีพียูอยู่เหนือ 2 เดือนที่แล้ว!

— Juddling

เซิร์ฟเวอร์มักจะมีมากกว่าหนึ่งคอร์ เปอร์เซ็นต์การใช้ CPU คำนวณจากหนึ่งคอร์ซึ่งเป็นอีกหนึ่งกระบวนการที่ใช้สองคอร์อย่างสมบูรณ์จะมีการใช้งาน CPU 200% ที่นี่ MySQL ใช้ 100% ของคอร์หนึ่งและอีก 60% ของคอร์อื่น นั่นไม่ได้หมายความว่าซีพียูทั้งหมดจะถูกใช้หมดไปเป็นไปได้ว่าเขายังคงมีซีพียูฟรีอย่างน้อยสองตัว

— xaav

CPU สูงมักหมายถึงการค้นหาที่ไม่มีประสิทธิภาพ โดยทั่วไปจะได้รับการแก้ไขผ่านการจัดทำดัชนีที่ดีขึ้น (โดยเฉพาะ 'คอมโพสิต') และ / หรือปฏิรูปการสืบค้น

— Rick James

คำตอบ:

265

ก่อนอื่นฉันจะบอกว่าคุณอาจต้องการปิดการเชื่อมต่อแบบต่อเนื่องเนื่องจากพวกเขามักทำอันตรายมากกว่าดี

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

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

สิ่งอื่น ๆ ที่คุณสามารถตรวจสอบได้คือการเรียกใช้แบบสอบถามต่อไปนี้ในขณะที่โหลด CPU สูง:

SHOW PROCESSLIST;

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

นอกจากนี้คุณยังจะต้องการที่จะเก็บตาในสิ่งที่ต้องการขนาดบัฟเฟอร์ของคุณแคชตาราง , แคชแบบสอบถามและinnodb_buffer_pool_size (ถ้าคุณกำลังใช้ InnoDB ตาราง) เป็นทั้งหมดของจัดสรรหน่วยความจำเหล่านี้สามารถมีผลกระทบต่อประสิทธิภาพการทำงานแบบสอบถามซึ่งสามารถทำให้เกิด MySQL เพื่อ กินซีพียู

คุณอาจต้องการอ่านต่อไปนี้เนื่องจากมีข้อมูลที่ดี

เป็นความคิดที่ดีมากในการใช้ profiler บางสิ่งที่คุณสามารถเปิดได้เมื่อคุณต้องการซึ่งจะแสดงให้คุณเห็นว่าแบบสอบถามของคุณกำลังทำงานอยู่หากมีข้อความค้นหาที่ซ้ำกันใช้เวลานานเท่าใด ฯลฯ ฯลฯ ตัวอย่างของสิ่งนี้คือสิ่งที่ฉันกำลังทำงานอยู่PHP Profilerแต่มีมากมายออกมี หากคุณกำลังใช้ซอฟต์แวร์บางส่วนเช่น Drupal, Joomla หรือ Wordpress คุณจะต้องถามถึงภายในชุมชนเนื่องจากอาจมีโมดูลสำหรับพวกเขาที่ช่วยให้คุณได้รับข้อมูลนี้โดยไม่จำเป็นต้องรวมอะไรด้วยตนเอง

— Steven Surowiec
แหล่งที่มา

ขอบคุณมากสำหรับสิ่งนี้ฉันลบการเชื่อมต่อแบบถาวรและตั้งค่าบันทึกการสืบค้นที่ช้า ฉันอ่านบันทึกและแบบสอบถามส่วนใหญ่มาจากสองตารางและตารางไม่ได้รับการจัดทำดัชนีอย่างถูกต้อง! จะได้รับเพียงประมาณ 10 นาที แต่นี่คือผลที่ได้: ค่าเฉลี่ยโหลด CPU 0.48 (1 นาที) 0.95 (5 นาที) 2.42 (15 นาที) ขอบคุณมาก

— Juddling

ปัญหาเดียวกันแก้ไขโดยสร้างดัชนีตารางที่ทำให้กระบวนการช้าลงขอบคุณสตีเว่นและจัดลิ่ง

— gabrielem

@ Juddling คุณช่วยอธิบายวิธีการจัดทำดัชนีตารางได้ไหม? บางทีลิงก์บางอัน? ฉันรู้ว่ามันได้รับในขณะที่ แต่ฉันใหม่จริง ๆ กับสิ่งนี้ ขออภัยด้วยคำถามที่ไม่มี

— เสียงรบกวน

การบันทึกการสืบค้นที่ช้าช่วยให้ฉันพบปัญหาการใช้งาน CPU สูงโดยเฉพาะ ในกรณีของฉันมันเป็นปลั๊กอิน Wordpress (สุดยอดแท็กเมฆ - วิดเจ็ต) ซึ่งกำลังทำแบบสอบถามที่ยิ่งใหญ่ที่มีการกดทุกครั้งเพื่อแสดงแท็กยอดนิยม มันเป็นปลั๊กอินที่ยอดเยี่ยม แต่ต้องได้รับการปรับปรุงด้วยการแคชบางอย่าง (ฉันลงเอยด้วยการปรับแต่งเพื่อแก้ไขปัญหาของฉัน)

— jkincali

อีกสิ่งหนึ่งที่ช่วยแก้ไขปัญหาที่แตกต่างคือแก้ไขพารามิเตอร์ innodb_buffer_pool_size ที่กล่าวถึงข้างต้น ในขณะที่พยายามค้นหาสาเหตุของการใช้งาน CPU สูงฉันอ่านบางแห่งที่ innodb_buffer_pool_size ควรมีขนาดอย่างน้อยขนาดของไฟล์ ibdata1 ซึ่งอยู่ใน / var / lib / mysql ดูเหมือนว่า InnoDB จะทำงานได้อย่างมีประสิทธิภาพมากขึ้นเมื่อสามารถอยู่ในหน่วยความจำได้ นี่อาจเป็นเรื่องยากที่จะทำในบางสถานการณ์เพราะ ibdata1 มีขนาดใหญ่มาก! นอกจากนี้ยังแนะนำบางแห่งเพื่อให้แน่ใจว่า innodb_log_buffer_size คือ 25% ของขนาดของ innodb_buffer_pool_size

— jkincali

167

เนื่องจากนี่คือโพสต์อันดับต้น ๆ ถ้าคุณ google สำหรับการใช้งาน CPU สูงหรือโหลดฉันจะเพิ่มคำตอบเพิ่มเติม:

ในวันที่ 1 กรกฎาคม 2012 มีการเพิ่มวินาทีกระโดดในเวลา UTC ปัจจุบันเพื่อชดเชยการหมุนของโลกที่ช้าลงเนื่องจากกระแสน้ำ เมื่อรัน ntp (หรือ ntpd) วินาทีนี้จะถูกเพิ่มลงในนาฬิกา / เซิร์ฟเวอร์ของคอมพิวเตอร์ของคุณ ดูเหมือนว่า MySQLd จะไม่ชอบวินาทีพิเศษนี้ในบางระบบปฏิบัติการและให้ผลการโหลดซีพียูสูง การแก้ไขอย่างรวดเร็วคือ (เป็น root):

$ /etc/init.d/ntpd stop
$ date -s "`date`"
$ /etc/init.d/ntpd start

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

เนื่องจากโพสต์ต้นฉบับเมื่อประมาณ 3 ปีที่แล้วฉันสงสัยว่ามันเป็นสาเหตุของปัญหาโปสเตอร์ต้นฉบับ แต่มันเป็นสาเหตุของปัญหาของฉันและช่วยฉันตอนนี้ - ขอบคุณมาก! ข้อมูลเพิ่มเติม: blog.mozilla.org/it/2012/06/30/…

— Russell G

ปัญหาเดียวกันและวิธีแก้ปัญหาสำหรับฉันบน Ubuntu 12.04 ขั้นตอนในการแก้ปัญหาที่แตกต่างกันเล็กน้อย: บริการ ntp stop && date -s " date" && service ntp เริ่มการใช้งาน CPU CPU ทันทีลดลงจาก 50 - 100% ลงเหลือ 0 - 1%

— David Laing

สามารถดำเนินการนี้เพื่อให้แน่ใจเท่านั้นหรือไม่ ฉันหมายความว่ามันปลอดภัยหรือไม่ที่จะใช้มันแม้ว่าจะไม่ใช่เหตุผลหรือไม่

— มูฮัมหมัด Gelbana

1 กรกฎาคม 2558 - ฉันเพิ่งพบกับข้อผิดพลาดครั้งที่สองบนเซิร์ฟเวอร์ AWS EC2 ปัจจุบันที่ใช้ Amazon Linux ใช้sudo service ntpd stopในการกำหนดค่านี้

— Matt van Andel

+1 สำหรับโซลูชันนี้ MySQL ของฉันทำงานที่ 50-60% เป็นเวลาหลายเดือนโดยไม่มีเหตุผลหลังจากใช้โซลูชันนี้ลงไปที่ 0.0-0.3% ซึ่งเป็นวิธีที่ควรจะเป็น ขอบคุณมาก.

— zeeshan

หากเซิร์ฟเวอร์นี้สามารถมองเห็นได้จากโลกภายนอกก็ควรตรวจสอบว่ามีคำขอมากมายที่จะเชื่อมต่อจากโลกภายนอก (เช่นคนที่พยายามจะบุกเข้าไป)

— Rowland Shaw
แหล่งที่มา

ไม่แน่ใจว่าทำไมสิ่งนี้ดึงดูด downvote ที่ไม่ระบุชื่อเนื่องจากนี่เป็นสาเหตุในอดีตสำหรับบางระบบ

— Rowland Shaw

ฉันคิดว่าคะแนนโหวตลงเนื่องจากการมี MySQL ที่สามารถมองเห็นได้จากโลกภายนอกไม่ใช่ความคิดที่ดี

— MikeKulls

@ MikeKulls ไม่มันไม่ใช่ความคิดที่ดีเพราะมันจะทำหน้าที่เป็นเป้าหมายสำหรับผู้คนจำนวนมากที่จะลองและเข้ามาซึ่งจะทำให้ซีพียูโหลดสูง - ดังนั้นคำตอบของฉันก็เป็นหนึ่งในเหตุผลที่เป็นไปได้

— Rowland Shaw

ฉันเกลียดเมื่อมีคนลงคะแนนและไป!

— มูฮัมหมัด Gelbana

+1 เพราะนี่เป็นเหตุผลที่ถูกต้องสำหรับ MySQL ที่มีการใช้งาน CPU สูงและทุกคนที่นี่คือคำตอบจริงๆไม่ต้องการข้อมูลนี้!

— Chris Browne