Hi Axton, Good question. The server team has stated that they have frequent problems with this server. It often will just hang and requires a restart. Also, escalations tend to bottleneck and run behind for things like notifications. On the Database side,. DBA maintains that the database is not bottlenecking. He has also run the Oracle analyzer gadget to see if there are any index recommendations that come back, but the report he gets back is that there is no room for improvement.
Our slowest process time is during the Push action to CTM:People. I ran a log on this action and found that there is quite a bit of OOTB workflow that fires on Submit and Modify of CTM:People to keep supporting forms updated. I analysed each of these Fiilters, looking at the Push Quals, then looking at the form indexes that they are pushing to. This was a manual process but I found that all OOTB Push Actions do have the correct indexes to support the push based on the Quals being used. .ron On Thu, Jun 14, 2012 at 12:47 PM, Axton <axton.gr...@gmail.com> wrote: > ** I am curious what you were seeing on the original Windows escalation > server that led you to believe that the server could not handle the load. > Generally, the bottleneck for escalations is the database, especially when > you start setting up lots of escalation pools. > > Axton Grams > > > On Thu, Jun 14, 2012 at 11:05 AM, patchsk <vamsi...@gmail.com> wrote: > >> ** Ron, >> Remedy has escalations feature to support recurring tasks, it can be used >> to certain extent for bulk or mass updates. >> But the tool is not very scalable if you are talking about very bulky >> jobs or too many recurring jobs. Though I have not seen many people >> reaching to this extreme but every company is different on how they use >> remedy. >> So the idea is offload them from escalations as much as possible and >> still be compatible with remedy workings. >> >> Here are a few things I can think of: >> >> 1. As Frederick mentioned you can create some java or perl programs using >> remedy apis. Embed them in a shell script and call those shell scripts >> using cronjobs or job scheduling tools. Since you are going through remedy >> api all the serverside workflow will still be triggered and all the >> validations and push fields will be perfomed. >> Prefer Java/C as there isn't any active support for ARS Perl. In this way >> though all the load is still be taken care by arserver, esclation has >> nothing to do with this. >> You can build as many arservers as you want and have these scripts >> connect to different arservers. So this can be very scalable. >> Also Remedy ITSM OOTB ignores indexes at several places so analyze >> where the lag is and try to create indexes where possible. >> >> 2. Another thing you can look into is, use the current mechanism you are >> doing, and where ever possible and you do not need any workflow to be >> triggered during escalation updates, create a filter with RunIF: $USER$ = >> "AR Escalator" and Action:GoTo 999. This will skip all the workflow during >> escalation runs. >> >> 3. You are correct, any updates directly at SQL level will not fire >> remedy workflow and will be significantly faster as you are removing the >> whole application layer. >> But BMC standing is you will loose the support if you directly touch the >> data. So use it as a last resort and check with them before hand. >> >> >> On Thursday, June 14, 2012 4:02:02 AM UTC-7, Ron Tavares wrote: >>> >>> ** >>> Hi Vamsi >>> >>> Yes, BMC does raise concern in regards to the mixed OS. But they have >>> not yet told us that is not supported. I agree that it would be best to be >>> on the same OS. If we get good results with running escalations on >>> Solaris, the plan is to eventually move all our ARs to Solaris. >>> >>> Yes, we are using escalation pools. We plan on extending escalation >>> pools to some of the out of box escalations as well, once we confirm the >>> Solaris box can handle the extra workload. >>> >>> The idea of using cronjobs is interesting. I'm assuming you are talking >>> about cronjobs that would run some SQL scripts that would do the work of >>> the Escalations/Filters? I imagine we could get better processing times >>> out of this. However, I'm also thinking that this would prevent necessary >>> subsequent workflow from firing. For example, when you perform a Push >>> Filed to CTM:People, there is extensive out-of-box workflow that fires and >>> updates a bunch of related records. Pushing values to CTM:People via a SQL >>> action would not fire this workflow, correct? My guess is that it wouldn't >>> but I could be wrong as I never tried it. >>> >>> .ron >>> >>> On Thu, Jun 14, 2012 at 2:13 AM, patchsk <vamsi...@gmail.com> wrote: >>> >>>> ** >>>> The cleanest way you can do this is by using server group feature, from >>>> your description it seems you are already using that feature. >>>> >>>> I have worked on Windows,Solaris , Linux environments. >>>> But your scenario is tricky, as you are mixing windows arservers with >>>> solaris arserver. >>>> I have not seen in the manuals/white papers or haven't heard before >>>> people attempting to create server groups with remedy servers on different >>>> OS. >>>> There isn't anything very sticky OS related stuff stored in Remedy >>>> Metadata, so it may even work, but I am not sure. >>>> Did you guys check with BMC if this even possible? >>>> I think the best practice is to have all servers in the group to be of >>>> same OS and Remedy Version/patch. >>>> >>>> Are you using escalation pools? It will increase the throughput as with >>>> pools multiple escalations can run parallel. >>>> >>>> Also corporates usually will have some job scheduling tools like BMC >>>> ControlM. See if you can convert some of the escalations into cronjobs or >>>> some kind of jobs. >>>> >>>> >>>> On Wednesday, June 13, 2012 5:26:02 AM UTC-7, Ron Tavares wrote: >>>>> >>>>> ** >>>>> >>>>> Good Morning Listers, >>>>> >>>>> >>>>> >>>>> *The Problem:* >>>>> >>>>> We have lots of escalation traffic running on our system, which causes >>>>> our current Windows Escalation server to be over-taxed. To the best >>>>> of my knowledge, there is no way to run escalations on more than one >>>>> server >>>>> at any given time. >>>>> >>>>> >>>>> >>>>> *Solution Attempted:* >>>>> >>>>> So, we are in the process of standing up and configuring a new AR >>>>> server on Solaris 10, hoping that this will have more horsepower to handle >>>>> the large traffic. But we are having some issues. >>>>> >>>>> >>>>> >>>>> First off, we are not seeing the increase in processing time that we >>>>> had hoped for. We are also seeing various errors show up whenever >>>>> escalations fire workflow that touches the CTM:People form. It’s >>>>> important to note that these do not show in the arerror.log, but rather >>>>> they appear in the Putty session that was used to start the AR Server >>>>> process. Examples of errors are as follows: >>>>> >>>>> >>>>> >>>>> Error signaling server <server name> >>>>> >>>>> Message number : 91 >>>>> >>>>> Message : RPC call failed >>>>> >>>>> Appended : RPC: Unable to receive; An event requires attention >>>>> >>>>> Status Struct : >>>>> >>>>> Message type : ERROR >>>>> >>>>> >>>>> >>>>> Error signaling server <server name> >>>>> >>>>> Status List : 1 items >>>>> >>>>> in thread "Status List : 1 items >>>>> >>>>> Message number : 90 >>>>> >>>>> main Message : Cannot establish a network connection to the AR >>>>> System server >>>>> >>>>> " Appended : <server name>: RPC: Success >>>>> >>>>> >>>>> >>>>> Message : RPC call failed >>>>> >>>>> java.lang.**NoClassDefFoundError**: http://localhost:8080/rkm/**from** >>>>> Remedy/jsp?reset=**remedyUsers<http://localhost:8080/rkm/fromRemedy/jsp?reset=remedyUsers> >>>>> Message type : ERROR >>>>> >>>>> >>>>> >>>>> There are other issues as well, such as the ARDBC Plugin appearing to >>>>> load repeatedly every 10 minutes or so, after the AR Server starts. We >>>>> have tried increasing and decreasing the List and Fast threads. The >>>>> Escalations that we are testing are running on dedicated pools, and we >>>>> have >>>>> added the necessary threads to support those pools. The server does >>>>> not show that it is being maxed out on memory or CPUs. >>>>> >>>>> >>>>> >>>>> *Bottom Line: * >>>>> >>>>> I think we just do not have this Solaris box configured correctly for >>>>> Remedy. Perhaps we are approaching this with a “Windows” mentality >>>>> and missing some key steps. So, my question is; is there anyone out >>>>> there that is knowledgeable in configuring AR Servers on Solaris, and/or >>>>> has seen these issues before. I could really use some pointers here >>>>> as I am trying to guide the customer in the right direction, with my >>>>> limited experience/knowledge in UNIX environments. >>>>> >>>>> >>>>> >>>>> *Here are our specs:* >>>>> >>>>> ARS 7.1 p11 >>>>> >>>>> ITSM 7.0 >>>>> >>>>> DB Oracle10 running on Solaris 10 >>>>> >>>>> All AR Servers are running on Windows Server 2003, (with the exception >>>>> of the new Escalation server which is running on Solaris 10) >>>>> >>>>> We have a dedicated AR Server for Administrator functions and a >>>>> dedicated server for Escalations. >>>>> >>>>> >>>>> >>>>> Thanking all you Solaris Gurus in Advance, >>>>> >>>>> >>>>> >>>>> Ron >>>>> _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ >>>> >>>> _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ >>>> >>> >>> _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ >> >> _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ >> > > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
