This isn't an uncommon issue for Unity servers. Many of the issues are the result of SQL being on the system which, by it's very nature, will eat up as much memory as is available until another process calls on it and, at that time, it will give some of it back up for the requesting process. It also wn't usually use enough to crash the system although it may use a very large amount. Here is a great article about SQL behavior...
There's a nice MS doc that covers this:
http://support.microsoft.com/kb/321363
Typically 30% is very high threshold to have setup. I would honestly recommend 15% and have had to even recommend as low as 5% to 8% to avoid the alarms and the system was still stable with no issues. I would start with 15% for now. Also, if you are using CUOM it's recommended to run any system for a time to get a baseline before setting arbitrary monitoring percentages so that you don't run into this problem and know what the average memory usage is going to be during normal opporation for your system. Here is some info on that from one of my other case worked previously with alarms from CUOM.
You have to essentially create a baseline and then set your values based upon a baseline.
Here is a URL that covers Performance Monitoring:
http://www.cisco.com/en/US/partner/docs/voice_ip_comm/unity/5x/maintenance/guide/ex/5xcumge070.html#wp1089445
You have to establish a 'Normal' operating value. To do this, you
need to monitor your systems on a typical day and record the typical
range for each value. Once you have established that baseline, you
can set up alarms for values that exceed that normal range. Setting this level is tricky, but necessary. If you set it too low, you are going to get alarms weekly or daily. If you set it too high, you run the risk of degraded performance and not being alerted to it.
Thanks!
Tray
