![]() |
![]() |
![]() |
![]() |
![]() |
FTP | ![]() |
![]() |
CCD | ![]() |
![]() |
Buscar | ![]() |
![]() |
Trucos | ![]() |
![]() |
Trabajo | ![]() |
![]() |
Foros | ![]() |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
![]() |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
Entiendo la situación, pero alguna pista más seguro que puedes dar.
A bote pronto se me ocurre que el problema puede estar en que durante el desarrollo se han utilizado una cantidad limitada de datos de prueba con pocas conexiones, y al ponerlo en producción se ha encontrado con muchos más datos reales y más conexiones, haciendo que se hinche. |
#2
|
|||
|
|||
Hola.
Antes de nada muchas gracias por tu interés. Te lo agradezco de veras. No creo que sea tema de la cantidad de datos, porque al darnos cuenta del problema, arrancamos una aplicación sola en el servidor de producción, y aislamos la cantidad de datos, pero el consumo de memoria se dispara desde que se arranca, creo que en el caso de esta aplicación la subida brusca se produce en el momento en el que el componente ftp de la paleta fastnet se conecta a nuestro servidor ftp. Pasa lo mismo en otras con componentes de esta paleta. Con el servidor smtp, cada vez que se conecta para enviar un mensaje, sube el consumo, y el problema es que luego no se libera. he utilizado la funcion "SetProcessWorkingSetSize(GetCurrentProcess, $FFFFFFFF, $FFFFFFFF);" que leí en la página del Dr. Marteens, y me libera memoria física, pero la virtual la deja como está, y teoricamente debería hacer una liberación de ambas. En otra aplicación que se conecta vía sockets a otro equipo nos pasa tres cuartos de lo mismo: en el momento de la conexión sube el consumo, y ahí se queda, no la libera. El caso es que desde mi equipo, desde el que están compiladas todas estas aplicaciones, esto no pasa, y lo malo es que no puedo instalar la versión de delphi en el equipo de producción para compilarlas desde allí a ver si eso me soluciona algo. No se que más pistas puedo daros, no se me ocurre nada más, ni que más cosas puedo mirar. La verdad es que esto no nos había pasado antes, y empieza a ser un poco desesperante. |
#3
|
||||
|
||||
Por qué no pruebas a hacer un programita muy, muy simple con únicamente ese componente para ver si es el culpable o no.
|
#4
|
||||
|
||||
Creo que aparte de adivinar y suponer, las soluciones son:
1- Llevar tu equipo de desarrollo a la empresa y mirar 2- Usar http://www.automatedqa.com/downloads/memproof/ para ver si tienes un problema de mala liberacion de memoria 3- Probar con http://fastcodeproject.org/ para reemplazar el manejador de memoria de Delphi por uno mejor (el que usa Delphi 2005+ es muuuy rapido y eficiente y evita la fragmentacion de memoria) 4- Te falto las especificaciones del equipo. Datos a mirar: Puede que el servidor tenga hyperthreading, tenga mucha memoria, use varios procesadores, este alineado al lado incorrecto de la luna. Sobre todo eso ![]() La otra? Contrata a alguien y dale acceso por vnc o algo...
__________________
El malabarista. |
![]() |
|
|
![]() |
||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Memoria virtual para grandes matrices | JF Sebastian | OOP | 2 | 30-01-2007 20:11:41 |
Memoria virtual demasiado baja. | Diavlo | Windows | 1 | 03-07-2006 00:21:31 |
Excesivo consumo de memoria | 1111111 | Firebird e Interbase | 11 | 18-06-2005 23:08:20 |
Consumo de memoria | Telemaco | Conexión con bases de datos | 0 | 26-10-2004 15:59:44 |
Liberar Memoria Virtual | susje | Varios | 1 | 23-07-2003 20:52:40 |
![]() |
|