Тут другое.
У меня та же самая проблема. Причём наблюдается как в версии 6.4 так и после обновления до 6.6
Так же как и у тебя у меня тоже ошибка выдаётся при записи в таблицу {watchdog}. Причём чаще всего когда я открываю страницу "поиск обновлений". Просто в этом момент записывается много данных в логи, тоесть в ту же таблицу watchdog. Очистка этой таблицы не спасла.
Ещё часто такое бывает на таблицах связанных с кешем.

Итак я по RTFNил и вот что самое живое:

Во первых что говорят сами мускульщики:
http://dev.mysql.com/doc/refman/5.0/en/gone-away.html

Если почитаешь что там написано то эта ошибка может обозначать всё что угодно, вплоть до того что просто по ДНС не найден был хост.

В комментариях к этой статье ещё пишется что беда в том что используется протокол с компрессией.
И даже автор того комментария сделал по этому поводу багрепорт с пометкой некритический и обещался исправить его. Но это было в 2003 году так что всё уже пофиксено.

Самое реально из того что говорят мускулисты:

You can also get these errors if you send a query to the server that is incorrect or too large. If mysqld receives a packet that is too large or out of order, it assumes that something has gone wrong with the client and closes the connection. If you need big queries (for example, if you are working with big BLOB columns), you can increase the query limit by setting the server's max_allowed_packet variable, which has a default value of 1MB. You may also need to increase the maximum packet size on the client end. More information on setting the packet size is given in Section B.1.2.10, “Packet too large”.

An INSERT or REPLACE statement that inserts a great many rows can also cause these sorts of errors. Either one of these statements sends a single request to the server irrespective of the number of rows to be inserted; thus, you can often avoid the error by reducing the number of rows sent per INSERT or REPLACE.

Тоесть возможно что мы пытаемся передать какой то очень большой BLOB от которого MySQL в шоке. Кажется это ближе всего к истине.

Теперь с чем народ сталкивается и кто как считает:
http://drupal.ru/node/16363

И еще один момент (практически во всех версиях при локализации начинает не хватать длины некоторых полей), проявляется это обычно в администраторском интерфейсе при «пейджинговом» выводе, т.е. когда в строку урл дописываются параметры типа ?page=траляля ну и т.п. , пока я не знаю как это обойти и «тупо» увеличиваю длину полей в двух табличках: {accesslog} поля url и path (увеличиваю до 420) - обычно этого хватает,
и в табличке {watchdog} поле referer (увеличиваю до 420).

Батенька, мускул тупо молча обрезает всё что не влезает в поле и безо всяких ошибок. И вообще в админке никак не превысишь лимит в 255 символов.

http://setegnom.com/node/1239

Таблички в базе создаются, но при навигации по страницам выводятся такие ворнинги.
Поискал в Гугле, проблема такая существует. Однозначной причины, а следовательно и решения не нашел.
Предлагают увеличивать max_allowed_packet для MySQL, другие настройки..
Но у меня shared hosting, и управлять настройками mysql я не могу.

Размеры пакетов по умолчанию в опциях измеряются МЕГАБАЙТАМИ. сомневаюсь что пакет записи одной строчки лога может быть таким большим.

Хотя тут (http://drupal.org/node/186384#comment-842324) пишут

Had the same problem. Increasing max_allowed_packet didn't help.
Changing the wait_timeout variable in /var/lib/mysql/my.cnf did help. It defaults to 15 (seconds). Increased it to 45, and MySQL didn't go away anymore.

Есть ещё такое предположенние:
http://xpoint.ru/forums/computers/dbms/mysql/thread/41487.xhtml

Кажется, я нашел источник проблемы: это не php и даже не mysql - это Апач. Исследуя логи, я обнаружил, что ошибка иногда появлялась даже при запросе картинок из админской части - а тут уж ни php, ни mysql ни при чем. Поэтому подозрение упало на Апач. Оставался вопрос, почему проблема возникает только в админке - ведь и админку и юзерскую часть обслуживает один и тот же Апач. В конце концов я нашел причину. Ошибка возникала только в админке потому, что только в админке был .htaccess с AuthType Basic. А в Апаче был включен модуль auth_mysql - похоже, это именно он периодически глючит.

чёта не верится что хтаксес может завалить сервак базы...

Но самое интересное что если посмотреть внимательно на ошибку то мы заметим что во всемх ошибках одна и та же картина:

Тоесть ошибка при запросе записывается запросом в базу. Может из-за этого рекурсивно пакеты разрастаются до гигантских размеров.

Вот ещё есть какой то HOWTO MySql : " Warning: MySQL server has gone away " - Tune MySql to resolve this problem
http://drupal.org/node/259580
Завтра на работа попробую его опробовать.

Аха пасиб. Пойду лобзать

Так что так и не выяснили единый метод решения, что-то много всего))

менять сервер БД в любом случае надо, независимо от решения вопроса с обрывом соединения.

слишком большой пинг - 500мс. сайты с таким пингом до БД жить нормально не смогут.

Коллеги, так как решили данную проблему:

Warning: MySQL server has gone away query: INSERT INTO watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (1, 'php', '%message in %file on line %line.', 'a:4:{s:6:\"%error\";s:12:\"user warning\";s:8:\"%message\";s:119704:\"MySQL server has gone away\nquery: UPDATE cache_update SET data = 'a:16:{s:8:\\"autosave\\";a:10:{s:5:\\"title\\";s:8:\\"Autosave\\";s:10:\\"short_name\\";s:8:\\"autosave\\";s:10:\\"dc:creator\\";s:11:\\"edmund.kwok\\";s:11:\\"api_version\\";s:3:\\"6.x\\";s:17:\\"recommended_major\\";s:1:\\"1\\";s:16:\\"supported_majors\\";s:1:\\"1\\";s:13:\\"default_major\\";s:1:\\"1\\";s:14:\\"project_status in /home/studby/domains/.....

Расскажите пожалуйста, может кто-нибудь может помочь с решением?

У меня вылазит сообщение такое при подключении некоторых модулей.

"gor" wrote:

Альтернативный вариант - добавить следующую строку в файл index.php в самое начало.

error_reporting(1);

После проведения этой рекомендуемой манипуляции изменился лишь вывод Warning-ов. Они теперь не на белом фоне, а красиво выводятся на странице сайта.
Но под ними уже выводится контент хоть.

Всё ещё актуально...:(

Собственно, не так уж и много их дано. Вариант со сменой хостера не актуален, т.к. ошибка появляется и на хосте, и на локалке. Скрывать сообщения - это, я считаю, вообще не правильно. Тем более, что скрывать их не удаётся
У меня лично ошибка вылезает только в одном случае: при включении модуля Update status. Соответственно, есть подозрение на движок а не на хост.

"gor" wrote:

а этот вариант?

Я, конечно, не специалист, но править код CMS, как мне кажется, - далеко не самый лучший вариант. Для того вопросы и задаются, чтобы найти корректное решение. Понимаю, что порой проблемы приходится решать с помощью подобных костылей, спасибо andypost@drupal.org за подсказку. Однако, надеюсь всё же увидеть более корректное решение.

На Друпал.орге эта ошибка - в списке стандартных. Рекомендуют однозначно менять настройки мускула на требуемые Друпалом:

Resources allowed by the default configuration are normally insufficient to run a resource-intensive application (but on the safe side just in case the server is not powerful enough). You must modify the following resource specifications if they are available in your original configuration file, or add them to the configuration file if they are not already specified (because some are not present by default) :

(Important: remember to keep backup files *before* you do anything !!)

GENERAL SPECIFICATIONS:

[mysqld]

port = 3306
socket = /tmp/mysql.sock
skip-locking
key_buffer = 384M
max_allowed_packet = 64M
table_cache = 4096
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 64M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size = 32M

А также настойчиво рекомендуют перейти на InnoDB:

Note: It is assumed here that you are using the InnoDB database tables, as Drupal is a resource intensive application. If you are not using the InnoDB database tables try to change this, in view of the fact that you are getting the "Warning: MySQL server has gone away" - apparently meaning that your setup is resource intensive. Convert MyISAM Tables to InnoDB .

К сожалению далеко не на всех хостингах есть доступ к файлам конфигурации.
Полазал по комментам на drupal.org. Очень (!) много сообщений, что ошибка появляется при активации модуля "update status". Увидел ещё один вариант решения:
Если есть доступ к php.ini - установить в нём "mysqli.reconnect = On".
В моём случае не сработало.

Проблема решена Drupal 6.13 отключением педжинга и модуля "Update status"...

"Kohl" wrote:

Проблема решена Drupal 6.13 отключением педжинга и модуля "Update status"...

у меня тоже решилась отключением модуля

у меня кажется такое проявляется в основном после добавления или обновления модулей.
И кажется решилось заглядыванием в /update.php и выполнением предлагаемого там обновления базы...

хотя я и модуль "Update status" выключал/включал, и модуль "Database logging", и что-то про вывод и логгинг ошибок на admin/settings/error-reporting переключал, и в базе длину полей увеличивал - но кажется сработало таки именно забытое обновление базы.

Странно что про него пишет только отчёт admin/reports/status, а страничка admin/reports/updates - ни слова..

После обновления друпала тоже стала мучать эта ошибка. Всегда появляется при добавление комментария ( причем комментарий добавляется нормально) и иногда при добавление поста. Отключил модуль Update Sataus и модуль Ping. Проблема осталась.
Ошибок вылазит очень много но все они примерно такие
Warning: MySQL server has gone away query: INSERT INTO watchdog (uid, type, message, severity, link, location, referer, hostname, timestamp) VALUES (1, 'php', '<em>MySQL server has gone away\nquery: UPDATE users SET access = 1248875182 WHERE uid = 1</em> в файле <em>/home/****/public_html/includes/database.mysql.inc</em> в строке <em>174</em>.', 2, '', 'http://www.******.***/comment/reply/334', 'http://www.***.***/content/******_0', '93.8*.249.***', 1248875182) in /home/****/public_html/includes/database.mysql.inc on line 174

Добавленно 30.08.2009
Проблему после суток мучения решил. Отключил в модуле xmlsitemap уведомление поисковиков о обновление карты сайта. За сутки пробовал очищать и чистить таблицы кеша, сессий, watchdog и пр. Отключал и включал разные модули.
Экспериментально вычислил этот модуль. Так что проверьте у кого еще ошибка такая есть.

Воюю с той жэ проблемой.

перечитал, переклацал, перепробовал.

Поднялось.

Рецепт:
На хосте вылил и настроил свой php.ini, в котором увеличил памяти запросам, и время выполнения, а такжэ прописал реконнэкт.
Админка сайта значительно оживилась.

Прочитав предыдущий пост, и не обнаружив у себя xmlsitemap, отключил Update status.
Эроры пропали!!! Админка задышала полной грудью. ...ннно... Про апдэйты теперь не узнать.
В php файлы не лазил, эрроры не давил.

Вывод по моему сюжэту:
- кастомизация настроек php.ini рулит
- мой хостер не даёт изначально скриптам исходящего соединения.

Ищю решения вцЭлом.
Хочется чтоб как на локали всё, как чЯсики

У меня однозначно проблема была из-за таймаута при проверке обновлений модуля. Мне повезло, модуль был не нужен.

Пришлось отключить Update Status. И как теперь с этим жить???

кому не помогло выкл модуль "Update status" и модуль "Database logging" , Ping или еще чево там

откл перед всем этим модуль search (мжно уменьшить его кол-во страниц)

когда заработает хрон, все мож вкл, исключ Update

жить без него можно, включ его когда надо апдэйтить модули, после свежего апдэйта говорят и Update с хроном норм живет.

Проблема сходная (впервые возникла весной 2009). По той же ошибке не мог войти в админку. Сам сайт работал нормально.
Идеальное решение конечно было перейти на хостинг с прямым доступом к рекомендованным Drupal.org настройкам, но в моем случае хостер предоставлял услугу только в рамках VPS и пока переходить с виртуального хостинга на нее было не целесообразно.

В итоге на виртуальном хостинге пока в разное время работало только 2 решения:
1. (решение перстало работать на некоторых тарифных планах)проблема была из-за MySQL "wait timeout" (он был 10 секунд). Прямого доступа к php.ini не было и помогла установка модуля Database tweaks, в котором можно было прописать это время (увеличил до 70 сек) и почему-то заработало (пишу "почему-то", т.к. эти параметры лимитируются хостинг-провайдером).

Но через какое-то время из-за этого модуля сайт стал отваливаться с ошибкой я так понял из-за больших пакетов, которые вероятно генерил модуль "Update status" (больше было не кому) пришлось модуль отключить и через PHPMyAdmin увеличить в настройках модуля параметр "max allowed packet" до 24(Мегабайт), а потом снова активировать модуль (через PhpAdmin изменением статуса). Конечно лучше сразу после установки модуля эти параметры задать: и таймаут и максимальный пакет (правда сколь большие значения не задавай, если хостер их лимитировал, то на виртуалке обойти не получится). Очень редко сайт все таки отваливался, но тогда помогало отключение модуля через PhPAdmin-очистка кэша и повторное включение модуля (почему помогало, не знаю).

В итоге сайты какое-то время работали нормально.

2 решение (пока работает). Мигрировал один из сайтов на другой хостинг и там модуль Database tweaks перестал работать (хостер вытянул параметры на аналогичные предшествующей конфигурации, но не заработало). В общем или менять хостинг или настраивать. Попробовал преемник рекомендовванного модуля Drupal tweaks, поначалу у него не нашел настроек таймаута, в итоге не использовал. Позднее понял, что он приемник предыдущего модуля не в полной мере и требуется Database tweaks все-таки подключить, тогда становится доступна вкладка настроек "DB", где эти параметры и изменяются.

В итоге помогла только просьба к хостеру разместить копию php.ini в корневую папку сайта и в ней самому прописать, как предлагали выше в блоке
[MySQL]
mysqli.reconnect = On
После пары обращений к админке, все заработало. Даже удалось обратно подключить "Update status" (пока работает нормально).

P.S. Кстати в моем случае, до исправления проблемы тоже помогало отключение "Update status", на него грешил из-за того, что в нем проблема возникала из-за очень больших запросов к базе (листинг его Warning'ов занимал несколько экранов), хотя модулей на сайте было не так много.

В итоге следить за новыми обновлениями можно было и без его отключения, т.к. по прямой ссылке к /admin/reports/updates после мега списка ошибок можно было увидеть и куски нормальных панелей админки и статус по проверенным модулям (просто все в окружении сверху и снизу мега списков ошибок). Была даже наивная версия (не успел проверить), что если обновить устаревшие модули, то может и запрос от "Update status" будет покороче и система прочихается.

UPD. Уточнил решение 2. т.к. разобрался почему не были доступны настройки DB во вкладках настроек модуля Drupal tweaks.

"ws_admin" wrote:

По той же ошибке не мог войти в админку.

ws_admin, у меня сейчас такая же проблема
Настраиваю новый сайт, подключил модуль CAPTCHA и теперь вместо админки получаю список ошибок
Как мне теперь отключить этот модуль (а может заодно и update модуль) без админки? Можно как-то напрямую в базе данных или через какой-то друпаловский скрипт?
Ума не приложу, как теперь без админки что-то на сайте делать

Сносить все и заново устанавливать не хотелось бы...
К тому же нет гарантии, что подобное не повторится

такая же проблема появилась после добавления модуля виз.редактирования. вкл/выкл не помогало
сделал так :
В файле
includes/database.mysql.inc
в конце функции db_connect(), под строкой "SET NAMES" вставить:
mysql_query('SET SESSION wait_timeout = 60', $connection);
В файле
includes/database.mysqli.inc
в конце функции db_connect(), под строкой "SET NAMES" вставить:
mysqli_query($connection, 'SET SESSION wait_timeout = 60');
проблема исчерпана

TroYReall, спасибо.
Только последний твой пост помог решить проблему.
Теперь и апдейт и лог - всё четко работает.

тоже только отключения update status помогает

Этот ответ хостинга РБК помог решить проблему. Поднял память до 128мб и другие настройки получше. Тем более они в php.ini уже по умолчанию лежали в корне аккаунта, нужно было только строчку в .htaccess дописать
Работает все достаточно бодро с кучей модулей, кстати http://gamepart.ru
Пол дня перебирал куда уезжать с РБК, в итоге - пока остаюсь, а там посмотрим) Раньше у них бывали проблемы но последнее время лучше стало (у меня там 3 сайта на друпале)

Пришел к такому же решению:

"Omeh2003" wrote:

Проблему после суток мучения решил. Отключил в модуле xmlsitemap уведомление поисковиков о обновление карты сайта.

"TroYReall" wrote:

такая же проблема появилась после добавления модуля виз.редактирования. вкл/выкл не помогало
сделал так :
В файле
includes/database.mysql.inc
в конце функции db_connect(), под строкой "SET NAMES" вставить:
mysql_query('SET SESSION wait_timeout = 60', $connection);
В файле
includes/database.mysqli.inc
в конце функции db_connect(), под строкой "SET NAMES" вставить:
mysqli_query($connection, 'SET SESSION wait_timeout = 60');
проблема исчерпана

Алилуйяяя

"Korsarchik" wrote:

Алилуйяяя

И каждый раз при обновлении править модуль?

Добавление в ~/public_html/.htaccess

# php_value max_allowed_packet 64M
# php_value wait_timeout 288000
# php_value max_execution_time 288000
# php_value mysqli.reconnect 1

давало ошибку сервера, поискал, нашел такое объяснение:

Установка и настройка http://dev.1c-bitrix.ru/learning/course/?COURSE_ID=8&TYPE=Y
Обратите внимание: установка параметров PHP из .htaccess возможна только при выполнении следующих условий:
* используется веб-сервер Apache или совместимый с ним;
* файлы .htaccess обрабатываются веб-сервером, т.е. в настройках веб-сервера (httpd.conf) установлена директива: AllowOverride All или другое значение, отличное от None;
* PHP установлен как модуль Apache (в случае, если PHP работает как CGI, все необходимые значения следует учесть и установить при сборке PHP)

Прописал в ~/php.ini,
указав в ~/public_html/.htaccess:

SetEnv PHPRC /home/login

где login - ваш логин (каталог) у хостера (~/)

Кстати, в ~/public_html/.htaccess:
допустимо указать и так домашний каталог пользователя:
SetEnv PHPRC ~/

В php.ini:

max_execution_time = 60
max_input_time = 90
memory_limit = 64M
mysql.connect_timeout = 60
mysqli.reconnect = On

Ничего не помогло, лишь

"TroYReall" wrote:

В файле
includes/database.mysql.inc
в конце функции db_connect(), под строкой "SET NAMES" вставить:
mysql_query('SET SESSION wait_timeout = 60', $connection);
В файле
includes/database.mysqli.inc
в конце функции db_connect(), под строкой "SET NAMES" вставить:
mysqli_query($connection, 'SET SESSION wait_timeout = 60');
проблема исчерпана

Буду еще пробовать

"ws_admin" wrote:

В итоге на виртуальном хостинге пока в разное время работало только 2 решения:

"Node_one" wrote:

И каждый раз при обновлении править модуль?

ну хотя бы так... иначе совсем висит сайтик

Почему не помогает явное прописывание таймаута в /public_html/sites/default/settings.php :

ini_set('max_execution_time', 90);
ini_set('max_input_time', 90);
ini_set('mysql.connect_timeout', 90);
ini_set('mysqli.reconnect', 1);

Спасибо!
Переписывался с саппортом хостера, он положил в корень сайта, в ~/public_html/php.ini, где он прописал
mysql.connect_timeout = 160

Хорошо, закомментарил те строки, что "TroYReall" написал(а) (см. выше).

Этого в ~/public_html/php.ini не хватило, ошибки MySQL продолжались при включенном модуле Update при подключении модулей, я дописал еще в ~/public_html/php.ini строки, стало:

mysql.connect_timeout = 160

mysqli.connect_timeout = 160
mysql.reconnect = On
mysql.trace_mode = Off

Не проверял, но, кажется, сработал mysql.reconnect = On

Вот такой рецепт, без правки модулей.

"ws_admin" wrote:

Прямого доступа к php.ini не было и помогла установка модуля Database tweaks,

Мне хостер поместил в корень сайта, в ~/public_html/ php.ini, куда прописали настройки.

У Вас так не выйдет? Нельзя создать ~/public_html/php.ini ?

Аналогичную проблему удалось решить изменением пары строчек в php.ini:
http://www.drupal.ru/node/85155

Такая ошибка при попытке копировать бд с хостинга на локальный сервер. Подскажите в чем может быть проблема? (