Un caché loco de agentes de prueba
¡Buenos días a todos!
Me encontré con el siguiente problema:
Tener 32 procesadores lógicos en el sistema - utilizando 32 agentes para la optimización respectivamente (+ otros 40 remotos)
Cada agente acumula con bastante rapidez una caché de un tamaño completamente inadecuado de 2-2,6 GB, que en total ascendió a más de 70 GB en un día. La caché en sí no se borra, y crece constantemente. Lo único que detuvo esta locura fue quedarse sin espacio en el disco. Después de lo cual los agentes dejan de funcionar estúpidamente.
Las preguntas son las siguientes:
¿Alguien se ha enfrentado a este problema? ¿Cómo lo afronto? ¿Qué puede estar causando estos tamaños de caché?
Escribí una solicitud a servicedesk, hasta ahora nada.
El tamaño de la caché depende del número de ticks generados (es decir, cuanto más largo sea el periodo de prueba y el número de caracteres, mayor será la caché).
En tu caso, probablemente el principal problema es el número de agentes, porque ahora (build 1495) cada agente utiliza su propia instancia de caché.
El espacio de la caché se libera tras 5 minutos de inactividad del agente.
Además, el historial de garrapatas de los agentes probadores puede ocupar espacio si se utilizan en la nube (el historial de garrapatas también se limpia eventualmente, pero se ejecuta en días o semanas).
Por cierto, los agentes de la nube y los agentes locales son diferentes. En la imagen los agentes de la nube en el mismo ordenador se añaden a la granja de la red local - ¡Voilà! Conseguimos 8 agentes de prueba en un procesador con dos núcleos y cuatro procesadores lógicos (si vale la pena hacerlo es otra cuestión).
В Вашем случае, вероятно, главная проблема - количество агентов, т.к. сейчас (билд 1495) каждый агент использует собственный экземпляр кэша!
El probador no tiene ningún tipo de configuración, por lo que es imposible optimizarlo para tu sistema. En la salida obtenemos un abuso del disco duro con un gran número de archivos pequeños reescritos (hasta 800GB/día en SSD de 120GB a 32 agentes en el sistema), y lo que es curioso, los núcleos en ese momento están inactivos.
Resolví parcialmente el problema ejecutando 4 probadores diferentes en modo portátil en diferentes unidades físicas. Incluyendo el diske de la RAM, ya que el probador deja una gran cantidad de memoria desatendida.
Por cierto, ejecutar un agente con caché en un disco ram, suele aumentar el rendimiento hasta 3 veces. Lo que señala, una vez más, la asquerosa forma en que se organiza el probador.
Por cierto, los agentes de la nube y los agentes locales son diferentes. En la imagen los agentes de la nube en el mismo ordenador se añaden a la granja de la red local - ¡Voilà! Conseguimos 8 agentes de prueba en una CPU con dos núcleos y cuatro procesadores lógicos (si deberías hacer eso es otra cuestión).
Se trata de la (perdónenme los desarrolladores) estupidez de la organización de los probadores, donde el número de agentes pasa de ser una ventaja a ser un problema.
El probador no tiene ningún tipo de configuración, por lo que es imposible optimizarlo para tu sistema. En la salida obtenemos un abuso del disco duro con un gran número de archivos pequeños sobrescritos (hasta 800GB/día en SSD de 120GB con 32 agentes en el sistema), y lo que es curioso, los núcleos permanecen inactivos durante este tiempo.
...
¡Por cierto, la ejecución de un agente con caché en un disco de bastidor, a menudo aumenta el rendimiento hasta 3 veces! Lo que señala, una vez más, la asquerosa forma en que se organiza el probador.
...
Escriba al Servicio de Atención al Cliente.
¿Tener que leer varios gigabytes de datos de un disco es una "organización asquerosa"? Incluso la lectura de 1gb de datos de un ssd a una velocidad media de 200mbps tardará 5 segundos. ¿Y si hay 4-32 agentes por ahí?
Sólo piensas en el aspecto técnico de la tarea. Nada es gratis y nadie multiplica los requisitos técnicos por cero.
La solución técnica y el nivel de optimización de los agentes son sorprendentes: hemos invertido una cantidad salvaje de trabajo y hemos arañado milisegundos a todos los procesos. No te olvides de los volúmenes de datos, pon más RAM, pon ssd's más grandes, pon discos de bastidor y todo se acelerará.
Los precios de todas estas cosas ya son razonables, pero la clase y el volumen que se resuelve requieren un enfoque serio.
Cada agente está acumulando rápidamente una caché de un tamaño completamente inadecuado, de 2 a 2,6 GB, ¡sumando más de 70 GB en un día! La caché no se borra sola y crece constantemente. Lo único que detuvo esta locura fue quedarse sin espacio en el disco. Después de lo cual los agentes dejan de funcionar estúpidamente.
¿Qué hay que guardar en esos volúmenes?
Todo está bien con las cachés de datos. La guardamos en disco y la almacenamos en la memoria a la espera de que se repita. Tenga en cuenta la rapidez del recálculo en el mismo agente (tome un agente y una ejecución para demostrar el efecto).
Una cosa más: trabajamos muy poco con los discos. Escribimos en grandes múltiplos y entendemos claramente las peculiaridades de los discos ssd.
Los operadores suelen preferir comprobar el tamaño de la carpeta sin darse cuenta de que hay unos 10 Gbytes de registros grandes, generados personalmente.
Resolví parcialmente el problema ejecutando 4 probadores diferentes en modo portátil en diferentes discos físicos. Incluyendo el disco RAM, ya que el probador deja una gran cantidad de memoria sin atender.
Por cierto, ejecutar un agente con caché en un disco ram, suele aumentar el rendimiento hasta 3 veces. Lo que señala una vez más la asquerosa organización del probador.
¿Cuál es la razón para que la organización RAM-disco aumente el rendimiento muchas veces, si el nivel de optimización de los agentes es "maravilloso"? En mi opinión, preguntas lógicas, aunque desagradables.
ZS Tenemos que conseguir un software que borre los registros de los agentes. Son inútiles en tales cantidades. El usuario debe desactivar la impresión+alerta en el código durante las optimizaciones.
fxsaber:
Речь шла о гигабайтах КЕША на каждый локальный агент. Мне до сих пор не понятно, что можно там хранить в таких количествах?
En lugar de hacer declaraciones en el foro, echa un vistazo por ti mismo.
¿Cuál es la razón para organizar la RAMdisk para multiplicar el rendimiento si el nivel de optimización del agente es "sorprendente"? En mi opinión, preguntas lógicas, aunque desagradables.
Porque no tenemos derecho a comernos el 100% de la RAM para la caché y mantenerla indefinidamente. Pero si una persona creó un marco de disco de 32-64gb por sí mismo, movió agentes allí y comenzó a trabajar activamente con el disco, entonces sí, es posible obtener la velocidad de las operaciones de disco muchas veces.
Pero específicamente las operaciones de disco, no "todas a la vez por un factor de N".
Que el probador maneja los datos de forma asombrosa es evidente para cualquiera que lo utilice en modo constante y obtenga muchos beneficios de las cachés del probador calentadas, a la espera de nuevas ejecuciones en segundo plano. La experimentación suele consistir en decenas o centenares de ejecuciones de pruebas con una recompilación constante del código.
HH Necesitamos algún tipo de software para borrar los registros de los agentes. No los necesitamos en cantidades tan grandes. Y Print+Alert debería ser desactivado por el usuario en el código durante las optimizaciones.
Los registros del probador se borran automáticamente. Los que usan el probador lo saben. Y las cachés del probador son borradas por el terminal tan pronto como entiende que el probador ya no se utiliza.
El topikstarter comenzó el hilo en modo "¿cuánto tiempo?" e hizo algunas afirmaciones sin fundamento. Si hubiera proporcionado los datos correctamente recogidos, el 50% de las preguntas se habrían eliminado en la fase de recogida de datos.
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Usted acepta la política del sitio web y las condiciones de uso
¡Buenos días a todos!
Me encontré con el siguiente problema:
Tener 32 procesadores lógicos en el sistema - utilizando 32 agentes para la optimización respectivamente (+ otros 40 remotos)
Cada agente acumula con bastante rapidez una caché de tamaño totalmente inadecuado de 2 a 2,6 GB, lo que en total supone más de 70 GB al día. La caché no se borra por sí sola y crece constantemente. Lo único que detuvo la locura fue quedarse sin espacio en el disco. Después de lo cual los agentes dejan de funcionar estúpidamente.
Las preguntas son las siguientes:
¿Alguien se ha enfrentado a este problema? ¿Cómo lo afronto? ¿Qué puede causar tamaños de caché tan grandes?
Escribí una solicitud a servicedesk, hasta ahora silencio.