Publisher physical memory usage is 95%, sometimes peaks to 99%. Is this normal for the Publisher? I see sqlservr.exe has 284 MB, ccm.exe has 129 MB, DCX500.exe has 45 MB, rest all processes have below 36 MB each. There are 6 dllhost.exe process but none take more than 30 MB of memory each, and 100 MB in total.
I am wondering if this is normal for a Publisher, or is there some memory leak. I have seen some more customer sites, with same approx 90% physical memory usage. The subscriber is everywhere fine, at about 58% usage.
How many phones are registered with the Publisher ?
Does event viewer report any problems/errors ?
Are users experiencing problems How long has the CM been up and how long has it been running at 95%
This shouldnt be a problem if you dont have any viruses.Ive seen several CM running at around 90%
When callmanager boots up it loads the SQL db into memory 284mb is not that large.But what you dont want happening is information being swapped to disk.
You might want to look at adding some memeory and it wouldnt be a bad idea upgrading the OS version your a little way behind... and there are some nasty vulnerabilities which have havocked CM's these are patched with later releases.
I had the same problem albeit 3.3.3sr1 peaking at 99%most times. However, DLLHost was the torn in my flesh owing to a bug in MLA 1.2.2. After the mla patch to 1.2.2sr1 things has since returned to normal, though I am going to throw another gig of memory at it, the publisher that is.
I had a similar problem and opened a TAC case. Eventually, I was told that CM will take up to 95% of the memory and give it out to processes as they need them. So, according to TAC, 95% usage is not a problem. You will have to check to make sure that there is not a memory leak, that, eventually, various processes give up the memory. There is a bug for memory leaks in ver 3.1.3. There is no documentation on how CM uses memory but this info came, ultimately, from the developers, according to the TAC engineer.
Thats cool guys, it looked to me like normal, the way the memory was distributed over all the processes in the Publisher. I didnot see any particular processes holding abnormal amount of memory, so that should be normal.
And yes, I believe we will upgrade OS to 2000.2.5sr5. Btw, there are 480 phones, 170 cti ports and 70 route points.
I have found that the easiest way of identifying a memory leak is to take serveral snapshot/print screens of all the processes in task manager, and their associated amount of memory over a period of a week
Record the data in excel spreadsheet. By the end of the week you should have enough data to create a line graph for each process, and identify any substantial leaps in memory.
IntroductionCUCM Routing RulesDial String implementation PolicyCUCM Routing LogicSIP URI Call Routing Analysis+++ Case Study: 1 ++++++ Case Study: 2 +++Conclusion
Over the last few months, I have had the privilege of working on SI...
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...