Сайт размещен на отдельном сервере mac mini
недавно перенесли сайт с одного сервера на другой, поновее с новой ОС OS X El Capitan,
mysql ставил из dmg образа с оф сайта mysql, правда вот под нужную ос еще нету dmg, скачивал под 10.10
Установил, все работало нормально, но потом обнаружились проблемы, периодически при подключении к базе стало выдавать ошибку "2006 mysql server has gone away" (сайт на PHP).
С какого-то момента они начинают сыпаться постоянно. Перезагрузка mysql помогает и сутки, иногда больше, работает все без проблем. Потом все повторяется...
Замечу, что другой сайт тоже перенес точно такой же переезд, и mysql ставил тот же, но при этом он работает без ошибок
Что сервер отключает соединением по таймауту - отклоняем, настройка стоит по умолчанию, т.е. 8 часов... Да и ошибке возникает при первом коннекте в скрипте зачастую.
Пробовал переустанавливать другие версии mysql (5.5, 5.6), но ошибка не пропадает...
в логе ошибок только записи типа:
IP address '5.39.222.253' could not be resolved: nodename nor servname provided, or not known
Непонятно, куда это mysql пытается обратиться...
Сам mysql сервер при этом работает, проверял Uptime - не сбрасывается в моменты ошибок.
Вроде пишут еще либо слишком большие данные либо неверные. Но когда дамп заливал, таких ошибок не выдавало + настройку mac_allowed_packet увеличил до 1Гб

Если все-таки неверный запрос, то как его вычислить
Или какие еще могут быть причины, куда копать?

Akina,

Интересно, а чье же еще сообщение может быть в логах mysql ?

вадя,

и такую ошибку выдавал? вроде в таком случае должен был писать что-то типа "Too many connections"

Проблема все еще актуальна. Если кто может помочь за вознаграждение, прошу откликнуться.
также периодически выдает ошибку во время дампа базы. Пробовал ставить и percona-server из портов.
ошибки начинает выдавать, например, при возрастании нагрузки, если запустить нагрузочное тестирование с помощью утилиты siege на 50 соединениний - однозначно выдаст. При этом в процессах mysqld нагрузку на процессор создает 200-300-500%

Уже бессмысленно... Забыл дополнить, что на нем теперь тоже стала проявляться эта ошибка... На нем нагрузка меньше на порядок, поэтому видимо не проявлялось до поры до времени

Alex_Ustinov,
Вы полагаете, что все таки дело в запросах.
Как тогда объяснить, что такая беда происходит во время дампа
т.е. запускаю mysqldump и во время его выполнения при попытке открыть страницу сайта выдает 2006, причем выдает ее не при каком-то запросе , а еще в момент коннекта (если же клиент mysql попытаться запустить в терминале то описание ошибки другое:
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 102 )

Пока не могу 100% утверждать как отрабатывает бэкап, тестирую на резервном сервере, вроде пока создается полностью, на боевом точно было такое что и mysqldump вылетал , не доделав бэкап)

По поводу штудирования логов
По general - не совсем понятно, что искать... ну иногда, конечно, можно выявить зацикливания какие-нибудь , но тут такого нет... Есть, то что не нравится - к одной таблице пару десятков запросов аналогичных (select * from table where id=x) где id меняется, т.е. в скриптах можно заменить их одним запросом и потом разобрать резульатат в Php, но, врядли, это причина, работало так уже несколько лет и не вызывало проблем...

По медленным:
начала разбирать лог медленных запросов и убирать их вообще из скриптов, сначала вроде все шло неплохо, убрал правда десятка 3 запросов , после чего запускаю нагрузку и вроде сервер деражался, наверно больше получаса работал , хотя до этого при нагрузке выдавал ошибку уже в течение минуты
Потом я запустил еще одну копию siege в 50 потоков, в результате - ошибка. После чего запусал один экземпляр siege и все равно была ошибка...
На следующий день начал все заново, запустил нагрузку - в логах медленных запросов теперь новые запросы появились , убрал и их, снов запустил нагрузку - пока полет нормальный

два часа , полет нормальный
только slow-log продолжает пополняться записями типа:
use...
SET timestamp ...
т.е. даже такие операции выполняются медленно...

Хотя нет, вот ошибки посыпались, возможно и ранее проскакивали, разрешения на файл в котором метка ставится о том что была ошибка сбились, в итоге не видно если проскакивала , пока не посыпались кучей

Akinag_andreyв логе ошибок только записи типа:
IP address '5.39.222.253' could not be resolved: nodename nor servname provided, or not known
Давай начнём поиск источника обнаруженной ошибки (хотя не факт, что это основа, а не следствие более ранней ошибки). А в качестве первого шага попробуй уйти от разрешения адреса в имя через DNS, внеся соотв. запись в HOSTS.
g_andreyчье же еще сообщение может быть в логах mysql ?Если верить поверхностному просмотру результатов поиска, то эта проблема собственно с доступом к MySQL в линуксах и плотно связана с наличием SSH.

Сейчас за это цепляться думаю уже не стоит, таких ошибок пока нет может из-за того, что включены опции skip-networking
, skip_name_resolve - но отключил, пока тоже не появилось

Включил логирование не только ошибок но предупреждений
В итоге в логе вылезли следующие сообщения
[Warning] File Descriptor 1043 exceedeed FD_SETSIZE=1024
Через поиск вышел на статью
https://ellislab.com/blog/entry/mysql-5.7-server-os-x-has-gone-away

Здесь достаточно правдоподобно описано почему так происходит, примерно так: в случае OS X в системной функции, которую использует Mysql для проверки существования соединения есть баг - не отлавливается событие закрытия соединения, т.е. php закрывает соединение , а mysql этого не понимает и считает его открытым
В итоге когда число открытых соединений превышает 1024 ( системное ограничение а не mysql ) то вылетает эта ошибка...
как решение предлагается уменьшить
wait_timeout
interactive_timeout
чтобы сервер закрывал такие соединения
По ощущениям, по поведению сервера - это очень похоже на правду. НО не спасает уменьшение этих параметров....
К тому же, по логике когда появляется эта ошибка, число открытых соединений должно превышать 1024
А как проверяются открытые соединения - наверно, show processlist - выполняю ее непрерывно пока идет тестирование - в результате кол-во процессов не превышает 50 (число создаваемых siege соединений ), т.е. и близко не 1024, и как только siege завершает работу в течение нескольких секунд все эти процессы исчезают

g_andrey,

авторtable_cache старое название для переменной table_open_cache, в нем указывается количество открытых таблиц для всех демонов. Увеличение значения приведет к увеличению количества используемых дескрипторов файла. Советуют рассчитывать по формуле: количество одновременных соединений * количество открытых таблиц в соединении. Т.е. для каждого соединения используется свои ячейки из кэша. Для проверки можно запустить mysqltuner.pl

А вот дескрипторы, о которых здесь речь идет - это не могут быть те, число которых у меня превышено ? т.е. если кол-во соединений надо умножить на кол-во открытых таблиц, то вполне может быть что их будет больше 1024

Ну в принципе, про дескрипторы - есть что то похожее на правду:
если выполнять flush tables когда начинает выдавать ошибку то ошибку некоторое время не выскакивает
но с каждым разом запрос "flush tables" выполняется все медленнее и медленнее, при чем медленность выполнения относится не только к запросам mysql, время открывания папок по sftp также увеличивается, через некоторое время по vnc становится уже невозможно зайти
а если выполнить рестарт Mysql то "медляки" пропадают, то есть помимо дескрипторов как будто накапливается что-то еще

Во вложении скрин - вот такая картина - mysql под 300% нагрузки на цп
Ну не ужели не хватает ресурсов, нагрузка средненькая , где-то 3500 посетителей в сутки, 7-8 тыс страниц...
сервер с процессором i7 2.3Ггц, 16гб оперативки, ssd диск..

пытался уже все подряд в memcached пихать - но и то в итоге были провалы при коннекте к Memcache - полсекунды на это уходило...
Может дело и не в Mysql... может опять же это не причина, а следствие, в результате общей нагрузки и mysql не справляется и оттого у него нагрузка 300%... Но с другой стороны, удавалось удерживать ее на уровне, но при этом, отключив, наверное, половину запросов, на другом сервере, послабее

Подскажите куда копать дальше
mysqltuner прогонял - выставлял параметры рекомендуемые - улучшений нет, иногда даже казалось, что еще хуже становится...