slxdeveloper.com Community Forums

The Forums on slxdeveloper.com are now retired. The forum archive will remain available for the time being. Thank you for your participation on slxdeveloper.com!

Administration Forums - General Administration
Forum to discuss general administration topics for SalesLogix (including LAN & remote topics). View the code of conduct for posting guidelines.

Forums RSS Feed

Back to Forum List | Back to General Administration | New Thread

View: Search:

Author

Thread: 6.2.4 Memory issues?

John Oberg
Posts: 28

6.2.4 Memory issues? Your last visit to this thread was on 1/1/1970 12:00:00 AM

Posted: 28 Jun 06 9:42 AM

We just recently upgraded one of our clients from 6.1 to 6.2.4. They have ~50 users with no remotes, plus an instance of KnowlegeSync that handles some realtime updates to Opportunities, plus a nightly batch job described below. Everything went (relatively) smoothly, however there is a small problem on their SQL/SalesLogix server. Every night Mon-Fri. they have a job that uses Scribe to import changes from their AS/400 into SLX. The job can take anywhere from 2-6 hours to run. The problem is that during the job, the SLXLoggingServer process winds up taking up huge amounts of memory on the server, which it never releases back to the OS. For example, we rebooted the machine yesterday afternoon - after the process ran, SLXLoggingServer was using 512MB of memory (this is on a 2GB machine with SQL server using 1.5GB of memory at the moment, dynamically configured). We first became aware of the problem when the nightly job failed to run Monday night - investigation revealed that SLXLoggingServer was using 1.5GB of memory, SQL 1GB, causing EVERYTHING to page to disk, and the job had failed with an out of memory error.
So, on to the list of questions:
1. Does this kind of memory allocation sound somewhat normal for an implementation of this size? Or should I be looking for memory leaks?
2. Assuming this isn't a memory leak issue, is there a way to either limit the amount of memory SLXLoggingServer uses, or a way to force it to flush itself and free up allocated memory without restarting the server?
3. Are there any steps that you would recommend for troubleshooting this further?

I know this is kinda vague and fuzzy at the moment, but it's as clear a picture of the situation as I have right now

Thanks in advance for any help!

[Reply][Quote]

Frank Chaffin
Posts: 475

Re: 6.2.4 Memory issues? Your last visit to this thread was on 1/1/1970 12:00:00 AM

Posted: 28 Jun 06 10:18 AM

John,
We do not use Scribe, but we have had two similar problem with custom imports in the past. In each case it turned out to be memory leaks that SalesLogix had to fix. One fix had to do with Handles not releasing memory, the other had to do with a leak it the SetGlobalID function.

Quote:

1. Does this kind of memory allocation sound somewhat normal for an implementation of this size? Or should I be looking for memory leaks?

I think you should be looking for a memory leak.

Quote:

3. Are there any steps that you would recommend for troubleshooting this further?

See if you can recreate the situation against the SlxEval database on another system. If you can then you could ship this environment off to SalesLogix for analysis.

[Reply][Quote]

John Oberg
Posts: 28

Re: 6.2.4 Memory issues? Your last visit to this thread was on 1/1/1970 12:00:00 AM

Posted: 29 Jun 06 8:17 AM

I'm glad I'm not alone in thinking that it looks like a leak

Looks like I've got my work cut out for me to set up a test environment and pin this puppy down... Thanks for the help Frank!

[Reply][Quote]

Page 1 of 1

You can subscribe to receive a daily forum digest in your user profile. View the site code of conduct for posting guidelines.

Forum RSS Feed - Subscribe to the forum RSS feed to keep on top of the latest forum activity!

slxdeveloper.com is brought to you courtesy of Ryan Farley & Customer FX Corporation. This site, and all contents herein, are Copyright © 2024 Customer FX Corporation. The information and opinions expressed here are not endorsed by Sage Software.	code of conduct \|

page cache (param): 11/22/2024 3:58:44 PM