#1 2010-12-09 14:51:08

**_cgoldman_**

Memory requirements

We are currently using two servers for Adobe Connect, one with 4 GB of memory, and the other with 3.5 GB (4 GB is installed, but the OS only sees 3.5).

At a "peak" time (when we experience problems), we might see (as an example) 22 meeting rooms and 118 total people, which are distributed between our two servers.

Even though the usage numbers seem low, we have been struggling with our servers running out of available memory.  For the java process itself (jvm), the "free memory" sometimes goes down to 30 mb or so as reported by the health checker in the debug log (i.e. it gets too low for a garbage collection to be able to help?), and the subsequent result is a jvm hang -- with the wrapper then restarting the Adobe Connect service.

In general, based on the configuration, java seems to be capped at using 1 GB of memory.  The rest of the memory usage seems to come from the FMSCore.exe processes.  Sometimes we have FMSCore processes that use ~ 207 mb, 348 mb, or 655 mb of memory (to give some examples).  Obviously, the more meetings with have with FMSCore processes that use this much memory -- the more likely our system is to run out of available memory.

The questions which I would like to ask here:

- Are others seeing occasional high memory usage by FMSCore processes?

- Is anyone else finding that their servers can only handle a given number of rooms and people (less than the normal 500 people, etc. which should be supported on a single server)?

- Has anyone else experienced problems with the server(s) running out of memory, both in general and for java itself?

Thanks,
Charles.

**_mrock66_**

Re: Memory requirements

It sounds like you have some type of server or config issue.  Connect 7.5 and 8 run fine with 4GB of ram on our tests.  It can hold quite a number of meetings rooms per server too (i think 50 or so)

**_Connect_User_**

Re: Memory requirements

Were you able to identify the root cause and resolve the issue?
I would be interested to know.

**_cgoldman_**

Re: Memory requirements

I don't think that we really identified the root cause.  We "solved" (or at least temporarily worked around the problem) by adding more memory to our servers.

**_Connect_User_**

Re: Memory requirements

Are you on VMs or physical machines?

**_cgoldman_**

Re: Memory requirements

We actually have a mix -- one machine is physical, and the other is a VM.

I should amend and clarify my previous response here -- in addition to adding more overall memory to each server, we also allocated a bit more memory to the jvm (within the limits imposed by the 32-bit nature of the jvm).  Perhaps both of those changes have helped us.

**_Connect_User_**

Re: Memory requirements

I am wondering if you can share your hypervisor and vms config. We are in the process of upgrading to AC8 and I have the opportunity to make some infrastrucutre improvements. Based on your experience perhaps I can add more memory if we are short of and avoid the performance issue later.

**_cgoldman_**

Re: Memory requirements

Our configuration is the default for a Windows 2008R2 server, with the exception of the amount of RAM.  We are currently setup with 6 GB of RAM, although at least 8 GB would be preferable (at least in our environment/situation).

**_TrevorMartin_**

Re: Memory requirements

We have two VM servers running Connect that were previously running 4GB each but now have 8GB allocated. The FMS Cores were never much a problem. My issue was SQL running rampant with memory caching. After I set a cap on what it can use, I didn't have an issue. Still, during large seminars, the VM would bog a little bit, hence the 8GB upgrade. They both work beautifully now.

**_Connect_User_**

Re: Memory requirements

Thanks a lot.

Pardon my ignorance. Can you please assist me a lttle on what was the issue with SQL running rampant with memory caching? and how did you cap it? I have a SQL Server running on a physical machine with 12 GB of RAM.

**_TrevorMartin_**

Re: Memory requirements

MS SQL by nature will kidnap as much memory as it can get it's hands on because it assumes that it will need it at some point. So ultimately, it doesn't matter if you have 4 or 48 GB of RAM, SQL will eventually take all of it unless you cap it. It's not actually using most of it, but it "reserves" it.

To set a limit:

Open MS SQL Server Management Studio
Right click on your server in the Object Explorer window (in my case it was "localhost")
Click on Memory in the list on the left
There is a box on that page that says "Maximum server memory (in MB)"
Set that number to whatever is reasonable. My VM's have 8GB a piece and I have a cap of 2000 MB.

This will prevent MS SQL from using any more than around 2GB of memory.

Please note that the number you set is entirely dependent on how big your database is. For example, don't set the limit of 1000 GB when your database is huge. If SQL actually needs more memory than you're allowing it to use, it will run incredibly slow and eventually cause Connect to crash.

How big is your database?

**_Connect_User_**

Re: Memory requirements

As of now, my database is pretty small. Its somewhere around 5GB but its going to grow pretty soon since we have increased the ccu to 850. I am wondering if I should set it up to 2GB. Hopefully, it should be ok for a DB roughly the size of 50GB?

Please advise.

**_TrevorMartin_**

Re: Memory requirements

2 GB is probably not big enough for a large database, especially if it's a very active one. If you're users are constantly running tons of meetings, uploading content, modifying things, etc your DB is getting bombarded by queries. 850 concurrent users will probably require more than 2 GB. Since your server has 12 GB, I'd think about giving SQL 4 or so. You could always test it and scale up as necessary. Once you hit a number that doesn't cause anything to bog down then you can rope it off. A good test is to run reports in the web app. Reports are a telltale sign that the DB is being sluggish.