40/sec a 500/sec
Introducción
¿Sorprendido, por el título? bien, éste es un viaje de cómo agrietamos el jinx del scalability de la dirección los 40 expedientes pobres por segundo a 500 expedientes por segundo. Guárdese, la mayoría de los problemas que hicimos frente eran derecho delanteros, así que la gente experimentada pudo encontrar esto superfluo.
Contenido
¿* 1.0 donde estábamos?
1.1 La memoria golpea el cielo
1.2 tarifa de proceso baja
1.3 Pérdida de los datos:- (
1.4 Mysql nos tira hacia abajo
1.5 Cliente Lento Del Web
* camino 2.0 al nirvana
2.1 ¡Memoria que controla!
2.2 Aerodinamizar tarifa de proceso
2.3 ¿Qué uh-uh de la pérdida de los datos?
2.4 Preguntas del Sql Que templan
2.5 Esquema de la base de datos que templa
2.5 ¡Mysql nos ayuda a avanzar!
2.6 Más rápidamente... más rápidamente cliente del Web
* fondo 3.0
¿Dónde estábamos?
Teníamos inicialmente un sistema que podría escalar solamente hasta que 40 expedientes /sec. ¿Podría incluso recordar la discusión, sobre "qué debo ser el índice ideal de expedientes? ". Finalmente decidíamos que 40/sec era la tarifa ideal para un solo cortafuego. Tan cuando tenemos que salir, atleast necesitamos apoyar 3 cortafuegos. Por lo tanto decidíamos que 120/sec sería la tarifa ideal. De acuerdo con los datos de nuestro competitor(s) vinimos a la conclusión que, ellos podría apoyar alrededor de 240/sec. ¡Pensamos que era aceptable! pues era nuestro primer lanzamiento. Porque todos los competidores hablaron del número de cortafuegos él apoyó pero no en la tarifa.
La memoria golpea el cielo
¡Nuestra memoria golpeaba siempre el cielo incluso en 512MB! ¡(excepción de OutOfMemory) culpamos depositar inmemory del cewolf(s) del images.But generado que no podríamos escaparnos para largo! ¡Ninguna materia si conectamos a cliente o no nosotros golpeaba el cielo en un par del máximo de los días 3-4 días completamente! Interesante, esto era reproductivo cuando enviamos datos en el rates(then) muy alto, alrededor de 50/sec. Usted lo conjeturaba la derecha, un almacenador intermediario ilimitado que crece hasta que golpea la azotea.
Tarifa de proceso baja
Procesábamos expedientes en el índice de 40/sec. Utilizábamos la actualización a granel del dataobject(s). ¡Pero no dio la velocidad prevista! ¡Debido a esto comenzamos a amontonar datos en memoria dando por resultado memoria de la valla publicitaria!
Pérdida De los Datos:- (
A una velocidad muy elevada faltábamos mucho un packet(s). Nos parecíamos tener poca pérdida de los datos, pero ésa dio lugar a un cerdo de la memoria. En alguno que pellizcaba para limitar el tamaño de almacenador intermediario comenzamos a tener una pérdida constante de los datos de el cerca de 20% en las tarifas muy altas.
Mysql nos tira hacia abajo
Hacíamos frente a una época resistente en que importamos un fichero de diario alrededor de 140MB. Mysql comenzó a hog, el arrastre comenzado máquina y a veces él responding.Above parado uniforme todo, comenzamos a conseguir el timeout(s) del deadlock(s) y de la transacción. Cuál redujo eventual la sensibilidad del sistema.
Cliente Lento Del Web
Aquí culpamos otra vez el número de gráficos que demostramos en una página como el embotellamiento, no haciendo caso del hecho de que había muchos otros factores que tiraban hacia abajo el sistema. Las páginas llevaban 30 segundos la carga para una página con 6-8 gráficos y tablas después de 4 días en el centro de datos del Internet.
Camino Al Nirvana
¡Memoria Que controla!
Intentamos poner un límite en el tamaño de almacenador intermediario de 10.000, pero no dura para largo. El defecto principal en el diseño era que asumimos que el almacenador intermediario de alrededor 10000 sería suficiente, es decir seríamos expedientes de proceso antes de que el almacenador intermediario de 10.1000 alcances. En línea con el principio "que algo puede ir mal él irá mal!" fue mal. Comenzamos a soltar datos. Subsesquently que decidíamos ir con depositar basado del fichero "plano", en donde los datos fueron descargados en el fichero "plano" y cargados en la base de datos usando los "datos de la carga infile". Ésta era muchas veces más rápidamente que un relleno a granel vía conductor de la base de datos que usted puede ser que también desee a la comprobación algunas optimizaciones posibles con los datos de la carga infile. Esto fijó nuestro problema de aumentar el tamaño de almacenador intermediario de los expedientes crudos.
El segundo problema que hicimos frente era el aumento del cewolf(s) en la memoria que depositaba el mecanismo. ¡Por defecto utilizó "TransientSessionStorage" que deposita los objetos de la imagen en memoria, allí parecido para ser un cierto problema en la limpieza encima de los objetos, incluso después los rerferences fueran perdidos! Escribimos tan una puesta en práctica pequeña de "FileStorage" que almacenan los objetos de la imagen en el archivo local. Y sea servido a medida que la petición viene adentro. Por otra parte, también implmentated un mecanismo de la limpieza a las imágenes añejas del images(de la limpieza más viejas que 10mins).
Otro aspecto interesante que encontramos aquí era que el colector de la basura tenía la prioridad más baja así que los objetos creados para cada los expedientes, fue limpiado apenas para arriba. Aquí está una poca matemáticas para explicar la magnitud del problema. Siempre que recibamos un expediente del registro que creamos el objects(hashmap ~20, tokenized las secuencias etc) tan en el índice de 500/sec para 1 segundo, el número de objetos era 10,000(20*500*1). debido al colector de proceso pesado de la basura nunca tenía una ocasión a la limpieza los objetos. Tan todo lo que tuvimos que hacer era un pellizco retorcido de menor importancia, nosotros acaba de asignar la "falta de información" a las referencias del objeto. ¡Voila! el colector de la basura era nunca torturado conjetura; -)
Aerodinamizar tarifa de proceso
¡La tarifa de proceso estaba en un 40/sec pobre que significa que podríamos soportar apenas incluso un arrebato pequeño de los expedientes del registro! El control de la memoria nos dio un cierto consuelo, but que el problema real estaba con el uso de los filtros alertas sobre los expedientes. Teníamos alrededor 20 características para cada expediente, nosotros utilizamos buscar para todas las características. ¡Cambiamos la puesta en práctica al fósforo para esas características que teníamos criterios para! Por otra parte, también teníamos un escape de la memoria en el proceso alerta del filtro. Mantuvimos una coleta que creció por siempre. ¡Tuvimos que mantener tan un objeto del fichero "plano" que descargaba para evitar el re-ana'lisis de expedientes para formar objetos! Por otra parte, hacíamos el acto de buscar para un fósforo para cada uno de la característica incluso cuando no hicimos ningún criterio alerta configurar.
¿Qué uh-uh de la pérdida de los datos?
¡Una vez que fijáramos la memoria publica en la recepción de los datos es decir que descargan en fichero "plano", nosotros nunca perdió datos! Además de ése tuvimos que quitar un par de índices indeseados en la tabla cruda para evitar los gastos indirectos mientras que descargaban datos. Nosotros índices del hadd para las columnas que podrían tener un máximo de 3 valores posibles. Cuál hizo el relleno más lento y no era realmente útil.
Preguntas del Sql Que templan
Sus preguntas son sus llaves al funcionamiento. Una vez que usted comience a clavar las ediciones, usted verá que usted puede ser que incluso tenga que de-normalizar las tablas. ¡Lo hicimos! Aquí están algunos de los learnings dominantes:
* El uso "analiza la tabla" para identificar cómo la pregunta del mysql trabaja. Esto le dará la penetración alrededor porqué la pregunta es lenta, es decir si está utilizando los índices correctos, si está utilizando una exploración etc del nivel de la tabla.
* Nunca filas de la cancelación cuando usted se ocupa de datos enormes en la orden de 50.000 expedientes en una sola tabla. Siempre intento para hacer una "tabla de la gota" tanto como sea posible. ¡Si no es posible, reajuste su esquema, que es su solamente salida!
* Evite el join(s) indeseado, no están asustado de-normalizar (es decir duplique los valores de la columna) evitan el join(s) tanto como sea posible, tienden para tirar hacia abajo su pregunta. Una ventaja ocultada es el hecho de que imponen simplicidad en sus preguntas.
* Si usted se está ocupando de datos a granel, el uso "datos de la carga infile" allí es siempre dos opciones aquí, local y telecontrol. Utilice a local si el mysql y el uso están en el mismo telecontrol del uso de la máquina de otra manera.
* Intente partir sus preguntas complejas en dos o tres preguntas más simples. Las ventajas en este acercamiento son que el recurso del mysql no hogged para arriba para el proceso entero. Tienda para utilizar las tablas temporales. En vez de usar una sola pregunta que atraviesa a través de 5-6 tabula.
* Cuando usted se ocupa de la cantidad enorme de datos, es decir usted desea a los proces dice 50.000 expedientes o más en un solo intento de la pregunta usando límite al proceso de hornada los expedientes. Esto le ayudará a escalar el sistema a las nuevas alturas
* Utilice siempre un transaction(s) más pequeño en vez los grandes es decir que atraviesan a través de las tablas de "n". Esto traba para arriba los recursos del mysql, que pudieron causar la lentitud del sistema incluso para las preguntas simples
* Utilice el join(s) en columnas con índices o llaves extranjeras
* Asegúrese de que el preguntas del interfaz utilizador tengan criterios o limítese.
* También asegúrese de que la columna de los criterios esté puesta en un índice
* No tenga el valor numérico en criterios del sql dentro de cotizaciones, porque el mysql hace un tipo molde
* utilice las tablas temporales tanto como sea posible, y cáigalas...
* El relleno de select/delete es una cerradura doble de la tabla... esté enterado...
* Tome el cuidado que usted no duele la base de datos del mysql con la frecuencia de sus actualizaciones a la base de datos. Teníamos un caso típico que descargábamos a la base de datos después de que cada 300 expedientes. Tan cuando comenzamos a probar para 500/sec comenzamos a ver que el mysql nos arrastraba literalmente abajo. Ése es cuando realizamos que el typicall en el índice de 500/sec allí es "una petición infile de los datos de la carga" cada segundo a la base de datos del mysql. Tuvimos que cambiar tan para descargar los expedientes después de 3 minutos más bien que 300 expedientes.
Esquema de la base de datos que templa
Cuando usted se ocupa de la cantidad enorme de datos, asegúrese siempre de que usted repartiera sus datos. Ése es su camino al scalability. Una sola tabla con los lakhs de la opinión 10 puede nunca escalar. Cuando usted se prepone ejecutar las preguntas para los informes. Tenga siempre dos niveles de tablas, de las tablas crudas una para los datos reales y de otro sistema para el tables(del informe las tablas que los interfaces utilizador preguntan encendido!) Asegúrese siempre de que los datos sobre sus tablas del informe nunca crezcan más allá de un límite. Encajónele están planeando utilizar el oráculo, usted puede probar repartir basado en criterios. Pero desafortunadamente el mysql no apoya eso. Tendremos que tan hacer eso. Mantenga una tabla del meta en la cual usted tenga la información de jefe es decir que tabulan para buscar, para un sistema de tiempo dado de los criterios normalmente.
* Tuvimos que caminar a través de nuestro esquema de la base de datos y agregamos para agregar algunos índices, suprimimos alguno e incluso el column(s) duplicado para quitar el join(s) costoso.
* El ir adelante realizamos eso que tenía las tablas crudas como InnoDB era realmente gastos indirectos al sistema, así que nos lo cambiamos a MyISAM
* También fuimos al grado de reducir el número de filas en las tablas estáticas implicadas adentro ensamblamos
* La FALTA DE INFORMACIÓN en tablas de la base de datos se parece hacer un cierto funcionamiento golpear, así que evítelas
* No tenga índices para las columnas que ha permitido valores de 2-3
* Cheque cruzado la necesidad de cada índice en su tabla, son costosos. Si las tablas son de cheque del doble de InnoDB entonces su necesidad. Porque las tablas de InnoDB se parecen tomar alrededor 10-15 mide el tiempo del tamaño de las tablas de MyISAM.
* Utilice MyISAM siempre que haya una mayoría de, cualquiera una (seleccione o relleno) de preguntas. Si el relleno y el selectos van a ser más entonces es mejor tenerlo como InnoDB
¡Mysql nos ayuda a avanzar!
Temple su servidor del mysql solamente después de usted consonancia fina su queries/schemas y su código. Solamente entonces usted puede ver una mejora perceptible en funcionamiento. Aquí están algunos de los parámetros que vienen en práctico:
* Utilice el tamaño de la piscina de almacenador intermediario que permitirá a sus preguntas ejecutar más rápidamente -- innodb_buffer_pool_size=64M para InnoDB y utilizar -- key-bufer-size=32M para MyISAM
* Las preguntas simples uniformes comenzaron a tomar más tiempo que esperado. ¡Nos desconcertaron realmente! Realizamos que el mysql se parece cargar el índice de cualquier tabla que comience a insertar encendido. Qué sucedió típicamente estaba tan, cualquier pregunta simple a una tabla con 5-10 filas tomó alrededor 1-2 secs. En análisis adicional encontramos que momentos antes de la pregunta simple, "infile de los datos de la carga" sucedida. Esto desapareció cuando cambiamos las tablas crudas al tipo de MyISAM, porque el tamaño de almacenador intermediario para el innodb y MyISAM son dos diversas configuraciones.
para parámetros más configurables vea aquí.
Extremidad: comience su mysql para comenzar con la opción siguiente -- el registro-error esto permitirá el registro de errores
Más rápidamente... más rápidamente cliente del Web
¡El interfaz utilizador es la llave a cualquier producto, especialmente la velocidad percibida de la página es más importante! Aquí está una lista de las soluciones y de los learnings que pudieron venir en práctico:
* Si sus datos no van a cambiar para la opinión 3-5 minutos, es mejor depositar sus páginas del lado del cliente
* Tienda para utilizar los gráficos internos etc. de Iframe(s)for que dan un fastness percibido a sus páginas. Todavía mejore el uso el mecanismo contento basado Javascript del cargamento. Éste es algo que usted puede ser que desee para hacer cuando usted tiene gráficos de la opinión 3+ en la misma página.
* El Internet Explorer exhibe la página entera solamente cuando todo el contenido se recibe del servidor. Es tan recomendable utilizar iframes o el Javascript para el cargamento contento.
* Nunca utilice las entradas de multiple/duplicate del archivo del CSS en el HTML page. ¡El Internet Explorer tiende para cargar cada archivo del CSS como entrada separada y se aplica en la página completa!
¡La línea de fondo sus preguntas y esquema hace el sistema más lento! ¡Fíjelos primero y en seguida culparon la base de datos!
Vea También
* Alto Rendimiento Mysql
* Funcionamiento De la Pregunta
* Explique La Pregunta
* Preguntas Óptimas
* El Templar De InnoDB
* Mysql Que templa
Categorías: Analizador Del Cortafuego | El funcionamiento inclina esta página era el Last modified 18:00, el 31 de agosto de 2005.
- Ramesh-
Artículo Fuente: Messaggiamo.Com
Related:
» Seo Elite: New Seo Software!» AntiSpywareBOT
» Reverse Mobile
» Error Nuker
Webmaster obtener el código html
Añadir este artículo a su sitio web ahora!
Webmaster Envíe sus artículos
No es necesario que se registre! Completa el formulario y su artículo está en el Messaggiamo.Com Directorio!
