Usterki połączenia PHP/MYSQL pod dużym obciążeniem przez mysql.sock

Question

Zrobiłem sporo czytania przed pytaniem o to, więc pozwól mi wstępnie powiedzieć, że nie kończą mi się połączenia, pamięć lub procesor, i co mogę powiedzieć, nie kończą mi się też deskryptory plików.

Oto co PHP rzuca się na mnie, kiedy MySQL jest pod dużym obciążeniem:

nie można połączyć się z lokalnego serwera MySQL poprzez gniazdo „/var/lib/mysql/mysql.sock” (11 „Zasoby chwilowo niedostępne ")

Dzieje się to przypadkowo pod obciążeniem - ale im częściej naciskam, tym częściej php wyrzuca mi to. Podczas gdy tak się dzieje, zawsze mogę połączyć się lokalnie za pomocą konsoli i od PHP do 127.0.0.1 zamiast "localhost", który używa szybszego gniazda unix.

Oto kilka zmiennych systemowych aby wyeliminować typowe problemy:

cat /proc/sys/fs/file-max = 4895952 
lsof | wc -l = 215778 (during "outages") 

Najwyższa wykorzystanie dostępnych połączeń: 26% (261/1000)

InnoDB rozmiar puli bufora/data: 10,0 g/3,7 g (o wiele pokój)

• miękkie nofile 999999
• trudno nofile 999999

Jestem rzeczywiście działa MariaDB (wersja Server: 10.0.17-MariaDB MariaDB Server)

Wyniki te są generowane zarówno przy normalnym obciążeniu, i uruchamiając mysqlslap poza godzinami pracy, tak, powolne zapytania nie są problem - tylko wysokie połączenia.

Każda rada? Mogę zgłosić dodatkowe ustawienia/dane w razie potrzeby - mysqltuner.pl mówi, że wszystko jest w porządku -

i znowu, odkrywcza rzecz polega na tym, że łączenie się przez IP działa dobrze i jest szybkie podczas tych przerw - po prostu nie mogę dowiedzieć się, dlaczego.

Edycja: tutaj jest mój my.ini (niektóre wartości mogą wydawać się nieco wysoki z moich ostatnich zmian dotyczących rozwiązywania problemów, a należy pamiętać, że nie ma żadnych błędów w dziennikach MySQL, logi systemowe, lub dmesg)

socket=/var/lib/mysql/mysql.sock 
skip-external-locking 
skip-name-resolve 
table_open_cache=8092 
thread_cache_size=16 
back_log=3000 
max_connect_errors=10000 
interactive_timeout=3600 
wait_timeout=600                        
max_connections=1000 
max_allowed_packet=16M 
tmp_table_size=64M 
max_heap_table_size=64M 
sort_buffer_size=1M 
read_buffer_size=1M 
read_rnd_buffer_size=8M 
join_buffer_size=1M 
innodb_log_file_size=256M 
innodb_log_buffer_size=8M 
innodb_buffer_pool_size=10G 

[mysql.server] 
user=mysql 

[mysqld_safe] 
log-error=/var/log/mysqld.log 
pid-file=/var/run/mysqld/mysqld.pid 
open-files-limit=65535 

Answer 1

Najprawdopodobniej jest to spowodowane net.core.somaxconn Jaka jest wartość /proc/sys/net/core/somaxconn

net.core.somaxconn 

# The maximum number of "backlogged sockets". Default is 128. 

połączeń w kolejce, które nie są jeszcze podłączone. Każda rzecz nad tą kolejką zostanie odrzucona. Podejrzewam to w twojej sprawie. Spróbuj zwiększyć to w zależności od obciążenia.

metę jako użytkownik root

echo 1024 > /proc/sys/net/core/somaxconn 

Answer 2

Jest to coś, co może i powinno zostać rozwiązane przez analizę. Nauka, jak to zrobić, jest wielką umiejętnością.

Analiza, aby dowiedzieć się, co dzieje się pod dużym obciążeniem ... liczba zapytań, czas wykonania powinien być pierwszym krokiem. Określ obciążenie, a następnie wprowadź odpowiednie ustawienia db config. Może się okazać, że musisz zoptymalizować zapytania sql!

Następnie upewnij się, że ustawienia sterownika db db są wyrównane, aby w pełni wykorzystać połączenia z bazą danych.

Oto link do dokumentacji wątków MariaDB. Wiem, że mówi wersja 5.5, ale nadal jest trafna, a strona zawiera wersję 10. Istnieje lista ustawień, które mogą nie znajdować się w pliku .cnf, z którego można korzystać.

https://mariadb.com/kb/en/mariadb/threadpool-in-55/

Answer 3

Z mojej głowie, mogę myśleć o max_connections jako możliwego źródła problemu. Zwiększałbym limit, aby przynajmniej wyeliminować tę możliwość.

Mam nadzieję, że to pomaga.