Session initialisation failed

[BhEaN]

vuelvo a casa por Navidad....HO HO HO HO

[Cantona]

vuelvo a casa por Navidad....HO HO HO HO

rererererererererererrerrerre----bienvenido¡¡¡¡¡¡

[CrAfTy]

bien!!!! viene cargado de regalos!!!

[dancer28]

vuelvo a casa por Navidad....HO HO HO HO

Ohhhhhhhhhhhhhh!! Que mala suerte!!!

[pque]

vuelvo a casa por Navidad....HO HO HO HO

jejeje que cabron xDD

[saltarin]

No postea elalex, pero si un troll, juas, me la cacho enterita

[elalex]

Pues no es mi troll!!!

[SyLmaX]

vuelvo a casa por Navidad....HO HO HO HO

jejejeje.. como el turron!!

[saltarin]

Pues no es mi troll!!!

Yo soy tu troll!!!!

[dancer28]

Pues no es mi troll!!!

Yo soy tu troll!!!!

Los Trolls deben ser expulsados entonces???

[elalex]

Pues no es mi troll!!!

Yo soy tu troll!!!!

Los Trolls deben ser expulsados entonces???

Pues entonces si que deberia ser mi troll

[Coleto]

Pues no es mi troll!!!

Yo soy tu troll!!!!

Los Trolls deben ser expulsados entonces???

Pues entonces si que deberia ser mi troll

:troncharse2::troncharse2::troncharse2::troncharse2:

[Gus]

Por que la culpa es de Servidor y no del MYSQL y POstnuke?

Nuestra base de datos ocupa 438 Mb y tenemos un total de registro de 10,978,282 entre todas las tablas y una tabla en especial 9,724,297 . Leyendo el articulo de abajo me hace pensar que el MYSQL se nos queda corto para la web ya que Postnuke no debe estar muy bien optimizado por lo que nos jode el servidor. He estado hablando con otros usuarios del mismo Hosting que tiene portales de internet que tienen visitas masivas y a ellos no les fallan.
Todo lo que expongo es una opinion mia por lo que he podido leer por internet. Yo creo que deberiamos hacer ya la nueva web y quitarnos la mierda del Postnuke ya que hemos crecido demasiado.
BhEaN cuando nos ponemos a tope con la nueva web?

Aqui esta la informacion que encontrado?

¿Porqué MySQL es lento con grandes tablas?
bases de datos | mysql | rendimiento

Si has leido y estudiado suficiente acerca de MySQL probablemente habrás escuchado que MYSQL no es la elección acertada para manejar tablas con mas de 1.000.000 de registros.

Por otro lado tambien puede que tengas conocimiento que MySQL es el motor de compañias como Google, Yahoo, Technorati y estas manejan algunos billones de registros y consiguen un gran rendimiento.

La pregunta que puedes estar haciendote es cuál es la razón...

La razón es que normalmente estas tablas estan diseñadas y entendidas para trabajar con MySQL, si diseñas tus datos considerando que puede hacer y que no puede hacer MySQL probablemente conseguiras un buen rendimiento, cualquier sistema de administración de bases de datos es diferente con respecto a los otros, lo que funciona bien y es eficaz en Oracle,MS SQL,PostgreSQL no debe de ser lo que mayor rendimiento ofrece en MYSQL.

Incluso en el sistema de almacenamiento tienen muchas diferencias que los hace diferentes.

Las tres claves que deberias de tener en cuenta con tablas muy grandes son:
Buffers,Índices y consultas.

Buffers
Como ya sabrás un buffer es una ubicación de la memoria reservada para el almacenamiento temporal de información digital.

La primera cosa que deberias de tener muy clara es el hecho de que hay una gran diferencia entre cuando los datos estan en memoria y cuando no estan en memoria.

Si empezaste con un tamaño de memoria y notas un descenso gradual del rendimiento porque la base de datos esta creciendo una buena solucion sería asegurarte que tienes suficiente memoria para el volumen de datos que estas utilizando esto podrias realizarlo con diferentes técnicas.

Indices
Los índices son usados para encontrar rápidamente los registros que tengan un determinado valor en alguna de sus columnas. Sin un índice, MySQL tiene que iniciar con el primer registro y leer a través de toda la tabla para encontrar los registros relevantes.

Aún en tablas pequeñas, de unos 1000 registros, es por lo menos 100 veces más rápido leer los datos usando un índice, que haciendo una lectura secuencial por lo tanto queda claro que los indices son realmente eficaces para acelerar el acceso a datos.

Antes de proseguir con la explicacion he de aclarar algunos terminos como escaneo completo, que es leer todos los registros de la tabla de manera secuencial.

Cuando MySQL encuentre que hay un índice en una columna, lo usará en vez de hacer un escaneo completo de la tabla. Esto reduce de manera imporante los tiempos de CPU y las operaciones de entrada/salida en disco.

Dejame explicartelo con datos, considerando una tabla que tiene 100 Bytes por registros, con una unidad SCSI nosotros podriamos obtener 100MB/segundo de velocidad de lectura que nos daría alrededor de 1.000.000 de registro por segundo, si hablamos de tablas tipo MyISAM.

Aquí te dejo un ejemplo, he creado una tabla con 30 millones de registros, con una columna ('val') que tiene 10000 valores diferentes,vamos a ver las diferencias entre el tiempo de un escaneo total de la tabla y un escaneo utilizando un rango de valores por ejemplo entre 1 y 100, el resultado es el siguiente:

[BhEaN]

Gus, yo con la nueva web ya estoy, pero a mi ritmo... no dispongoo de todo el tiempo que me gustaría, pero los planes siguen como los habíamos hablado, tardará mas o menos, pero saldrá.

El tema de MySQL ya lo sabía, llevo muchos años con MySQL, jejejeje... por debajo de 1.000.000 de registros es la base de datos más rápida que existe, pero el rendimiento cae cuando se supera esa cifra... aún así, cuando decimos que "cae" el rendimiento nos referimos a que se ralentiza mucho los accesos a dichas tablas, sobre todo si no tienen indices definidos (como las que usa PostNuke)... pero ojo!... digo "ralentiza", no "falla"...

Los problemas que tenemos no son debidos a esto... podemos tener tablas con 50 millones de registros en MySQL perfectamente, y el unico problema que tendríamos es que sería más lento acceder a ellas, pero en ningun caso daría un error.

Cierto es que el pésimo diseño de las tablas que usa PostNuke no ayuda a que todo funcione perfectamente, pero vuelvo a decir que el mayor problema que ésto generaría sería en cuanto a velocidad, no a errores.

Muchas veces hemos visto que alguno de los errores era, por ejemplo, el acceso a alguna funcion propia de PHP, y el mensaje de error mostraba (en una ruta muy larga) el archivo en el que se estaba produciendo el error. La ruta mostraba claramente como esos archivos estan montados sobre un RAID de discos (logicamente) y el problema es que a veces falla el acceso a esos discos, por lo tanto la pagina que se quiere cargar en determinado "include" no se encuentra, mostrando el error que he comentado (lo he visto varias veces, por ejemplo, a la hora de cargar el banner... la web solo se carga hasta llegar al banner, y después muestra el error).

Quiero pensar que el diseño de las nuevas tablas que estoy haciendo es mejor que el actual, al menos está mucho más optimizado, pero por supuesto pienso seguir usando MySQL para la nueva web, jajajajaa... faltaría mas!!


En cualquier caso, es muy molesto a veces tener que aguatar durante algunas horas el dichoso error, pero ees algo temporal, cuando la nueva web esté terminada, esperemos que se acaben los problemas.

Saludos,

[saltarin]

Hoy os odio yo a todos