A alguien le pasó esto alguna vez?

Cristian,

Seguramente el shared hosting que tiene un timeout de MySQL de 15 segundos o algo así, y drupal tiene algunas operaciones que duran más.

Una solucion es utilizar db_tweaks
http://drupal.org/project/db_tweaks

HTH, salud

Podés adoptar esta solución como temporaria, y luego habilitar db_tweaks y volverla atrás.
http://drupal.org/node/259580#comment-1511512

Efectuá un repair de las tablas que tiene overhead o que están marcados como "en uso".

Suena más que tenés algun problema con alguna tabla en tu base de datos si todo ha estado bien hasta ahora.

Llevo dos dias que no descanso con este problema, pero luego llegué a este sitio y hasta ahora, puedo decir que encontre la solucion. Mil Gracias.

sobre problemas afines:

http://www.advomatic.com/blogs/dave-hansen-lange/dreaded-mysql-has-gone-...

Resulta que los problemas de que MySql "se vuelva loco" y paralice un servidor muchas veces es debido a que por defecto, cada conexión con la base de datos sigue con vida por 8 horas. Entonces si algo pasa y no se termina la transacción bien, se van consumiendo todas las conexiones. Entonces la gente agrega en /etc/my.cnf (el archivo de configuración de MySql) una entrada para "wait_timeout" de unos pocos minutos. Entonces, nunca más mensajes de error "no hay más conexiones ..."

La contra de esto es que, cuando hay una tarea larga y/o pesada, que necesita más tiempo, la conexión termina antes de lo debido, y ahora recibís el error elusivo "MySql se ha ido..." (MySql has gone away...).

Como esto ocurre con tareas especiales (tipo cron, etc., con indexación para la búsqueda de Drupal, etc.), el artículo sugiere algo de código PHP para customizar el tiempo de vida (wait_timeout) para sesiones especificas, una opción no muy conocida.

Hola amigos llevaba dias con el problema, gracias por el aporte, me ha sido de gran ayuda

Un saludo

no hay caso me pasa lo mismo

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:567009:\"MySQL server has gone away\nquery: UPDATE cache_update SET data = 'a:40:{s:5:\"abuse\";a:10:{s:5:\"title\";s:5:\"abuse\";s:10:\"short_name\";s:5:\"abuse\";s:10:\"dc:creator\";s:6:\"BTMash\";s:11:\"api_version\";s:3:\"6.x\";s:17:\"recommended_major\";s:1:\"1\";s:16:\"supported_majors\";s:3:\"1,2\";s:13:\"default_major\";s:1:\"1\";s:14:\"project_status\"; in /home/a8488742/public_html/mamalibre/includes/database.mysql.inc on line 136

Yo también tengo exactamente ese problema al ejecutar el cron teniendo el módulo search activado.

La web está en un hosting compartido pero con el paquete business, el más caro.

Probé a borrar el semáforo, el módulo db_tweaks y el supercron, el hook en database.mysql.inc y database.mysqli.inc, en las Opciones de búsqueda aumenté el nº de letras a indexar y reduje el nº de elementos, y finalmente probé el módulo que indicó victorkane.
Nada funcionó, sigo con el mismo mensaje :(

Entonces deben ayudarte en el tuning del MySql.

Ahora bien, como es el caso con otros hosting, el servidor de MySql no está en el mismo servidor que el servidor web; esto podría llevar a lentitud en la hora de hacer búsquedas y pedidos a la base de datos:

"The SQL Database Servers

MySQL databases are stored on separate servers renowned for this purpose.
Every SQL server is a high-availability machine with several RAID-1 hard disks. In case of a hard disk failure the other takes over its function without data loss. The security of your data is the most important issue for us."

http://www.ovh.co.uk/shared_hosting/we_hosting_without_limits.xml

Si tenés bastante tráfico, estarías mejor con un hosting que no hace esto, o, optar por un dedicated server (bastante más costo). Desgraciadamente, parece que no tienen VPS.

Hoy día Drupal no es una cosa rara que alguna gente usa, sino una solución de primera, entonces el hosting te tiene que ayuar con esto.

La otra, Marta, sería sacar el cron, y indexá cada tanto a mano en un horario de poco tráfico, sacando el sitio fuera de línea para hacerlo.

Por ejemplo, en Drupal 6, andá a Configuración del sitio / Opciones de búsqueda

Bajar el número de elementos a indexar en cada ejecución del cron (digamos a 50 o menos hasta que se resuelve el problema).

Luego, en un momento de poco tráfico, y tal vez las primeras veces con el sitio fuera de línea, oprimí el botón Volver a Indexar el Sitio

Para ejectuar cron manualmente, ir a Informes / Informe de estado (Reports / Status report)

Hacia el final, dice "Tareas de mantenimiento de cron" y te informa sobre cuándo fue ejecutado cron, y es allí donde hay un link a "ejecutar cron manualmente".

Yo por mí parte, no usaría todos los módulos "extrafalarias" sobre cron, etc. sino que correría cron manualmente hasta que se solucione (bajando la cantidad de elementos a indexar)...

Avisá si eso ayuda.