And that is why SAS is going to take over. Systems management is easier to justify at larger scales.
Sent from my iPhone > On Dec 15, 2017, at 11:42 PM, Anthony Holloway > <avholloway+cisco-v...@gmail.com> wrote: > > Out of curiosity, how long had Tomcat been running before you restarted it? > > This isn't at you Terry, but in general. > > Companies will spend a lot of money getting systems in place, but then > completely forget that technology has a life cycle; leading towards a better > experience. And no, I don't just mean upgrade to the latest shiny version. > I mean, efficiency, features, user experience, stability, scale, shorter MTTR. > > Without being able to quantify it, I have seen more than a comfortable amount > of environments without: a pre-production environment, proper analytics, > proper change control, a good monitoring solution (emails from RTMT don't > count), resource usage monitoring, a good backup strategy, vmtools up to > date, and anything other than just MACD work being performed. > > It's like there's this sole effort on "projects," and the old saying: "if > isn't broke, don't fix it," wins again. We lose the chance to truly > understand our systems, and therefore the chance to optimize them. > > /rant > > Disclaimer: Today was a long cutover, and I'm tired > > PS Ryan amazes me too. > >> On Thu, Dec 14, 2017 at 10:32 PM Terry Oakley <terry.oak...@rdc.ab.ca> wrote: >> Thank you again Ryan. I think I found the issue. One of the tests showed >> a problem with AXL services. Restarted Tomcat and we appear to be much >> better. >> >> >> From: Terry Oakley >> Sent: Thursday, December 14, 2017 5:29:31 PM >> To: Ryan Huff >> >> Cc: cisco-voip@puck.nether.net >> Subject: Re: [cisco-voip] UC server performance and UCCX agent in reserve >> Thanks Ryan.. .I will have a look tonight.. >> >> PS i don't know how you find all the time to respond to all of us but I am >> very thankful that you do. 😊 >> From: Ryan Huff <ryanh...@outlook.com> >> Sent: Thursday, December 14, 2017 5:26:53 PM >> To: Terry Oakley >> Cc: cisco-voip@puck.nether.net >> Subject: Re: [cisco-voip] UC server performance and UCCX agent in reserve >> >> Just based on that description alone, I’d say it might be possible you have >> some LAN congestion? >> Everything you’re talking about here is riding http/https. >> >> - Any recent QoS policy changes? >> >> - Is other non-UC web traffic slower than normal from those PCs? >> >> - Run utils diagnose test on the CLI of each server and see if you find any >> goodies ... >> >> -Ryan >> >> On Dec 14, 2017, at 7:18 PM, Terry Oakley <terry.oak...@rdc.ab.ca> wrote: >> >>> For the past week and a bit I have noticed a decline in UC (Call Manager) >>> response time when editing/adding a device. The message 'loading' stays >>> on for 5 to 10 seconds or even longer. Page refresh is also really slow. >>> In looking at RTMT the CPU/Memory/disk space are all around 50% or less >>> with no apparent spikes. Any suggestions on where this lag could be? >>> >>> On another but may be related , a couple of our agents (but not all) both >>> have had their phones restart while in use, and today both had their agent >>> go into Reserved state for a couple of minutes before finally connecting >>> and allowing them service. Again any suggestions on where one would >>> look would be appreciated. >>> >>> UC 11.5 SU3 >>> UCCX 11.5 >>> IMP 11.5 SU3 >>> O365 >>> Unity Connection 11.5 >>> >>> Terry >>> >>> _______________________________________________ >>> cisco-voip mailing list >>> cisco-voip@puck.nether.net >>> https://puck.nether.net/mailman/listinfo/cisco-voip >> _______________________________________________ >> cisco-voip mailing list >> cisco-voip@puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-voip > _______________________________________________ > cisco-voip mailing list > cisco-voip@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip