Re: Performance Issues - Multitenancy
Doug, Thank you for the additional information. I don't recall if we had the same issues with older versions, or if the addition of the parent fields add another layer of complexity in the searches, which is why we were seeing performance problems in our 9.1 implementation. Just to give everyone an idea of the numbers we are using. We have close to 300 companies configured in our system. We also have implemented row level access based on login id for some things. Like Doug mentioned we spent a lot of time figuring out data access and row level security for this particular organization. However, there are a lot of challenges and potential trade offs. Performance is one of them and we are constantly looking at how to improve performance. Prior to applying the settings that Shawn sent, our a search to CTM:People, which has roughly 13 records, would come back in 70 seconds for a regular user. After the settings were done the same search came back in less than 3 seconds, so you can see a massive improvement. Brian From: Action Request System discussion list(ARSList) <arslist@ARSLIST.ORG> on behalf of Mueller, Doug <doug_muel...@bmc.com> Sent: Tuesday, November 22, 2016 12:50 PM To: arslist@ARSLIST.ORG Subject: Re: Performance Issues - Multitenancy ** Just some background to help here…. Implementing an effective row level security model is actually quite an involved operation. It is about security so it has to be foolproof with no holes and no exceptions to data access for people without access. It has to include many complex considerations like not allowing searching on data you don’t have access to – not just limiting the return of that data… For example, if you did not have access to a salary field but you could search for people with salary > 10,000 and < 15,000, you could find out salary even though you could not see the field. So, there is some quite involved logic and SQL to protect all this. It is involved as there is no DB level support for this level of security. OK, so this is all prelude to the discussion here. We had situations where customers had users in large numbers of groups. That means we need to check permission for all those groups when checking for row level security. That generated enormous SQL commands and that could confuse the optimizers of the databases and trigger table scans. So, customers in this situation encountered significant slowness like Brian was seeing in his environment. We found alternate ways to do the query that were much more efficient in the database for large lists of users. Our testing showed that it was equivalent performance for few groups but much better (order of magnitude in many cases) for large group lists. So, we introduced a new style of qualifications for the row level security search. You can see the difference in the commands if you turn on SQL logging. Now, what we found is that there are some conditions where the combination of number of groups users are in (generally users being in small numbers of groups) and the data volume where the older strategy actually works better. We have not found a pattern of exactly what triggers one strategy to be better vs. the other. SO, we have an option that you can set – that is detailed in the message below – where you can tell the system to use one strategy or the other. It will always be the case that a row level security controlled search will be slower than an unlimited access search as there are additional checks needed. However, if you find there are major differences, you may want to check which strategy for row level security enforcement is active and see if the other one is faster for your environment. Test a variety of users as you may find that if you have a mix of users with few groups and some in MANY groups that there is a difference and you need to choose which strategy is overall best for your organization. There is no data impact or risk or anything with the two options. They both work and protect your access and are secure. They both use the same data and neither alters any data. They simply build SQL differently to do the enforcement. So, you can try both options safely. I hope this offers some insight into this situation and what occurred and why this option exists. I am glad that it was the key to helping in your situation to be able to control which strategy you were using. Doug Mueller From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Brian Pancia Sent: Monday, November 21, 2016 8:17 AM To: arslist@ARSLIST.ORG Subject: Re: Performance Issues - Multitenancy ** Shawn, Thanks. That ended up being the fix. Brian From: Action Request System discussion list(ARSList) <arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>> on behalf of Shawn Scutching
Re: Performance Issues - Multitenancy
Just some background to help here Implementing an effective row level security model is actually quite an involved operation. It is about security so it has to be foolproof with no holes and no exceptions to data access for people without access. It has to include many complex considerations like not allowing searching on data you don't have access to - not just limiting the return of that data... For example, if you did not have access to a salary field but you could search for people with salary > 10,000 and < 15,000, you could find out salary even though you could not see the field. So, there is some quite involved logic and SQL to protect all this. It is involved as there is no DB level support for this level of security. OK, so this is all prelude to the discussion here. We had situations where customers had users in large numbers of groups. That means we need to check permission for all those groups when checking for row level security. That generated enormous SQL commands and that could confuse the optimizers of the databases and trigger table scans. So, customers in this situation encountered significant slowness like Brian was seeing in his environment. We found alternate ways to do the query that were much more efficient in the database for large lists of users. Our testing showed that it was equivalent performance for few groups but much better (order of magnitude in many cases) for large group lists. So, we introduced a new style of qualifications for the row level security search. You can see the difference in the commands if you turn on SQL logging. Now, what we found is that there are some conditions where the combination of number of groups users are in (generally users being in small numbers of groups) and the data volume where the older strategy actually works better. We have not found a pattern of exactly what triggers one strategy to be better vs. the other. SO, we have an option that you can set - that is detailed in the message below - where you can tell the system to use one strategy or the other. It will always be the case that a row level security controlled search will be slower than an unlimited access search as there are additional checks needed. However, if you find there are major differences, you may want to check which strategy for row level security enforcement is active and see if the other one is faster for your environment. Test a variety of users as you may find that if you have a mix of users with few groups and some in MANY groups that there is a difference and you need to choose which strategy is overall best for your organization. There is no data impact or risk or anything with the two options. They both work and protect your access and are secure. They both use the same data and neither alters any data. They simply build SQL differently to do the enforcement. So, you can try both options safely. I hope this offers some insight into this situation and what occurred and why this option exists. I am glad that it was the key to helping in your situation to be able to control which strategy you were using. Doug Mueller From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Brian Pancia Sent: Monday, November 21, 2016 8:17 AM To: arslist@ARSLIST.ORG Subject: Re: Performance Issues - Multitenancy ** Shawn, Thanks. That ended up being the fix. Brian From: Action Request System discussion list(ARSList) <arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>> on behalf of Shawn Scutchings <shawn.scutchi...@gov.ab.ca<mailto:shawn.scutchi...@gov.ab.ca>> Sent: Friday, November 18, 2016 3:12 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Performance Issues - Multitenancy ** We had a similar issue and were provided the following by BMC: The Engineer assisting us with this issue has reviewed the information provided and agrees the query we see taking to complete are running row level access. He would like you to test disabling the new RLS implementation and use the old implementation to see if the issue persists or not. 1. Please open the Centralized Configuration form in the com.bmc.arsys.server.shared section 2. Add the following parameter: Disable-New-RLS-Implementation with a value of true Disable-New-RLS-Implementation: T 3. Restart the servers in the group This change will use a LIKE clause to allow the database to search the columns directly. Once the change has been made the servers restarted, please enable API, SQL, and Filter logging and reproduce the issue. If the performance impact is seen searching the fields that have drop-down menus for non admin users after the change has been made, please run the log zipper to gather and send the log files and forward the zip file along with the name of the user who performed the search.
Re: Performance Issues - Multitenancy
Shawn, Thanks. That ended up being the fix. Brian From: Action Request System discussion list(ARSList) <arslist@ARSLIST.ORG> on behalf of Shawn Scutchings <shawn.scutchi...@gov.ab.ca> Sent: Friday, November 18, 2016 3:12 PM To: arslist@ARSLIST.ORG Subject: Re: Performance Issues - Multitenancy ** We had a similar issue and were provided the following by BMC: The Engineer assisting us with this issue has reviewed the information provided and agrees the query we see taking to complete are running row level access. He would like you to test disabling the new RLS implementation and use the old implementation to see if the issue persists or not. 1. Please open the Centralized Configuration form in the com.bmc.arsys.server.shared section 2. Add the following parameter: Disable-New-RLS-Implementation with a value of true Disable-New-RLS-Implementation: T 3. Restart the servers in the group This change will use a LIKE clause to allow the database to search the columns directly. Once the change has been made the servers restarted, please enable API, SQL, and Filter logging and reproduce the issue. If the performance impact is seen searching the fields that have drop-down menus for non admin users after the change has been made, please run the log zipper to gather and send the log files and forward the zip file along with the name of the user who performed the search. Fixed our issue…worth a try. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Friday, November 18, 2016 1:03 PM To: arslist@ARSLIST.ORG Subject: Re: Performance Issues - Multitenancy ** Brian, Turn on SQL Logging and perform the same search between the two different users and compare the SQL, maybe even provide the sql here for analysisthe 'slow vs fast' queries should be fairly obvious what's causing the difference. On Fri, Nov 18, 2016 at 11:24 AM, Brian Pancia <panc...@finityit.com<mailto:panc...@finityit.com>> wrote: ** We are running into some serious performance issues with multitenancy. We're on BMC ITSM 9.1 SP1 and SQL Server 2012. If I do a search on a form like CTM:People with an account that has unrestricted access the search comes back in about 2-3 seconds for 13 records. That same search with a user that is restricted to a certain company will come back in 70 seconds, which is a significant difference. That is the first issue. The second issue is that the database server CPU utilization will spike to 100% during the searches. During the unrestricted user test not a big deal because it is only a couple seconds and no one notices the spike. However, for the other user it brings the system to a halt for 70 seconds. If the user kills their session prior to the search complete the search will hang in the database and consume 100% of the CPU indefinitely. Any recommendations would be appreciated. We have done all the BMC recommended performance tuning on the systems. Thanks, Brian DISCLAIMER: The information contained in this e-mail and its attachments contain confidential information belonging to the sender, which is legally privileged. The information is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are notified that any disclosure, copying, distribution or action in reliance upon the contents of the information transmitted is strictly prohibited. If you have received this information in error, please delete it immediately. _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. _ARSlist: "Where the Answers Are" and have been for 20 years_ DISCLAIMER: The information contained in this e-mail and its attachments contain confidential information belonging to the sender, which is legally privileged. The information is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are notified that any disclosure, copying, distribution or action in reliance upon the contents of the information transmitted is strictly prohibited. If you have received this information in error, please delete it immediately. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Performance Issues - Multitenancy
We had a similar issue and were provided the following by BMC: The Engineer assisting us with this issue has reviewed the information provided and agrees the query we see taking to complete are running row level access. He would like you to test disabling the new RLS implementation and use the old implementation to see if the issue persists or not. 1. Please open the Centralized Configuration form in the com.bmc.arsys.server.shared section 2. Add the following parameter: Disable-New-RLS-Implementation with a value of true Disable-New-RLS-Implementation: T 3. Restart the servers in the group This change will use a LIKE clause to allow the database to search the columns directly. Once the change has been made the servers restarted, please enable API, SQL, and Filter logging and reproduce the issue. If the performance impact is seen searching the fields that have drop-down menus for non admin users after the change has been made, please run the log zipper to gather and send the log files and forward the zip file along with the name of the user who performed the search. Fixed our issue…worth a try. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Friday, November 18, 2016 1:03 PM To: arslist@ARSLIST.ORG Subject: Re: Performance Issues - Multitenancy ** Brian, Turn on SQL Logging and perform the same search between the two different users and compare the SQL, maybe even provide the sql here for analysisthe 'slow vs fast' queries should be fairly obvious what's causing the difference. On Fri, Nov 18, 2016 at 11:24 AM, Brian Pancia <panc...@finityit.com<mailto:panc...@finityit.com>> wrote: ** We are running into some serious performance issues with multitenancy. We're on BMC ITSM 9.1 SP1 and SQL Server 2012. If I do a search on a form like CTM:People with an account that has unrestricted access the search comes back in about 2-3 seconds for 13 records. That same search with a user that is restricted to a certain company will come back in 70 seconds, which is a significant difference. That is the first issue. The second issue is that the database server CPU utilization will spike to 100% during the searches. During the unrestricted user test not a big deal because it is only a couple seconds and no one notices the spike. However, for the other user it brings the system to a halt for 70 seconds. If the user kills their session prior to the search complete the search will hang in the database and consume 100% of the CPU indefinitely. Any recommendations would be appreciated. We have done all the BMC recommended performance tuning on the systems. Thanks, Brian DISCLAIMER: The information contained in this e-mail and its attachments contain confidential information belonging to the sender, which is legally privileged. The information is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are notified that any disclosure, copying, distribution or action in reliance upon the contents of the information transmitted is strictly prohibited. If you have received this information in error, please delete it immediately. _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Performance Issues - Multitenancy
Brian, Turn on SQL Logging and perform the same search between the two different users and compare the SQL, maybe even provide the sql here for analysisthe 'slow vs fast' queries should be fairly obvious what's causing the difference. On Fri, Nov 18, 2016 at 11:24 AM, Brian Pancia <panc...@finityit.com> wrote: > ** > > We are running into some serious performance issues with multitenancy. > We're on BMC ITSM 9.1 SP1 and SQL Server 2012. If I do a search on a form > like CTM:People with an account that has unrestricted access the search > comes back in about 2-3 seconds for 13 records. That same search with > a user that is restricted to a certain company will come back in 70 > seconds, which is a significant difference. That is the first issue. The > second issue is that the database server CPU utilization will spike to 100% > during the searches. During the unrestricted user test not a big deal > because it is only a couple seconds and no one notices the spike. However, > for the other user it brings the system to a halt for 70 seconds. If the > user kills their session prior to the search complete the search will hang > in the database and consume 100% of the CPU indefinitely. > > > Any recommendations would be appreciated. We have done all the BMC > recommended performance tuning on the systems. > > > Thanks, > > > Brian > > > DISCLAIMER: The information contained in this e-mail and its attachments > contain confidential information belonging to the sender, which is legally > privileged. The information is intended only for the use of the > recipient(s) named above. If you are not the intended recipient, you are > notified that any disclosure, copying, distribution or action in reliance > upon the contents of the information transmitted is strictly prohibited. If > you have received this information in error, please delete it immediately. > _ARSlist: "Where the Answers Are" and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Performance Issues - Multitenancy
I do not have any suggestions, I do assume that the rest of the experts will want to know the Server configuration such as how may servers, CPUs, GB RAM -Original Message- From: Brian Pancia <panc...@finityit.com> To: arslist <arslist@ARSLIST.ORG> Sent: Fri, Nov 18, 2016 1:25 pm Subject: Performance Issues - Multitenancy ** We are running into some serious performance issues with multitenancy. We're on BMC ITSM 9.1 SP1 and SQL Server 2012. If I do a search on a form like CTM:People with an account that has unrestricted access the search comes back in about 2-3 seconds for 13 records. That same search with a user that is restricted to a certain company will come back in 70 seconds, which is a significant difference. That is the first issue. The second issue is that the database server CPU utilization will spike to 100% during the searches. During the unrestricted user test not a big deal because it is only a couple seconds and no one notices the spike. However, for the other user it brings the system to a halt for 70 seconds. If the user kills their session prior to the search complete the search will hang in the database and consume 100% of the CPU indefinitely. Any recommendations would be appreciated. We have done all the BMC recommended performance tuning on the systems. Thanks, Brian DISCLAIMER: The information contained in this e-mail and its attachments contain confidential information belonging to the sender, which is legally privileged. The information is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are notified that any disclosure, copying, distribution or action in reliance upon the contents of the information transmitted is strictly prohibited. If you have received this information in error, please delete it immediately._ARSlist: "Where the Answers Are" and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Performance Issues - Multitenancy
We are running into some serious performance issues with multitenancy. We're on BMC ITSM 9.1 SP1 and SQL Server 2012. If I do a search on a form like CTM:People with an account that has unrestricted access the search comes back in about 2-3 seconds for 13 records. That same search with a user that is restricted to a certain company will come back in 70 seconds, which is a significant difference. That is the first issue. The second issue is that the database server CPU utilization will spike to 100% during the searches. During the unrestricted user test not a big deal because it is only a couple seconds and no one notices the spike. However, for the other user it brings the system to a halt for 70 seconds. If the user kills their session prior to the search complete the search will hang in the database and consume 100% of the CPU indefinitely. Any recommendations would be appreciated. We have done all the BMC recommended performance tuning on the systems. Thanks, Brian DISCLAIMER: The information contained in this e-mail and its attachments contain confidential information belonging to the sender, which is legally privileged. The information is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are notified that any disclosure, copying, distribution or action in reliance upon the contents of the information transmitted is strictly prohibited. If you have received this information in error, please delete it immediately. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Regarding Tomcat 6.0 Performance Issues
Hi Team, We are using *Tomcat 6.0* as our AR System Mid-Tier and we are getting performance issues of 150% CPU utilization as shown below. *MESSAGE: us194px04.tycoelectronics.net <http://us194px04.tycoelectronics.net> - Total Processor Time (150.57%) for tomcat6 process has met/exceeded the threshold (80.00%) * *NODE: us194px04.tycoelectronics.net <http://us194px04.tycoelectronics.net>* When this alert starts triggering, one of our Web Services running in this Tomcat Server starts failing and starts throwing the below error. *US194WB136.us.tycoelectronics.com <http://US194WB136.us.tycoelectronics.com> TycoApps HRFormTool 3/17/2016 12:33:44 PM [DE] CreateRemedyTicket: Unable to connect to the remote server at 2016-03-17 16:33:44Z US194WB136.us.tycoelectronics.com <http://US194WB136.us.tycoelectronics.com> TycoApps HRFormTool* When we spoke with the BMC Support we got the below recommendations for increasing the Heap Size and also change in the GC Settings as shown below. *Those settings are: * *-XX:+UseCompressedOops* *-XX:+UseConcMarkSweepGC* *-XX:+UseParNewGC* *-XX:NewRatio=3* *-XX:PermSize=256m* *-XX:+HeapDumpOnOutOfMemoryError* *-XX:ErrorFile=\java_hs_err.log* *-XX:HeapDumpPath= (Add path here) * *Note: Min and Max heapsize recommended is 1024 and 2048 (These values can be changed and optimized according to the environment). * We wanted to understand whether the above changes would increase the performance of the Tomcat Server and also resolve the above specified error. Expecting your expert level guidance on the above issue. Thank you, Sriram. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
8.1.01 Change Approval Performance Issues
Within 8.x, BMC has deprecated old AR Approval Process by reducing the approval process from 16 to just 4. See link below: https://communities.bmc.com/community/bmcdn/bmc_it_service_support/change_process_management/blog/2014/01/23/change-approval-processes-consolidation-in-itsm-cm-8x The OOB change approval processes are now evaluating both CIs and Impacted Areas for change approvals. We are working on improving our overall Change process maturing and have started adding companies on changes within the impacted areas and associating all CIs that are affected by the specific change. Our process for our technicians is to relate the CIs that are impacted by your change and then use the Impact Analysis functionality to relate any other CIs that are also affected. This can result in thousands of CIs being related to the change ticket. This is where the problem begins :) When moving the change ticket through the approval process, the approval engine then has to sift through CHG:Change-ImpactedAreasCIAssociation_outer_ApproverLookup to evaluate every single CI and Impacted area to determine whether there is an approval mapping to tied to them. We have had many instances where this evaluating has been still occurring after 12hrs+ which we have had to delete in the app pending form because other records were queued up behind it. We have a ticket opened with BMC, but they haven't been helpful other than saying you shouldn't have more than 1,000 CIs associated to a change ticket. (really???) Are there any improvements that can be made to improve the performance of the approval server that we haven't done already? (see setup below) Below is current setup: -5 Sun Solaris App Servers (2 dedicated for Server Group processes (8 CPU 16GB RAM each), 3 User Facing (4CPU 16GBRAM each)) -Dedicated RPC port 390680 (Min=6 Max=8) and thread logs show it stays around 7. -RPC Loopback plugin configured on 390626 (Min=4 Max=12) and thread logs shows it says around 4-5. -Definition Check Interval = 300 -Thread Count = 4 -Fast Threads Min=12 Max=40 -List Threads Min=12 Max=40 I know we can modify the AP:Process to look at other forms instead of the CHG:Change-ImpactedAreasCIAssociation_outer_ApproverLookup or re-enable the deprecated processes, but then if we have any issues in the future, BMC will point out that we are following the OOB processes so I'm trying to utilize the OOB processes before I take that route. Are there any other folks out there that are using the OOB approval processes in 8.x and relating thousands of CIs without issues? ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: 8.1.01 Change Approval Performance Issues
Jamie, I don't run ITSM, so my comment here is more anecdotal than anything elsebut, I have heard that CMDB is not necessarily the most properly indexed beast out there. So, I personally look at the values that are being used as join criteria on anything related to that join, and ensure that all of the join criteria records are indexed properly, then re-run a test to see if you see any better performance out of the system :) On Fri, Aug 22, 2014 at 9:52 AM, Jamie jamie.bo...@transamerica.com wrote: Within 8.x, BMC has deprecated old AR Approval Process by reducing the approval process from 16 to just 4. See link below: https://communities.bmc.com/community/bmcdn/bmc_it_service_support/change_process_management/blog/2014/01/23/change-approval-processes-consolidation-in-itsm-cm-8x The OOB change approval processes are now evaluating both CIs and Impacted Areas for change approvals. We are working on improving our overall Change process maturing and have started adding companies on changes within the impacted areas and associating all CIs that are affected by the specific change. Our process for our technicians is to relate the CIs that are impacted by your change and then use the Impact Analysis functionality to relate any other CIs that are also affected. This can result in thousands of CIs being related to the change ticket. This is where the problem begins :) When moving the change ticket through the approval process, the approval engine then has to sift through CHG:Change-ImpactedAreasCIAssociation_outer_ApproverLookup to evaluate every single CI and Impacted area to determine whether there is an approval mapping to tied to them. We have had many instances where this evaluating has been still occurring after 12hrs+ which we have had to delete in the app pending form because other records were queued up behind it. We have a ticket opened with BMC, but they haven't been helpful other than saying you shouldn't have more than 1,000 CIs associated to a change ticket. (really???) Are there any improvements that can be made to improve the performance of the approval server that we haven't done already? (see setup below) Below is current setup: -5 Sun Solaris App Servers (2 dedicated for Server Group processes (8 CPU 16GB RAM each), 3 User Facing (4CPU 16GBRAM each)) -Dedicated RPC port 390680 (Min=6 Max=8) and thread logs show it stays around 7. -RPC Loopback plugin configured on 390626 (Min=4 Max=12) and thread logs shows it says around 4-5. -Definition Check Interval = 300 -Thread Count = 4 -Fast Threads Min=12 Max=40 -List Threads Min=12 Max=40 I know we can modify the AP:Process to look at other forms instead of the CHG:Change-ImpactedAreasCIAssociation_outer_ApproverLookup or re-enable the deprecated processes, but then if we have any issues in the future, BMC will point out that we are following the OOB processes so I'm trying to utilize the OOB processes before I take that route. Are there any other folks out there that are using the OOB approval processes in 8.x and relating thousands of CIs without issues? ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: 8.1.01 Change Approval Performance Issues
Thanks for the feedback LJ. I still need to go through the SQL logs to see if indexing can improve things, which is on my list to do but wanted to also reach out in parallel to the list in case others have already fought this. I've attached the form of CHG:Change-ImpactedAreasCIAssociation_outer_ApproverLookup to this message to show how horrific this is set up :). ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: 8.1.01 Change Approval Performance Issues
I don't know why BMC would EVER say that you shouldn't have more than 1000 CI's for one change. What happens in any large company when they issue a Microsoft patch for their desktops? I know for our customers there could easily be many thousands of things connected. That said, quality time with the SQL logs is the way to go. Run the log analyzer of your choice and get on the indexes. We've see query times for some things go from 2M 30S (for a query repeated for every CI update) down to under 1 MS. That changed our processing time from 3 seconds per CI to 15 CI's per second. I am a big BMC fan, but I think they need to do MUCH more testing with large volumes of data. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Jamie Sent: Friday, August 22, 2014 12:25 PM To: arslist@ARSLIST.ORG Subject: Re: 8.1.01 Change Approval Performance Issues Thanks for the feedback LJ. I still need to go through the SQL logs to see if indexing can improve things, which is on my list to do but wanted to also reach out in parallel to the list in case others have already fought this. I've attached the form of CHG:Change-ImpactedAreasCIAssociation_outer_ApproverLookup to this message to show how horrific this is set up :). ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years - No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4745 / Virus Database: 4007/8066 - Release Date: 08/19/14 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Crystal Reports and Performance issues
Fellow ARSListers, I have been trying to track down a problem with performance. We appear to have located the problem coming from our Crystal Reports server than runs multiple reports against Remedy every day. I have the option enabled to put large result buffer entries in the Thread log file. My goal was to see large queries being executed against the Remedy database. What I found was that several entries in the log file from the login used by our Crystal Reports server. Has anyone see this behavior before? It appears as if Crystal Reports is sending the same query over and over again to Remedy for processing. I have seen a single report generate 3 dozen similar entries to what I have listed below. The report also eats up over half of the CPU's processing power while this report is running. THRD /* Mon Sep 13 2010 16:29:17.2030 */ Thread Id 3100 (GLEWF) large result buffer allocation - /Length: 1505110/Entries: 10729/Client Ver: =10/RPC ID: 134939/User: entp_report/Form: HPD:Help Desk_SLA/ THRD /* Mon Sep 13 2010 16:29:20.2650 */ Thread Id 2944 (GLEWF) large result buffer allocation - /Length: 1505110/Entries: 10729/Client Ver: =10/RPC ID: 134950/User: entp_report/Form: HPD:Help Desk_SLA/ THRD /* Mon Sep 13 2010 16:29:23.3440 */ Thread Id 4836 (GLEWF) large result buffer allocation - /Length: 1505110/Entries: 10729/Client Ver: =10/RPC ID: 134962/User: entp_report/Form: HPD:Help Desk_SLA/ THRD /* Mon Sep 13 2010 16:29:26.4690 */ Thread Id 4604 (GLEWF) large result buffer allocation - /Length: 1505110/Entries: 10729/Client Ver: =10/RPC ID: 134973/User: entp_report/Form: HPD:Help Desk_SLA/ THRD /* Mon Sep 13 2010 16:29:29.5630 */ Thread Id 1256 (GLEWF) large result buffer allocation - /Length: 1505110/Entries: 10729/Client Ver: =10/RPC ID: 134987/User: entp_report/Form: HPD:Help Desk_SLA/ THRD /* Mon Sep 13 2010 16:29:32.6560 */ Thread Id 2552 (GLEWF) large result buffer allocation - /Length: 1505110/Entries: 10729/Client Ver: =10/RPC ID: 134998/User: entp_report/Form: HPD:Help Desk_SLA/ THRD /* Mon Sep 13 2010 16:29:35.7030 */ Thread Id 2616 (GLEWF) large result buffer allocation - /Length: 1505110/Entries: 10729/Client Ver: =10/RPC ID: 135010/User: entp_report/Form: HPD:Help Desk_SLA/ THRD /* Mon Sep 13 2010 16:29:38.7500 */ Thread Id 5340 (GLEWF) large result buffer allocation - /Length: 1505110/Entries: 10729/Client Ver: =10/RPC ID: 135023/User: entp_report/Form: HPD:Help Desk_SLA/ THRD /* Mon Sep 13 2010 16:29:41.8130 */ Thread Id 5904 (GLEWF) large result buffer allocation - /Length: 1505110/Entries: 10729/Client Ver: =10/RPC ID: 135034/User: entp_report/Form: HPD:Help Desk_SLA/ THRD /* Mon Sep 13 2010 16:29:44.7350 */ Thread Id 3296 (GLEWF) large result buffer allocation - /Length: 1505110/Entries: 10729/Client Ver: =10/RPC ID: 135049/User: entp_report/Form: HPD:Help Desk_SLA/ THRD /* Mon Sep 13 2010 16:29:47.6880 */ Thread Id 5492 (GLEWF) large result buffer allocation - /Length: 1505110/Entries: 10729/Client Ver: =10/RPC ID: 135060/User: entp_report/Form: HPD:Help Desk_SLA/ THRD /* Mon Sep 13 2010 16:29:50.6880 */ Thread Id 3512 (GLEWF) large result buffer allocation - /Length: 1505110/Entries: 10729/Client Ver: =10/RPC ID: 135072/User: entp_report/Form: HPD:Help Desk_SLA/ THRD /* Mon Sep 13 2010 16:29:52.9230 */ Thread Id 3668 (GLEWF) large result buffer allocation - /Length: 1505110/Entries: 10729/Client Ver: =10/RPC ID: 135083/User: entp_report/Form: HPD:Help Desk_SLA/ THRD /* Mon Sep 13 2010 16:29:54.7660 */ Thread Id 2692 (GLEWF) large result buffer allocation - /Length: 1505110/Entries: 10729/Client Ver: =10/RPC ID: 135095/User: entp_report/Form: HPD:Help Desk_SLA/ THRD /* Mon Sep 13 2010 16:29:57.7980 */ Thread Id 5252 (GLEWF) large result buffer allocation - /Length: 1505110/Entries: 10729/Client Ver: =10/RPC ID: 135106/User: entp_report/Form: HPD:Help Desk_SLA/ THRD /* Mon Sep 13 2010 16:30:00.8920 */ Thread Id 4908 (GLEWF) large result buffer allocation - /Length: 1505110/Entries: 10729/Client Ver: =10/RPC ID: 135117/User: entp_report/Form: HPD:Help Desk_SLA/ Any insight or assistance to resolving why Crystal is doing this would be much appreciated. I have used Crystal Reports in the past, but have never been aware of any behavior like this. However, all of my tests point to the reports being run through Crystal as the source of our performance issues. James Van Sickle Senior Remedy Developer Office: 972-308-4090 Mobile: 214-263-9340 _ This email and its attachments, if any, are intended for the personal use of the named recipient(s) and may contain confidential, privileged, or proprietary information. If you are not a named recipient, or an agent responsible for delivering it to a named recipient, you have received this email in error. In that event, please (a) immediately notify me
Re: Crystal Reports and Performance issues
If the Crystal report in question contains sub reports then you will get multiple queries. If the main reports result set contains lots of records then you will get as many SQL calls for each of the sub reports. This is not out of the ordinary. On Sep 13, 2010, at 5:53 PM, Van Sickle, James W james.vansic...@cmc.com wrote: ** Fellow ARSListers, I have been trying to track down a problem with performance. We appear to have located the problem coming from our Crystal Reports server than runs multiple reports against Remedy every day. I have the option enabled to put large result buffer entries in the Thread log file. My goal was to see large queries being executed against the Remedy database. What I found was that several entries in the log file from the login used by our Crystal Reports server. Has anyone see this behavior before? It appears as if Crystal Reports is sending the same query over and over again to Remedy for processing. I have seen a single report generate 3 dozen similar entries to what I have listed below. The report also eats up over half of the CPU’s processing power while this report is running. THRD /* Mon Sep 13 2010 16:29:17.2030 */ Thread Id 3100 (GLEWF) large result buffer allocation - /Length: 1505110/Entries: 10729/Client Ver: =10/RPC ID: 134939/User: entp_report/Form: HPD:Help Desk_SLA/ THRD /* Mon Sep 13 2010 16:29:20.2650 */ Thread Id 2944 (GLEWF) large result buffer allocation - /Length: 1505110/Entries: 10729/Client Ver: =10/RPC ID: 134950/User: entp_report/Form: HPD:Help Desk_SLA/ THRD /* Mon Sep 13 2010 16:29:23.3440 */ Thread Id 4836 (GLEWF) large result buffer allocation - /Length: 1505110/Entries: 10729/Client Ver: =10/RPC ID: 134962/User: entp_report/Form: HPD:Help Desk_SLA/ THRD /* Mon Sep 13 2010 16:29:26.4690 */ Thread Id 4604 (GLEWF) large result buffer allocation - /Length: 1505110/Entries: 10729/Client Ver: =10/RPC ID: 134973/User: entp_report/Form: HPD:Help Desk_SLA/ THRD /* Mon Sep 13 2010 16:29:29.5630 */ Thread Id 1256 (GLEWF) large result buffer allocation - /Length: 1505110/Entries: 10729/Client Ver: =10/RPC ID: 134987/User: entp_report/Form: HPD:Help Desk_SLA/ THRD /* Mon Sep 13 2010 16:29:32.6560 */ Thread Id 2552 (GLEWF) large result buffer allocation - /Length: 1505110/Entries: 10729/Client Ver: =10/RPC ID: 134998/User: entp_report/Form: HPD:Help Desk_SLA/ THRD /* Mon Sep 13 2010 16:29:35.7030 */ Thread Id 2616 (GLEWF) large result buffer allocation - /Length: 1505110/Entries: 10729/Client Ver: =10/RPC ID: 135010/User: entp_report/Form: HPD:Help Desk_SLA/ THRD /* Mon Sep 13 2010 16:29:38.7500 */ Thread Id 5340 (GLEWF) large result buffer allocation - /Length: 1505110/Entries: 10729/Client Ver: =10/RPC ID: 135023/User: entp_report/Form: HPD:Help Desk_SLA/ THRD /* Mon Sep 13 2010 16:29:41.8130 */ Thread Id 5904 (GLEWF) large result buffer allocation - /Length: 1505110/Entries: 10729/Client Ver: =10/RPC ID: 135034/User: entp_report/Form: HPD:Help Desk_SLA/ THRD /* Mon Sep 13 2010 16:29:44.7350 */ Thread Id 3296 (GLEWF) large result buffer allocation - /Length: 1505110/Entries: 10729/Client Ver: =10/RPC ID: 135049/User: entp_report/Form: HPD:Help Desk_SLA/ THRD /* Mon Sep 13 2010 16:29:47.6880 */ Thread Id 5492 (GLEWF) large result buffer allocation - /Length: 1505110/Entries: 10729/Client Ver: =10/RPC ID: 135060/User: entp_report/Form: HPD:Help Desk_SLA/ THRD /* Mon Sep 13 2010 16:29:50.6880 */ Thread Id 3512 (GLEWF) large result buffer allocation - /Length: 1505110/Entries: 10729/Client Ver: =10/RPC ID: 135072/User: entp_report/Form: HPD:Help Desk_SLA/ THRD /* Mon Sep 13 2010 16:29:52.9230 */ Thread Id 3668 (GLEWF) large result buffer allocation - /Length: 1505110/Entries: 10729/Client Ver: =10/RPC ID: 135083/User: entp_report/Form: HPD:Help Desk_SLA/ THRD /* Mon Sep 13 2010 16:29:54.7660 */ Thread Id 2692 (GLEWF) large result buffer allocation - /Length: 1505110/Entries: 10729/Client Ver: =10/RPC ID: 135095/User: entp_report/Form: HPD:Help Desk_SLA/ THRD /* Mon Sep 13 2010 16:29:57.7980 */ Thread Id 5252 (GLEWF) large result buffer allocation - /Length: 1505110/Entries: 10729/Client Ver: =10/RPC ID: 135106/User: entp_report/Form: HPD:Help Desk_SLA/ THRD /* Mon Sep 13 2010 16:30:00.8920 */ Thread Id 4908 (GLEWF) large result buffer allocation - /Length: 1505110/Entries: 10729/Client Ver: =10/RPC ID: 135117/User: entp_report/Form: HPD:Help Desk_SLA/ Any insight or assistance to resolving why Crystal is doing this would be much appreciated. I have used Crystal Reports in the past, but have never been aware of any behavior like this. However, all of my tests point to the reports being run through Crystal as the source of our performance issues. James Van Sickle Senior Remedy Developer Office
Re: Crystal Reports and Performance issues
/ Any insight or assistance to resolving why Crystal is doing this would be much appreciated. I have used Crystal Reports in the past, but have never been aware of any behavior like this. However, all of my tests point to the reports being run through Crystal as the source of our performance issues. James Van Sickle Senior Remedy Developer Office: 972-308-4090 Mobile: 214-263-9340 This email and its attachments, if any, are intended for the personal use of the named recipient(s) and may contain confidential, privileged, or proprietary information. If you are not a named recipient, or an agent responsible for delivering it to a named recipient, you have received this email in error. In that event, please (a) immediately notify me by reply email, (b) do not review, copy, save, forward, or print this email or any of its attachments, and (c) immediately delete and/or destroy this email and its attachments and all electronic and physical copies thereof. Thank you. _attend WWRUG10 www.wwrug.com ARSlist: Where the Answers Are_ _attend WWRUG10 www.wwrug.com ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Re: Performance issues with BMC AR Server 7.1
hello, Thanks for the reply. We have an active link on Incident Management Console with an interval of 1 min to refresh the incidents table in the console (Change Field Action). This could be one of the reasons for the performance degradation. Can you please suggest any other alternative ways to achieve this which wouldn't hit the performance? Thanks On Jun 21, 1:24 pm, Walters, Mark mark_walt...@bmc.com wrote: I'd suggest that you need to try and break this problem down to look at it in more detail - you're unlikely to find a single configuration setting that will suddenly make the system perform acceptably. Identify one or two key activities that you consider to be performing poorly - submitting an incident or running some other piece of workflow for example. Enable server and client side logging and reproduce the problem several times. Review the logs and see where the time is being spent - it may be a particular piece of workflow or query that is taking a long time. It's interesting to note that admin users are not seeing the same issues. The most obvious difference is that admin users will not be subject to the permission checking that ordinary users are. Do you have a large number of permission groups configured? The Optimizing and Troubleshooting manual has lots of information about how to debug performance issues. Mark -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Princy Sent: 20 June 2010 19:23 To: arsl...@arslist.org Subject: Performance issues with BMC AR Server 7.1 Hi All, We are facing lot of performance issues with the Remedy Server, which is making it very slow to access. Found in other posts that the Refresh On Entry Change option if enabled is the cause for most of the performance degradation issues. And on incidents form, for most of the tables this option is enabled. Would like to know if disabling this option would increase the performance. Another issue we are facing is that few users (with Admin permissions) when access the system, they find it fast. But other users like problem engineer/service desk user when access the system, it is very slow and unusable. Could some one please throw light on this issue? Thanks. ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgattend wwrug10www.wwrug.comARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org attend wwrug10www.wwrug.comARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Re: Performance issues with BMC AR Server 7.1
Princy, Performance optimization of ARS include lot of parameters, below are the few of them which you can try. You can go for the configuration of the list fast threads along with the private queues. Analyze the SQL logs confirm which SQL queries are taking time. Configure the server for qualified searches only. Indexing major tables which always come in more searches is a prime one. Check out for QBE searches in field properties. Set field actions while opening a child form which generally produces the white screen while fetching the data from the parent form. Cache files on the client desktops (delete *.arf *.arv files) may be for few clients. Hope this helps. Cheers, Mahendra Mahalkar On Tue, Jul 20, 2010 at 3:52 PM, Princy princy.0...@gmail.com wrote: hello, Thanks for the reply. We have an active link on Incident Management Console with an interval of 1 min to refresh the incidents table in the console (Change Field Action). This could be one of the reasons for the performance degradation. Can you please suggest any other alternative ways to achieve this which wouldn't hit the performance? Thanks On Jun 21, 1:24 pm, Walters, Mark mark_walt...@bmc.com wrote: I'd suggest that you need to try and break this problem down to look at it in more detail - you're unlikely to find a single configuration setting that will suddenly make the system perform acceptably. Identify one or two key activities that you consider to be performing poorly - submitting an incident or running some other piece of workflow for example. Enable server and client side logging and reproduce the problem several times. Review the logs and see where the time is being spent - it may be a particular piece of workflow or query that is taking a long time. It's interesting to note that admin users are not seeing the same issues. The most obvious difference is that admin users will not be subject to the permission checking that ordinary users are. Do you have a large number of permission groups configured? The Optimizing and Troubleshooting manual has lots of information about how to debug performance issues. Mark -Original Message- From: Action Request System discussion list(ARSList) [mailto: arsl...@arslist.org] On Behalf Of Princy Sent: 20 June 2010 19:23 To: arsl...@arslist.org Subject: Performance issues with BMC AR Server 7.1 Hi All, We are facing lot of performance issues with the Remedy Server, which is making it very slow to access. Found in other posts that the Refresh On Entry Change option if enabled is the cause for most of the performance degradation issues. And on incidents form, for most of the tables this option is enabled. Would like to know if disabling this option would increase the performance. Another issue we are facing is that few users (with Admin permissions) when access the system, they find it fast. But other users like problem engineer/service desk user when access the system, it is very slow and unusable. Could some one please throw light on this issue? Thanks. ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgattend wwrug10www.wwrug.comARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org attend wwrug10www.wwrug.comARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Re: Performance issues with BMC AR Server 7.1
That depends on what really that Active Link does. What does it do? And what is the requirement around which you have built that AL? Joe From: Princy princy.0...@gmail.com To: arslist@ARSLIST.ORG Sent: Tue, July 20, 2010 6:22:17 AM Subject: Re: Performance issues with BMC AR Server 7.1 hello, Thanks for the reply. We have an active link on Incident Management Console with an interval of 1 min to refresh the incidents table in the console (Change Field Action). This could be one of the reasons for the performance degradation. Can you please suggest any other alternative ways to achieve this which wouldn't hit the performance? Thanks On Jun 21, 1:24 pm, Walters, Mark mark_walt...@bmc.com wrote: I'd suggest that you need to try and break this problem down to look at it in more detail - you're unlikely to find a single configuration setting that will suddenly make the system perform acceptably. Identify one or two key activities that you consider to be performing poorly - submitting an incident or running some other piece of workflow for example. Enable server and client side logging and reproduce the problem several times. Review the logs and see where the time is being spent - it may be a particular piece of workflow or query that is taking a long time. It's interesting to note that admin users are not seeing the same issues. The most obvious difference is that admin users will not be subject to the permission checking that ordinary users are. Do you have a large number of permission groups configured? The Optimizing and Troubleshooting manual has lots of information about how to debug performance issues. Mark -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Princy Sent: 20 June 2010 19:23 To: arsl...@arslist.org Subject: Performance issues with BMC AR Server 7.1 Hi All, We are facing lot of performance issues with the Remedy Server, which is making it very slow to access. Found in other posts that the Refresh On Entry Change option if enabled is the cause for most of the performance degradation issues. And on incidents form, for most of the tables this option is enabled. Would like to know if disabling this option would increase the performance. Another issue we are facing is that few users (with Admin permissions) when access the system, they find it fast. But other users like problem engineer/service desk user when access the system, it is very slow and unusable. Could some one please throw light on this issue? Thanks. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Re: Performance issues with BMC AR Server 7.1
Princy, You might want to check the qualification in the table fields and optimize those so there are no table scans and the queries make use of available indexes. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Princy Sent: Sunday, June 20, 2010 2:23 PM To: arslist@ARSLIST.ORG Subject: Performance issues with BMC AR Server 7.1 Hi All, We are facing lot of performance issues with the Remedy Server, which is making it very slow to access. Found in other posts that the Refresh On Entry Change option if enabled is the cause for most of the performance degradation issues. And on incidents form, for most of the tables this option is enabled. Would like to know if disabling this option would increase the performance. Another issue we are facing is that few users (with Admin permissions) when access the system, they find it fast. But other users like problem engineer/service desk user when access the system, it is very slow and unusable. Could some one please throw light on this issue? Thanks. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Re: Performance issues with BMC AR Server 7.1
I'd suggest that you need to try and break this problem down to look at it in more detail - you're unlikely to find a single configuration setting that will suddenly make the system perform acceptably. Identify one or two key activities that you consider to be performing poorly - submitting an incident or running some other piece of workflow for example. Enable server and client side logging and reproduce the problem several times. Review the logs and see where the time is being spent - it may be a particular piece of workflow or query that is taking a long time. It's interesting to note that admin users are not seeing the same issues. The most obvious difference is that admin users will not be subject to the permission checking that ordinary users are. Do you have a large number of permission groups configured? The Optimizing and Troubleshooting manual has lots of information about how to debug performance issues. Mark -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Princy Sent: 20 June 2010 19:23 To: arslist@ARSLIST.ORG Subject: Performance issues with BMC AR Server 7.1 Hi All, We are facing lot of performance issues with the Remedy Server, which is making it very slow to access. Found in other posts that the Refresh On Entry Change option if enabled is the cause for most of the performance degradation issues. And on incidents form, for most of the tables this option is enabled. Would like to know if disabling this option would increase the performance. Another issue we are facing is that few users (with Admin permissions) when access the system, they find it fast. But other users like problem engineer/service desk user when access the system, it is very slow and unusable. Could some one please throw light on this issue? Thanks. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Performance issues with BMC AR Server 7.1
Hi All, We are facing lot of performance issues with the Remedy Server, which is making it very slow to access. Found in other posts that the Refresh On Entry Change option if enabled is the cause for most of the performance degradation issues. And on incidents form, for most of the tables this option is enabled. Would like to know if disabling this option would increase the performance. Another issue we are facing is that few users (with Admin permissions) when access the system, they find it fast. But other users like problem engineer/service desk user when access the system, it is very slow and unusable. Could some one please throw light on this issue? Thanks. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Re: Performance issues
The last piece of information (# of records / table and size on disk) is easily retrievable real time, if you are on Oracle.. The Oracle system view user_tables (or the table all_tables if you have administrative access to the database) should have that information among a lot of other useful information.. You would need to update the statistics for the most current information for some of it like averages etc. but if I'm not mistaken, size and number of records is real time info on that table. I do not know the equivalent of MS-SQL or Sybase or Informix but it should not be that hard to find.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of John Sundberg Sent: Thursday, February 18, 2010 5:47 PM To: arslist@ARSLIST.ORG Subject: Re: Performance issues ** Another option: Point your web browser to: http://remedyserver:9090/bmc/backplane/stats You should see a graph of: - filters sorted by # of times run - filters sorted by total time consumed - escalations sorted by # of records modified - escalations sorted by total time consumed Also: - a list of all tables on the system sorted by # of records / table. - a list of all tables sorted by disk size If you click on the trends tab -- you should see the above with historical values. The above should be helpful in pinpointing your issues. OK - OK -- I am sorry -- I have to quit dreaming -- it just makes you depressed. -John On Feb 18, 2010, at 12:56 PM, LJ Longwing wrote: ** Tim, That doesn't seem excessive to mewhenever I'm looking at performance issues I turn on SQL and API logging at the server and run the ARLogAnalyzer against them...it tells me which processes are taking to long and I tweak that workflow, indexes, etc. -- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Tim Rondeau Sent: Thursday, February 18, 2010 11:43 AM To: arslist@ARSLIST.ORG Subject: Performance issues ** Arsystem 7.1 patch 7 ITSM suite, using SLM, CMDB, Change Management, Problem and Incident We are running SQL 2005 on windows 2003 server, plenty of CPU/disk and RAM. Looking for some feed back on how some have handled performance issues. We process about 400 changes a day and about 800 incidents a day. Just seems like this system can’t handle it. DB timeouts, white screens all the time. DBA of course states no issues. In March we are moving to Oracle RAC, which will be 2 robust db servers. APP will still be on windows. Thanks Tim _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ -- John Sundberg Kinetic Data, Inc. Building a Better Service Experience Recipient of the WWRUG09 Innovator of the Year Award john.sundb...@kineticdata.com 651.556.0930 I www.kineticdata.com ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Performance issues
Hi Tim, Have you tried running the performance analysis reports from Abydos Analyser ? This should highlight any problems with indexing on forms based on workflow qualifications and also unqualified queries that might be causing full table scans. Hope that helps. Kind regards, The Abydos Team. Tel: +44 (0)1582 400127 US Freephone: 866-635-4358 Fax: +44 (0)1582 450260 Email: i...@abydos-workflow.com Web: http://www.abydos-workflow.com Abydos Analyser - the quickest way to analyse, document, edit and graphically present workflow rules within BMC Remedy applications. Abydos Designer - the fastest and most efficient way to design, deploy, track and maintain IT or other business processes within BMC Remedy applications. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Performance issues
I am running this now, Thanks From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Simon Urquhart Sent: Friday, February 19, 2010 5:25 AM To: arslist@ARSLIST.ORG Subject: Re: Performance issues ** Hi Tim, Have you tried running the performance analysis reports from Abydos Analyser ? This should highlight any problems with indexing on forms based on workflow qualifications and also unqualified queries that might be causing full table scans. Hope that helps. Kind regards, The Abydos Team. Tel: +44 (0)1582 400127 US Freephone: 866-635-4358 Fax: +44 (0)1582 450260 Email: i...@abydos-workflow.com Web: http://www.abydos-workflow.com Abydos Analyser - the quickest way to analyse, document, edit and graphically present workflow rules within BMC Remedy applications. Abydos Designer - the fastest and most efficient way to design, deploy, track and maintain IT or other business processes within BMC Remedy applications. _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Performance issues
Arsystem 7.1 patch 7 ITSM suite, using SLM, CMDB, Change Management, Problem and Incident We are running SQL 2005 on windows 2003 server, plenty of CPU/disk and RAM. Looking for some feed back on how some have handled performance issues. We process about 400 changes a day and about 800 incidents a day. Just seems like this system can't handle it. DB timeouts, white screens all the time. DBA of course states no issues. In March we are moving to Oracle RAC, which will be 2 robust db servers. APP will still be on windows. Thanks Tim ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Performance issues
Tim, That doesn't seem excessive to mewhenever I'm looking at performance issues I turn on SQL and API logging at the server and run the ARLogAnalyzer against them...it tells me which processes are taking to long and I tweak that workflow, indexes, etc. _ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Tim Rondeau Sent: Thursday, February 18, 2010 11:43 AM To: arslist@ARSLIST.ORG Subject: Performance issues ** Arsystem 7.1 patch 7 ITSM suite, using SLM, CMDB, Change Management, Problem and Incident We are running SQL 2005 on windows 2003 server, plenty of CPU/disk and RAM. Looking for some feed back on how some have handled performance issues. We process about 400 changes a day and about 800 incidents a day. Just seems like this system can't handle it. DB timeouts, white screens all the time. DBA of course states no issues. In March we are moving to Oracle RAC, which will be 2 robust db servers. APP will still be on windows. Thanks Tim _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Performance issues
The things I've looked for regarding performance issues: * Speed/duplex settings on your NICs - I don't have any hard numbers on this, but I've seen in the past (not necessarily with Remedy) where if the NIC's and switch port's speed/duplex settings don't match or if they're set to auto/auto, explicitly configuring these settings to match (e.g. 1Gbit/Full) on both the NIC and switch port have yielded HUGE throughput improvements. * Use the SQL profiler tool to set up a trace that logs all transactions that take more than N amount of time to complete. I generally use 1000ms when I do traces like this, as it's my belief that no single SELECT statement should take more than a second to complete. You can use the output of this tool to find queries (SELECTS are the easiest to analyze) that run long, and see if you're perhaps missing an index on an oft-searched column. * Use the Windows Performance monitor on the SQL server itself and get some stats on memory usage, and especially disk I/O (average disk queue length for individual disks is the most helpful). Slow disk I/O is second only to lack of available RAM in its performance-killing effectiveness. In past experience, I found that having even a handful of heavily used tables all on the same disk can cause an I/O bottleneck. I've also found that having even two or three heavily used tables and those tables' indexes on the same disk hurts too. * Of course, turning on API and SQL logging and running that through arloganalyzer doesn't hurt either if nothing else is telling you anything interesting. This tool would help you determine if you have enough available threads configured, for example (e.g. a high thread wait time would indicate you don't have enough threads, etc.). Mike From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Tim Rondeau Sent: Thursday, February 18, 2010 12:43 PM To: arslist@ARSLIST.ORG Subject: Performance issues ** Arsystem 7.1 patch 7 ITSM suite, using SLM, CMDB, Change Management, Problem and Incident We are running SQL 2005 on windows 2003 server, plenty of CPU/disk and RAM. Looking for some feed back on how some have handled performance issues. We process about 400 changes a day and about 800 incidents a day. Just seems like this system can't handle it. DB timeouts, white screens all the time. DBA of course states no issues. In March we are moving to Oracle RAC, which will be 2 robust db servers. APP will still be on windows. Thanks Tim _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Performance issues
Me either, thanks I will run that again and see if I can get to the bottom of this. From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of LJ Longwing Sent: Thursday, February 18, 2010 1:57 PM To: arslist@ARSLIST.ORG Subject: Re: Performance issues ** Tim, That doesn't seem excessive to mewhenever I'm looking at performance issues I turn on SQL and API logging at the server and run the ARLogAnalyzer against them...it tells me which processes are taking to long and I tweak that workflow, indexes, etc. From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Tim Rondeau Sent: Thursday, February 18, 2010 11:43 AM To: arslist@ARSLIST.ORG Subject: Performance issues ** Arsystem 7.1 patch 7 ITSM suite, using SLM, CMDB, Change Management, Problem and Incident We are running SQL 2005 on windows 2003 server, plenty of CPU/disk and RAM. Looking for some feed back on how some have handled performance issues. We process about 400 changes a day and about 800 incidents a day. Just seems like this system can't handle it. DB timeouts, white screens all the time. DBA of course states no issues. In March we are moving to Oracle RAC, which will be 2 robust db servers. APP will still be on windows. Thanks Tim _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Performance issues
The version 7 apps OTB to the best of my knowledge do not lead to performance issues like the older ITSP apps used to for lack of indexes etc. If there were any customizations done, to any queries, on table fields etc on screens that give you those 'white screens' I would take a second look at all those customizations if you know on top of your head where those are.. Those may point out to badly designed queries against unindexed fields.. or just badly designed queries that need to be redone - period.. SQL and API logging off course will give you all the fine details - and is the best way to go to fine tune things in the end.. Then you also say you use SQL 2005.. Having plenty of disk space, CPU, RAM and other conceivable goodies doesn't guarantee that your SQL server is gonna fly. Have you look at performance check points on your SQL server? The log and data file growth configurations? Are the log files full? Are they being automatically truncated? Do you have to manually do that? Have you defragged the disk drive that the log and data files reside on? How many open connections at any point of time to the database? Is the database refusing new connections? What is the configured limit? Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Tim Rondeau Sent: Thursday, February 18, 2010 2:37 PM To: arslist@ARSLIST.ORG Subject: Re: Performance issues ** Me either, thanks I will run that again and see if I can get to the bottom of this. From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of LJ Longwing Sent: Thursday, February 18, 2010 1:57 PM To: arslist@ARSLIST.ORG Subject: Re: Performance issues ** Tim, That doesn't seem excessive to mewhenever I'm looking at performance issues I turn on SQL and API logging at the server and run the ARLogAnalyzer against them...it tells me which processes are taking to long and I tweak that workflow, indexes, etc. -- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Tim Rondeau Sent: Thursday, February 18, 2010 11:43 AM To: arslist@ARSLIST.ORG Subject: Performance issues ** Arsystem 7.1 patch 7 ITSM suite, using SLM, CMDB, Change Management, Problem and Incident We are running SQL 2005 on windows 2003 server, plenty of CPU/disk and RAM. Looking for some feed back on how some have handled performance issues. We process about 400 changes a day and about 800 incidents a day. Just seems like this system can't handle it. DB timeouts, white screens all the time. DBA of course states no issues. In March we are moving to Oracle RAC, which will be 2 robust db servers. APP will still be on windows. Thanks Tim ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Performance issues
Quick check: do you have Development Cache Mode turned on on that server? If so, try turning it off and see if that makes a difference. Lyle From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Tim Rondeau Sent: Thursday, February 18, 2010 11:43 AM To: arslist@ARSLIST.ORG Subject: Performance issues ** Arsystem 7.1 patch 7 ITSM suite, using SLM, CMDB, Change Management, Problem and Incident We are running SQL 2005 on windows 2003 server, plenty of CPU/disk and RAM. Looking for some feed back on how some have handled performance issues. We process about 400 changes a day and about 800 incidents a day. Just seems like this system can't handle it. DB timeouts, white screens all the time. DBA of course states no issues. In March we are moving to Oracle RAC, which will be 2 robust db servers. APP will still be on windows. Thanks Tim _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Performance issues
Another option: Point your web browser to: http://remedyserver:9090/bmc/backplane/stats You should see a graph of: - filters sorted by # of times run - filters sorted by total time consumed - escalations sorted by # of records modified - escalations sorted by total time consumed Also: - a list of all tables on the system sorted by # of records / table. - a list of all tables sorted by disk size If you click on the trends tab -- you should see the above with historical values. The above should be helpful in pinpointing your issues. OK - OK -- I am sorry -- I have to quit dreaming -- it just makes you depressed. -John On Feb 18, 2010, at 12:56 PM, LJ Longwing wrote: ** Tim, That doesn't seem excessive to mewhenever I'm looking at performance issues I turn on SQL and API logging at the server and run the ARLogAnalyzer against them...it tells me which processes are taking to long and I tweak that workflow, indexes, etc. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG ] On Behalf Of Tim Rondeau Sent: Thursday, February 18, 2010 11:43 AM To: arslist@ARSLIST.ORG Subject: Performance issues ** Arsystem 7.1 patch 7 ITSM suite, using SLM, CMDB, Change Management, Problem and Incident We are running SQL 2005 on windows 2003 server, plenty of CPU/disk and RAM. Looking for some feed back on how some have handled performance issues. We process about 400 changes a day and about 800 incidents a day. Just seems like this system can’t handle it. DB timeouts, white screens all the time. DBA of course states no issues. In March we are moving to Oracle RAC, which will be 2 robust db servers. APP will still be on windows. Thanks Tim _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ -- John Sundberg Kinetic Data, Inc. Building a Better Service Experience Recipient of the WWRUG09 Innovator of the Year Award john.sundb...@kineticdata.com 651.556.0930 I www.kineticdata.com ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Performance issues
Johnthat WAS NOT FUNNYI almost did it _ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of John Sundberg Sent: Thursday, February 18, 2010 3:47 PM To: arslist@ARSLIST.ORG Subject: Re: Performance issues ** Another option: Point your web browser to: http://remedyserver:9090/bmc/backplane/stats You should see a graph of: - filters sorted by # of times run - filters sorted by total time consumed - escalations sorted by # of records modified - escalations sorted by total time consumed Also: - a list of all tables on the system sorted by # of records / table. - a list of all tables sorted by disk size If you click on the trends tab -- you should see the above with historical values. The above should be helpful in pinpointing your issues. OK - OK -- I am sorry -- I have to quit dreaming -- it just makes you depressed. -John On Feb 18, 2010, at 12:56 PM, LJ Longwing wrote: ** Tim, That doesn't seem excessive to mewhenever I'm looking at performance issues I turn on SQL and API logging at the server and run the ARLogAnalyzer against them...it tells me which processes are taking to long and I tweak that workflow, indexes, etc. _ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Tim Rondeau Sent: Thursday, February 18, 2010 11:43 AM To: arslist@ARSLIST.ORG Subject: Performance issues ** Arsystem 7.1 patch 7 ITSM suite, using SLM, CMDB, Change Management, Problem and Incident We are running SQL 2005 on windows 2003 server, plenty of CPU/disk and RAM. Looking for some feed back on how some have handled performance issues. We process about 400 changes a day and about 800 incidents a day. Just seems like this system can't handle it. DB timeouts, white screens all the time. DBA of course states no issues. In March we are moving to Oracle RAC, which will be 2 robust db servers. APP will still be on windows. Thanks Tim _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ -- John Sundberg Kinetic Data, Inc. Building a Better Service Experience Recipient of the WWRUG09 Innovator of the Year Award john.sundb...@kineticdata.com 651.556.0930 I http://www.kineticdata.com/ www.kineticdata.com _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Performance issues
The reason of course that it wasn't funny is because that sort of information would be sweet to have...but the system wasn't designed to provide it... _ From: LJ Longwing [mailto:lj.longw...@gmail.com] Sent: Thursday, February 18, 2010 4:00 PM To: arslist@ARSLIST.ORG Subject: RE: Performance issues Johnthat WAS NOT FUNNYI almost did it _ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of John Sundberg Sent: Thursday, February 18, 2010 3:47 PM To: arslist@ARSLIST.ORG Subject: Re: Performance issues ** Another option: Point your web browser to: http://remedyserver:9090/bmc/backplane/stats You should see a graph of: - filters sorted by # of times run - filters sorted by total time consumed - escalations sorted by # of records modified - escalations sorted by total time consumed Also: - a list of all tables on the system sorted by # of records / table. - a list of all tables sorted by disk size If you click on the trends tab -- you should see the above with historical values. The above should be helpful in pinpointing your issues. OK - OK -- I am sorry -- I have to quit dreaming -- it just makes you depressed. -John On Feb 18, 2010, at 12:56 PM, LJ Longwing wrote: ** Tim, That doesn't seem excessive to mewhenever I'm looking at performance issues I turn on SQL and API logging at the server and run the ARLogAnalyzer against them...it tells me which processes are taking to long and I tweak that workflow, indexes, etc. _ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Tim Rondeau Sent: Thursday, February 18, 2010 11:43 AM To: arslist@ARSLIST.ORG Subject: Performance issues ** Arsystem 7.1 patch 7 ITSM suite, using SLM, CMDB, Change Management, Problem and Incident We are running SQL 2005 on windows 2003 server, plenty of CPU/disk and RAM. Looking for some feed back on how some have handled performance issues. We process about 400 changes a day and about 800 incidents a day. Just seems like this system can't handle it. DB timeouts, white screens all the time. DBA of course states no issues. In March we are moving to Oracle RAC, which will be 2 robust db servers. APP will still be on windows. Thanks Tim _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ -- John Sundberg Kinetic Data, Inc. Building a Better Service Experience Recipient of the WWRUG09 Innovator of the Year Award john.sundb...@kineticdata.com 651.556.0930 I http://www.kineticdata.com/ www.kineticdata.com _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
DSL 2.1 - ITSM 7.0.3 patch 7 - DSL Performance issues
All, Has anyone run into issues where search menus and other drop downs just hang because of inefficient SQL queries? A lot of the menus (the Product File Lookup form search menu for File ID for example), does a LIKE query against a huge number of records. The thing is, this is OOB with the DSL data load provided by BMC. Is there a way to optimize these menus without a lot of custom work? I guess I can always reach out to the DBA to see if he can work some magic on indexes. I do see that the field being searched on is indexed on the form, but obviously it is not helping. Tauf Chowdhury | Forest Laboratories, Inc. Analyst, Service Management Informatics-Infrastructure Office: 631.858.7765 Mobile:646.483.2779 ** This e-mail and its attachments may contain Forest Laboratories, Inc. proprietary information that is privileged, confidential or subject to copyright belonging to Forest Laboratories, Inc. This e-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this e-mail, or the employee or agent responsible for delivering this e-mail to the intended recipient, you are hereby notified that any dissemination, distribution, copying or action taken in relation to the contents of and attachments to this e-mail is strictly prohibited and may be unlawful. If you have received this e-mail in error, please notify the sender immediately and permanently delete the original and any copy of this e-mail and any printout. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
ARVALIDATE Cache and Performance Issues
We upgraded from 6.3 to 7.1 recently without changing any workflow or functions. Since that time, our server keeps hanging and sometimes crashing. We realized that we didn't have enough CPUs for 7.1 last week and so we added additional CPUs and oddly enough it just made our situation worse. We have contacted BMC but they are not responding very quickly and we have done everything that they have come back with. Looking at our API logs, we noticed that ARValidateCache is showing up quite frequently. Can anyone please explain to me what that means or what it applies to. I read in the manuals about it, but I would like to know more about the purpose and why it would keep showing up everytime we start having a server freeze. Thank you ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: ARVALIDATE Cache and Performance Issues
Sorry that should be ARValidateFormCache On Nov 3, 9:17 am, jaimie jaimie...@gmail.com wrote: We upgraded from 6.3 to 7.1 recently without changing any workflow or functions. Since that time, our server keeps hanging and sometimes crashing. We realized that we didn't have enough CPUs for 7.1 last week and so we added additional CPUs and oddly enough it just made our situation worse. We have contacted BMC but they are not responding very quickly and we have done everything that they have come back with. Looking at our API logs, we noticed that ARValidateCache is showing up quite frequently. Can anyone please explain to me what that means or what it applies to. I read in the manuals about it, but I would like to know more about the purpose and why it would keep showing up everytime we start having a server freeze. Thank you ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: ARVALIDATE Cache and Performance Issues
Jaimie, Did you upgrade just the server or the clients as well? What patch of 7.1 did you go to, are you Native clients or Mid-Tier. I seem to remember a bug in the initial release 7.1, or was it with mismatched client/server...but either way the client re-cached EVERY time a form was opened instead of using its already received cache... -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of jaimie Sent: Tuesday, November 03, 2009 7:20 AM To: arslist@ARSLIST.ORG Subject: Re: ARVALIDATE Cache and Performance Issues Sorry that should be ARValidateFormCache On Nov 3, 9:17 am, jaimie jaimie...@gmail.com wrote: We upgraded from 6.3 to 7.1 recently without changing any workflow or functions. Since that time, our server keeps hanging and sometimes crashing. We realized that we didn't have enough CPUs for 7.1 last week and so we added additional CPUs and oddly enough it just made our situation worse. We have contacted BMC but they are not responding very quickly and we have done everything that they have come back with. Looking at our API logs, we noticed that ARValidateCache is showing up quite frequently. Can anyone please explain to me what that means or what it applies to. I read in the manuals about it, but I would like to know more about the purpose and why it would keep showing up everytime we start having a server freeze. Thank you __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: ARVALIDATE Cache and Performance Issues
This is the client checking to see if the cache you have is the most up to date information you have on the workflow. If there is a newer version on the AR Server then it will issue an ARExport etc. If you believe the workflow has not changed then make sure you delete your local .arv and .arf files. Kind regards Danny Sorry that should be ARValidateFormCache On Nov 3, 9:17 am, jaimie jaimie...@gmail.com wrote: We upgraded from 6.3 to 7.1 recently without changing any workflow or functions. Since that time, our server keeps hanging and sometimes crashing. We realized that we didn't have enough CPUs for 7.1 last week and so we added additional CPUs and oddly enough it just made our situation worse. We have contacted BMC but they are not responding very quickly and we have done everything that they have come back with. Looking at our API logs, we noticed that ARValidateCache is showing up quite frequently. Can anyone please explain to me what that means or what it applies to. I read in the manuals about it, but I would like to know more about the purpose and why it would keep showing up everytime we start having a server freeze. Thank you ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: ARVALIDATE Cache and Performance Issues
We updated both at the same time to patch 7. We are using mid-tier, native clients, but more users go through Citrix which is also version 7.1. do you remember if there was a fix for that? On Nov 3, 9:42 am, LJ Longwing lj.longw...@gmail.com wrote: Jaimie, Did you upgrade just the server or the clients as well? What patch of 7.1 did you go to, are you Native clients or Mid-Tier. I seem to remember a bug in the initial release 7.1, or was it with mismatched client/server...but either way the client re-cached EVERY time a form was opened instead of using its already received cache... -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of jaimie Sent: Tuesday, November 03, 2009 7:20 AM To: arsl...@arslist.org Subject: Re: ARVALIDATE Cache and Performance Issues Sorry that should be ARValidateFormCache On Nov 3, 9:17 am, jaimie jaimie...@gmail.com wrote: We upgraded from 6.3 to 7.1 recently without changing any workflow or functions. Since that time, our server keeps hanging and sometimes crashing. We realized that we didn't have enough CPUs for 7.1 last week and so we added additional CPUs and oddly enough it just made our situation worse. We have contacted BMC but they are not responding very quickly and we have done everything that they have come back with. Looking at our API logs, we noticed that ARValidateCache is showing up quite frequently. Can anyone please explain to me what that means or what it applies to. I read in the manuals about it, but I would like to know more about the purpose and why it would keep showing up everytime we start having a server freeze. Thank you __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are ____ ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are- Hide quoted text - - Show quoted text - ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: ARVALIDATE Cache and Performance Issues
Which patch? -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of jaimie Sent: Tuesday, November 03, 2009 7:50 AM To: arslist@ARSLIST.ORG Subject: Re: ARVALIDATE Cache and Performance Issues We updated both at the same time to patch 7. We are using mid-tier, native clients, but more users go through Citrix which is also version 7.1. do you remember if there was a fix for that? On Nov 3, 9:42 am, LJ Longwing lj.longw...@gmail.com wrote: Jaimie, Did you upgrade just the server or the clients as well? What patch of 7.1 did you go to, are you Native clients or Mid-Tier. I seem to remember a bug in the initial release 7.1, or was it with mismatched client/server...but either way the client re-cached EVERY time a form was opened instead of using its already received cache... -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of jaimie Sent: Tuesday, November 03, 2009 7:20 AM To: arsl...@arslist.org Subject: Re: ARVALIDATE Cache and Performance Issues Sorry that should be ARValidateFormCache On Nov 3, 9:17 am, jaimie jaimie...@gmail.com wrote: We upgraded from 6.3 to 7.1 recently without changing any workflow or functions. Since that time, our server keeps hanging and sometimes crashing. We realized that we didn't have enough CPUs for 7.1 last week and so we added additional CPUs and oddly enough it just made our situation worse. We have contacted BMC but they are not responding very quickly and we have done everything that they have come back with. Looking at our API logs, we noticed that ARValidateCache is showing up quite frequently. Can anyone please explain to me what that means or what it applies to. I read in the manuals about it, but I would like to know more about the purpose and why it would keep showing up everytime we start having a server freeze. Thank you __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are __ __ ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are- Hide quoted text - - Show quoted text - ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: ARVALIDATE Cache and Performance Issues
Patch 7 On Nov 3, 9:58 am, LJ Longwing lj.longw...@gmail.com wrote: Which patch? -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of jaimie Sent: Tuesday, November 03, 2009 7:50 AM To: arsl...@arslist.org Subject: Re: ARVALIDATE Cache and Performance Issues We updated both at the same time to patch 7. We are using mid-tier, native clients, but more users go through Citrix which is also version 7.1. do you remember if there was a fix for that? On Nov 3, 9:42 am, LJ Longwing lj.longw...@gmail.com wrote: Jaimie, Did you upgrade just the server or the clients as well? What patch of 7.1 did you go to, are you Native clients or Mid-Tier. I seem to remember a bug in the initial release 7.1, or was it with mismatched client/server...but either way the client re-cached EVERY time a form was opened instead of using its already received cache... -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of jaimie Sent: Tuesday, November 03, 2009 7:20 AM To: arsl...@arslist.org Subject: Re: ARVALIDATE Cache and Performance Issues Sorry that should be ARValidateFormCache On Nov 3, 9:17 am, jaimie jaimie...@gmail.com wrote: We upgraded from 6.3 to 7.1 recently without changing any workflow or functions. Since that time, our server keeps hanging and sometimes crashing. We realized that we didn't have enough CPUs for 7.1 last week and so we added additional CPUs and oddly enough it just made our situation worse. We have contacted BMC but they are not responding very quickly and we have done everything that they have come back with. Looking at our API logs, we noticed that ARValidateCache is showing up quite frequently. Can anyone please explain to me what that means or what it applies to. I read in the manuals about it, but I would like to know more about the purpose and why it would keep showing up everytime we start having a server freeze. Thank you __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are __ __ ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are- Hide quoted text - - Show quoted text - ____ ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are- Hide quoted text - - Show quoted text - ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: ARVALIDATE Cache and Performance Issues
Also I checked the logs and the ARExport is not showing up every time the ARValidateFormCache is showing up. On Nov 3, 10:08 am, jaimie jaimie...@gmail.com wrote: Patch 7 On Nov 3, 9:58 am, LJ Longwing lj.longw...@gmail.com wrote: Which patch? -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of jaimie Sent: Tuesday, November 03, 2009 7:50 AM To: arsl...@arslist.org Subject: Re: ARVALIDATE Cache and Performance Issues We updated both at the same time to patch 7. We are using mid-tier, native clients, but more users go through Citrix which is also version 7.1. do you remember if there was a fix for that? On Nov 3, 9:42 am, LJ Longwing lj.longw...@gmail.com wrote: Jaimie, Did you upgrade just the server or the clients as well? What patch of 7.1 did you go to, are you Native clients or Mid-Tier. I seem to remember a bug in the initial release 7.1, or was it with mismatched client/server...but either way the client re-cached EVERY time a form was opened instead of using its already received cache... -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of jaimie Sent: Tuesday, November 03, 2009 7:20 AM To: arsl...@arslist.org Subject: Re: ARVALIDATE Cache and Performance Issues Sorry that should be ARValidateFormCache On Nov 3, 9:17 am, jaimie jaimie...@gmail.com wrote: We upgraded from 6.3 to 7.1 recently without changing any workflow or functions. Since that time, our server keeps hanging and sometimes crashing. We realized that we didn't have enough CPUs for 7.1 last week and so we added additional CPUs and oddly enough it just made our situation worse. We have contacted BMC but they are not responding very quickly and we have done everything that they have come back with. Looking at our API logs, we noticed that ARValidateCache is showing up quite frequently. Can anyone please explain to me what that means or what it applies to. I read in the manuals about it, but I would like to know more about the purpose and why it would keep showing up everytime we start having a server freeze. Thank you __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinumSponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are __ __ ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are- Hide quoted text - - Show quoted text - ____ ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are- Hide quoted text - - Show quoted text - ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are- Hide quoted text - - Show quoted text - ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: ARVALIDATE Cache and Performance Issues
OkI would recommend writing an AL on your home page that checks if $VERSION$ != Expected version, and have it throw a message to the user saying they need to upgrade, and run a log or send an email or something to the admins so they can follow-up with those users -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of jaimie Sent: Tuesday, November 03, 2009 8:08 AM To: arslist@ARSLIST.ORG Subject: Re: ARVALIDATE Cache and Performance Issues Patch 7 On Nov 3, 9:58 am, LJ Longwing lj.longw...@gmail.com wrote: Which patch? -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of jaimie Sent: Tuesday, November 03, 2009 7:50 AM To: arsl...@arslist.org Subject: Re: ARVALIDATE Cache and Performance Issues We updated both at the same time to patch 7. We are using mid-tier, native clients, but more users go through Citrix which is also version 7.1. do you remember if there was a fix for that? On Nov 3, 9:42 am, LJ Longwing lj.longw...@gmail.com wrote: Jaimie, Did you upgrade just the server or the clients as well? What patch of 7.1 did you go to, are you Native clients or Mid-Tier. I seem to remember a bug in the initial release 7.1, or was it with mismatched client/server...but either way the client re-cached EVERY time a form was opened instead of using its already received cache... -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of jaimie Sent: Tuesday, November 03, 2009 7:20 AM To: arsl...@arslist.org Subject: Re: ARVALIDATE Cache and Performance Issues Sorry that should be ARValidateFormCache On Nov 3, 9:17 am, jaimie jaimie...@gmail.com wrote: We upgraded from 6.3 to 7.1 recently without changing any workflow or functions. Since that time, our server keeps hanging and sometimes crashing. We realized that we didn't have enough CPUs for 7.1 last week and so we added additional CPUs and oddly enough it just made our situation worse. We have contacted BMC but they are not responding very quickly and we have done everything that they have come back with. Looking at our API logs, we noticed that ARValidateCache is showing up quite frequently. Can anyone please explain to me what that means or what it applies to. I read in the manuals about it, but I would like to know more about the purpose and why it would keep showing up everytime we start having a server freeze. Thank you __ __ __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are __ __ ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are- Hide quoted text - - Show quoted text - __ __ ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are- Hide quoted text - - Show quoted text - ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: ARVALIDATE Cache and Performance Issues
If we had any users on an older client it would only be about 15 users. The remaining 400 go through Citrix and that client was upgraded to 7.1 patch 7 all all of our Citrix servers. On Nov 3, 10:21 am, LJ Longwing lj.longw...@gmail.com wrote: OkI would recommend writing an AL on your home page that checks if $VERSION$ != Expected version, and have it throw a message to the user saying they need to upgrade, and run a log or send an email or something to the admins so they can follow-up with those users -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of jaimie Sent: Tuesday, November 03, 2009 8:08 AM To: arsl...@arslist.org Subject: Re: ARVALIDATE Cache and Performance Issues Patch 7 On Nov 3, 9:58 am, LJ Longwing lj.longw...@gmail.com wrote: Which patch? -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of jaimie Sent: Tuesday, November 03, 2009 7:50 AM To: arsl...@arslist.org Subject: Re: ARVALIDATE Cache and Performance Issues We updated both at the same time to patch 7. We are using mid-tier, native clients, but more users go through Citrix which is also version 7.1. do you remember if there was a fix for that? On Nov 3, 9:42 am, LJ Longwing lj.longw...@gmail.com wrote: Jaimie, Did you upgrade just the server or the clients as well? What patch of 7.1 did you go to, are you Native clients or Mid-Tier. I seem to remember a bug in the initial release 7.1, or was it with mismatched client/server...but either way the client re-cached EVERY time a form was opened instead of using its already received cache... -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of jaimie Sent: Tuesday, November 03, 2009 7:20 AM To: arsl...@arslist.org Subject: Re: ARVALIDATE Cache and Performance Issues Sorry that should be ARValidateFormCache On Nov 3, 9:17 am, jaimie jaimie...@gmail.com wrote: We upgraded from 6.3 to 7.1 recently without changing any workflow or functions. Since that time, our server keeps hanging and sometimes crashing. We realized that we didn't have enough CPUs for 7.1 last week and so we added additional CPUs and oddly enough it just made our situation worse. We have contacted BMC but they are not responding very quickly and we have done everything that they have come back with. Looking at our API logs, we noticed that ARValidateCache is showing up quite frequently. Can anyone please explain to me what that means or what it applies to. I read in the manuals about it, but I would like to know more about the purpose and why it would keep showing up everytime we start having a server freeze. Thank you __ __ __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinumSponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are __ __ ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are- Hide quoted text - - Show quoted text - __ __ ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are- Hide quoted text - - Show quoted text - ____ ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are- Hide quoted text - - Show quoted text - ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: ARVALIDATE Cache and Performance Issues
The ARValidateFormCache will be executed everytime you open a form. It will be a quick call if the cache is up to date and it will do an ARExport if its not. If you are seeing ARValidateFormCache taking longer than half a second then contact BMC. I found that on our system the ARExport hit the server a lot harder than the ARValidateFormCache. Also I checked the logs and the ARExport is not showing up every time the ARValidateFormCache is showing up. On Nov 3, 10:08 am, jaimie jaimie...@gmail.com wrote: Patch 7 On Nov 3, 9:58 am, LJ Longwing lj.longw...@gmail.com wrote: Which patch? -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of jaimie Sent: Tuesday, November 03, 2009 7:50 AM To: arsl...@arslist.org Subject: Re: ARVALIDATE Cache and Performance Issues We updated both at the same time to patch 7. We are using mid-tier, native clients, but more users go through Citrix which is also version 7.1. do you remember if there was a fix for that? On Nov 3, 9:42 am, LJ Longwing lj.longw...@gmail.com wrote: Jaimie, Did you upgrade just the server or the clients as well? What patch of 7.1 did you go to, are you Native clients or Mid-Tier. I seem to remember a bug in the initial release 7.1, or was it with mismatched client/server...but either way the client re-cached EVERY time a form was opened instead of using its already received cache... -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of jaimie Sent: Tuesday, November 03, 2009 7:20 AM To: arsl...@arslist.org Subject: Re: ARVALIDATE Cache and Performance Issues Sorry that should be ARValidateFormCache On Nov 3, 9:17 am, jaimie jaimie...@gmail.com wrote: We upgraded from 6.3 to 7.1 recently without changing any workflow or functions. Since that time, our server keeps hanging and sometimes crashing. We realized that we didn't have enough CPUs for 7.1 last week and so we added additional CPUs and oddly enough it just made our situation worse. We have contacted BMC but they are not responding very quickly and we have done everything that they have come back with. Looking at our API logs, we noticed that ARValidateCache is showing up quite frequently. Can anyone please explain to me what that means or what it applies to. I read in the manuals about it, but I would like to know more about the purpose and why it would keep showing up everytime we start having a server freeze. Thank you __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinumSponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are __ __ ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are- Hide quoted text - - Show quoted text - ____ ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are- Hide quoted text - - Show quoted text - ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are- Hide quoted text - - Show quoted text - ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: ARVALIDATE Cache and Performance Issues
I have never run on a Citrix server before. Do all users share a home directory? Would the cache files get removed at any point? If we had any users on an older client it would only be about 15 users. The remaining 400 go through Citrix and that client was upgraded to 7.1 patch 7 all all of our Citrix servers. On Nov 3, 10:21 am, LJ Longwing lj.longw...@gmail.com wrote: OkI would recommend writing an AL on your home page that checks if $VERSION$ != Expected version, and have it throw a message to the user saying they need to upgrade, and run a log or send an email or something to the admins so they can follow-up with those users -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of jaimie Sent: Tuesday, November 03, 2009 8:08 AM To: arsl...@arslist.org Subject: Re: ARVALIDATE Cache and Performance Issues Patch 7 On Nov 3, 9:58 am, LJ Longwing lj.longw...@gmail.com wrote: Which patch? -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of jaimie Sent: Tuesday, November 03, 2009 7:50 AM To: arsl...@arslist.org Subject: Re: ARVALIDATE Cache and Performance Issues We updated both at the same time to patch 7. We are using mid-tier, native clients, but more users go through Citrix which is also version 7.1. do you remember if there was a fix for that? On Nov 3, 9:42 am, LJ Longwing lj.longw...@gmail.com wrote: Jaimie, Did you upgrade just the server or the clients as well? What patch of 7.1 did you go to, are you Native clients or Mid-Tier. I seem to remember a bug in the initial release 7.1, or was it with mismatched client/server...but either way the client re-cached EVERY time a form was opened instead of using its already received cache... -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of jaimie Sent: Tuesday, November 03, 2009 7:20 AM To: arsl...@arslist.org Subject: Re: ARVALIDATE Cache and Performance Issues Sorry that should be ARValidateFormCache On Nov 3, 9:17 am, jaimie jaimie...@gmail.com wrote: We upgraded from 6.3 to 7.1 recently without changing any workflow or functions. Since that time, our server keeps hanging and sometimes crashing. We realized that we didn't have enough CPUs for 7.1 last week and so we added additional CPUs and oddly enough it just made our situation worse. We have contacted BMC but they are not responding very quickly and we have done everything that they have come back with. Looking at our API logs, we noticed that ARValidateCache is showing up quite frequently. Can anyone please explain to me what that means or what it applies to. I read in the manuals about it, but I would like to know more about the purpose and why it would keep showing up everytime we start having a server freeze. Thank you __ __ __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinumSponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are __ __ ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are- Hide quoted text - - Show quoted text - __ __ ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are- Hide quoted text - - Show quoted text - ____ ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are- Hide quoted text - - Show quoted text - ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers
Re: ARVALIDATE Cache and Performance Issues
Those 15 might be the bugs in your stew...ARValidateFormCache, if I'm not mistaken is a 'resource intensive' action...you didn't say if you were ITSM or not, but those forms are huge and could in theory cause problems. Are you guys Windows/Solaris/...? -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of jaimie Sent: Tuesday, November 03, 2009 8:31 AM To: arslist@ARSLIST.ORG Subject: Re: ARVALIDATE Cache and Performance Issues If we had any users on an older client it would only be about 15 users. The remaining 400 go through Citrix and that client was upgraded to 7.1 patch 7 all all of our Citrix servers. On Nov 3, 10:21 am, LJ Longwing lj.longw...@gmail.com wrote: OkI would recommend writing an AL on your home page that checks if $VERSION$ != Expected version, and have it throw a message to the user saying they need to upgrade, and run a log or send an email or something to the admins so they can follow-up with those users -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of jaimie Sent: Tuesday, November 03, 2009 8:08 AM To: arsl...@arslist.org Subject: Re: ARVALIDATE Cache and Performance Issues Patch 7 On Nov 3, 9:58 am, LJ Longwing lj.longw...@gmail.com wrote: Which patch? -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of jaimie Sent: Tuesday, November 03, 2009 7:50 AM To: arsl...@arslist.org Subject: Re: ARVALIDATE Cache and Performance Issues We updated both at the same time to patch 7. We are using mid-tier, native clients, but more users go through Citrix which is also version 7.1. do you remember if there was a fix for that? On Nov 3, 9:42 am, LJ Longwing lj.longw...@gmail.com wrote: Jaimie, Did you upgrade just the server or the clients as well? What patch of 7.1 did you go to, are you Native clients or Mid-Tier. I seem to remember a bug in the initial release 7.1, or was it with mismatched client/server...but either way the client re-cached EVERY time a form was opened instead of using its already received cache... -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of jaimie Sent: Tuesday, November 03, 2009 7:20 AM To: arsl...@arslist.org Subject: Re: ARVALIDATE Cache and Performance Issues Sorry that should be ARValidateFormCache On Nov 3, 9:17 am, jaimie jaimie...@gmail.com wrote: We upgraded from 6.3 to 7.1 recently without changing any workflow or functions. Since that time, our server keeps hanging and sometimes crashing. We realized that we didn't have enough CPUs for 7.1 last week and so we added additional CPUs and oddly enough it just made our situation worse. We have contacted BMC but they are not responding very quickly and we have done everything that they have come back with. Looking at our API logs, we noticed that ARValidateCache is showing up quite frequently. Can anyone please explain to me what that means or what it applies to. I read in the manuals about it, but I would like to know more about the purpose and why it would keep showing up everytime we start having a server freeze. Thank you __ __ __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinumSponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are __ __ __ __ ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are __ __ __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are- Hide quoted text - - Show quoted text - __ __ ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are- Hide quoted text - - Show quoted text - __ __ ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers
Re: ARVALIDATE Cache and Performance Issues
We are not using any ITSM applications, its all custom forms. We are on AIX and using Oracle 10g R3. On Nov 3, 10:39 am, LJ Longwing lj.longw...@gmail.com wrote: Those 15 might be the bugs in your stew...ARValidateFormCache, if I'm not mistaken is a 'resource intensive' action...you didn't say if you were ITSM or not, but those forms are huge and could in theory cause problems. Are you guys Windows/Solaris/...? -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of jaimie Sent: Tuesday, November 03, 2009 8:31 AM To: arsl...@arslist.org Subject: Re: ARVALIDATE Cache and Performance Issues If we had any users on an older client it would only be about 15 users. The remaining 400 go through Citrix and that client was upgraded to 7.1 patch 7 all all of our Citrix servers. On Nov 3, 10:21 am, LJ Longwing lj.longw...@gmail.com wrote: OkI would recommend writing an AL on your home page that checks if $VERSION$ != Expected version, and have it throw a message to the user saying they need to upgrade, and run a log or send an email or something to the admins so they can follow-up with those users -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of jaimie Sent: Tuesday, November 03, 2009 8:08 AM To: arsl...@arslist.org Subject: Re: ARVALIDATE Cache and Performance Issues Patch 7 On Nov 3, 9:58 am, LJ Longwing lj.longw...@gmail.com wrote: Which patch? -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of jaimie Sent: Tuesday, November 03, 2009 7:50 AM To: arsl...@arslist.org Subject: Re: ARVALIDATE Cache and Performance Issues We updated both at the same time to patch 7. We are using mid-tier, native clients, but more users go through Citrix which is also version 7.1. do you remember if there was a fix for that? On Nov 3, 9:42 am, LJ Longwing lj.longw...@gmail.com wrote: Jaimie, Did you upgrade just the server or the clients as well? What patch of 7.1 did you go to, are you Native clients or Mid-Tier. I seem to remember a bug in the initial release 7.1, or was it with mismatched client/server...but either way the client re-cached EVERY time a form was opened instead of using its already received cache... -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of jaimie Sent: Tuesday, November 03, 2009 7:20 AM To: arsl...@arslist.org Subject: Re: ARVALIDATE Cache and Performance Issues Sorry that should be ARValidateFormCache On Nov 3, 9:17 am, jaimie jaimie...@gmail.com wrote: We upgraded from 6.3 to 7.1 recently without changing any workflow or functions. Since that time, our server keeps hanging and sometimes crashing. We realized that we didn't have enough CPUs for 7.1 last week and so we added additional CPUs and oddly enough it just made our situation worse. We have contacted BMC but they are not responding very quickly and we have done everything that they have come back with. Looking at our API logs, we noticed that ARValidateCache is showing up quite frequently. Can anyone please explain to me what that means or what it applies to. I read in the manuals about it, but I would like to know more about the purpose and why it would keep showing up everytime we start having a server freeze. Thank you __ __ __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinumSponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are __ __ __ __ ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are __ __ __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinumSponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are- Hide quoted text - - Show quoted text - __ __ ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are- Hide quoted text - - Show quoted text
Re: Performance Issues with 7.1 Patch 7
Saby, We are running SQL 2005 also.Things seem better since then, but it was a bad week From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Sabyson Fernandes Sent: Friday, October 02, 2009 11:08 AM To: arslist@ARSLIST.ORG Subject: Re: Performance Issues with 7.1 Patch 7 ** Hi Tim, Not sure what DB you are using. But have you checked for locks at the db level? We had a similar issue and the error we were getting was mis-leading and pointing us to the plugins, when infact it was locks at the db levels for the tables that the plugin was accessing that was slowing/timing out operations. We are running ARS 7.1 P5 with ITSM 7.0.3 Patch 7 (server groups) on a windows server with SQL Server 2005 db on the backend. Saby From: Tim Rondeau timothy.rond...@phaseforward.com To: arslist@ARSLIST.ORG Sent: Friday, October 2, 2009 10:18:34 AM Subject: Re: Performance Issues with 7.1 Patch 7 ** Everyone I don’t think it actually was email. I think the email errors, just because DB was too busy. Anyone have any other issues with the DB with this patch on windows? Thanks Tim From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Rodriguez, Rafael J x23718 Sent: Friday, October 02, 2009 9:54 AM To: arslist@ARSLIST.ORG Subject: Re: Performance Issues with 7.1 Patch 7 Email ** Tim as per BMC's recommendation for performance tunning for email engine, please check the following setting in your emaildeamon.properties file and make the neccessary changes. You will experience a HUGE performance boost. Change the following entries in the emaildeamon.properties file from 100 to 200: com.remedy.arsys.emaildaemon.IncomingConnectionRecycleSize=200 com.remedy.arsys.emaildaemon.IncomingMessagesQueueSize=200 com.remedy.arsys.emaildaemon.OutgoingConnectionRecycleSize=200 com.remedy.arsys.emaildaemon.SendEmailSetSize=200 Also change the following line item from true to false which will force email polling to seconds from Minutes. com.remedy.arsys.emaildaemon.MailboxPollingUnitIsMinutes=false From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Tim Rondeau Sent: Thursday, October 01, 2009 11:13 PM To: arslist@ARSLIST.ORG Subject: Performance Issues with 7.1 Patch 7 Email ** Running 7.1 patch 7 and noticing slowness which really brings remedy to a hault. The table is T.64 which is AR SYSTEM Email Messages. Anyone have performance issues with this version. Thanks Tim _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_
Re: Performance Issues with 7.1 Patch 7 Email
Tim, How many records on are on the email messages form? Kevin Begosh, RSP Remedy Development ACE-IT ISGS Defense 301-791-3540 Phone 240-291-2467 Cell kevin.beg...@lmco.com From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Tim Rondeau Sent: Thursday, October 01, 2009 10:16 PM To: arslist@ARSLIST.ORG Subject: Re: Performance Issues with 7.1 Patch 7 Email ** Joe, Looking at it now, I don't think it was email.I think the errors in the log because database was too busy. Do you have 7.1 patch 7, we are running on windows? Seen any performance issues. Tim From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe DeSouza Sent: Friday, October 02, 2009 12:02 AM To: arslist@ARSLIST.ORG Subject: Re: Performance Issues with 7.1 Patch 7 Email ** Tim, If the unprocessed emails in that form are not really important, then I would suggest to truncate the T64 and H64 and the email attachment tables T H and B table.. and the other relationship tables Then once you have the ball rolling again, make sure that a new email after being processed is being auto deleted. I do not remember offhand if its an escalation that deletes it periodically or if a filter deletes it after having processed the email. But whatever it is - if it fails to delete, you need to look into why. Maybe your error logs would tell you something? Joe From: Tim Rondeau timothy.rond...@phaseforward.com To: arslist@ARSLIST.ORG Sent: Thursday, October 1, 2009 11:12:48 PM Subject: Performance Issues with 7.1 Patch 7 Email ** Running 7.1 patch 7 and noticing slowness which really brings remedy to a hault. The table is T.64 which is AR SYSTEM Email Messages. Anyone have performance issues with this version. Thanks Tim _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Performance Issues with 7.1 Patch 7 Email
We have experienced some fun with Remedy 7.1 P7 email, more with Outbound intermittently NOT sending attachments. Contact me off list and I can give you the short story. Oh how I wish I still had Rem-Mail. Doug From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Begosh, Kevin Sent: Friday, October 02, 2009 8:39 AM To: arslist@ARSLIST.ORG Subject: Re: Performance Issues with 7.1 Patch 7 Email ** Tim, How many records on are on the email messages form? Kevin Begosh, RSP Remedy Development ACE-IT ISGS Defense 301-791-3540 Phone 240-291-2467 Cell kevin.beg...@lmco.com From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Tim Rondeau Sent: Thursday, October 01, 2009 10:16 PM To: arslist@ARSLIST.ORG Subject: Re: Performance Issues with 7.1 Patch 7 Email ** Joe, Looking at it now, I don't think it was email.I think the errors in the log because database was too busy. Do you have 7.1 patch 7, we are running on windows? Seen any performance issues. Tim From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe DeSouza Sent: Friday, October 02, 2009 12:02 AM To: arslist@ARSLIST.ORG Subject: Re: Performance Issues with 7.1 Patch 7 Email ** Tim, If the unprocessed emails in that form are not really important, then I would suggest to truncate the T64 and H64 and the email attachment tables T H and B table.. and the other relationship tables Then once you have the ball rolling again, make sure that a new email after being processed is being auto deleted. I do not remember offhand if its an escalation that deletes it periodically or if a filter deletes it after having processed the email. But whatever it is - if it fails to delete, you need to look into why. Maybe your error logs would tell you something? Joe From: Tim Rondeau timothy.rond...@phaseforward.com To: arslist@ARSLIST.ORG Sent: Thursday, October 1, 2009 11:12:48 PM Subject: Performance Issues with 7.1 Patch 7 Email ** Running 7.1 patch 7 and noticing slowness which really brings remedy to a hault. The table is T.64 which is AR SYSTEM Email Messages. Anyone have performance issues with this version. Thanks Tim _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ DISCLAIMER Important! This message is intended for the above named person(s) only and is CONFIDENTIAL AND PROPRIETARY. If you are not the intended recipient of this e-mail and have received it in error, please immediately notify the sender by return email and then delete it from your mailbox. This message may be protected by the attorney-client privilege and/or work product doctrine. Accessing, copying, disseminating or re-using any of the information contained in this e-mail by anyone other than the intended recipient is strictly prohibited. Finally, you should check this email and any attachments for the presence of viruses, as the sender accepts no liability for any damage caused by any virus transmitted by this email. Thank you. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Performance Issues with 7.1 Patch 7 Email
Tim as per BMC's recommendation for performance tunning for email engine, please check the following setting in your emaildeamon.properties file and make the neccessary changes. You will experience a HUGE performance boost. Change the following entries in the emaildeamon.properties file from 100 to 200: com.remedy.arsys.emaildaemon.IncomingConnectionRecycleSize=200 com.remedy.arsys.emaildaemon.IncomingMessagesQueueSize=200 com.remedy.arsys.emaildaemon.OutgoingConnectionRecycleSize=200 com.remedy.arsys.emaildaemon.SendEmailSetSize=200 Also change the following line item from true to false which will force email polling to seconds from Minutes. com.remedy.arsys.emaildaemon.MailboxPollingUnitIsMinutes=false From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Tim Rondeau Sent: Thursday, October 01, 2009 11:13 PM To: arslist@ARSLIST.ORG Subject: Performance Issues with 7.1 Patch 7 Email ** Running 7.1 patch 7 and noticing slowness which really brings remedy to a hault. The table is T.64 which is AR SYSTEM Email Messages. Anyone have performance issues with this version. Thanks Tim _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Performance Issues with 7.1 Patch 7
Everyone I don't think it actually was email. I think the email errors, just because DB was too busy. Anyone have any other issues with the DB with this patch on windows? Thanks Tim From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Rodriguez, Rafael J x23718 Sent: Friday, October 02, 2009 9:54 AM To: arslist@ARSLIST.ORG Subject: Re: Performance Issues with 7.1 Patch 7 Email ** Tim as per BMC's recommendation for performance tunning for email engine, please check the following setting in your emaildeamon.properties file and make the neccessary changes. You will experience a HUGE performance boost. Change the following entries in the emaildeamon.properties file from 100 to 200: com.remedy.arsys.emaildaemon.IncomingConnectionRecycleSize=200 com.remedy.arsys.emaildaemon.IncomingMessagesQueueSize=200 com.remedy.arsys.emaildaemon.OutgoingConnectionRecycleSize=200 com.remedy.arsys.emaildaemon.SendEmailSetSize=200 Also change the following line item from true to false which will force email polling to seconds from Minutes. com.remedy.arsys.emaildaemon.MailboxPollingUnitIsMinutes=false From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Tim Rondeau Sent: Thursday, October 01, 2009 11:13 PM To: arslist@ARSLIST.ORG Subject: Performance Issues with 7.1 Patch 7 Email ** Running 7.1 patch 7 and noticing slowness which really brings remedy to a hault. The table is T.64 which is AR SYSTEM Email Messages. Anyone have performance issues with this version. Thanks Tim _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Performance Issues with 7.1 Patch 7
Hi Tim, Not sure what DB you are using. But have you checked for locks at the db level? We had a similar issue and the error we were getting was mis-leading and pointing us to the plugins, when infact it was locks at the db levels for the tables that the plugin was accessing that was slowing/timing out operations. We are running ARS 7.1 P5 with ITSM 7.0.3 Patch 7 (server groups) on a windows server with SQL Server 2005 db on the backend. Saby From: Tim Rondeau timothy.rond...@phaseforward.com To: arslist@ARSLIST.ORG Sent: Friday, October 2, 2009 10:18:34 AM Subject: Re: Performance Issues with 7.1 Patch 7 ** Everyone I don’t think it actually was email. I think the email errors, just because DB was too busy. Anyone have any other issues with the DB with this patch on windows? Thanks Tim From:Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Rodriguez, Rafael J x23718 Sent: Friday, October 02, 2009 9:54 AM To: arslist@ARSLIST.ORG Subject: Re: Performance Issues with 7.1 Patch 7 Email ** Tim as per BMC's recommendation for performance tunning for email engine, please check the following setting in your emaildeamon.properties file and make the neccessary changes. You will experience a HUGE performance boost. Change the following entries in the emaildeamon.properties file from 100 to 200: com.remedy.arsys.emaildaemon.IncomingConnectionRecycleSize=200 com.remedy.arsys.emaildaemon.IncomingMessagesQueueSize=200 com.remedy.arsys.emaildaemon.OutgoingConnectionRecycleSize=200 com.remedy.arsys.emaildaemon.SendEmailSetSize=200 Also change the following line item from true to false which will force email polling to seconds from Minutes. com.remedy.arsys.emaildaemon.MailboxPollingUnitIsMinutes=false From:Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Tim Rondeau Sent: Thursday, October 01, 2009 11:13 PM To: arslist@ARSLIST.ORG Subject: Performance Issues with 7.1 Patch 7 Email ** Running 7.1 patch 7 and noticing slowness which really brings remedy to a hault. The table is T.64 which is AR SYSTEM Email Messages. Anyone have performance issues with this version. Thanks Tim _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are__Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Performance Issues with 7.1 Patch 7 Email
I have noticed the databse being busy errors even when you have search related problems on large forms due to either indexing or just that the form has so many records that unqulified searches has that thread crawling... Currently I am already on 7.5 How many records in your email message form? select count(*) from T64; should give you that result without causing a performance hit on the db as it reports that number from the statistics.. Joe From: Tim Rondeau timothy.rond...@phaseforward.com To: arslist@ARSLIST.ORG Sent: Friday, October 2, 2009 12:16:00 AM Subject: Re: Performance Issues with 7.1 Patch 7 Email ** Joe, Looking at it now, I don’t think it was email. I think the errors in the log because database was too busy. Do you have 7.1 patch 7, we are running on windows? Seen any performance issues. Tim From:Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe DeSouza Sent: Friday, October 02, 2009 12:02 AM To: arslist@ARSLIST.ORG Subject: Re: Performance Issues with 7.1 Patch 7 Email ** Tim, If the unprocessed emails in that form are not really important, then I would suggest to truncate the T64 and H64 and the email attachment tables T H and B table.. and the other relationship tables Then once you have the ball rolling again, make sure that a new email after being processed is being auto deleted. I do not remember offhand if its an escalation that deletes it periodically or if a filter deletes it after having processed the email. But whatever it is - if it fails to delete, you need to look into why. Maybe your error logs would tell you something? Joe From:Tim Rondeau timothy.rond...@phaseforward.com To: arslist@ARSLIST.ORG Sent: Thursday, October 1, 2009 11:12:48 PM Subject: Performance Issues with 7.1 Patch 7 Email ** Running 7.1 patch 7 and noticing slowness which really brings remedy to a hault. The table is T.64 which is AR SYSTEM Email Messages. Anyone have performance issues with this version. Thanks Tim ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Performance Issues with 7.1 Patch 7
I read this email a minute after replying to your other one... select top 20 schemaid, nextid, name from arschema where nextid 1 order by nextid asc; is likely to give you a list of top 20 tables that have a record count of more than 1 (unless you have deleted in some and not reset the nextid) Increase 20 to 30 in case you see that the 20th table has a significantly large number of rows. Look at all the searches that happen on all these tables, and see if any of the searches are not optimized by way of searching a non indexed field.. Joe From: Tim Rondeau timothy.rond...@phaseforward.com To: arslist@ARSLIST.ORG Sent: Friday, October 2, 2009 10:18:34 AM Subject: Re: Performance Issues with 7.1 Patch 7 ** Everyone I don’t think it actually was email. I think the email errors, just because DB was too busy. Anyone have any other issues with the DB with this patch on windows? Thanks Tim From:Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Rodriguez, Rafael J x23718 Sent: Friday, October 02, 2009 9:54 AM To: arslist@ARSLIST.ORG Subject: Re: Performance Issues with 7.1 Patch 7 Email ** Tim as per BMC's recommendation for performance tunning for email engine, please check the following setting in your emaildeamon.properties file and make the neccessary changes. You will experience a HUGE performance boost. Change the following entries in the emaildeamon.properties file from 100 to 200: com.remedy.arsys.emaildaemon.IncomingConnectionRecycleSize=200 com.remedy.arsys.emaildaemon.IncomingMessagesQueueSize=200 com.remedy.arsys.emaildaemon.OutgoingConnectionRecycleSize=200 com.remedy.arsys.emaildaemon.SendEmailSetSize=200 Also change the following line item from true to false which will force email polling to seconds from Minutes. com.remedy.arsys.emaildaemon.MailboxPollingUnitIsMinutes=false From:Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Tim Rondeau Sent: Thursday, October 01, 2009 11:13 PM To: arslist@ARSLIST.ORG Subject: Performance Issues with 7.1 Patch 7 Email ** Running 7.1 patch 7 and noticing slowness which really brings remedy to a hault. The table is T.64 which is AR SYSTEM Email Messages. Anyone have performance issues with this version. Thanks Tim _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Performance Issues with 7.1 Patch 7 Email
Running 7.1 patch 7 and noticing slowness which really brings remedy to a hault. The table is T.64 which is AR SYSTEM Email Messages. Anyone have performance issues with this version. Thanks Tim ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Performance Issues with 7.1 Patch 7 Email
Tim, If the unprocessed emails in that form are not really important, then I would suggest to truncate the T64 and H64 and the email attachment tables T H and B table.. and the other relationship tables Then once you have the ball rolling again, make sure that a new email after being processed is being auto deleted. I do not remember offhand if its an escalation that deletes it periodically or if a filter deletes it after having processed the email. But whatever it is - if it fails to delete, you need to look into why. Maybe your error logs would tell you something? Joe From: Tim Rondeau timothy.rond...@phaseforward.com To: arslist@ARSLIST.ORG Sent: Thursday, October 1, 2009 11:12:48 PM Subject: Performance Issues with 7.1 Patch 7 Email ** Running 7.1 patch 7 and noticing slowness which really brings remedy to a hault. The table is T.64 which is AR SYSTEM Email Messages. Anyone have performance issues with this version. Thanks Tim ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Performance Issues with 7.1 Patch 7 Email
Joe, Looking at it now, I don't think it was email.I think the errors in the log because database was too busy. Do you have 7.1 patch 7, we are running on windows? Seen any performance issues. Tim From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe DeSouza Sent: Friday, October 02, 2009 12:02 AM To: arslist@ARSLIST.ORG Subject: Re: Performance Issues with 7.1 Patch 7 Email ** Tim, If the unprocessed emails in that form are not really important, then I would suggest to truncate the T64 and H64 and the email attachment tables T H and B table.. and the other relationship tables Then once you have the ball rolling again, make sure that a new email after being processed is being auto deleted. I do not remember offhand if its an escalation that deletes it periodically or if a filter deletes it after having processed the email. But whatever it is - if it fails to delete, you need to look into why. Maybe your error logs would tell you something? Joe From: Tim Rondeau timothy.rond...@phaseforward.com To: arslist@ARSLIST.ORG Sent: Thursday, October 1, 2009 11:12:48 PM Subject: Performance Issues with 7.1 Patch 7 Email ** Running 7.1 patch 7 and noticing slowness which really brings remedy to a hault. The table is T.64 which is AR SYSTEM Email Messages. Anyone have performance issues with this version. Thanks Tim _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Server Performance Issues??
The pause is between api calls: 13:43:24.9668 -EXECAL OK ... 13:46:05.4660 +GLE ARGetListEntry -- schema RPQ:Log from Remedy User There is maybe something else that is causing the wait time? If you run AL and Filter logs, where do you see the pause? Axton Grams On 8/30/07, David Sanders [EMAIL PROTECTED] wrote: Hi List I wonder whether anyone has come across a situation like this and can throw any light on what might be causing these performance issues. ARS Server 6.03.00 patch 013 SunOS 5.10 Oracle 9.2.0.5.0 64bit on remote machine (shared with other apps) Running arwklga against combined API+SQL logs throws up several lines like this: 2:40.5023 205245 actlink_set Wed Aug 29 2007 13:43:24.9652 SELECT assignShort,assignLong FROM actlink_set WHERE actlinkId = 6881 AND actionIndex = 0 AND fieldId = 1077077 2:23.4299 191087 actlink_set Wed Aug 29 2007 13:32:39.6091 SELECT assignShort,assignLong FROM actlink_set WHERE actlinkId = 6881 AND actionIndex = 0 AND fieldId = 1077077 Looking at one of these in detail gives 205243 API 0016990986 List390620 lp2d06 Wed Aug 29 2007 13:43:24.9636 +EXECAL ARExecuteProcessForActiveLink from Remedy User (protocol 11) at IP address 152.78.134.145 205244 SQL 0016990986 List390620 lp2d06 Wed Aug 29 2007 13:43:24.9638 SELECT actlinkId from actlink where name = 'RPQ:SHR-Lock0' 205245 SQL 0016990986 List390620 lp2d06 Wed Aug 29 2007 13:43:24.9652 SELECT assignShort,assignLong FROM actlink_set WHERE actlinkId = 6881 AND actionIndex = 0 AND fieldId = 1077077 205246 API 0016990986 List390620 lp2d06 Wed Aug 29 2007 13:43:24.9668 -EXECAL OK 208592 API 0016991463 List390620 lai Wed Aug 29 2007 13:46:05.4660 +GLE ARGetListEntry -- schema RPQ:Log from Remedy User 208593 SQL 0016991463 List390620 lai Wed Aug 29 2007 13:46:05.4675 SELECT T201.C1,C8,C700037500,C700037000,C700034003,C73000 FROM T201 WHERE … That is, these set fields actions seem to be taking a couple of minutes to complete. Looking at the objects involved, they are doing @@:Application-Generate-GUID or @@:Application-Confirm-Group processes. The +EXECAL to –EXECAL OK is quick, but the thread then does nothing for 2 mins 39 secs before the next action from another user. Is arwkloga misleading me when it says the actlink_set is taking 2 mins 40s – is there an issue with the PROCESS actions? – or is the thread just idle? Does anyone know what might take an Application-Generate-GUID process over 2 minutes to complete? As far as I can see, list and fast threads usage are OK and the system is not waiting for a thread. Thanks for any advice David Sanders Remedy Solution Architect Enterprise Service Suite @ Work == ARS List Award Winner 2005 Best 3rd party Remedy Application See theESS Concepts Guide tel +44 1494 468980 mobile +44 7710 377761 email [EMAIL PROTECTED] web http://www.westoverconsulting.co.uk ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Server Performance Issues??
Hi David, The detailed log rows does not show that the API-call is taking much time. There is a wait-time in between the calls, but... If you look at the RPC ID, you see a jump from 0016990986 to 0016991463, so the server has performed 477 API-calls between these calls. They may have been thread executed by other threads. Could arwklga have missinformed you? Best Regards - Misi, RRR AB, http://www.rrr.se Products from RRR Scandinavia: * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. * RRR|Translator - Manage and automate your language translations. Find these products, and many free tools and utilities, at http://rrr.se. Hi List I wonder whether anyone has come across a situation like this and can throw any light on what might be causing these performance issues. ARS Server 6.03.00 patch 013 SunOS 5.10 Oracle 9.2.0.5.0 64bit on remote machine (shared with other apps) Running arwklga against combined API+SQL logs throws up several lines like this: 2:40.5023 205245 actlink_set Wed Aug 29 2007 13:43:24.9652 SELECT assignShort,assignLong FROM actlink_set WHERE actlinkId = 6881 AND actionIndex = 0 AND fieldId = 1077077 2:23.4299 191087 actlink_set Wed Aug 29 2007 13:32:39.6091 SELECT assignShort,assignLong FROM actlink_set WHERE actlinkId = 6881 AND actionIndex = 0 AND fieldId = 1077077 Looking at one of these in detail gives 205243API 0016990986 List390620 lp2d06 Wed Aug 29 2007 13:43:24.9636 +EXECAL ARExecuteProcessForActiveLink from Remedy User (protocol 11) at IP address 152.78.134.145 205244SQL 0016990986 List390620 lp2d06 Wed Aug 29 2007 13:43:24.9638 SELECT actlinkId from actlink where name = 'RPQ:SHR-Lock0' 205245SQL 0016990986 List390620 lp2d06 Wed Aug 29 2007 13:43:24.9652 SELECT assignShort,assignLong FROM actlink_set WHERE actlinkId = 6881 AND actionIndex = 0 AND fieldId = 1077077 205246API 0016990986 List390620 lp2d06 Wed Aug 29 2007 13:43:24.9668 -EXECAL OK 208592API 0016991463 List390620 lai Wed Aug 29 2007 13:46:05.4660 +GLE ARGetListEntry -- schema RPQ:Log from Remedy User 208593SQL 0016991463 List390620 lai Wed Aug 29 2007 13:46:05.4675 SELECT T201.C1,C8,C700037500,C700037000,C700034003,C73000 FROM T201 WHERE That is, these set fields actions seem to be taking a couple of minutes to complete. Looking at the objects involved, they are doing @@:Application-Generate-GUID or @@:Application-Confirm-Group processes. The +EXECAL to EXECAL OK is quick, but the thread then does nothing for 2 mins 39 secs before the next action from another user. Is arwkloga misleading me when it says the actlink_set is taking 2 mins 40s is there an issue with the PROCESS actions? or is the thread just idle? Does anyone know what might take an Application-Generate-GUID process over 2 minutes to complete? As far as I can see, list and fast threads usage are OK and the system is not waiting for a thread. Thanks for any advice David Sanders Remedy Solution Architect Enterprise Service Suite @ Work == ARS List Award Winner 2005 Best 3rd party Remedy Application See the ESS Concepts Guide tel +44 1494 468980 mobile +44 7710 377761 email [EMAIL PROTECTED] web http://www.westoverconsulting.co.uk ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Server Performance Issues??
Hi Misi and Axton Thanks for the feedback. Yes, that was my suspicion (and hope) that arwklga was wrong. Arwklga was claiming that these process calls are taking 2 minutes to complete, but as far as I could see the +EXECAL to -EXECAL OK is completed quickly. I had 2 theories: 1) that the thread is actually idle and waiting for 2 minutes, or 2) that the @@:Application-Generate-GUID process is kicked off, the -EXECAL OK is returned immediately, but it is taking a further 2 minutes to return the result of the process. So the real question is, does the -EXECAL OK indicate that the process call has been started successfully, or completed successfully? Axton - I'll see if I can get some AL/Filter logs when this happens to compare with the API logs - that might answer the above question. Regards... Dave David Sanders Remedy Solution Architect Enterprise Service Suite @ Work == ARS List Award Winner 2005 Best 3rd party Remedy Application See the ESS Concepts Guide tel +44 1494 468980 mobile +44 7710 377761 email [EMAIL PROTECTED] web http://www.westoverconsulting.co.uk -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Misi Mladoniczky Sent: Thursday, August 30, 2007 7:04 PM To: arslist@ARSLIST.ORG Subject: Re: Server Performance Issues?? Hi David, The detailed log rows does not show that the API-call is taking much time. There is a wait-time in between the calls, but... If you look at the RPC ID, you see a jump from 0016990986 to 0016991463, so the server has performed 477 API-calls between these calls. They may have been thread executed by other threads. Could arwklga have missinformed you? Best Regards - Misi, RRR AB, http://www.rrr.se Products from RRR Scandinavia: * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. * RRR|Translator - Manage and automate your language translations. Find these products, and many free tools and utilities, at http://rrr.se. Hi List I wonder whether anyone has come across a situation like this and can throw any light on what might be causing these performance issues. ARS Server 6.03.00 patch 013 SunOS 5.10 Oracle 9.2.0.5.0 64bit on remote machine (shared with other apps) Running arwklga against combined API+SQL logs throws up several lines like this: 2:40.5023 205245 actlink_set Wed Aug 29 2007 13:43:24.9652 SELECT assignShort,assignLong FROM actlink_set WHERE actlinkId = 6881 AND actionIndex = 0 AND fieldId = 1077077 2:23.4299 191087 actlink_set Wed Aug 29 2007 13:32:39.6091 SELECT assignShort,assignLong FROM actlink_set WHERE actlinkId = 6881 AND actionIndex = 0 AND fieldId = 1077077 Looking at one of these in detail gives 205243API 0016990986 List390620 lp2d06 Wed Aug 29 2007 13:43:24.9636 +EXECAL ARExecuteProcessForActiveLink from Remedy User (protocol 11) at IP address 152.78.134.145 205244SQL 0016990986 List390620 lp2d06 Wed Aug 29 2007 13:43:24.9638 SELECT actlinkId from actlink where name = 'RPQ:SHR-Lock0' 205245SQL 0016990986 List390620 lp2d06 Wed Aug 29 2007 13:43:24.9652 SELECT assignShort,assignLong FROM actlink_set WHERE actlinkId = 6881 AND actionIndex = 0 AND fieldId = 1077077 205246API 0016990986 List390620 lp2d06 Wed Aug 29 2007 13:43:24.9668 -EXECAL OK 208592API 0016991463 List390620 lai Wed Aug 29 2007 13:46:05.4660 +GLE ARGetListEntry -- schema RPQ:Log from Remedy User 208593SQL 0016991463 List390620 lai Wed Aug 29 2007 13:46:05.4675 SELECT T201.C1,C8,C700037500,C700037000,C700034003,C73000 FROM T201 WHERE . That is, these set fields actions seem to be taking a couple of minutes to complete. Looking at the objects involved, they are doing @@:Application-Generate-GUID or @@:Application-Confirm-Group processes. The +EXECAL to -EXECAL OK is quick, but the thread then does nothing for 2 mins 39 secs before the next action from another user. Is arwkloga misleading me when it says the actlink_set is taking 2 mins 40s - is there an issue with the PROCESS actions? - or is the thread just idle? Does anyone know what might take an Application-Generate-GUID process over 2 minutes to complete? As far as I can see, list and fast threads usage are OK and the system is not waiting for a thread. Thanks for any advice David Sanders Remedy Solution Architect Enterprise Service Suite @ Work == ARS List Award Winner 2005 Best 3rd party Remedy Application See the ESS Concepts Guide tel +44 1494 468980 mobile +44 7710 377761 email [EMAIL PROTECTED] web http://www.westoverconsulting.co.uk ___ UNSUBSCRIBE or access
Re: Server Performance Issues??
- for completion of a call + for start of a call Axton Grams On 8/30/07, David Sanders [EMAIL PROTECTED] wrote: Hi Misi and Axton Thanks for the feedback. Yes, that was my suspicion (and hope) that arwklga was wrong. Arwklga was claiming that these process calls are taking 2 minutes to complete, but as far as I could see the +EXECAL to -EXECAL OK is completed quickly. I had 2 theories: 1) that the thread is actually idle and waiting for 2 minutes, or 2) that the @@:Application-Generate-GUID process is kicked off, the -EXECAL OK is returned immediately, but it is taking a further 2 minutes to return the result of the process. So the real question is, does the -EXECAL OK indicate that the process call has been started successfully, or completed successfully? Axton - I'll see if I can get some AL/Filter logs when this happens to compare with the API logs - that might answer the above question. Regards... Dave David Sanders Remedy Solution Architect Enterprise Service Suite @ Work == ARS List Award Winner 2005 Best 3rd party Remedy Application See the ESS Concepts Guide tel +44 1494 468980 mobile +44 7710 377761 email [EMAIL PROTECTED] web http://www.westoverconsulting.co.uk -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Misi Mladoniczky Sent: Thursday, August 30, 2007 7:04 PM To: arslist@ARSLIST.ORG Subject: Re: Server Performance Issues?? Hi David, The detailed log rows does not show that the API-call is taking much time. There is a wait-time in between the calls, but... If you look at the RPC ID, you see a jump from 0016990986 to 0016991463, so the server has performed 477 API-calls between these calls. They may have been thread executed by other threads. Could arwklga have missinformed you? Best Regards - Misi, RRR AB, http://www.rrr.se Products from RRR Scandinavia: * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. * RRR|Translator - Manage and automate your language translations. Find these products, and many free tools and utilities, at http://rrr.se. Hi List I wonder whether anyone has come across a situation like this and can throw any light on what might be causing these performance issues. ARS Server 6.03.00 patch 013 SunOS 5.10 Oracle 9.2.0.5.0 64bit on remote machine (shared with other apps) Running arwklga against combined API+SQL logs throws up several lines like this: 2:40.5023 205245 actlink_set Wed Aug 29 2007 13:43:24.9652 SELECT assignShort,assignLong FROM actlink_set WHERE actlinkId = 6881 AND actionIndex = 0 AND fieldId = 1077077 2:23.4299 191087 actlink_set Wed Aug 29 2007 13:32:39.6091 SELECT assignShort,assignLong FROM actlink_set WHERE actlinkId = 6881 AND actionIndex = 0 AND fieldId = 1077077 Looking at one of these in detail gives 205243API 0016990986 List390620 lp2d06 Wed Aug 29 2007 13:43:24.9636 +EXECAL ARExecuteProcessForActiveLink from Remedy User (protocol 11) at IP address 152.78.134.145 205244SQL 0016990986 List390620 lp2d06 Wed Aug 29 2007 13:43:24.9638 SELECT actlinkId from actlink where name = 'RPQ:SHR-Lock0' 205245SQL 0016990986 List390620 lp2d06 Wed Aug 29 2007 13:43:24.9652 SELECT assignShort,assignLong FROM actlink_set WHERE actlinkId = 6881 AND actionIndex = 0 AND fieldId = 1077077 205246API 0016990986 List390620 lp2d06 Wed Aug 29 2007 13:43:24.9668 -EXECAL OK 208592API 0016991463 List390620 lai Wed Aug 29 2007 13:46:05.4660 +GLE ARGetListEntry -- schema RPQ:Log from Remedy User 208593SQL 0016991463 List390620 lai Wed Aug 29 2007 13:46:05.4675 SELECT T201.C1,C8,C700037500,C700037000,C700034003,C73000 FROM T201 WHERE . That is, these set fields actions seem to be taking a couple of minutes to complete. Looking at the objects involved, they are doing @@:Application-Generate-GUID or @@:Application-Confirm-Group processes. The +EXECAL to -EXECAL OK is quick, but the thread then does nothing for 2 mins 39 secs before the next action from another user. Is arwkloga misleading me when it says the actlink_set is taking 2 mins 40s - is there an issue with the PROCESS actions? - or is the thread just idle? Does anyone know what might take an Application-Generate-GUID process over 2 minutes to complete? As far as I can see, list and fast threads usage are OK and the system is not waiting for a thread. Thanks for any advice David Sanders Remedy Solution Architect Enterprise Service Suite @ Work == ARS List Award Winner 2005 Best 3rd party Remedy Application See the ESS
ITSM 7: Change Mgmt Performance Issues
Hi All, We have ITSM installed on a Load balancer environment (Solaris + Oracle). When the logs into the system, through the user tool and clicks on Change Management Console, it takes a lot of time to load that, may be 30-45 seconds. Is there anyway to optimise this performance issue? It also takes probably same amount of time to create a new change ticket. Regards, Veeral Oza, Application Developer, Column Technologies, Cell: 224-587-0765 Desk: 847-632-3327 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Performance issues with turning off case sensitivity?
I read somewhere that if you turn off case sensitity in Oracle, you could have perform issues due to some kind of an index thing. Has anyone else experienced this? We are in the process of migrating to 10g and have considered turning this off, but if it's going to cost performance, we may need to rethink this. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Performance issues with turning off case sensitivity?
We had SEVERE performance issues trying to operate Oracle case insensitive. In fact, we postponed a database conversion from Sybase because of this. This e-mail and its attachments are confidential and solely for the intended addressee(s). Do not share or use them without Fannie Mae's approval. If received in error, contact the sender and delete them. -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of melreed95 Sent: Monday, April 09, 2007 10:40 AM To: arslist@ARSLIST.ORG Subject: Performance issues with turning off case sensitivity? I read somewhere that if you turn off case sensitity in Oracle, you could have perform issues due to some kind of an index thing. Has anyone else experienced this? We are in the process of migrating to 10g and have considered turning this off, but if it's going to cost performance, we may need to rethink this. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Performance Issues
Thank you Joe, Micheal and Patrick... will try out your suggestions and will let you know the results. Ankur From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Michael Worts Sent: 16 March 2007 06:38 PM To: arslist@ARSLIST.ORG Subject: Re: Performance Issues ** Ankur, You said that API shows a delay. Are you sure the API call is the one causing the problem or is it the SQL generated from the API call. If you combine your API and SQL log files, by writing them to the same file, you will be able to see which one is giving you the problem. e.g. it may take the API 0.001 seconds to call the SQL, it may take 60 seconds for the SQL to run and then another 0.001 seconds to return the results to the API. If the SQL is taking a long time to run, you may want to extract the SQL statement and run an EXPLAIN PLAN to see if you are using indexes correctly (or at all!). If the delay is in the API, you could be looking at a network/connectivity problem between the AR Server and the database (are you running your database remotely?) If you combine you API and SQL log files, you should be able to get a better understanding of what the API call is trying to do ... remember, one single API call (arCreateEntry) could generate multiple SQL statements and API's, so you need to make sure you understand what function you are testing in the application and what API and SQL is being executed. This will give you the big picture. Thanks, Mike. Michael Worts Remedy Specialist IGS, Business Consulting Services ITIL Service Manager Certified Tel: +44 (0)1962 822273 Mob: +44 (0)7801 755346 Internet: [EMAIL PROTECTED] Joe DeSouza [EMAIL PROTECTED] Sent by: Action Request System discussion list(ARSList) arslist@ARSLIST.ORG 16/03/2007 11:59 Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject Re: Performance Issues ** My guess is it might be one of these few things.. Memory leak on the current version/patch of the ARS you are on.. If this is the problem, in my experience with ARS 6.3 patch 19 is stable enough. Patch 20 reccommended though for the new DST update. However 20 is pretty new and though there are no known issues with memory leaks, there have been reported problems with the DST update itself. Another reason could be data fragmentation on the disk. This could be rectified with an backup of the database after stopping the ARS. Delete the database and recreate it using the same original parameters and restore the database. Another possible reason might be that there are certain searches happening on the current table whose record count is 700K. And the searches happening on this table is not using any defined indexes. You say it is a home grown application so it is very possible the developers who built it might have not defined the indexes required. You might need to see if your table is indexed properly. Look for all possible searches happening through qualifications used in 'set field if' actions of workflow, or qualifications used in table fields, qualifications used in search menus that might be defined and are used on this form, etc.. Hope this helps.. Joe D'Souza - Original Message From: Ankur Gulati (GR/EIL) [EMAIL PROTECTED] To: arslist@ARSLIST.ORG Sent: Friday, March 16, 2007 7:15:38 AM Subject: Performance Issues ** Hi Listers, We have a home grown application with few integrations with external interfaces. Since last few weeks the application performance has depleted by 60%. Earlier it was 20% CPU utilization and now the remedy application takes 70-75% at any given time. The data would not be more than 700,000. Some times the external integrations would fail, restart of AR Server sometimes do help, but again in 1 or 2 days it starts to suck all the system resources and takes 70% utilization. The system takes more than 4 mins to save a record and some times it takes lil more than that too, same is the case with the searches too. SQL and API Log shows lot of delay. mainly APIs are having delay but I don't have much knowledge to interpret API log. I don't understand what has affected the application suddenly. As far as hardware goes...I don't know the exact specs but I am sure tht it is under utilized. the System is ARS 6.0.1 on Solaris 9, database :Oracle 9i we also noticed lot of inactive remedy sessions in the oracle. Any idea what are they? Can they affect the performance. There aren't many indexes but still the system was running fine till few weeks back. I need help as from where should I start looking at the probable performance issues and what all things I can tweak to improve it. Incase you need more details, please do let me know. Regards Ankur Never miss an email again! Yahoo! Toolbar http://us.rd.yahoo.com/evt=49938/*http://tools.search.yahoo.com/toolbar /features/mail/ alerts you the instant new
Performance Issues
Hi Listers, We have a home grown application with few integrations with external interfaces. Since last few weeks the application performance has depleted by 60%. Earlier it was 20% CPU utilization and now the remedy application takes 70-75% at any given time. The data would not be more than 700,000. Some times the external integrations would fail, restart of AR Server sometimes do help, but again in 1 or 2 days it starts to suck all the system resources and takes 70% utilization. The system takes more than 4 mins to save a record and some times it takes lil more than that too, same is the case with the searches too. SQL and API Log shows lot of delay. mainly APIs are having delay but I don't have much knowledge to interpret API log. I don't understand what has affected the application suddenly. As far as hardware goes...I don't know the exact specs but I am sure tht it is under utilized. the System is ARS 6.0.1 on Solaris 9, database :Oracle 9i we also noticed lot of inactive remedy sessions in the oracle. Any idea what are they? Can they affect the performance. There aren't many indexes but still the system was running fine till few weeks back. I need help as from where should I start looking at the probable performance issues and what all things I can tweak to improve it. Incase you need more details, please do let me know. Regards Ankur ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Performance Issues
My guess is it might be one of these few things.. Memory leak on the current version/patch of the ARS you are on.. If this is the problem, in my experience with ARS 6.3 patch 19 is stable enough. Patch 20 reccommended though for the new DST update. However 20 is pretty new and though there are no known issues with memory leaks, there have been reported problems with the DST update itself. Another reason could be data fragmentation on the disk. This could be rectified with an backup of the database after stopping the ARS. Delete the database and recreate it using the same original parameters and restore the database. Another possible reason might be that there are certain searches happening on the current table whose record count is 700K. And the searches happening on this table is not using any defined indexes. You say it is a home grown application so it is very possible the developers who built it might have not defined the indexes required. You might need to see if your table is indexed properly. Look for all possible searches happening through qualifications used in 'set field if' actions of workflow, or qualifications used in table fields, qualifications used in search menus that might be defined and are used on this form, etc.. Hope this helps.. Joe D'Souza - Original Message From: Ankur Gulati (GR/EIL) [EMAIL PROTECTED] To: arslist@ARSLIST.ORG Sent: Friday, March 16, 2007 7:15:38 AM Subject: Performance Issues ** Hi Listers, We have a home grown application with few integrations with external interfaces. Since last few weeks the application performance has depleted by 60%. Earlier it was 20% CPU utilization and now the remedy application takes 70-75% at any given time. The data would not be more than 700,000. Some times the external integrations would fail, restart of AR Server sometimes do help, but again in 1 or 2 days it starts to suck all the system resources and takes 70% utilization. The system takes more than 4 mins to save a record and some times it takes lil more than that too, same is the case with the searches too. SQL and API Log shows lot of delay. mainly APIs are having delay but I don't have much knowledge to interpret API log. I don't understand what has affected the application suddenly. As far as hardware goes...I don't know the exact specs but I am sure tht it is under utilized. the System is ARS 6.0.1 on Solaris 9, database :Oracle 9i we also noticed lot of inactive remedy sessions in the oracle. Any idea what are they? Can they affect the performance. There aren't many indexes but still the system was running fine till few weeks back. I need help as from where should I start looking at the probable performance issues and what all things I can tweak to improve it. Incase you need more details, please do let me know. Regards Ankur Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Performance Issues
Ankur, You said that API shows a delay. Are you sure the API call is the one causing the problem or is it the SQL generated from the API call. If you combine your API and SQL log files, by writing them to the same file, you will be able to see which one is giving you the problem. e.g. it may take the API 0.001 seconds to call the SQL, it may take 60 seconds for the SQL to run and then another 0.001 seconds to return the results to the API. If the SQL is taking a long time to run, you may want to extract the SQL statement and run an EXPLAIN PLAN to see if you are using indexes correctly (or at all!). If the delay is in the API, you could be looking at a network/connectivity problem between the AR Server and the database (are you running your database remotely?) If you combine you API and SQL log files, you should be able to get a better understanding of what the API call is trying to do ... remember, one single API call (arCreateEntry) could generate multiple SQL statements and API's, so you need to make sure you understand what function you are testing in the application and what API and SQL is being executed. This will give you the big picture. Thanks, Mike. Michael Worts Remedy Specialist IGS, Business Consulting Services ITIL Service Manager Certified Tel: +44 (0)1962 822273 Mob: +44 (0)7801 755346 Internet: [EMAIL PROTECTED] Joe DeSouza [EMAIL PROTECTED] Sent by: Action Request System discussion list(ARSList) arslist@ARSLIST.ORG 16/03/2007 11:59 Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject Re: Performance Issues ** My guess is it might be one of these few things.. Memory leak on the current version/patch of the ARS you are on.. If this is the problem, in my experience with ARS 6.3 patch 19 is stable enough. Patch 20 reccommended though for the new DST update. However 20 is pretty new and though there are no known issues with memory leaks, there have been reported problems with the DST update itself. Another reason could be data fragmentation on the disk. This could be rectified with an backup of the database after stopping the ARS. Delete the database and recreate it using the same original parameters and restore the database. Another possible reason might be that there are certain searches happening on the current table whose record count is 700K. And the searches happening on this table is not using any defined indexes. You say it is a home grown application so it is very possible the developers who built it might have not defined the indexes required. You might need to see if your table is indexed properly. Look for all possible searches happening through qualifications used in 'set field if' actions of workflow, or qualifications used in table fields, qualifications used in search menus that might be defined and are used on this form, etc.. Hope this helps.. Joe D'Souza - Original Message From: Ankur Gulati (GR/EIL) [EMAIL PROTECTED] To: arslist@ARSLIST.ORG Sent: Friday, March 16, 2007 7:15:38 AM Subject: Performance Issues ** Hi Listers, We have a home grown application with few integrations with external interfaces. Since last few weeks the application performance has depleted by 60%. Earlier it was 20% CPU utilization and now the remedy application takes 70-75% at any given time. The data would not be more than 700,000. Some times the external integrations would fail, restart of AR Server sometimes do help, but again in 1 or 2 days it starts to suck all the system resources and takes 70% utilization. The system takes more than 4 mins to save a record and some times it takes lil more than that too, same is the case with the searches too. SQL and API Log shows lot of delay. mainly APIs are having delay but I don't have much knowledge to interpret API log. I don't understand what has affected the application suddenly. As far as hardware goes...I don't know the exact specs but I am sure tht it is under utilized. the System is ARS 6.0.1 on Solaris 9, database :Oracle 9i we also noticed lot of inactive remedy sessions in the oracle. Any idea what are they? Can they affect the performance. There aren't many indexes but still the system was running fine till few weeks back. I need help as from where should I start looking at the probable performance issues and what all things I can tweak to improve it. Incase you need more details, please do let me know. Regards Ankur Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. Check it out. __20060125___This posting was submitted with HTML in it___ Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Re: Performance Issues
I have heard support mention. by different folks. Do not stay on 6.01 for any reason.. it is a headache.. On 3/16/07, Ankur Gulati (GR/EIL) [EMAIL PROTECTED] wrote: ** Hi Listers, We have a home grown application with few integrations with external interfaces. Since last few weeks the application performance has depleted by 60%. Earlier it was 20% CPU utilization and now the remedy application takes 70-75% at any given time. The data would not be more than 700,000. Some times the external integrations would fail, restart of AR Server sometimes do help, but again in 1 or 2 days it starts to suck all the system resources and takes70% utilization. The system takes more than 4 mins to save a record and some times it takes lil more than that too, same is the case with the searches too. SQL and API Log shows lot of delay. mainly APIs are having delay but I don't have much knowledge to interpret API log. I don't understand what has affected the application suddenly. As far as hardware goes...I don't know the exact specs but I am sure tht it is under utilized. the System is ARS 6.0.1 on Solaris 9, database :Oracle 9i we also noticed lot of inactive remedy sessions in the oracle. Any idea what are they? Can they affect the performance. There aren't many indexes but still the system was running fine till few weeks back. I need help as from where should I start looking at the probable performance issues and what all things I can tweak to improve it. Incase you need more details, please do let me know. Regards Ankur __20060125___This posting was submitted with HTML in it___ -- Patrick Zandi ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Performance Issues caused by User Queries - Remedy 6.3/Oracle 10.0.2
Thanks you Axton, Patrick, Lars!!! We really appreciate the input so far and I've taken these suggestions to the powers that be for discussion!! I look forward to any other ideas that may be out there! Thank you all again!! Shawn Stonequist EMNS, Inc. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Performance Issues caused by User Queries - Remedy 6.3/Oracle 10.0.2
I worked with a DB once, don't remember which one (may have been Oracle) that allowed query monitoring to be turned on at the DB level and you could turn it on for a week or so and it would report to you the heaviest queries taking place during its monitoring time. I seem to remember it being a bit of a performance hit...but you can't do that type of thing without impacting performance -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Shawn Stonequist Sent: Wednesday, January 03, 2007 7:57 AM To: arslist@ARSLIST.ORG Subject: Re: Performance Issues caused by User Queries - Remedy 6.3/Oracle 10.0.2 Thanks you Axton, Patrick, Lars!!! We really appreciate the input so far and I've taken these suggestions to the powers that be for discussion!! I look forward to any other ideas that may be out there! Thank you all again!! Shawn Stonequist EMNS, Inc. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Performance Issues caused by User Queries - Remedy 6.3/Oracle 10.0.2
We have an active link on our biggest forms that checks the Advanced
Search Criteria field (ID 1005) along with some combinations of our
other fields. Something like this:
'Search Criteria' = $NULL$
AND
(
('Description' != $NULL$ OR 'Work Log' != $NULL$ OR 'Solution' !=
$NULL$)
AND
('Assignee' = $NULL$ AND 'User ID' = $NULL$ AND 'Create Date' =
$NULL$)
)
We have about 20 fields indexed on one big form and we actually check to
make sure that one of them has a value. If all of them are null, and
they specify something in a large text field, and the advanced search is
null, then we throw an error. I realize the advanced search still gives
them free reign to do whatever they want, but most of the people who
don't know how to form a good search also don't know how to use the
advanced search bar. It's the ones who know enough to try using the
advanced search but do so very poorly that still hurt us from time to
time. But this workflow cuts out a lot of bad QBE searches.
Chad Hall
(501) 342-2650
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Shawn Stonequist
Sent: Wednesday, January 03, 2007 8:57 AM
To: arslist@ARSLIST.ORG
Subject: Re: Performance Issues caused by User Queries - Remedy
6.3/Oracle 10.0.2
Thanks you Axton, Patrick, Lars!!!
We really appreciate the input so far and I've taken these suggestions
to
the powers that be for discussion!!
I look forward to any other ideas that may be out there!
Thank you all again!!
Shawn Stonequist
EMNS, Inc.
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where
the Answers Are
*
The information contained in this communication is confidential, is
intended only for the use of the recipient named above, and may be
legally privileged.
If the reader of this message is not the intended recipient, you are
hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited.
If you have received this communication in error, please resend this
communication to the sender and delete the original message or any copy
of it from your computer system.
Thank you.
*
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the
Answers Are
Re: Performance Issues caused by User Queries - Remedy 6.3/Oracle 10.0.2
Oracle keeps stats on all active sessions. Since db connections from Remedy
are persistent, you can see what the heaviest sql is from the db side.
These are things your dba should know how to use/interpret. These are some
of the stats I find useful at times:
-- Disk Intensive SQL - origmod
set wrap on
set linesize 250
set pagesize 1000
column username format a20
column sql_text format a64
select a.USERNAME,
DISK_READS,
EXECUTIONS,
round(DISK_READS / decode(EXECUTIONS, 0, 1, EXECUTIONS)) Reads/Execs,
v$sqltext.SQL_TEXT
from dba_users a,
v$session,
v$sqlarea,
v$sqltext
where PARSING_USER_ID=USER_ID and
v$sqlarea.address = v$sqltext.address and
v$sqlarea.hash_value = v$sqltext.hash_value
and v$sqlarea.ADDRESS=SQL_ADDRESS(+)
and DISK_READS 1
order by DISK_READS desc, EXECUTIONS desc, piece asc;
-- Buffer Scan Intensive SQL
set wrap on
set linesize 250
set pagesize 1000
column sql_text format a80
select executions,
round(disk_reads / decode(executions, 0, 1, executions) / 400,2) as
Response,
sql_text
from v$sqlarea
where buffer_gets / decode(executions,0,1, executions) / 400 10
order by executions desc;
-- Shared Pool SQL With Most Loads
set wrap on
set linesize 250
set pagesize 1000
column sql_text format a80
select executions,
sql_text
from v$sqlarea
where loads 50
order by executions desc;
-- Wait Statistics
set wrap on
set linesize 250
set pagesize 1000
select class,
count,
time
from v$waitstat;
-- Disk Sorts
set wrap on
set linesize 250
set pagesize 1000
select name,
value
from v$sysstat
where name like 'sort%';
-- Tables With Questionable Indexes
set wrap on
set linesize 250
set pagesize 1000
column table_owner format a20
column table_name format a40
column column_name format a20
select table_owner,
table_name,
column_name
from all_ind_columns
where column_position=1
group by table_owner,
table_name,
column_name
having count(*) 1;
-- Buffer Cache hit Rate
select 100*(cur.value+con.value-phys.value)/(cur.value+con.value)
from v$sysstat cur,
v$sysstat con,
v$sysstat phys,
v$statname ncu,
v$statname nco,
v$statname nph
where cur.statistic# = ncu.statistic#
and ncu.name = 'db block gets'
and con.statistic# = nco.statistic#
and nco.name = 'consistent gets'
and phys.statistic# = nph.statistic#
and nph.name = 'physical reads';
Axton Grams
On 1/3/07, Hall Chad - chahal [EMAIL PROTECTED] wrote:
We have an active link on our biggest forms that checks the Advanced
Search Criteria field (ID 1005) along with some combinations of our
other fields. Something like this:
'Search Criteria' = $NULL$
AND
(
('Description' != $NULL$ OR 'Work Log' != $NULL$ OR 'Solution' !=
$NULL$)
AND
('Assignee' = $NULL$ AND 'User ID' = $NULL$ AND 'Create Date' =
$NULL$)
)
We have about 20 fields indexed on one big form and we actually check to
make sure that one of them has a value. If all of them are null, and
they specify something in a large text field, and the advanced search is
null, then we throw an error. I realize the advanced search still gives
them free reign to do whatever they want, but most of the people who
don't know how to form a good search also don't know how to use the
advanced search bar. It's the ones who know enough to try using the
advanced search but do so very poorly that still hurt us from time to
time. But this workflow cuts out a lot of bad QBE searches.
Chad Hall
(501) 342-2650
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Shawn Stonequist
Sent: Wednesday, January 03, 2007 8:57 AM
To: arslist@ARSLIST.ORG
Subject: Re: Performance Issues caused by User Queries - Remedy
6.3/Oracle 10.0.2
Thanks you Axton, Patrick, Lars!!!
We really appreciate the input so far and I've taken these suggestions
to
the powers that be for discussion!!
I look forward to any other ideas that may be out there!
Thank you all again!!
Shawn Stonequist
EMNS, Inc.
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where
the Answers Are
*
The information contained in this communication is confidential, is
intended only for the use of the recipient named above, and may be
legally privileged.
If the reader of this message is not the intended recipient, you are
hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited.
If you have received this communication in error, please resend this
communication to the sender and delete the original message or any copy
of it from your computer system.
Thank you.
*
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where
the Answers
Performance Issues caused by User Queries - Remedy 6.3/Oracle 10.0.2
Greetings List!! We have an issue in which some users (we know not who) are running queries which are affecting the performance of our Remedy system, causing significant delays, issues, and even complete system lock-ups for all our Users. We have three goals that we would like to accomplish: 1) Identify the user(s) and what they are doing 2) Prevent future performance degradation of this nature 3) Stop offending queries in progress should prevention be not possible to bypassed in some manner, using a method other than rebooting our database (as this brings all our users down, which is what we are trying to remedy) We are interested in any possible solutions or paths to accomplish one or more of these goals. We spoke with our Remedy Partner that provides our support, but unfortunately, their best resolution was using User/API/SQL Logging Remedy-side. Unfortunately, for this to be successful, we would need to know before the offending query is run, or have it always running (something our SA is against due to system resource concerns) Our SA provided me the following information concerning our configuration, which may be helpful (I apologize that I don't know what it all means): Distributed Server Remedy 6.3.0 patch 018 Oracle 10.0.2 Monolithic We look forward to and appreciate any assistance available. Thanks Shawn Stonequist EMNS, Inc. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Performance Issues caused by User Queries - Remedy 6.3/Oracle 10.0.2
You can do a couple of things: - look at the remedy logs to figure out what these people are doing (sql); then take steps to stop it. - Limit the number of records the server can return (admin tool/ar.conf) Unfortunately, from the db side, there is not much you can do to stop what has started, short of stopping your remedy server. Each queue (fast/list/custom) configured on your arserver is configured with a set min/max number of threads. At startup, remedy establishes X number of connections to your db (sum of the min threads for all queues). These are persistent sessions and should not be mucked with from the db side. Axton Grams On 1/2/07, Shawn Stonequist [EMAIL PROTECTED] wrote: Greetings List!! We have an issue in which some users (we know not who) are running queries which are affecting the performance of our Remedy system, causing significant delays, issues, and even complete system lock-ups for all our Users. We have three goals that we would like to accomplish: 1) Identify the user(s) and what they are doing 2) Prevent future performance degradation of this nature 3) Stop offending queries in progress should prevention be not possible to bypassed in some manner, using a method other than rebooting our database (as this brings all our users down, which is what we are trying to remedy) We are interested in any possible solutions or paths to accomplish one or more of these goals. We spoke with our Remedy Partner that provides our support, but unfortunately, their best resolution was using User/API/SQL Logging Remedy-side. Unfortunately, for this to be successful, we would need to know before the offending query is run, or have it always running (something our SA is against due to system resource concerns) Our SA provided me the following information concerning our configuration, which may be helpful (I apologize that I don't know what it all means): Distributed Server Remedy 6.3.0 patch 018 Oracle 10.0.2 Monolithic We look forward to and appreciate any assistance available. Thanks Shawn Stonequist EMNS, Inc. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Performance Issues caused by User Queries - Remedy 6.3/Oracle 10.0.2
We ran into these issues awhile back given some of our tables have millions of rows, so we created a simple search capture form and search protection dialog form. These could help if uses are performing searching in forms or reports, if they are searching via ODBC then you might consider limiting use to a permission group or specific datetime range in the AR.CFG The search capture is a form with some AL's that grab fields from a form being searched or the advanced search (add the search bar field to the form), if it is a crystal report you can decode the search with Set fields ($PROCESS$ Application-Map-Ids-To-Names $ReportFormName$ $Search$) The search protection recognizes specific search fields and/or datetime field ranges. Example of one scenario: if STRSTR(SUBSTR($Search Bar$,STRSTR($Search Bar$, 'Create Date') + 13), 'Create Date') 40 then a daterange is used (although there are other permutations to check) - find the time between the range or some other action If the query doesn't meet criteria we direct the user to a separate dialog form with selectable search criteria and limited date ranges. Hope this helps Pat Dill Enterprise Tools Team Roosevelt Commons, Floor 5 206-545-3217 Office 206-931-3006 Cell -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Shawn Stonequist Sent: Tuesday, January 02, 2007 2:34 PM To: arslist@ARSLIST.ORG Subject: Performance Issues caused by User Queries - Remedy 6.3/Oracle 10.0.2 Greetings List!! We have an issue in which some users (we know not who) are running queries which are affecting the performance of our Remedy system, causing significant delays, issues, and even complete system lock-ups for all our Users. We have three goals that we would like to accomplish: 1) Identify the user(s) and what they are doing 2) Prevent future performance degradation of this nature 3) Stop offending queries in progress should prevention be not possible to bypassed in some manner, using a method other than rebooting our database (as this brings all our users down, which is what we are trying to remedy) We are interested in any possible solutions or paths to accomplish one or more of these goals. We spoke with our Remedy Partner that provides our support, but unfortunately, their best resolution was using User/API/SQL Logging Remedy-side. Unfortunately, for this to be successful, we would need to know before the offending query is run, or have it always running (something our SA is against due to system resource concerns) Our SA provided me the following information concerning our configuration, which may be helpful (I apologize that I don't know what it all means): Distributed Server Remedy 6.3.0 patch 018 Oracle 10.0.2 Monolithic We look forward to and appreciate any assistance available. Thanks Shawn Stonequist EMNS, Inc. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Performance Issues caused by User Queries - Remedy 6.3/Oracle 10.0.2
Shawn, why not take a look at rrrLog from misi, at www.rrr.se rrrLog: Find the performance bottle necks in your system. What form use most system resources? Find slow API/SQL-calls, and browse the filters that have been triggered. You will be able to sort by processing time and identify which sql command a used made, and who this user was. In the bottom are the logfiles, api, sql, filter, esc, but presented is a readable format. We tested the product, and found slow 'like searches', both in ars code and triggered by users. L ars -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Shawn Stonequist Sent: Tuesday, January 02, 2007 11:34 PM To: arslist@ARSLIST.ORG Subject: Performance Issues caused by User Queries - Remedy 6.3/Oracle 10.0.2 Greetings List!! We have an issue in which some users (we know not who) are running queries which are affecting the performance of our Remedy system, causing significant delays, issues, and even complete system lock-ups for all our Users. We have three goals that we would like to accomplish: 1) Identify the user(s) and what they are doing 2) Prevent future performance degradation of this nature 3) Stop offending queries in progress should prevention be not possible to bypassed in some manner, using a method other than rebooting our database (as this brings all our users down, which is what we are trying to remedy) We are interested in any possible solutions or paths to accomplish one or more of these goals. We spoke with our Remedy Partner that provides our support, but unfortunately, their best resolution was using User/API/SQL Logging Remedy-side. Unfortunately, for this to be successful, we would need to know before the offending query is run, or have it always running (something our SA is against due to system resource concerns) Our SA provided me the following information concerning our configuration, which may be helpful (I apologize that I don't know what it all means): Distributed Server Remedy 6.3.0 patch 018 Oracle 10.0.2 Monolithic We look forward to and appreciate any assistance available. Thanks Shawn Stonequist EMNS, Inc. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Administrator - Performance Issues when saving form
You didn't specify what database you are connecting to, so I am making a guess... It may be that your db server is caching the data in it's memory so the first save takes some time to get the data from the disk. Secondary updates already have the current data for the filter in memory so it is quicker. After using the User Tool the filter is no longer in the DB server's memory so an update afterwards has to re-get the data from the disk Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Runar Helle Sent: Wednesday, November 22, 2006 9:18 AM To: arslist@ARSLIST.ORG Subject: Administrator - Performance Issues when saving form Hi, all I've got a question about performance in AR Administrator. The performance varies for each time I save. Sometimes it takes up to 25 seconds to save a filter, other times only half a second. We are talking about the same filter, and the change could be as small as changing a character to its name (add or remove. Makes no difference) The interesting thing is that it seems to be very slow the first time I save the filter. If I make an other change, save is quick. And if I make yet an other change it is also very quick. If I then turn to the user tool and do *any* operation that does an API/SQL call to the server, it all breaks down again. The first time I save anything in the admin tool after touching the user tool, things are sloow. After the first save operation in the admin tool, subsequent saves to that element is quick again. Good thing: It's consistent. I've have checked the APISQL log and the difference in API-time between the quick and the slow saves is only milliseconds. CPU usage on server is only 50 percent at its peak during save operation. For the quick saves, I can hardly register any CPU load on the server. There is no noticeable load on the client either. The server is a dual 3.4 GHz with 3,5 GB RAM. Administrator 6,3 patch 12 ARS 6.3, patch 12 Any ideas? Best regards, Runar ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Administrator - Performance Issues when saving form
Sounds like the server is re-caching on changes. Go into the admin tool, click on File-Server Info, on the config tab ensure that Development Cache Mode is clicked during your changes. It should improve performance. When you have completed your development, turn this option off. Terry On Wed, 22 Nov 2006 10:29:28 -0600 Grooms, Frederick W [EMAIL PROTECTED] wrote: You didn't specify what database you are connecting to, so I am making a guess... It may be that your db server is caching the data in it's memory so the first save takes some time to get the data from the disk. Secondary updates already have the current data for the filter in memory so it is quicker. After using the User Tool the filter is no longer in the DB server's memory so an update afterwards has to re-get the data from the disk Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Runar Helle Sent: Wednesday, November 22, 2006 9:18 AM To: arslist@ARSLIST.ORG Subject: Administrator - Performance Issues when saving form Hi, all I've got a question about performance in AR Administrator. The performance varies for each time I save. Sometimes it takes up to 25 seconds to save a filter, other times only half a second. We are talking about the same filter, and the change could be as small as changing a character to its name (add or remove. Makes no difference) The interesting thing is that it seems to be very slow the first time I save the filter. If I make an other change, save is quick. And if I make yet an other change it is also very quick. If I then turn to the user tool and do *any* operation that does an API/SQL call to the server, it all breaks down again. The first time I save anything in the admin tool after touching the user tool, things are sloow. After the first save operation in the admin tool, subsequent saves to that element is quick again. Good thing: It's consistent. I've have checked the APISQL log and the difference in API-time between the quick and the slow saves is only milliseconds. CPU usage on server is only 50 percent at its peak during save operation. For the quick saves, I can hardly register any CPU load on the server. There is no noticeable load on the client either. The server is a dual 3.4 GHz with 3,5 GB RAM. Administrator 6,3 patch 12 ARS 6.3, patch 12 Any ideas? Best regards, Runar ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Administrator - Performance Issues when saving form
Hi Runar Annoying isn't it? Try this for a test. Open up a filter, then go to View...By Form and select another form that your filter isn't attached to. Then try modifying and saving the open filter - on my system it is nearly instantaneous. Then change the objects you are viewing - click on Forms, then click back on Filters, and try it again. First time takes a long time, then instant again after that. It looks to me as though it is caused by the admin tool refreshing the list of objects displayed in the admin tool. If it knows the object isn't in the list it is currently displaying, there is no delay... otherwise it can take some time. I don't know whether this throws any light on the issue or not... David Sanders Remedy Solution Architect Enterprise Service Suite @ Work == ARS List Award Winner 2005 Best 3rd party Remedy Application tel +44 1494 468980 mobile +44 7710 377761 email [EMAIL PROTECTED] web http://www.westoverconsulting.co.uk -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Runar Helle Sent: Wednesday, November 22, 2006 3:18 PM To: arslist@ARSLIST.ORG Subject: Administrator - Performance Issues when saving form Hi, all I've got a question about performance in AR Administrator. The performance varies for each time I save. Sometimes it takes up to 25 seconds to save a filter, other times only half a second. We are talking about the same filter, and the change could be as small as changing a character to its name (add or remove. Makes no difference) The interesting thing is that it seems to be very slow the first time I save the filter. If I make an other change, save is quick. And if I make yet an other change it is also very quick. If I then turn to the user tool and do *any* operation that does an API/SQL call to the server, it all breaks down again. The first time I save anything in the admin tool after touching the user tool, things are sloow. After the first save operation in the admin tool, subsequent saves to that element is quick again. Good thing: It's consistent. I've have checked the APISQL log and the difference in API-time between the quick and the slow saves is only milliseconds. CPU usage on server is only 50 percent at its peak during save operation. For the quick saves, I can hardly register any CPU load on the server. There is no noticeable load on the client either. The server is a dual 3.4 GHz with 3,5 GB RAM. Administrator 6,3 patch 12 ARS 6.3, patch 12 Any ideas? Best regards, Runar ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Remedy on Citrix | Performance Issues
** Is there a table field refreshing or an image on the new tab? Those are usually the most likely suspects. Rick From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Jason McDonaldSent: Monday, August 21, 2006 7:49 AMTo: arslist@ARSLIST.ORGSubject: Re: Remedy on Citrix | Performance Issues ** Well, when a user is changing tabls in helpdesk 4.00.03, the aruser window freezes over and it takes almost 5 mins for the tab to refresh. On 8/17/06, Frank Caruso [EMAIL PROTECTED] wrote: ** What types of performance problems? On 8/17/06, Jason McDonald [EMAIL PROTECTED] wrote: ** Dear Listers, ARS 5.1.2 Helpdesk 4.00.03 HP UNIX11.11i Oracle 9i Some of our remedy helpdesk users are facing performance problems when logging on from Citrix environment. Users logging on from other environments have so far not reported any problems. Would like your advice on performance debugging tips for Remedy on Citrix. Thanks, Jason __20060125___This posting was submitted with HTML in it___ -- Frank CarusoSpecific Integration, Inc.Senior Remedy Engineerwww.specificintegration.com703-376-1249 __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___
Re: Remedy on Citrix | Performance Issues
** The one issue we had was that all of the arf and arx files were being stored in the same folder on the CITRIX server. After a day or so it would take the user tool a long time to bring up a form because it had to hunt through several thousand cache files. Deleting the cache files helped in the short term. Our CITRIX admin then configured the servers so that users did not share the same HOME folder.On 8/21/06, Jason McDonald [EMAIL PROTECTED] wrote:** Well, when a user is changing tabls in helpdesk 4.00.03, the aruser window freezes over and it takes almost 5 mins for the tab to refresh. On 8/17/06, Frank Caruso [EMAIL PROTECTED] wrote: ** What types of performance problems? On 8/17/06, Jason McDonald [EMAIL PROTECTED] wrote: ** Dear Listers, ARS 5.1.2 Helpdesk 4.00.03 HP UNIX11.11i Oracle 9i Some of our remedy helpdesk users are facing performance problems when logging on from Citrix environment. Users logging on from other environments have so far not reported any problems. Would like your advice on performance debugging tips for Remedy on Citrix. Thanks, Jason __20060125___This posting was submitted with HTML in it___ -- Frank CarusoSpecific Integration, Inc.Senior Remedy Engineer www.specificintegration.com703-376-1249 __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ -- Frank CarusoSpecific Integration, Inc.Senior Remedy Engineerwww.specificintegration.com703-376-1249 __20060125___This posting was submitted with HTML in it___
Re: Remedy on Citrix | Performance Issues
** The clients working on windows environments are not affected. Only the users working from CITRIX env. In the remedy support page there are 3 tables refreshing on display (Incidents table, requests table and problem-cases table). No images as such are placed. Why is this affecting ONLY the citrix users and not the others? Thanks On 8/21/06, Rick Cook [EMAIL PROTECTED] wrote: ** Is there a table field refreshing or an image on the new tab? Those are usually the most likely suspects. Rick From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG ] On Behalf Of Jason McDonaldSent: Monday, August 21, 2006 7:49 AMTo: arslist@ARSLIST.ORG Subject: Re: Remedy on Citrix | Performance Issues ** Well, when a user is changing tabls in helpdesk 4.00.03, the aruser window freezes over and it takes almost 5 mins for the tab to refresh. On 8/17/06, Frank Caruso [EMAIL PROTECTED] wrote: ** What types of performance problems? On 8/17/06, Jason McDonald [EMAIL PROTECTED] wrote: ** Dear Listers, ARS 5.1.2 Helpdesk 4.00.03 HP UNIX11.11i Oracle 9i Some of our remedy helpdesk users are facing performance problems when logging on from Citrix environment. Users logging on from other environments have so far not reported any problems. Would like your advice on performance debugging tips for Remedy on Citrix. Thanks, Jason __20060125___This posting was submitted with HTML in it___ -- Frank CarusoSpecific Integration, Inc.Senior Remedy Engineer www.specificintegration.com703-376-1249 __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___
Remedy on Citrix | Performance Issues
** Dear Listers, ARS 5.1.2 Helpdesk 4.00.03 HP UNIX11.11i Oracle 9i Some of our remedy helpdesk users are facing performance problems when logging on from Citrix environment. Users logging on from other environments have so far not reported any problems. Would like your advice on performance debugging tips for Remedy on Citrix. Thanks, Jason __20060125___This posting was submitted with HTML in it___
Re: Remedy on Citrix | Performance Issues
** What types of performance problems?On 8/17/06, Jason McDonald [EMAIL PROTECTED] wrote: ** Dear Listers, ARS 5.1.2 Helpdesk 4.00.03 HP UNIX11.11i Oracle 9i Some of our remedy helpdesk users are facing performance problems when logging on from Citrix environment. Users logging on from other environments have so far not reported any problems. Would like your advice on performance debugging tips for Remedy on Citrix. Thanks, Jason __20060125___This posting was submitted with HTML in it___ -- Frank CarusoSpecific Integration, Inc.Senior Remedy Engineerwww.specificintegration.com703-376-1249 __20060125___This posting was submitted with HTML in it___
Remedy ITSM 6.0 | Performance Issues
Title: Remedy ITSM 6.0 | Performance Issues ** Hello all, Our Helpdesk system esp support console has gone very slow on WAN. We suspect its the number of records which is there and plan to enable archiving. Please share, any other possible reasons for which you have seen it going slow...? and how to analyse it? Thanks nazish Nazish Bano | Sapient [EMAIL PROTECTED] | +91.124.282.6235 (D) | +91.9811552073 (M) __20060125___This posting was submitted with HTML in it___
Windows 2000 and CMDB Performance Issues
Listers, I am creating a CMDB 1.1 Patch 3 with ITSM system. ARS 6.3 ITSM 6.0. We are seeing many serious performance issues and we have not even started any heavy testing. The CMDB times out when trying to do anything with it and we can not hardly even search for a Ticket when an Import is running. A friend mentioned it is because I am running Windows 2000 Server for the application server. Has anyone heard this? If so is there any documentation or specific things you can share about Windows 2000 and CMDB etc... Also has anyone else experienced performance issues like this with CMDB? ARS 6.3, ITSM 6.o, CMDB Patch 3, Application Server=Windows 2000, Database Oracle 10G on a very beefy AIX box. Regards, David Charters 317-331-8985 ___ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
Re: Windows 2000 and CMDB Performance Issues
Title: RE: Windows 2000 and CMDB Performance Issues ** -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of dcharters Also has anyone else experienced performance issues like this with CMDB? ARS 6.3, ITSM 6.o, CMDB Patch 3, Application Server=Windows 2000, Database Oracle 10G on a very beefy AIX box. What is the connection between these two boxes? I've seen issues with clogged connections between them. Also, what is the version of the Oracle 9iR2 clients? James McKenzie __20060125___This posting was submitted with HTML in it___
Re: Windows 2000 and CMDB Performance Issues
Title: RE: Windows 2000 and CMDB Performance Issues ** While I am running Windows 2003 on both the application and database with MS SQL 2000 SP4 I did see some issues until I upgraded my network connections to 1GB. After that things were all good. Thanks, Andrew Baxter Manager, Information Technology w. (781) 902-6026 f. (781) 902-6002 From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of McKenzie, James J C-E LCMC HQISEC/L3 Sent: Tuesday, August 08, 2006 10:29 AM To: arslist@ARSLIST.ORG Subject: Re: Windows 2000 and CMDB Performance Issues -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of dcharters Also has anyone else experienced performance issues like this with CMDB? ARS 6.3, ITSM 6.o, CMDB Patch 3, Application Server=Windows 2000, Database Oracle 10G on a very beefy AIX box. What is the connection between these two boxes? I've seen issues with clogged connections between them. Also, what is the version of the Oracle 9iR2 clients? James McKenzie __20060125___This posting was submitted with HTML in it___ This e-mail is sent by Hudson Highland Group, Inc., or one of its subsidiaries, and may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. __20060125___This posting was submitted with HTML in it___
Re: Windows 2000 and CMDB Performance Issues
Title: RE: Windows 2000 and CMDB Performance Issues ** Dave: What version of the 9iR2 clients (5,6,7...) are you using? If you are confused at this point, there were fixes to the clients that may fix the problem you are experiencing right now. James McKenzie -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of dcharters Sent: Tuesday, August 08, 2006 9:06 AM To: arslist@ARSLIST.ORG Subject: Re: Windows 2000 and CMDB Performance Issues 9iR2 and the connection is a Gigabyte with 1 hop On Tue, 8 Aug 2006 07:28:40 -0700, McKenzie, James J C-E LCMC HQISEC/L3 wrote -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of dcharters Also has anyone else experienced performance issues like this with CMDB? ARS 6.3, ITSM 6.o, CMDB Patch 3, Application Server=Windows 2000, Database Oracle 10G on a very beefy AIX box. What is the connection between these two boxes? I've seen issues with clogged connections between them. Also, what is the version of the Oracle 9iR2 clients? James McKenzie __ _ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org -- Open WebMail Project (http://openwebmail.org) ___ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org __20060125___This posting was submitted with HTML in it___
Server performance issues?
** All, I'm working nicely through the changes required to our test installation of ARS 6.3/Helpdesk 6 (I can't really call it ITSM6 yet), and the server performance isn't looking too good at the moment. When I talk performance, I'm talking about general working in the Admin tool - saving forms/active links and filters, exporting data. It was slow on our old server (Win2k, ARS 5.1.1, Helpdesk 4, running dual 500mHz processors with 1gig of ram), but its definitely slower on the new server (Win2k3, ARS 6.3, Helpdesk 6, running dual 3gig processors with 4gig of ram). Right now I'm trying to do a definitions back of the helpdesk form, and I've been sitting waiting for what feels like an eternity - go the export defs window open, selected HPD:HelpDesk, and I've done a Add All Related, and its just hanging. Any suggestions where to look on our servers? Have to admit that the Admin tool is unpatched though - does anyone expect that I'd have performance improvements in moving to a later patch? Regards, Dave ps. How to get an ARS 5.1.1 to 6.3/Helpdesk 4 to 6 migration done in less than 2 weeks - I'll tell you by the end of the week, which is my supposed deadline :) __20060125___This posting was submitted with HTML in it___
Re: Server performance issues?
** Dave, One thing that's a little different about how ARS 6.3 works is that there's more initial caching at the client level to speed up performance in subsequent transactions. This can be controlled to some extent by changing your caching thresholds, and by turning on the Developer Cache Mode for production systems. Mid-Tier is especially susceptible to the caching issue - initial downloads of a large form may take close to a minute. But once that's done, if recaching isn't required, subsequent updates and normal transactions are very quick. Rick From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Dave BarberSent: Monday, May 08, 2006 8:34 AMTo: arslist@ARSLIST.ORGSubject: Server performance issues? ** All, I'm working nicely through the changes required to our test installation of ARS 6.3/Helpdesk 6 (I can't really call it ITSM6 yet), and the server performance isn't looking too good at the moment. When I talk performance, I'm talking about general working in the Admin tool - saving forms/active links and filters, exporting data. It was slow on our old server (Win2k, ARS 5.1.1, Helpdesk 4, running dual 500mHz processors with 1gig of ram), but its definitely slower on the new server (Win2k3, ARS 6.3, Helpdesk 6, running dual 3gig processors with 4gig of ram). Right now I'm trying to do a definitions back of the helpdesk form, and I've been sitting waiting for what feels like an eternity - go the export defs window open, selected HPD:HelpDesk, and I've done a "Add All Related", and its just hanging. Any suggestions where to look on our servers? Have to admit that the Admin tool is unpatched though - does anyone expect that I'd have performance improvements in moving to a later patch? Regards, Dave ps. How to get an ARS 5.1.1 to 6.3/Helpdesk 4 to 6 migration done in less than 2 weeks - I'll tell you by the end of the week, which is my supposed deadline :)__20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___
Re: Server performance issues?
Title: RE: Server performance issues? ** Rick: I highly recommend turning on and off the Developer Cache mode ONLY when you are working on forms on a production machine (why aren't you working on a dev machine anyhow). If you can get it, take the old production machine and use it as your dev machine. This will allow you to run on a smaller scale to see what effects you will have if you are running a larger production machine with hundreds of users. James McKenzie Remedy Engineer Enterprise Systems Device Management Enterprise Systems Engineering Directorate C-E LCMC ISEC Fort Huachuca, Arizona 85613 Phone: (520) 538-3171 From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook Sent: Monday, May 08, 2006 8:39 AM To: arslist@ARSLIST.ORG Subject: Re: Server performance issues? ** Dave, One thing that's a little different about how ARS 6.3 works is that there's more initial caching at the client level to speed up performance in subsequent transactions. This can be controlled to some extent by changing your caching thresholds, and by turning on the Developer Cache Mode for production systems. Mid-Tier is especially susceptible to the caching issue - initial downloads of a large form may take close to a minute. But once that's done, if recaching isn't required, subsequent updates and normal transactions are very quick. Rick From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Dave Barber Sent: Monday, May 08, 2006 8:34 AM To: arslist@ARSLIST.ORG Subject: Server performance issues? ** All, I'm working nicely through the changes required to our test installation of ARS 6.3/Helpdesk 6 (I can't really call it ITSM6 yet), and the server performance isn't looking too good at the moment. When I talk performance, I'm talking about general working in the Admin tool - saving forms/active links and filters, exporting data. It was slow on our old server (Win2k, ARS 5.1.1, Helpdesk 4, running dual 500mHz processors with 1gig of ram), but its definitely slower on the new server (Win2k3, ARS 6.3, Helpdesk 6, running dual 3gig processors with 4gig of ram). Right now I'm trying to do a definitions back of the helpdesk form, and I've been sitting waiting for what feels like an eternity - go the export defs window open, selected HPD:HelpDesk, and I've done a Add All Related, and its just hanging. Any suggestions where to look on our servers? Have to admit that the Admin tool is unpatched though - does anyone expect that I'd have performance improvements in moving to a later patch? Regards, Dave ps. How to get an ARS 5.1.1 to 6.3/Helpdesk 4 to 6 migration done in less than 2 weeks - I'll tell you by the end of the week, which is my supposed deadline :) __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___
Re: Server performance issues?
** We've only got two active systems : The ARS 5.1.1/Helpdesk 4 Live system (archaic, albeit reliable hardware) The ARS 6.3/Helpdesk 6 test system - this is the one I'm working on. I've just connected to the server via virtual desktop, its running at patch 15. Tried the same thing - doing an export of the defs related to HPD:HelpDesk, and its freezing at the Export all related. I'll check the developer cache; I'd forgotten about that. Still doesn't adequately explain the crabby performance though, especially on much higher spec hardware, with considerably lower loading (the live server handles definition exports quite nicely, regardless of the number of users, always has done, the test server has just 2 users connected at the moment). Ta, Dave On 08/05/06, McKenzie, James J C-E LCMC HQISEC/L3 [EMAIL PROTECTED] wrote: ** Rick: I highly recommend turning on and off the Developer Cache mode ONLY when you are working on forms on a production machine (why aren't you working on a dev machine anyhow). If you can get it, take the old production machine and use it as your dev machine. This will allow you to run on a smaller scale to see what effects you will have if you are running a larger production machine with hundreds of users. James McKenzie Remedy Engineer Enterprise Systems Device Management Enterprise Systems Engineering Directorate C-E LCMC ISEC Fort Huachuca, Arizona 85613 Phone: (520) 538-3171 From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook Sent: Monday, May 08, 2006 8:39 AM To: arslist@ARSLIST.ORG Subject: Re: Server performance issues? ** Dave, One thing that's a little different about how ARS 6.3 works is that there's more initial caching at the client level to speed up performance in subsequent transactions. This can be controlled to some extent by changing your caching thresholds, and by turning on the Developer Cache Mode for production systems. Mid-Tier is especially susceptible to the caching issue - initial downloads of a large form may take close to a minute. But once that's done, if recaching isn't required, subsequent updates and normal transactions are very quick. Rick From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Dave Barber Sent: Monday, May 08, 2006 8:34 AM To: arslist@ARSLIST.ORG Subject: Server performance issues? ** All, I'm working nicely through the changes required to our test installation of ARS 6.3/Helpdesk 6 (I can't really call it ITSM6 yet), and the server performance isn't looking too good at the moment. When I talk performance, I'm talking about general working in the Admin tool - saving forms/active links and filters, exporting data. It was slow on our old server (Win2k, ARS 5.1.1, Helpdesk 4, running dual 500mHz processors with 1gig of ram), but its definitely slower on the new server (Win2k3, ARS 6.3, Helpdesk 6, running dual 3gig processors with 4gig of ram). Right now I'm trying to do a definitions back of the helpdesk form, and I've been sitting waiting for what feels like an eternity - go the export defs window open, selected HPD:HelpDesk, and I've done a Add All Related, and its just hanging. Any suggestions where to look on our servers? Have to admit that the Admin tool is unpatched though - does anyone expect that I'd have performance improvements in moving to a later patch? Regards, Dave ps. How to get an ARS 5.1.1 to 6.3/Helpdesk 4 to 6 migration done in less than 2 weeks - I'll tell you by the end of the week, which is my supposed deadline :) __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___
