Alto Rendimiento Desarrollo

AntecedentesAlto Rendimiento Desarrollo

Hemos estado trabajando muy duro para tratar de encontrar soluciones para una aplicación de "alto rendimiento". La aplicación es básicamente un administrador de memoria de alto rendimiento, con una sincronización en el disco. Las "lecturas" y "escrituras" son tremendamente altas, alrededor de 3000 transacciones por segundo. Tratamos de hacer todo lo posible en la memoria, pero eventualmente los datos se vuelven obsoletos y deben ser enjuagados en el disco, y aquí es donde se produce un gran "cuello de botella". La aplicación tiene varios subprocesos, con aproximadamente 50 subprocesos. No hay ninguna IPC (comunicaciones entre procesos)

intentos

inicialmente Escribimos esto en Java, y funcionó bastante bien, hasta una cierta carga, fue golpeado el cuello de botella y simplemente no podía Mantenga. Luego lo probamos en C# y se alcanzó el mismo cuello de botella. Probamos esto con código no administrado (C#), y aunque en las pruebas iniciales fue deslumbrantemente rápido usando MMF (archivos de mapas de memoria), en producción, la lectura fue lenta (están usando Vistas). Intentamos con CouchBase, pero tropezamos con problemas relacionados con la alta utilización de la red. ¡Esta podría ser una mala configuración de nuestra parte!

Historia: En nuestro intento de Java (no MMF), nuestro hilo con la cola de la información que necesita para obtener vuelca en disco se basa en la medida de no poder seguir el ritmo "escritura" en el disco. En nuestro método de archivo de mapa de memoria C#, el problema es que las LECTURAS son muy lentas y las ESCRITURAS funcionan perfectamente. Por alguna razón, ¡las vistas son lentas!

Pregunta

Entonces la pregunta es, situaciones en las que la intención de transferir grandes cantidades de datos; ¿Puede alguien ayudarme con un posible enfoque o diseño arquitectónico que pueda ayudar? Sé que esto parece un poco amplio, pero creo que la naturaleza específica del alto rendimiento y el alto rendimiento deberían reducir las respuestas.

¿Alguien puede responder por el uso de Couchbase, MongoDB o Cassandra en ese nivel? Se apreciarían otras ideas o soluciones .

Fuente

2012-08-17 Dane Balia

No estoy seguro, pero creo que la escritura de datos en otro hilo en el disco cuando cuando ciertos alcanzado el límite (pero no enorme número, por ejemplo, una cuarta parte de lo que eres usar ahora) mientras sigue leyendo datos puede ayudar. Entonces puedes liberar este recuerdo y comenzar a escribir otros. Realmente no sé la respuesta, solo creo que puede ayudar –

No estoy seguro de si se ajusta a su problema de transferencia de datos, pero se mostró un diseño de software en un documento de la Universidad de California. "SEDA: una arquitectura para servicios de Internet bien acondicionados y escalables". ACM ISBN 1-58113-389-8-1/01/10. Habla acerca de cómo obtener un alto rendimiento en un sistema de subprocesos múltiples/-gestados. –

Adil, gracias, estamos haciendo eso. Coding.mof revisará el documento, muy apreciado. –

Cantidades masivas de datos y acceso al disco. ¿De qué tipo de disco estamos hablando? Los HDD tienden a pasar mucho tiempo moviendo la cabeza si trabajas con más de un archivo. (Sin embargo, eso no debería ser un problema si usa SSD). Además, debe aprovechar el hecho de que los archivos mapeados en memoria se administran en fragmentos de tamaño de página. Las estructuras de datos deben estar alineadas con los límites de la página, si es posible.

Pero en cualquier caso, debe asegurarse de saber lo que es el cuello de botella. La optimización de las estructuras de datos no ayudaría mucho si realmente pierde el tiempo debido a la sincronización del hilo, por ejemplo. Y si está utilizando una unidad de disco duro, la alineación de la página puede no ser tan útil como meter todo en un solo archivo de alguna manera. Entonces, use las herramientas adecuadas para descubrir qué frenos aún lo están frenando.

Usar una implementación de base de datos de uso general puede no ser de gran ayuda para usted. Son, después de todo, de propósito general. Si el rendimiento es realmente un gran problema, una implementación especial con sus requisitos en mente podría superar estas implementaciones más generales.

Fuente

2012-08-17 07:01:30 Wormbo

Dicha herramienta de creación de perfiles, por ejemplo, para Java es [JProfiler] (http://www.ej-technologies.com/products/jprofiler/overview.html?gclid=CKOD54mM7rECFRHMzAod2QkAMw) –

Hola Wormbo, gracias. Sugerencias: investigué la ruta SSD anteriormente, pero desafortunadamente debido a los problemas de "celda" de las lecturas y escrituras límite a pesar de los algoritmos actualizados para evitar esto por los fabricantes de hardware, nuestra tasa de procesamiento matará el disco en un corto período de tiempo. La estructura de datos se alinea con los límites de la página "? ¿Por qué es tan beneficioso? –

coding.mof, yip hizo el perfil, utilizando productos de IBM y Microsofts. Gracias –

En primer lugar, me gustaría aclarar que tengo poca (si alguna) experiencia en la construcción de aplicaciones escalables de alto rendimiento.

Martin Fowler tiene una descripción de la arquitectura LMAX que permitió que una aplicación procesara aproximadamente 6 millones de pedidos por segundo en un solo hilo. No estoy seguro de que pueda ayudarlo (dado que aparentemente necesita mover una gran cantidad de datos), pero tal vez pueda obtener algunas ideas al respecto: http://martinfowler.com/articles/lmax.html

La arquitectura se basa en Event Sourcing que se usa a menudo para proporcionar (relativamente) escalabilidad fácil.

Fuente

2012-08-17 08:33:16

Tx, echa un vistazo a –

Parece prometedor, toma un poco de tiempo para obtener el "concepto". Pero veremos si podemos sacar algo del patrón Disruptor. –

Sí, esto no soluciona realmente nuestro problema. El patrón disruptivo se centra más en cuándo hay que realizar un gran trabajo (pasos de trabajo) y en la contención entre el trabajo (por ejemplo, el encontrado en Cola). Nuestro problema está en una cola que es independiente e incapaz de escribir de manera eficiente en el disco, sin que la cola alcance un tamaño inmanejable. –

-1

Si lo desea, evite rápidamente la persistencia y las colas tanto como sea posible para las escrituras y use memoria/caché en las lecturas.

El lenguaje tiene poco que ver con ella. \

Fuente

2012-11-02 08:55:43 user1496062

No estoy seguro sobre el voto negativo. Los idiomas generalmente varían entre un 10-30% (algunos en un 50%). Pero IO en el disco es como 10K más lento que la memoria .. Mire a Lmax minimizar IO y hacer 6M transacciones/segundo en una sola máquina. Lo mismo ocurre con el uso común, use una cola persistente y le garantizo que su rendimiento se reducirá por lo menos en un factor de 10. Y tiene el horrible mantenimiento manual de las colas de mensajes no entregados. Ahora mira las cifras del idioma en comparación con los costos persistentes. Eso no significa que no tengas persistencia sino que minimices. – user1496062

Respuesta

Cuestiones relacionadas