Zbyt duże obciążenie pamięci przez MySQL

[Pitu 160]

Witam

 

Mam dość poważny problem. Nie mam pojęcia co się dzieje lecz od kilku dni co ok. 30min. - 1h zużycie pamięci sięga 100% ca za tym idzie zapycha się swap. Load skacze to bardzo dużych wartości.

 

Screen z htop

 

 

Mój my.cnf

 

[mysqld]
bind-address=127.0.0.1
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
query_cache_limit=1M
query_cache_size=32M
query_cache_type=1
max_connections=200
max_user_connections=600
interactive_timeout=100
wait_timeout=100
connect_timeout=10
thread_cache_size=128
key_buffer=128M
join_buffer_size=2M
max_allowed_packet=32M
table_cache=2000
sort_buffer_size=2M
read_buffer_size=2M
read_rnd_buffer_size=1536K
max_connect_errors=10
thread_concurrency=4
myisam_sort_buffer_size=64M
skip-locking
server-id=1

[mysql.server]
user=mysql
basedir=/var/lib

[safe_mysqld]
bind-address=127.0.0.1
err-log=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
open_files_limit=8192
SAFE_MYSQLD_OPTIONS=”–defaults-file=/etc/my.cnf
–log-slow-queries=/var/log/slow-queries.log”

#[mysqldump]
#quick
#max_allowed_packet=16M

[mysql]
no-auto-rehash

[isamchk]
key_buffer=128M
sort_buffer=128M
read_buffer=32M
write_buffer=32M

[myisamchk]
key_buffer=128M
sort_buffer=128M
read_buffer=32M
write_buffer=32M

[mysqlhotcopy]
interactive-timeout

 

 

CentOS 9.5 + Plesk

2x2,8GHz

2GB RAM

[Damian. 0]

zle zoptymalizowany mysql, niestety ja ci nie pomogę bo w optymalizacjach nie jestem za dobry

[Gość squeezer]

Cóż, ja akurat optymalizacją się zajmuję, ale także, na ten moment, wiele więcej nie jestem w stanie powiedzieć.

 

Z tego co widać na screenie, wisi Ci sporo wątków, czyli sporo połączeń. Pytanie, jak wygląda "normalne" zużycie pamięci? To może działać w obie strony - jedno ciężkie (albo nieoptymalne) zapytanie przytyka serwer, co przekłada się na wzrost liczby zapytań czekających na wykonanie, co przekłada się na wzrost zapotrzebowania na pamięć, co przekłada się na zwolnienie serwera, co przekłada się... I tak dalej.

Może też być w drugą stronę - w "normalnej" pracy pamięci jest na styk i jeśli chwilowo do serwera połączy się większa ilość klientów, to tej pamięci zaczyna brakować, co powoduje zwolnienie działania serwera, co powoduje... I tak dalej.

 

Zacznij od tego, żeby sprawdzić co konkretnie jest przyczyną problemu. Z konfiguracji wynika że slowlogi powinieneś mieć włączone. Jeśli nie masz, to włącz. Ustaw także zmienną long_query_time=1 - będą się logować zapytania o czasie wykonywania dłuższym niż 1 sekunda. Zobacz w slowlogu co się złapało. Sprawdź EXPLAINem plan tych zapytań. Jeśli brakuje indeksów, dodaj. Jeśli zapytania są nieoptymalne, przepisz je. Monitoruj zużycie pamięci w czasie, zrzucaj sobie co pewien czas (np. co 5 minut) także listę procesów. Jeśli w slowlogu wszystko będzie ok, to tak zbierane informacje pomogą sprawdzić, czy wzrost obciążenia bazy bierze się z większej odwiedzalności, czy też nie jest to połączone.

[beliq 442]

Pamiętaj o tym, że MySQL rezerwuje pewną ilość pamięci per połączenie.

W związku z tym jeśli masz np. 500 połączeń do bazy, które się utrzymują constant, to zasadniczo niezależnie od konfiguracji

będziesz miał duże użycie pamięci. Optymalizacja zapytań może nic nie dać. Trzeba będzie dołożyć pamięci do serwera i przejść na system x86_64.

 

Jeśli masz dużo połączeń, a uważasz, że niekoniecznie jest to uzasadnione, to sprawdź na liście procesów co ten MySQL tak naprawdę robi.

Może się okazać, że architektura jednego z zapytań jest trefna, wykonuje się ono długo, a efektem tego jest utrzymywanie

przez kilkadziesiąt sekund wszystkich przychodzących żądań w fazie oczekiwania na obsługę.