mySQL error.log

Cześć wszystkim.

Mam problem z serwerem mySQL.
Serwer działa koszmarnie wolno a log błędów puchnie jak szalony. Dostawca komercyjnego oprogramowania twierdzi, że błędy w logu świadczą tylko o tym, że serwer działa prawidłowo a cały problem leży po stronie komputera który ja przygotowałem.
Baza uruchomiona jest na wirtualnej maszynie na Hyper-V z Ubuntu 18.4 LTS (zgodnie z zaleceniami producenta programu).
Załączam log błędów serwera.
Czy dostawca programu ma rację i ja coś skopałem?

Proszę znawców baz danych o wypowiedź i poradę.

Pozdrawiam,
Wojtek

A baza skonfigurowana zgodnie z zaleceniami dostawcy? W logach widać, że jest problem z zalogowaniem na konta użytkowników bazodanowych:

[Note] Access denied for user '1T6ZYVIXM82RJTBK'@'192.168.1.101' (using password: YES)
[Note] Access denied for user 'BWGU80SKAZSK9350'@'192.168.1.101' (using password: NO)
[Note] Access denied for user 'BWGU80SKAZSK9350'@'192.168.1.113' (using password: NO)
[Note] Access denied for user 'BWGU80SKAZSK9350'@'192.168.1.134' (using password: NO)
[Note] Access denied for user 'BWGU80SKAZSK9350'@'192.168.1.162' (using password: NO)
[Note] Access denied for user 'BWGU80SKAZSK9350'@'192.168.1.172' (using password: NO)
[Note] Access denied for user 'MPE5KY2R8W97CFNG'@'192.168.1.162' (using password: NO)
[Note] Access denied for user 'MPE5KY2R8W97CFNG'@'192.168.1.162' (using password: YES)
[Note] Access denied for user 'U73QF3YADWCEKIAA'@'192.168.1.134' (using password: YES)
[Note] Access denied for user 'ZCABEVJV2BWVVRHS'@'192.168.1.113' (using password: YES)
[Note] Access denied for user 'e2client'@'10.8.0.6' (using password: NO)
[Note] Access denied for user 'root'@'192.168.1.101' (using password: NO)
[Note] Access denied for user 'root'@'192.168.1.101' (using password: YES)
[Note] Access denied for user 'root'@'192.168.1.113' (using password: NO)
[Note] Access denied for user 'root'@'192.168.1.113' (using password: YES)
[Note] Access denied for user 'root'@'192.168.1.134' (using password: NO)
[Note] Access denied for user 'root'@'192.168.1.134' (using password: YES)
[Note] Access denied for user 'root'@'192.168.1.162' (using password: NO)
[Note] Access denied for user 'root'@'192.168.1.162' (using password: YES)
[Note] Access denied for user 'root'@'192.168.1.172' (using password: NO)
[Note] Access denied for user 'root'@'192.168.1.172' (using password: YES)
[Note] Access denied for user 'root'@'localhost' (using password: NO)
[Note] Access denied for user 'root'@'localhost' (using password: YES)

Dostawca programu chciał, żeby przygotować "gołego" ubuntu z sambą. Całą resztę konfiguracji, czyli zainstalowanie serwera mysql, konfiguracja i odtworzenie bazy z backupu robili serwisanci dostawcy.
Przesłałem im dzisiaj ten plik i stwierdzili, że wszystko jest ok, a problem leży po mojej stronie bo z komputerem jest coś nie tak.

Ubuntu dostał 5 GB ram i 4 rdzenie. W htop widać jak co 0,50-1 minuty pojawiają się skoki obciążenia jednego rdzenia na 100% i trwa to jakieś 4-8 sekund.
Jest 5 komputerów klienckich, które łączą się z bazą. A obciążenie przez klientów jest znikome.

Skoro problem jest powtarzalny, to można próbować analizować i zrozumieć co się dzieje i dlaczego.

1. Który proces żre 100% CPU?
2. Co w tym czasie robi problematyczny proces? Może czekać na coś bardzo aktywnie, może coś liczyć etc. W takich sytuacjach korzystam z narzędzi:

• procstack (zbieram stosy procesu co jakiś czasu, np. sekundę i przez jakiś czas np. przez minutę)
• strace (zbieram przez jakiś czas wszystko co proces robi w kontekście wywołań sytemowych + czasy tych wywołań + co robią procesy sforkowane: strace -f -T -o mojtrejs.txt -p <pid> )
• czasem schodzę na poziom tego co dzieje się w kernelu (czyli długi czas oczekiwania na zakończenie wywołania systemowego, ale nie wiadomo co kernel w tym czasie robi w kwestii obsługi wywołania)

Alternatywnie można wyjść od konfiguracji MySQLa i zastanowić się, które parametry można zmodyfikować by było lepeij. Pokaż konfigurację tego MySQla.

ja bym stawiał, że masz jakiegoś syfa w sieci, który próbuje się dostać do bazy (wnioskuję z danych jakie są używane do logowania). Miałem raz przypadek, że na słabo zabezpieczonym serwerze ktoś kopalnie bitcoinów odpalił :/.

Proces mysql żre 100%.
Config w załączniku.

abrakadaber napisał(a):

ja bym stawiał, że masz jakiegoś syfa w sieci, który próbuje się dostać do bazy (wnioskuję z danych jakie są używane do logowania). Miałem raz przypadek, że na słabo zabezpieczonym serwerze ktoś kopalnie bitcoinów odpalił :/.

Jak sprawdziłem przez MySQL Workbench ci użytkownicy są w bazie. Producent twierdzi, że to normalne że użytkownicy najpierw próbują się logować an konto root bazy.

No i załącznik

Nie jestem specjalistą od mysqla, więc te zmiany InnoDB mogą nie zdziałać cudów i nie rozwiążą problemów, ale wklejony plik konfiguracyjny sugeruje, że baza jedzie na jakichś domyślnych wartościach.

Może zrób sobie backup tej konfiguracji, zmodyfikuj wartości dla inno db, zrestartuj bazę i zobacz czy poszło ku lepszemu.

innodb_buffer_pool_size = 3G  
innodb_buffer_pool_size_instances = 16
innodb_file_per_table = ON
innodb_log_buffer_size = 16M
innodb_log_file_size = 2G
innodb_thread_concurrency=8

Możesz też zapytać dostawcę dlaczego nie optymalizował tych ustawień inno db, ewentualnie, które parametry bazy są inne niż domyślne ;)

Możesz też sobie włączyć logowanie zapytań powolnych, bądź takich, które nie korzystają z indeksów:

slow_query_log		= 1
slow_query_log_file	= /var/log/mysql/mysql-slow.log
long_query_time = 2
log-queries-not-using-indexes

edycja:

1. Sugeruję zmiany konfiguracji dla InnoDB dlatego, że logi mówią tak "2019-12-11T0648.123183Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4397ms. The settings might not be optimal. (flushed=8 and evicted=0, during the time.)"
2. Logowanie "wolnych zapytań", może dostarczyć dodatkowych informacji o tym, czy któreś query nie działa wybitnie powoli.
3. innodb_log_file_size=2GB - jest bez sensu wartością i "dobrą" wartość możesz dobrać na podstawie "workloadu" jaki masz na tej bazie -> https://www.percona.com/blog/2008/11/21/how-to-calculate-a-good-innodb-log-file-size/

Dzięki za sugestie i pomysły. Wprowadzę zmiany w konfiguracji i rano zobaczę czy jest poprawa.