Old Thread: http://forums.d2jsp.org/topic.php?t=66256919&f=120

So we still have not had this resolved and we are receiving the out of memory exception just about daily. When it hits it is ALWAYS when I fetch data (record, mail merge, etc.) and not when I switch modules. My CPU usage soars to 100% when I attempt to fetch data sometimes.

I did some investigation one day and kept my resource monitor open to possibly detect some sort of pattern. While I did not notice a specific pattern other than fetching data requires a lot of CPU usage- I noticed that over the course of a couple hours of fetching data, the working set of Sendouts Surge will hit >1,000,000 KB. WTF? All of my other processes combined do not use this many pages. It is worthy noting that restarting the process reduces the working set significantly.

On top it all, we are being handed a plate of bullshit: they claim our four workstations are the ONLY ones in their entire client base experiencing this issue.

This company is merging with a bigger company in the coming years and with it, requires the inheritance of the bigger company's program.

My question to the community: with the information provided, and the amount of dodging they are doing is it safe to assume there is just a huge flaw in the memory management of the program? Big enough not to invest resources in when the program will be canned in a year or two?

Unfortunately their servers have all of our data and we can't merge customer relationship managers- so I guess I just want to share my frustrations as well as request other feedback

(Here is the link to the old thread: http://forums.d2jsp.org/topic.php?t=66256919&f=120 I also have photos and videos of this error, as well as my resource monitor/task manager at the time.)

Make sure the JVM is allocated enough memory - I don't know what operating system you're running on, but look for the Xms/Xmx jvm flags and ensure that the heap size isn't artificially restricted by them.

Even though Java is a memory-managed language, it's still very possible to leak memory... i.e. http://stackoverflow.com/questions/670791/common-java-memory-reference-leak-patterns
But this may not be relevant to you if you're just running a program and have no access or control over the source code...

So I'd say... just make sure you're actually allocating enough memory to your JVM. It may also matter whether you're running on 32-bit or 64-bit systems (as 32-bit systems are hard-limited to using 4GB of memory in any case)

This post was edited by irimi on May 14 2013 06:48pm

The first thing I see / notice in the other thread is "I upgraded the RAM (>8GB) on the few systems that run the program that throws this error (Sendouts Surge CRM) and"
You're aware programs running on windows 32 have a 1.5 GB memory access limit right?

That sort of memory usage is really something you only need for stuff like SQL / Oracle.
What does the program do / what sort of stuff should one expect to see happening?
The comment in the other thread seems to hit it pretty much - memory issue in the program itself - faulty programming.
If you for example "create" a list and fill it with data, then copy it somewhere else, then create another list in a loop - you'll quickly have increasing memory. Especially if the list consists of a number of objects of structures instead of a single string or integer variable.
The key when reading data is to either create a list / object "once" and re-use it, then free it at the end.
Or create and free it after each usage (though that will be slower). If your memory usage it increasing this much, that would indicated the read data is stored raw as an uncompressed list into the memory of the client program.
Generally if you have a database worth (for example) 200 MB, and read this into your client app's memory as a list / struct, you can expect this data to inflate to about 4x it's database size.

If you can create a CSV / XML dump of your current data, you can always convert it to another database or program later.
Export you data - that's the important thing to do.

There is absolutely nothing you can do in terms of machine hardware if the software is having a level of memory management this bad.
I'm guessing you don't have the source code either?

How "big" is this database with 150k profiles?
What does the program you use "do"?

This post was edited by bbrtki on May 16 2013 08:28am