Wysokie użycie procesora MySQL [zamknięte]

191

Ostatnio mój procesor serwera jest bardzo wysoki.

Średnie obciążenie procesora 13,91 (1 min) 11,72 (5 min) 8,01 (15 min), a moja witryna odnotowała jedynie niewielki wzrost ruchu.

Po uruchomieniu górnego polecenia zobaczyłem, że MySQL używa 160% procesora!

Ostatnio optymalizuję tabele i przełączyłem się na trwałe połączenia. Czy może to powodować, że MySQL używa dużej ilości procesora?

mysql cpu-usage

— Juddling
źródło

Trwałe połączenia prawie zawsze nie są dobrym rozwiązaniem.

— jason

Zdejmę je teraz i uważam na różnicę, ponieważ nigdy nie pamiętam, że procesor był powyżej 2 miesięcy temu!

— Juddling,

Serwery mają zwykle więcej niż jeden rdzeń. Procent wykorzystania procesora jest obliczany w odniesieniu do jednego rdzenia, inny oznacza, że proces wykorzystujący maksymalnie dwa rdzenie będzie zużywał 200% procesora. Tutaj MySQL używa do 100% jednego rdzenia i 60% innego rdzenia. Nie oznacza to, że wszystkie procesory są zużyte, najprawdopodobniej nadal ma co najmniej dwa wolne procesory.

— xaav

Wysoki procesor prawie zawsze oznacza nieefektywne zapytania. Rozwiązuje się je zwykle poprzez lepsze indeksowanie (zwłaszcza „złożone”) i / lub przeformułowanie zapytania.

— Rick James,

Odpowiedzi:

265

Najpierw powiedziałbym, że prawdopodobnie chcesz wyłączyć trwałe połączenia, ponieważ prawie zawsze wyrządzają więcej szkody niż pożytku.

Po drugie, powiedziałbym, że chcesz dokładnie sprawdzić użytkowników MySQL, aby upewnić się, że nikt nie może połączyć się ze zdalnego serwera. Jest to także ważna kwestia bezpieczeństwa do sprawdzenia.

Po trzecie, powiedziałbym, że chcesz włączyć dziennik wolnych zapytań MySQL, aby mieć oko na wszelkie zapytania, które zajmują dużo czasu, i użyj go, aby upewnić się, że nie masz żadnych zapytań blokujących tabele kluczy zbyt długo.

Inne rzeczy, które można sprawdzić, to uruchomienie następującego zapytania, gdy obciążenie procesora jest wysokie:

SHOW PROCESSLIST;

Spowoduje to wyświetlenie zapytań, które są aktualnie uruchomione lub w kolejce do uruchomienia, co to jest zapytanie i co robi (to polecenie skróci zapytanie, jeśli jest zbyt długie, możesz użyć POKAŻ PEŁNĄ PROCESLISTĘ, aby zobaczyć pełny tekst zapytania) .

Warto również, aby mieć oko na takie rzeczy jak swojej wielkości bufora, stół cache , cache zapytań i innodb_buffer_pool_size (jeśli używasz tabel InnoDB), a wszystkie te alokacji pamięci może mieć wpływ na wydajność zapytań, które mogą doprowadzić do MySQL zjedz procesor.

Prawdopodobnie zechcesz także przeczytać poniższe, ponieważ zawierają one dobre informacje.

Bardzo dobrym pomysłem jest również użycie profilera. Coś, co możesz włączyć, kiedy chcesz, to pokaże, jakie zapytania są uruchomione przez twoją aplikację, jeśli są duplikaty zapytań, jak długo je zajmują itp. Itp. Przykładem czegoś takiego jest to, nad którym pracuję, nazywane PHP Profiler, ale jest ich wiele. Jeśli używasz oprogramowania takiego jak Drupal, Joomla lub Wordpress, zechcesz zapytać w społeczności, ponieważ prawdopodobnie są dla nich dostępne moduły, które pozwalają uzyskać te informacje bez konieczności ręcznej integracji.

— Steven Surowiec
źródło

dziękuję bardzo za to, usunąłem trwałe połączenia, a następnie skonfigurowałem dziennik wolnych zapytań. przeczytałem dziennik i większość zapytań pochodziła z dwóch tabel, a tabele nie zostały poprawnie zindeksowane! minęło tylko około 10 minut, ale oto wynik: średnie obciążenie procesora 0,48 (1 minuta) 0,95 (5 minut) 2,42 (15 minut) dzięki bardzo

— Juddling

ten sam problem, rozwiązany przez indeksowanie tabel, które spowalniają proces, dziękuję Steven i Juddling

— gabrielem

@ Juddling Czy mógłbyś rozwinąć sposób indeksowania tabeli? Może jakiś link? Wiem, że minęło trochę czasu, ale jestem naprawdę nowy w tej sprawie. Przepraszam za pytanie noobish

— JayVDiyk

Rejestrowanie wolnych zapytań pomogło mi znaleźć szczególny problem wysokiego wykorzystania procesora. W moim przypadku była to wtyczka Wordpress (ultimate-tag-cloud-widget), która przy każdym trafieniu wykonywała monstrualne zapytanie, aby pokazać popularne tagi. To świetna wtyczka, ale należy ją wzbogacić o buforowanie (skończyłem dostosowywać ją, aby rozwiązać problem).

— jkincali

Kolejną rzeczą, która pomogła w innym problemie, była modyfikacja parametru innodb_buffer_pool_size wspomnianego powyżej. Próbując znaleźć przyczynę wysokiego wykorzystania procesora, przeczytałem gdzieś, że innodb_buffer_pool_size powinien mieć przynajmniej rozmiar pliku ibdata1, który znajduje się w / var / lib / mysql. Wygląda na to, że InnoDB działa o wiele wydajniej, gdy może być rezydentem w pamięci. W niektórych sytuacjach może to być trudne, ponieważ ibdata1 może być ogromny! Sugerowano również, aby gdzie innodb_log_buffer_size miał 25% wielkości innodb_buffer_pool_size.

— jkincali

167

Ponieważ jest to najwyższy post, jeśli używasz wysokiego obciążenia procesora lub obciążenia MySQL, dodam dodatkową odpowiedź:

1 lipca 2012 r. Dodano sekundę przestępną do aktualnego czasu UTC, aby zrekompensować spowolnienie obrotu Ziemi z powodu pływów. Podczas uruchamiania ntp (lub ntpd) ta sekunda została dodana do zegara twojego komputera / serwera. MySQLd wydaje się nie lubić tej dodatkowej sekundy w niektórych systemach operacyjnych i zapewnia duże obciążenie procesora. Szybka poprawka to (jako root):

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

— RedPixel
źródło

Ponieważ oryginalny post powstał około 3 lata temu, wątpię, aby był przyczyną problemu z oryginalnym postem. Ale to była przyczyna mojego problemu i właśnie mnie uratował - dziękuję! Więcej informacji: blog.mozilla.org/it/2012/06/30/…

— Russell G

Ten sam problem i rozwiązanie dla mnie na Ubuntu 12.04. Kroki do rozwiązania nieco inaczej: service ntp stop && date -s " date" && service ntp start Wykorzystanie procesora MySQL natychmiast spadło z 50 - 100% do 0 - 1%

— David Laing

Czy można to wykonać tylko dla pewności? To znaczy, czy bezpiecznie jest go uruchomić, nawet jeśli nie jest to przyczyną?

— Muhammad Gelbana,

1 lipca 2015 r. - Właśnie doświadczyłem tego bardzo skokowego drugiego błędu na bieżącym serwerze AWS EC2 z systemem Amazon Linux. Użyj sudo service ntpd stopw tej konfiguracji.

— Matt van Andel

+1 za to rozwiązanie. Mój MySQL działał na poziomie 50-60% przez wiele miesięcy bez powodu, po zastosowaniu tego rozwiązania spadł do teraz 0,0-0,3% i tak właśnie powinno być. Wielkie dzięki.

— zeeshan

Jeśli ten serwer jest widoczny dla świata zewnętrznego, warto sprawdzić, czy ma wiele żądań połączenia ze świata zewnętrznego (tj. Osób próbujących się do niego włamać)

— Rowland Shaw
źródło

Nie jestem pewien, dlaczego przyciągnęło to anonimowe zdanie, ponieważ w przeszłości było to przyczyną niektórych systemów.

— Rowland Shaw

Myślę, że głosowanie w dół jest spowodowane tym, że posiadanie MySQL widocznego dla świata zewnętrznego nie jest dobrym pomysłem.

— MikeKulls,

@MikeKulls Nie, to nie jest dobry pomysł, ponieważ będzie działał jako cel dla wielu osób, aby spróbować uzyskać dostęp, co da duże obciążenie procesora - stąd moja odpowiedź jako jeden z możliwych powodów.

— Rowland Shaw,

Nienawidzę tego, gdy ktoś po prostu oddaje głos i idzie!

— Muhammad Gelbana,

+1, ponieważ jest to absolutnie uzasadniony powód, dla którego MySQL ma wysokie użycie procesora, a każdy, dla kogo jest to odpowiedź, naprawdę naprawdę potrzebuje tych informacji!

— Chris Browne,