Недавно столкнулся с такой проблемой и решил здесь поделиться решением, которое нашел в интернете. Вкратце опишу, где встретилась такая ошибка: на сайте есть модуль парсера, сначала он собирает данные, а затем загружает их в инфоблоки. Так вот малое количество данных успешно загружалось, а вот большое на строке с CIBlockElement::GetList выдавало ошибку "MySQL server has gone away". Не сразу понял в чем дело, но в итоге разобрался - MySQL сбрасывал соединение, т.к. долго не было подключения к базе после подключения к серверу (или как-то так, не силен в терминологии). В общем решение вот такое - в файле "bitrix/php_interface/after_connect.php" нужно добавить строку:
$DB->Query("SET wait_timeout=28800");
Число в скобках - это количество секунд ожидания подключения.
Зайцев Артемий, не проверял, точно нет - его отключали при первичной настройке сервера из расчета, что при 32 Гб ОЗУ он не нужен, при том, что никогда больше 8 не было занято. По крайней мере, в моем случае решение с таймаутом сработало, тем более оно логично.
О, наконец таки я нашел решение этой проблемы. у меня КП битрикс 24 коробочная версия, в один прекрасный момент, оказался бэкапиться средствами самого портала. скрипт бэкапа вываливался с ошибкой MySQL server has gone away. две с половиной недели бодания с саппортом, ни к чему не привели. саппорт в итоге вообще сказал что это не их проблема, типа решайте сами. при этом mysqldump отлично создавал полный бамп базы. на своп не как-то не обращал внимания, так как сервер никогда не забивал доступные ему 2 гига. даже при запуске скрипта бэкапа, немного выползал за гиг. когда подключил своп (оказалось что у свопа сменился UUID и он тупо не понтировался при старте), то оказалось что при работе скрипта, сервер нехило так залазит в своп. по истине в битриксе работают марсиане.
Зайцев Артемий, О, наконец таки я нашел решение этой проблемы. у меня КП битрикс 24 коробочная версия, в один прекрасный момент, оказался бэкапиться средствами самого портала. скрипт бэкапа вываливался с ошибкой MySQL server has gone away. две с половиной недели бодания с саппортом, ни к чему не привели. саппорт в итоге вообще сказал что это не их проблема, типа решайте сами. при этом mysqldump отлично создавал полный бамп базы.
на своп не как-то не обращал внимания, так как сервер никогда не забивал доступные ему 2 гига. даже при запуске скрипта бэкапа, немного выползал за гиг. когда подключил своп (оказалось что у свопа сменился UUID и он тупо не понтировался при старте), то оказалось что при работе скрипта, сервер нехило так залазит в своп. по истине в битриксе работают марсиане.
Роман Козин , виртуальная машина Битрикса так настроена, что под буферы и кеши выделено определенное гарантированное количество памяти. Причем эти настройки меняются автоматически, когда вы меняете объем памяти и перезагружаете сервер.
Но если вы посмотрите графики munin на любом действующем сайте, вы увидите что виртуальная машина регулярно чуть-чуть использует свап-диск и в этом нет ничего страшного.
Зайцев Артемий, в использовании свапа нет ничего хорошего. он очень замедляет работу. что собственно логично. в идеале, свап не должен использоваться вообще. он должен быть только для того, что бы в случае непредвиденного повышения нагрузки, сервер не ушел в анабиоз выжрав всю память. на счет автодостройки bitrix env я в курсе. пришлось допиливать ее кастомными конфигами, что бы оно не выжирало бесконтрольно память с залезанием в своп.
Козин Роман написал: на счет автодостройки bitrix env я в курсе. пришлось допиливать ее кастомными конфигами, что бы оно не выжирало бесконтрольно память с залезанием в своп.
Хмелёв Борис, А тут бесполезно делиться, все зависит от ресурсов сервера и нагрузок. Основной фактор на жор памяти оказывает параметр innodb_buffer_pool_size. В докумеентации рекомендуется устанавливать его в 70 - 80% от общей RAM на сервере. Но тут нужно еще учитывать, что если в БД находится на том же сервере где и сам битрикс с apache и прочими сервисами, то в зависимости от нагрузки нужно учитывать и их потребности. Но исходя из моей практики, параметр innodb_buffer_pool_size на высоко нагруженных базах, должен быть не меньше чем размер используемой БД. Если размер БД 15 гигов, то и этот параметр желательно делать не меньше 15 гигов. Но опять же все индивидуально, если эти ваши 15 гигов использует 1,5 человека, то оно нормально будет работать и на двух гигах RAM Еще полезно позапускать mysqltuner, и следать его рекомендациям. Собственно функционал этого тюнера имеется и в адмнке битрикса.
Целый день не могу проблему решить, все говорят о параметрах в php.ini и в my.conf, но в моем случае это ни к чему не приводит. В логах так же инфы нет. Может кто-то сталкивался с подобным и есть альтернативные варианты решения? Спасибо.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».