Hello Jarl, LG, Frederick, everyone I have also entered into that discussion about what is normal, since performance is not really affected, I mean, they do not notice slow response, timeouts or anything like that. I really do not know how much % is normal, all that I see is the sniffer report where Remedy is using most of the pipe 70% of the time, say, from 9am to 1pm, and I understand it is in real time, I mean the tool is not able to trace histoircal data. If the other applications are only left with 30% but not affected in performa nce, there should not be any concern. It is only that network guy is not aware of these implications from user perspective, he only sees a graph and Remedy using most of his pipe.
I also have the Remedy SQL logs, I should find anything strange there, I have deactivated some custom escalations since I think they are generating most of this flow of information. Based in all of your reponses, I see if this customer is limited to a 10Mbps channel, would it be reasonable to respond as an official statement that this behaviour is normal and that this 10Mbps should be incremented so Remedy does not Thank you and Best Regards, Mauricio 2011/2/9 LJ LongWing <[email protected]>: > Mauricio, > I have this type of discussion with people on a regular basis, and I must > ask them 'define too much'. In this situation I would argue that it's not > that the Remedy server is utilizing too much bandwidth, but instead that the > pipe size between the app server and the db server is too small. Remedy is > a 'chatty' application. I recently read a doc on performance and it says > that if your db server is not on the same node as the app server, expect > your network bandwidth needs to double, this means that most of the > interaction that comes from the client (web or native) goes through the app > server to the db. I think you should be sitting on a 100MB or even 1GB > connection, and if possible, have your app server sitting on the same switch > as the db server so nothing needs to go over any links in your network.... > > So in short, if it's using too much % of the pipe, increase the size of the > pipe and move it to the same subnet so it doesn't clog as many pipes between > point 1 and point 2 > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[email protected]] On Behalf Of Mauricio M. > Sent: Wednesday, February 09, 2011 10:54 AM > To: [email protected] > Subject: Sniffer Pro v4.5 reports ARServer consuming too much bandwidth > > Hello, > > > Does anyone can shed some light on how to troubleshoot and give a good > approach to a situation I am facing with a customer? > > I am not a network expert, but our customer is reporting way too much > bandwidth consumption between ARServer box and Oracle DB box in a L2L > with 10Mbps. ARSystem is 7.0 on Linux, they are using a really old > Remedy Helpdesk version 6.0 and the BD is Oracle10.12g. The linux box > is dedicated to Remedy and it is not heavily used, there are a very > few users connected any given time. > > The network guy is providing me with some graphs and data they have > collected using Sniffer Pro Version 4.50.04. According to his > explanation, the numbers and percentages he provides in the following > output represent the amount of bytes that are being transmitted since > the sniffer is activated. > > For instance, I have this snapshot at 10:45 am, where he reports a > total amount of 199,350,000,000 bytes being transmitted in that > particular moment, and Remedy using 140,607,1000,000 bytes of that > total. > > The table he provides shows the following: > > Point 1 (Remedy) to Point 2 (Node 1 Oracle Database): 70.44% bandwith usage > Point 1 (Inconcert) to Point 2 (x): 9.07% > Point 1 to Point 2: 1.67% > Point 1 to Point 2: 1.4% > (Some other business applications are listed in the table, I am not > listing them but they give me a total of 100%) > > I would appreciate some insight on this issue, what other factors > should I consider > > Thank you > > Mauricio > > ____________________________________________________________________________ > ___ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
