Confío en los creadores del software que son bastante capaces. Este software ya tiene mas de 5 años en el mercado, eso si que se apresuraron en el lanzamiento de la version definitiva. A pesar de ello mi DB es muy grande y necesitaré un buen equipo. Una solución de server, por los precios que veo, estan algo lejanos de mi presupuesto por ahora.
y un raid 5 con discos sata de 10000rpm, con un proce y memorias a 1066 (pa que no se eleve tanto el costo)
si quieres usar 8G de ram seria optimo usar linux, y ahi le pones una maquina virtual con windows xp y volará
a un amigo le arme un quad de 2.4 con 4G de ram de 1066, 2 sata de 7200 en raid 0, una placa asus P5 algo (la de 150 lukas), una 8600 y fuente de 650 real. El pc era para render para un ploter, por la cantidad de ram le instalamos vista 64, pero el programa de render no corria asi que le pusimos una maquina virtual... LA CAGO COMO RENDEREABA!!!! una bala la maquina... asi que en linux deberia ser mejor
Una placa que soporte Quad core y RAID 0 de 2 raptor de 36gb con tarjeta de video integrada y que tenga drivers para linux para correr RAID (no se como es el caso), en una distribucion minima por consola. Creo que 1 GB RAM basta para tener la DB corriendo en un mini server linux, creo que no necesito mas potencia.
Despues me armo otro pc ppal. con la tarjeta grafica y demas cosas
sería muy interesante de probar, antes de comprar la maquina definitiva.
----
otra duda, es que si tengo un server linux de la base de datos, cuando windows haga una consulta sencilla, de cuanto será el LAG adicional al tener los datos que pasar por la conexion de red ?
No es tanto lag, windows de por sí no tiene la posibilidad de hacer la conexión via socket, lo hace ocupando TCP/IP, así que para el caso... daría lo mismo
Quote:
Originalmente publicado por Zuljin
Ojo rucio
El costo de la consulta sql no es tanto porque sea count() o no, sino por lo que tenga el where. Evidentemente si haces algo de este tipo:
select count(*)
from usuarios
vas a barrer toda la tabla y no hay por donde mejorarla. Sin embargo, si haces algo como esto:
select count(*)
from usuarios
where comuna = 'Chaitén'
y el campo comuna tiene un índice, la consulta va a volar.
Ah obvio... pero igual se tiene que hacer un recorrido secuencial de todos aquellos registros que cumplan comuna = 'Chaitén', lo cual igual puede ser muy lento en caso de que sean muchos registros que cumplan con esa condición, aunque exista un índice en comuna. Ahora bien, si hacemos por ejemplo:
select count(comuna) from usuarios where comuna = 'Chaitén';
la consulta debería volar... Aunque no he hecho la prueba y puede que igual haga un recorrido secuencial.
Veré si mañana tengo la oportunidad de corroborar esto.
Quote:
Originalmente publicado por Zuljin
En mi experiencia, la optimización de tiempo de respuesta comienza de la siguiente manera:
1.- Negocio
2.- Modelo lógico de datos (relaciones entre entidades)
3.- Modelo físico de datos (índices, partitioning, etc)
4.- Motor de Base de datos (el tuning de oracle/postgresql/mysql/mssql)
5.- Hardware (mejores discos, más ram, más y mejores procesadores)
Listado por orden de importancia
Me parece Klaudioz que tu puedes trabajar desde el punto 3 hacia abajo, suponiendo que el punto 1 y 2 ya están cocinados y cualquier modificación en esos niveles implicaría un cambio brutal en tu aplicación. O sea, si el modelo de datos lo hiciste mal y tu aplicación ya está trabajando con ese modelo de datos, mejorarlo implicaría tocar muchop código.
Entrando en detalles, pon la sentencia sql completa que es la que se te demora mucho, para ver que se puede hacer al respecto. No se, reescribir la sentencia sql o sugerir poner un índice (un índice bien puesto te cambia la vida, papá)
That's so fucking true
En cuanto al tuneo... te sugiero encarecidamente que te hagas una réplica de la base de datos y jueges ahí: la configuración depende mucho de cómo estén hechos las bases de datos, y lo que te pueda recomendar quizás no es lo mejor.
Sin embargo, ciertas pistas de valores que puedas/tengas que configurar:
max_connections = trata de dejarla en el mínimo posible, puesto que cada conexión te toma alrededor de 400 bytes de memoria compartida.
superuser_reserved_connections = déjalo en 1.
shared_buffers = el parámetro más importante. Hay algunos que sugieren dejarla del tamaño 1/3 de la memoria total que tengas, no olvides que este valor lo tienes que multiplicar por 8192 para ver realmente cuántos MB son. Sin embargo, puede que para tu base de datos este valor no corresponda realmente a tus necesidades, por lo que vas a tener que jugar bastante para conseguir un balance. Ponerle demasiado te puede jugar en contra, así que cuidado. Para que te hagas una idea, en la base de datos que arriba describo, lo tengo en 435MB. Si estás trabajando con Linux, no olvides incrementar el SHMMAX en tu conf. de kernel (Típicamente /proc/sys/kernel/shmmax ) y ejecutar sysctl -p para aplicar cambios y acto seguido reiniciar postgresql.
Ejemplo:
valor por default = 8192 * 1000 = 8MB
si lo dejas en supongamos 30000 = 30000*8192 = 245MB de RAM.
temp_buffers = configúralo sólo en el caso de que tengas funciones o procedimientos almacenados. Es la memoria habilitado para estos ítems.
max_prepared_transactions = tb tiene que ver con las funciones o procedimientos almacenados. Tienes que jugar para ver qué tal te anda.
work_mem = es el trabajo de espacio que le dejas a postgres en el resultado de las funciones. Si la base de datos te retorna 30.000 registros en una función, te sugiero dejar bien alto este valor xD
max_fsm_pages = no me acuerdo bien para qué es esto, pero haciendo un vacuum la base de datos te dirá en cuánto dejar este valor. Revisa asimismo los logs para ver qué te dicen. Un VACUUM FULL o un VACUUM VERBOSE ANALYZE deberían entregarte mucha más información al respecto.
bgwriter_delay = si tienes UPS, déjalo en un valor alto. Esto demorará la escritura en disco, pero acelerará bastante la base de datos si hace muchísimos inserts.
Lo demás ya me dio paja explicarlos uno por uno
Te recomiendo leer este doc que deja bastante claro algunas cosas, aunque ojo: es un documento viejo y algunas confs ya no aparecen en las últimas versiones: http://www.varlena.com/GeneralBits/T...ed_conf_e.html
Originalmente publicado por Maledictum en un carrete
Pta, si me pusiera medio kilo de pechugas como la marlén olivarí, me iría de hocico al suelo
Quote:
Originalmente publicado por -Panchote-
osea si tu vas a algun lugar a solucionar un problema.. erres un pendejo lloron y todo lo que diceses? osea hello!!!!!
Quote:
Originalmente publicado por warezmen
aunque la referencia a balrog me excita màs debido a sus sensuales curvas
Frase célebre de hoy: "Debido a la gran cantidad de guiños y referencias relacionadas con el mundo informático, esta sección permanecerá siempre incompleta, al menos hasta que se complete"
Les cuento que finalmente decidi por construir un servidor a traves de la pagina de dell, que tienen un descuento importante. Me di cuenta que este se pierde agregando piezas, asi que me haré un server minimo y si es necesario iré mejorandolo. Ya les contaré mi experiencia y los resultados.
anoche estaba pensando ... (sips, a veces pienso )
Creo que la mejor conf. que le puedes poner con un bajo presupuesto, es un disco de 7200 barato para el sistema operativo, y un disco tipo raptor o uno de 15kRPM donde dejas montado exclusivamente la carpeta /pgsql/data/, tirando los logs a otra carpeta dentro del disco más lento. De esa manera, separas sistema operativo de datos y consigues mayor rapidez exclusivamente en los datos que es lo que te interesa
Placa madre una más o menos cara, la idea es que sea buena. Sus 2GB en RAM y ojalá un quadcore: mientras más cores y clientes, más se beneficia postgresql, debido a que asigna cores por conexión. (Aunque un usuario esté haciendo mierda un core, ningún otro cliente sufrirá de bajas de velocidad, debido a que van a trabajar en un espacio totalmente distinto).
Y si te compras un server ya armado.. te recomiendo el G5 DL380 Compaq/HP Además, los encuentro más bonitos que los dell (Aunque creo que consigues mayor velocidad en un AMD, aunque tendría que corroborar esto)
Originalmente publicado por Maledictum en un carrete
Pta, si me pusiera medio kilo de pechugas como la marlén olivarí, me iría de hocico al suelo
Quote:
Originalmente publicado por -Panchote-
osea si tu vas a algun lugar a solucionar un problema.. erres un pendejo lloron y todo lo que diceses? osea hello!!!!!
Quote:
Originalmente publicado por warezmen
aunque la referencia a balrog me excita màs debido a sus sensuales curvas
Frase célebre de hoy: "Debido a la gran cantidad de guiños y referencias relacionadas con el mundo informático, esta sección permanecerá siempre incompleta, al menos hasta que se complete"
Oye Klaudioz, y si estás cotizando un servidor de pruebas por que no te compras uno armado?
Saca la cotización que de entregue Dell y fíjate cuanto te cuesta. Luego, contáctate con Pablo de Rigam y dile que eres usuario de Chilehardware y que quieres cotizarle un servidor con determinado presupuesto.
Pablo de Rigam tiene experiencia en el cuento: le armó un Octocore a Alcapone para cómputo, y un Dual Core a mi para Base de Datos.
Según tus requerimientos de espacio y presupuesto puedes jugar por muchas unidades de disco SATA de 7200RPM o pocas unidades de disco SAS de 15 mil rpm
Si tu servidor es para producción entonces olvida lo anterior y ve por una máquina de marca.
Al final compre este por dell, ppalmente por el descuento de 250 lukas que habia hasta el viernes.
Procesador Intel® Xeon® cuádruple E5335; 2X4MB Cache, 2.0GHz, 1333MHZ FSB
Procesador adicional Sólo un procesador
Memoria Memorias DIMM 2GB, 667MHz (2x1 GB), Dual Ranked de búfer completo
Teclado Teclado USB, latinoamérica, negro
Monitor Opción sin monitor
Disco Duro Disco duro de 80 GB, SATAII, de 3.5 pulgadas, con velocidad de 7,200 RPM
Controlador de Disco Duro Controlador SATA integrado - Sin RAID
Unidad de Floppy Sin unidad de disquete
Sistema Operativo Sin sistema operativo
Mouse Mouse mecánico de dos botones, con conexión USB, negro
Tarjeta de Red Adaptador de red integrado de un solo puerto Gigabit
Dispositivo Óptico CD-RW/DVD ROM de 48X
Documentacion Documentación electrónica y kit OpenManage en CD
Configuración de Discos Duros Controlador SATA integrado que soporta 1-2 unidades de disco duro - No RAID
Servicio de Soporte de Hardware 3 años de servicio en sitio con respuesta al siguiente día laborable
Opciones de Instalación Sin evaluación de instalación
Obtenga $250000 de descuento por la compra de este sistema! - $210.084,03
Precio Total: $580.011,02
Lo compre bien penca en lo que es almacenamiento, ya que si estoy disconforme compro un raptor y si aun no me satisface una controladora + 2 raptor en RAID 0. El solo procesador lo he visto en tiendas en 270000 y las placas de server son carisimas, asi que creo que he pagado un buen precio.
) 
