init.d en gentoo

no te funciona:
#rc-update add net.eth0 default
??

Creo que era asi, hechale un ojo al manual, porque hace tiempo que no uso el rc-update
Y respecto al foro si, ya hace tiempo que petardea cada dos por tres

Saludos

[OT mode]
Eso no es porque la base de datos se haga grande, suena más a una mala administración de los servicios (IMNHO). Sin embargo, PostgreSQL estas cosas (hilos fantasmas) no las hace, tarda más, pero no las hace (transacciones r00lz). Además de que PostgreSQL tiene chequeos de integridad y bla bla bla Sin embargo una migración a PostgreSQL puede ser más que dolorosa.
[/OT mode]

Sobre lo de gentoo.... pues mirar los docs no viene mal para estas cosas. Decirte que lleva un sistema de inicio de scripts es distinto al que usan Debian, RedHat, ... es más parecido a los Unix como FreeBSD, NetBSD, Solaris (no estoy 100% seguro) y Linux como Slackware.

Salu2.Ferdy

Sobre lo de PostgreSQL cierto, tiene que ser muy doloroso Ferdy ... pero espero que no siga lo de los hilos fantasmas porque sino creo que van a tener que plantearse algo ...

Sobre lo del rc gracias y mas gracias por darme la lección de leerme el doc ( ando perro ultimamente ) y sobre que son mas parecidos a los de FreeBSD ... bueno es parecida la estructura, pero poco mas, y como estoy acostumbrado mas al sistema de /usr/local/etc/rc.d/ de FreeBSD o los rc's de Debian.. pues me lio un poco con este tema, es que al verdad nunca me paso el tener el script bien y en su sitio y que no lo lance

Venga un saludo y de nuevo Gracias

Sobre lo de PostgreSQL cierto, tiene que ser muy doloroso Ferdy ... pero espero que no siga lo de los hilos fantasmas porque sino creo que van a tener que plantearse algo ...

Je... una mala administración de PostgreSQL puede dar peores resultados que una mala administración de MySQL.... ya se que tienen que hacer algo, pero una migración a PostgreSQL no es algo viable IMHO

Salu2.Ferdy

Cierto, es mas hace tiempo que pense que es posible que en si la Base de Datos este mal enfocada ( es decir no estar bien normalizada, o malamente relacionada o quien sabe ) y sea por esa razón por la que de estos problemas, una base de datos para pequeñas tareas puede estar todo lo mal que sea que puede cubrirte la necesidad pero a terminos ya algo mas grandes es muy importante tener bien normalizada, estructurada, y relacionada una base de datos, pero vamos no se dado que nunca vi la base de datos como la tienen

Venga un saludo

Bueno, si no me equivoco aquí se usa vBulletin. vBulletin no tiene nada nada mal la estructura y enfoque. Pero un MySQL no solo hay que instalarlo y darle caña, hay que darle límites y optimizarlo, además de darle el hardware que necesita Quizá rehacer índices más a menudo o algo así... vete tu a saber.

Salu2.Ferdy

Esto en mi opinion quedaria en feedback que te cagas

PD: que no me salga ningun troll, que no me estoy metiendo con nadie eh! solo peisno que alli podriamos obtener respuestas sobre esto de los responsables

Personalmente lo considero más un tema de debate sobre bases de datos en carga extrema que una critica a los responsables... piensa que si ellos quieren ayuda vendrán a pedirla. Más "marrones voluntarios" no busco, una mano no se la niego a nadie.

Salu2.Ferdy

Escrito originalmente por Ferdy
[OT mode]
Eso no es porque la base de datos se haga grande, suena más a una mala administración de los servicios (IMNHO). Sin embargo, PostgreSQL estas cosas (hilos fantasmas) no las hace, tarda más, pero no las hace (transacciones r00lz). Además de que PostgreSQL tiene chequeos de integridad y bla bla bla Sin embargo una migración a PostgreSQL puede ser más que dolorosa.
[/OT mode]

Me temo que sí que se debe al tamaño de la base de datos (principalmente al de la tabla que guarda los mensajes), unido al elevado acceso concurrente y las limitaciones propias de MySQL (interbloqueos), ya que las tablas se optimizan cada día y la configuración de mysql está ajustada (y probada) al máximo para conseguir el mejor equilibrio de eficiencia/conexiones máximas. Con transacciones está claro que se evitarían los "hilos fantasmas", pero no me quiero ni imaginar el hardware necesario para ejecutar EOL con PostgreSQL de forma fluida, por no hablar del trabajo de migración.

El problema de los "hilos fantasmas" es que en momentos de saturación de MySQL la tabla de threads queda bloqueada y antes de que se inserte en ella el hilo el cliente vuelve a darle a enviar (o da un timeout), no escribiendose después en la tabla de posts pero volviendo a insertar en la de hilos al darle de nuevo a enviar. Intenté solucionarlo comprobando antes de insertar si había un hilo reciente del mismo autor y con el mismo título, pero en muchos casos no funciona la comprobación pq la primera inserción aún no se ha realizado.

De todas formas los "hilos fantasmas" son sólo uno de los problemas, pero tampoco el más importante. Para solucionarlos he comprado un servidor nuevo que hará de frontend (Apache+PHP+resto de servicios secundarios), dejando el actual sólo para MySQL. Espero que mejore la situación.

Pues no, no hará mucha falta mucho hardware para ejecutar EOL en PostgreSQL. El problema es que vBulletin está pensado para MySQl3 y no para MySQL4 que ya hace las cosas bien. (retroalimentación de features desde pgSQL). Migrarlo.. eso es otra cosa.

Sobre las transacciones, pues MySQL4 las soporta...

Pero me inclino a pensar que el tamaño no es TAN influyente como dices. Quizá mis conocimientos sobre bases de datos no son muy buenos...

Salu2.Ferdy

Escrito originalmente por Ferdy
Pues no, no hará mucha falta mucho hardware para ejecutar EOL en PostgreSQL. El problema es que vBulletin está pensado para MySQl3 y no para MySQL4 que ya hace las cosas bien. (retroalimentación de features desde pgSQL). Migrarlo.. eso es otra cosa.

Sobre las transacciones, pues MySQL4 las soporta...

Pero me inclino a pensar que el tamaño no es TAN influyente como dices. Quizá mis conocimientos sobre bases de datos no son muy buenos...

Salu2.Ferdy

Pues yo te aseguro que el tamaño sí que importa (y no hablo del miembro viril). La prueba fue la poda de mensajes que hice hace tiempo (unos 500.000) con lo que el funcionamiento de la web mejoró mucho en las horas punta (y en el resto de horas disminuyó el tiempo de ejecución de los scripts).

De pgSQL no sé mucho la verdad, sólo he leído comparativas en las que ensalzan su características frente a MySQL, pero siempre destacan la eficiencia de éste último.

Sobre las transacciones, su uso implica un mayor consumo de recursos considerable, y de esto no vamos precisamente sobrados...

De todas formas tengo pensado utilizar MySQL4 próximamente utilizando el nuevo servidor como base de pruebas, no creo que el paso a la actual versión estable de MySQL suponga ningún cambio drástico y con las perrerías que le he hecho al código del vbulletin para optimizar su funcionamiento no tengo problemas en modificar lo que haga falta.

La eterna balanza, fiabilidad vs. eficiencia.

No se qué versión de MySQL estarás usando, pero te comento que he visto bases de datos MUY (y cuando digo muy, son muy muy) grandes, y el tamaño no era lo mas importante.

Si, MySQL es más eficiente hasta cierto punto en que se cambian las cosas, MySQL empieza a hacer cosas parecidas a los 'hilos fantasmas' y PostgreSQL simplemente sigue en su línea.

Salu2.Ferdy

Escrito originalmente por Ferdy
La eterna balanza, fiabilidad vs. eficiencia.

No se qué versión de MySQL estarás usando, pero te comento que he visto bases de datos MUY (y cuando digo muy, son muy muy) grandes, y el tamaño no era lo mas importante.

Si, MySQL es más eficiente hasta cierto punto en que se cambian las cosas, MySQL empieza a hacer cosas parecidas a los 'hilos fantasmas' y PostgreSQL simplemente sigue en su línea.

Salu2.Ferdy

Pues utilizamos la última versión de la versión anterior (valga la redundancia), la 3.23.58. Sobre el tamaño, teóricamente mysql puede manejar tablas de hasta 2TB creo, la más grande de EOL (el índice de búsquedas) pesa 1.1GB y tiene 33 millones de filas, pero ésta no es problema pq la actualizo de madrugada. El mayor problema está en la tabla de posts, 650MB con 1.500.000 filas y 3 índices. Pero la cuestión no es sólo esa, el problema es que juntamos una tabla grande en la que por tanto la escritura es "lenta" con un montón de lecturas concurrentes en ciertos momentos punta, y mysql no deja leer una tabla que se está modificando (pgSQL deja?).

En fin, está complicada la cosa, pero cualquier consejo será bienvenido .

MySQL hace bloqueo de tablas y pgSQL hace bloqueos por celdas lo que es infinitamente más eficiente.

Hemos estado tratando con una base de datos de entre 2 y 3Gb en total y MySQL iba 'mas o menos' bien. Nunca sufrimos hilos fantasmas... sufrimos lentitud y caidas, pero bueno al final la migración a pgSQL no pudo ser posible asi que migramos a MySQL4 y lo pusimos en un servidor aparte.

Salu2.Ferdy