02-08-2014 10:41 AM - edited 03-14-2019 01:03 PM
Before opening a TAC case, I figured I'll try to see if the community can shed some light on what I'm perceiving as an issue - correct me if I'm wrong though.
I havent noticed any noticable and agent impacting CTI issues, however, when I go into Performance Monitor and monitor Talking Agent Count for process ctisvr, the number is incredibly inflated and continues to increase. I've attached a picture of PerfMon at the bottom of the post. Additionally, I've noticed a lot of QueueMSG and unQueueMSG messages in the ctisvr dumplog, over and over. Is this a concern? Also, what exactly does it mean when this says Max Calls Ever? The number says 218 now, but it was 256 a few days ago.
Events from February 8, 2014:
00:00:00:027 cg1A-ctisvr Trace: CTIApplication::ProcessTimeNotificationEvent - Time=05:00:00 UTC NewHalfHour=TRUE
00:00:00:992 cg1A-ctisvr CTIServer ACTIVE, 8 CTI Client connection(s), 0 call(s) in progress, PG Status: NORMAL
00:00:00:992 cg1A-ctisvr Period connection(s): 0 Period call(s): 0 (0.00 calls/sec)
00:00:00:992 cg1A-ctisvr Period EnterpriseCTI traffic: 42844 messages (23.80 msgs/sec)
00:00:00:992 cg1A-ctisvr 12589468 bytes / 1800 seconds (6994.15 bytes/sec)
00:00:00:992 cg1A-ctisvr 1426 heartbeats (0.79 hb/sec)
00:00:00:992 cg1A-ctisvr 1.12ms average queue time/msg
00:00:00:992 cg1A-ctisvr 0.04ms average CPU time/msg (0.09% busy)
00:00:00:992 cg1A-ctisvr EnterpriseCTI Server version: Release 9.0.3.0 , Build 206
00:00:00:992 cg1A-ctisvr Build date: 03/19/13 18:42:28
00:00:00:992 cg1A-ctisvr CTIServer UP time: 3 days 22 hours 11 minutes
00:00:00:992 cg1A-ctisvr EnterpriseCTI Meters from last: 24 hrs 0 min 0 sec
00:00:00:992 cg1A-ctisvr CTIServer-OPC traffic: 2323750 messages (26.90 msgs/sec)
00:00:00:992 cg1A-ctisvr 968872080 bytes (11213.80 bytes/sec)
00:00:00:992 cg1A-ctisvr Active time: 24 hrs 0 min 0 sec
00:00:00:992 cg1A-ctisvr Number of Connections Today: 0
00:00:00:992 cg1A-ctisvr Max Connections Today/Ever: 8 / 8
00:00:00:992 cg1A-ctisvr Number of Calls Today: 9208
00:00:00:992 cg1A-ctisvr Max Calls Today/Ever: 185 / 218
00:00:00:992 cg1A-ctisvr EnterpriseCTI traffic: 3077823 messages (35.62 msgs/sec)
00:00:00:992 cg1A-ctisvr 760914617 bytes (8806.88 bytes/sec)
00:00:00:992 cg1A-ctisvr 12578 bytes/sec (peak)
00:00:00:992 cg1A-ctisvr 1 hb/sec (peak)
00:00:00:992 cg1A-ctisvr Invalid EntCTI Msgs Rec'd: 1
00:00:00:992 cg1A-ctisvr Max Global Transmit Queue: 305
00:00:00:992 cg1A-ctisvr Max Client Transmit Queue: 305
00:00:00:992 cg1A-ctisvr OPCResponse Min/Max/Ever: 2 / 87 / 712
00:00:00:992 cg1A-ctisvr OpenResponse Min/Max/Ever: 99000 / 0 / 5
00:00:00:992 cg1A-ctisvr HBResponse Min/Max/Ever: 0 / 2 / 2
00:00:00:992 cg1A-ctisvr CtrlResponse Min/Max/Ever: 3 / 13412 / 15030
00:00:00:992 cg1A-ctisvr OtherResponse Min/Max/Ever: 0 / 112338 / 199263
00:00:00:992 cg1A-ctisvr Max Xmit Delay Today/Ever: 1048 / 1722
00:00:00:992 cg1A-ctisvr Average Msg Queue/CPU Time: 0.90ms / 0.07ms (0.19% busy)
00:00:00:992 cg1A-ctisvr MessageQueue Min/Max/Ever: 0 / 35 / 146
00:00:00:992 cg1A-ctisvr MessageCPU Min/Max/Ever: 0 / 9 / 134
00:00:00:992 cg1A-ctisvr ValidateCall Errors Today: 3
00:00:00:992 cg1A-ctisvr 0 Active Call(s), 0 Total Call(s) in progress
00:00:04:625 cg1A-ctisvr Trace: TransportProtocol::QueueMSG - CTIOSServer (SessionID 3) , Message queued: (1 msgs in the queue, max:15000)
00:00:04:625 cg1A-ctisvr Trace: TransportProtocol::QueueMSG - CTIOSServer (SessionID 3) , Message queued: (2 msgs in the queue, max:15000)
00:00:04:625 cg1A-ctisvr Trace: TransportProtocol::QueueMSG - CTIOSServer (SessionID 3) , Message queued: (3 msgs in the queue, max:15000)
00:00:04:625 cg1A-ctisvr Trace: TransportProtocol::QueueMSG - CTIOSServer (SessionID 3) , Message queued: (4 msgs in the queue, max:15000)
00:00:04:625 cg1A-ctisvr Trace: TransportProtocol::QueueMSG - CTIOSServer (SessionID 3) , Message queued: (5 msgs in the queue, max:15000)
00:00:05:625 cg1A-ctisvr Trace: TransportProtocol::UnQueueMSG - CTIOSServer (SessionID 3) , Message unqueued: (34 msgs in the queue, max:15000)
00:00:05:626 cg1A-ctisvr Trace: TransportProtocol::UnQueueMSG - CTIOSServer (SessionID 3) , Message unqueued: (33 msgs in the queue, max:15000)
00:00:05:626 cg1A-ctisvr Trace: TransportProtocol::UnQueueMSG - CTIOSServer (SessionID 3) , Message unqueued: (32 msgs in the queue, max:15000)
00:00:05:626 cg1A-ctisvr Trace: TransportProtocol::UnQueueMSG - CTIOSServer (SessionID 3) , Message unqueued: (31 msgs in the queue, max:15000)
00:00:05:626 cg1A-ctisvr Trace: TransportProtocol::UnQueueMSG - CTIOSServer (SessionID 3) , Message unqueued: (30 msgs in the queue, max:15000)
Solved! Go to Solution.
02-11-2014 07:11 PM
Omar,
Finally got around to this, no I don't see such a high number for a ctisvr which has been in production for a while. I am seeing a 3 digit number even though we only have 100 agents, but perhaps this is a cumulative number for the X past days. So if your CC is bigger you might be ok.
Was looking at the wrong thing, I too have a very large number so I think you're right it's a total count probably since it was last cycled.
Let me know if you want me to check anything else.
david
02-08-2014 10:43 AM
Omar
I'll check my lab to see what comes up, but this just seems like a bad way to check for talking agents. Is this more of a mental exercise or you don't trust what you're seeing in reporting?
david
02-08-2014 10:51 AM
Hi David,
Customer has not complained about any reporting flaws (they use Exony VIM), however, when I was conducting a turnover session to their support team earlier this week, I showed them PerfMon as one of several ways to monitor as a health check. I had selected Talking Agent Count for the ctisvr process and was surprised to see such a high number. The turnover session was Tuesday and that number, at that time, was 3,500... it's now almost 25,000.
Thanks
02-11-2014 07:11 PM
Omar,
Finally got around to this, no I don't see such a high number for a ctisvr which has been in production for a while. I am seeing a 3 digit number even though we only have 100 agents, but perhaps this is a cumulative number for the X past days. So if your CC is bigger you might be ok.
Was looking at the wrong thing, I too have a very large number so I think you're right it's a total count probably since it was last cycled.
Let me know if you want me to check anything else.
david
02-11-2014 07:48 PM
David,
Now that you mention is, this does seem to correlate with the ctisrvr process uptime. Looking at Portico right now and it tells me that the process has been up for 7 days, 20 hours, 52 minutes and 9 seconds which seems to be right on par with the moment I first looked at this counter in PerfMon. I had a turnover session to the customer last Tuesday morning and that number was in the low 200s and is now almost 30,000.
I ended up opening a low-sev TAC case just get some answers, so I appreciate your contribution to this. I'm hoping to get the other aspect of this answered - what exactly is being calculated at the beginning of the dump with Max Calls Ever, Max Connections Ever, and all the other ones that have an Ever parameter. Does the number pertaining the Ever aspect count the total number since the process was last cycled?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide