MySQL yüksek CPU kullanımı [kapalı]

191

Son zamanlarda sunucu CPU'm çok yükseliyor.

CPU yükü ortalama 13,91 (1 dk) 11,72 (5 dk) 8,01 (15 dk) ve sitemde trafikte sadece hafif bir artış oldu.

Bir üst komut çalıştırdıktan sonra, MySQL'in% 160 CPU kullandığını gördüm!

Son zamanlarda tabloları optimize ediyorum ve kalıcı bağlantılara geçtim. Bu MySQL'in yüksek miktarda CPU kullanmasına neden olabilir mi?

mysql cpu-usage

— Juddling
kaynak

Kalıcı bağlantılar neredeyse her zaman kullanılacak doğru şey değildir.

— jason

Ben şimdi onları çıkarmak ve bir fark için izleyeceğim çünkü cpu bir ay önce 2 yukarıda olmak asla hatırlamıyorum!

— 09:33

Sunucular birden fazla çekirdeğe sahip olma eğilimindedir. CPU kullanımı yüzdesi bir çekirdeğe göre hesaplanır, başka bir deyişle iki çekirdeği tamamen kullanan bir işlemin CPU kullanımı% 200 olur. Burada, MySQL bir çekirdeğin% 100'ünü ve başka bir çekirdeğin% 60'ını kullanıyor. Bu, tüm CPU'ların tükendiği anlamına gelmez, büyük olasılıkla hala en az iki boş CPU'ya sahiptir.

— xaav

Yüksek CPU neredeyse her zaman verimsiz sorgular anlamına gelir. Bunlar genellikle daha iyi indeksleme (özellikle 'bileşik') ve / veya sorgunun yeniden düzenlenmesi yoluyla çözülür.

— Rick James

Yanıtlar:

265

Öncelikle kalıcı bağlantıları kapatmak istediğinizi söyleyebilirim, çünkü neredeyse her zaman yarardan daha fazla zarar verirler.

İkincisi, MySQL kullanıcılarınızı iki kez kontrol etmek istediğinizi söyleyebilirim, sadece uzak bir sunucudan kimsenin bağlantı kurmasının mümkün olmadığından emin olmak için. Bu da kontrol edilmesi gereken önemli bir güvenlik şeyidir.

Üçüncüsü , uzun süren sorgulara göz atmak için MySQL Yavaş Sorgu Günlüğünü açmak istediğinizi ve anahtar tabloları çok uzun süre kilitleyen sorguların olmadığından emin olmak için bunu kullanmak istediğinizi söyleyebilirim .

Kontrol edebileceğiniz diğer bazı şeyler, CPU yükü yüksekken aşağıdaki sorguyu çalıştırmak olacaktır:

SHOW PROCESSLIST;

Bu, o anda çalışmakta olan sorguları veya çalıştırılacak kuyrukları, sorgunun ne olduğunu ve ne yaptığını gösterir (bu komut çok uzunsa sorguyu keser, tam sorgu metnini görmek için TAM İŞLEMİ GÖSTER seçeneğini kullanabilirsiniz) .

Ayrıca, arabellek boyutlarınız, tablo önbelleğiniz , sorgu önbelleğiniz ve innodb_buffer_pool_size (innodb tabloları kullanıyorsanız) gibi tüm bellek ayırmalarının MySQL'in CPU yemek.

Ayrıca, bazı iyi bilgiler içerdiklerinden muhtemelen aşağıdakileri de okumak isteyebilirsiniz.

Profiler kullanmak da çok iyi bir fikir. İstediğinizde açabileceğiniz bir şey, uygulamanızın hangi sorguları çalıştırdığını, yinelenen sorgular varsa, ne kadar sürdüğünü vb. Gösterecektir. Bunun gibi bir örnek üzerinde çalıştığım bir örnek PHP Profiler ama orada çok var. Drupal, Joomla veya Wordpress gibi bir yazılım parçası kullanıyorsanız, topluluk içinde sormak isteyeceksiniz, çünkü muhtemelen onlar için herhangi bir şeyi manuel olarak entegre etmenize gerek kalmadan bu bilgileri almanıza izin veren modüller vardır.

— Steven Surowiec
kaynak

Bunun için çok teşekkürler, kalıcı bağlantıları kaldırıldı ve sonra yavaş sorgu günlüğü ayarlayın. günlüğü okumak ve sorguların çoğu iki tablodan geldi ve tablolar düzgün dizin değildi! sadece 10 dakika oldu ama sonuç şu: CPU yük ortalamaları 0.48 (1 dk) 0.95 (5 dakika) 2.42 (15 dakika) çok teşekkürler

— Juddling

aynı sorun, süreci yavaşlatan tabloları endeksleyerek çözüldü, teşekkür ederim Steven ve Juddling

— gabrielem

@Juddling Bir tabloyu nasıl endeksleyeceğinizi açıklayabilir misiniz lütfen? Belki bir bağlantı? Bir süre geçtiğini biliyorum, ama bu konuda gerçekten yeniyim. Noobish soru üzgünüm

— JayVDiyk

Yavaş sorguları günlüğe kaydetme, yüksek CPU kullanımıyla ilgili özel sorunumu bulmama yardımcı oldu. Benim durumumda, sadece popüler etiketleri göstermek için her isabetle korkunç bir sorgu yapan bir Wordpress eklentisi (ultimate-tag-cloud-widget) idi. Bu harika bir eklenti, ancak bir tür önbellekleme ile artırılması gerekiyor (Sorunumu çözmek için özelleştirme sona erdi).

— jkincali

Farklı bir soruna yardımcı olan başka bir şey, yukarıda belirtilen innodb_buffer_pool_size parametresini değiştirmekti. Yüksek CPU kullanımının nedenini bulmaya çalışırken, innodb_buffer_pool_size dosyasının en azından / var / lib / mysql dosyasında bulunan ibdata1 dosyasının boyutu olması gerektiğini bir yerde okudum. Görünüşe göre InnoDB bellekte ikamet edebildiği zaman çok daha verimli çalışıyor. Bazı durumlarda bunu yapmak zor olabilir, çünkü ibdata1 çok büyük olabilir! Ayrıca innodb_log_buffer_size'nin innodb_buffer_pool_size boyutunun% 25'i olduğundan emin olmak için bir yere önerildi.

— jkincali

167

Bu, MySQL yüksek CPU kullanımı veya yüklemesi için google için üst yazı olduğundan ek bir cevap ekleyeceğim:

1 Temmuz 2012'de, gelgit nedeniyle dünyanın yavaşlayan dönüşünü telafi etmek için geçerli UTC saatine bir saniye saniye eklendi. Ntp (veya ntpd) çalıştırılırken bu saniye bilgisayarınızın / sunucunuzun saatine eklenir. MySQLd, bazı işletim sistemlerinde bu ekstra saniyeyi sevmiyor gibi görünüyor ve yüksek bir CPU yükü veriyor. Hızlı düzeltme (kök olarak):

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

— RedPixel
kaynak

Orijinal yazı yaklaşık 3 yıl önce olduğundan, orijinal posterin probleminin nedeni olduğundan şüpheliyim. Ama sorunumun sebebi buydu ve beni şimdi kurtardı - çok teşekkürler! Daha fazla bilgi: blog.mozilla.org/it/2012/06/30/…

— Russell G

Ubuntu 12.04'te benim için aynı sorun ve çözüm. Biraz farklı çözüm adımları: servis ntp stop && date -s " date" && service ntp start MySQL CPU kullanımı anında% 50 - 100'den% 0 - 1'e düştü

— David Laing

Bu yalnızca emin olmak için yürütülebilir mi? Yani, nedeni olmasa bile çalıştırmak güvenli midir?

— Muhammad Gelbana

1 Temmuz 2015 - Amazon Linux çalıştıran bir AWS EC2 sunucusunda bu çok büyük ikinci hatayı yaşadım. sudo service ntpd stopBu yapılandırmada kullanın .

— Matt van Andel

Bu çözüm için +1. MySQL aylarca hiçbir neden olmadan% 50-60 oranında çalışıyordu, bu çözümü uyguladıktan sonra şimdi% 0.0-0.3'e kadar düştü, olması gerektiği gibi. Çok teşekkürler.

— zeeshan

Bu sunucu dış dünya tarafından görülebiliyorsa, dış dünyadan bağlanmak için çok fazla istek olup olmadığını kontrol etmeye değer (yani, bu sunucuya girmeye çalışan insanlar)

— Rowland Shaw
kaynak

Geçmişte bazı sistemler için bunun bir nedeni olduğu düşünüldüğünde, bunun neden anonim bir aşağılık çektiğinden emin değilim.

— Rowland Shaw

Sanırım aşağı oy, MySQL'in dış dünyaya görünür olması iyi bir fikir değil.

— MikeKulls

@MikeKulls Hayır, pek çok insanın giriş yapması ve giriş yapması için bir hedef olarak hareket edeceği için iyi bir fikir değil, bu da yüksek bir CPU yükü verecek - bu yüzden cevabım olası bir sebep olarak.

— Rowland Shaw

Birisi sadece aşağı oy ve gitme nefret ediyorum!

— Muhammad Gelbana

+1 çünkü MySQL'in yüksek CPU kullanımına sahip olması kesinlikle meşru bir nedendir ve bunun cevabı olan herkes gerçekten bu bilgiye ihtiyaç duyar!

— Chris Browne