Re: Wrong escalation execution time
Hi Mahmoud, Please check the escalation pool. May be you might have one escalation pool that has so many filters that needs to be executed. Try to create a new pool and assign this escalation to that. Thanks, Vishal From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Mahmoud Mahdy-Mohamed, Vodafone Egypt Sent: Sunday, August 24, 2014 4:39 PM To: arslist@ARSLIST.ORG Subject: Re: Wrong escalation execution time ** Please ignore last message, it was sent by mistake From: Mahmoud Mahdy-Mohamed, Vodafone Egypt Sent: Sunday, August 24, 2014 1:57 PM To: arslist@ARSLIST.ORG Subject: RE: Wrong escalation execution time Any updates..?? From: Mahmoud Mahdy-Mohamed, Vodafone Egypt Sent: Tuesday, August 19, 2014 12:05 PM To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG Subject: Wrong escalation execution time Dears, Kindly help as I'm facing a critical issue, the escalations are running randomly regardless the execution time that it should execute in. For example I have escalation that has to run every minute however it is running after 30 min which causes a delay in other related work flows. Note:- I'm using 7.6.04 SP4 Thanks, Best Regards, Mahmoud Mahdy Mohammed,PMP | Business Process Automation Technology | Products Services Delivery Phone: +20(0)1004999638 Mail: mahmoud.mahdy-moha...@vodafone.commailto:mohamed.abdel-haf...@vodafone.com * The content of this document is classified as Vodafone Egypt S.A.E. Confidential and Proprietary Information. The recipient hereby is committed to hold in strict confidence the contents of this (e-mail, document, information) and not to disclose to any third party without the prior written consent of Vodafone Egypt S.A.E. Recipient will be held liable for any unauthorized disclosure. If you have received this message in error, please notify the sender by return e-mail and delete the message in its entirety, including any attachments. http://www.vodafone.com.eghttp://www.vodafone.com.eg/ * _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: Wrong escalation execution time
how much data this escalation is suppose to process? Note that you are running it every minute. You can try below approach. 1. Put this escalation on a separate escalation pool.. 2. Try running it during the off peak business hours (when there is less load on the server) 3. Enable Escalation, API/SQL/Filter logs at the scheduled time of the escalation run see what activity is been performed at that time. HTH, Regards, Mayuresh On Sun, Aug 24, 2014 at 4:26 PM, Mahmoud Mahdy-Mohamed, Vodafone Egypt mahmoud.mahdy-moha...@vodafone.com wrote: ** Any updates..?? *From:* Mahmoud Mahdy-Mohamed, Vodafone Egypt *Sent:* Tuesday, August 19, 2014 12:05 PM *To:* arslist@ARSLIST.ORG *Subject:* Wrong escalation execution time Dears, Kindly help as I’m facing a critical issue, the escalations are running randomly regardless the execution time that it should execute in. For example I have escalation that has to run every *minute* however it is running after *30 min* which causes a delay in other related work flows. Note:- I’m using 7.6.04 SP4 *Thanks,* *Best Regards,* *Mahmoud Mahdy Mohammed,PMP* | Business Process Automation *Technology | Products Services Delivery* *Phone:* +20(0)1004999638 * Mail:* *mahmoud.mahdy-moha...@vodafone.com mohamed.abdel-haf...@vodafone.com* * The content of this document is classified as Vodafone Egypt S.A.E. Confidential and Proprietary Information. The recipient hereby is committed to hold in strict confidence the contents of this (e-mail, document, information) and not to disclose to any third party without the prior written consent of Vodafone Egypt S.A.E. Recipient will be held liable for any unauthorized disclosure. If you have received this message in error, please notify the sender by return e-mail and delete the message in its entirety, including any attachments. http://www.vodafone.com.eg * _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: Wrong escalation execution time
Any updates..?? From: Mahmoud Mahdy-Mohamed, Vodafone Egypt Sent: Tuesday, August 19, 2014 12:05 PM To: arslist@ARSLIST.ORG Subject: Wrong escalation execution time Dears, Kindly help as I'm facing a critical issue, the escalations are running randomly regardless the execution time that it should execute in. For example I have escalation that has to run every minute however it is running after 30 min which causes a delay in other related work flows. Note:- I'm using 7.6.04 SP4 Thanks, Best Regards, Mahmoud Mahdy Mohammed,PMP | Business Process Automation Technology | Products Services Delivery Phone: +20(0)1004999638 Mail: mahmoud.mahdy-moha...@vodafone.commailto:mohamed.abdel-haf...@vodafone.com * The content of this document is classified as Vodafone Egypt S.A.E. Confidential and Proprietary Information. The recipient hereby is committed to hold in strict confidence the contents of this (e-mail, document, information) and not to disclose to any third party without the prior written consent of Vodafone Egypt S.A.E. Recipient will be held liable for any unauthorized disclosure. If you have received this message in error, please notify the sender by return e-mail and delete the message in its entirety, including any attachments. http://www.vodafone.com.eg * ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Wrong escalation execution time
Please ignore last message, it was sent by mistake From: Mahmoud Mahdy-Mohamed, Vodafone Egypt Sent: Sunday, August 24, 2014 1:57 PM To: arslist@ARSLIST.ORG Subject: RE: Wrong escalation execution time Any updates..?? From: Mahmoud Mahdy-Mohamed, Vodafone Egypt Sent: Tuesday, August 19, 2014 12:05 PM To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG Subject: Wrong escalation execution time Dears, Kindly help as I'm facing a critical issue, the escalations are running randomly regardless the execution time that it should execute in. For example I have escalation that has to run every minute however it is running after 30 min which causes a delay in other related work flows. Note:- I'm using 7.6.04 SP4 Thanks, Best Regards, Mahmoud Mahdy Mohammed,PMP | Business Process Automation Technology | Products Services Delivery Phone: +20(0)1004999638 Mail: mahmoud.mahdy-moha...@vodafone.commailto:mohamed.abdel-haf...@vodafone.com * The content of this document is classified as Vodafone Egypt S.A.E. Confidential and Proprietary Information. The recipient hereby is committed to hold in strict confidence the contents of this (e-mail, document, information) and not to disclose to any third party without the prior written consent of Vodafone Egypt S.A.E. Recipient will be held liable for any unauthorized disclosure. If you have received this message in error, please notify the sender by return e-mail and delete the message in its entirety, including any attachments. http://www.vodafone.com.eg * ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Wrong escalation execution time
There's one other thing that can be really vexing when dealing with this problem. Let's decide you go multi-threaded. You put your escalation that needs to run every minute on a new pool (thread) of #4. You set some of the others to 1, 2, and 3. But...if you leave ANY of the escalations undeclared for which pool they should use, they still CAN use #4, and mess up your escalation. I've seen that happen quite a few times. So basically - if you are going to define a pool for one escalation - you might as well do it for ALL of the escalations. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Brian Goralczyk Sent: Tuesday, August 19, 2014 6:39 PM To: arslist@ARSLIST.ORG Subject: Re: Wrong escalation execution time ** One of the tricks that I have found to help is to look at the number of records that are in the table and how many are returned by your escalation. Then decide what is being done to them and does it need to be single threaded? If not, and you just need the escalation to schedule the work it might be something that you can turn multi-threaded in the way it runs by having an escalation for that has one record and performs a push to all the matching records. I can go into this deeper if anyone prefers. But it can definitely improve the performance of escalations. Brian Goralczyk On Tue, Aug 19, 2014 at 1:15 PM, Doug Blair d...@blairing.commailto:d...@blairing.com wrote: ** Mahmoud, I have done quite a bit of fiddling with just this situation. Simply put, out-of-the-box the Escalation process is single threaded, which means that with no further adjustments only one escalation can operate at any given time. A long running escalation will delay the start of others, and a very long running escalation can cause some cases of the shorter ones to be skipped entirely. To fix this you can add threads to the escalation process (390603). This will allow more than one escalation to run at the same time. This will allow more of your escalations to complete without blocking each other, but still might allow some to be delayed. There is also the chance that some escalations depend on other escalations to be completed before they will do what is expected. The notification engine has a couple cases like this. These sorts of escalations can be grouped together using escalation pools. Please do not be tempted to add one thread or pool for every escalation! That would work, but would waste a lot of resources and potentially slow things down. You will need to turn on escalation logging and see how many escalations are ready too fire each minute, then adjust the number of threads so that more of them will fire and complete. Then group the ones which should not be blocked into unique pools. You can experiment with all of these pools and threads a bit, and remember that each thread, whether in an escalation queue or any other queue will tax the system somewhat. You want those threads to be mostly busy, and for there to be at least one thread/pool combination to be available every minute for your essential one. One way to be certain this happens might be to isolate your critical escalation in a pool by itself (let’s say pool 3), set your escalation threads to 3, and set all the other escalations to either pool NULL (which is the default) or pools 1-2. Anything in pool 1 or 2 will run on one of the first two available threads, and your essential one will be the only thing that runs in thread 3. You might have several escalations which need to fire every minute. As long as those don’t take a long time to run they could be all in the same pool. If you find that running all the escalations assigned to pool 3 takes longer than a minute, you’ll need to look at more threads or more pools. You can also investigate scheduling of the escalations. It is very common to find that a lot are scheduled to run at :00 in each hour (the default value). Perhaps some of these can be mored to another time so they do not all trigger at once. All that said, there is also the possibility that some of your escalations might be poorly written and just be doing things very inefficiently. Look closely at the RUNIF qualifications of those that seem to take a long time to complete, and turn those just as you would an inefficient filter qualification or search for a report or other lookup… Hope this helps! Doug Blair On Aug 19, 2014, at 4:04 AM, Mahmoud Mahdy-Mohamed, Vodafone Egypt mahmoud.mahdy-moha...@vodafone.commailto:mahmoud.mahdy-moha...@vodafone.com wrote: ** Dears, Kindly help as I’m facing a critical issue, the escalations are running randomly regardless the execution time that it should execute in. For example I have escalation that has to run every minute however it is running after 30 min which causes a delay in other related work flows. Note:- I’m using 7.6.04 SP4 Thanks, Best Regards, Mahmoud Mahdy Mohammed,PMP
Re: Wrong escalation execution time
William, I have never seen that, I have experienced that any escalation that doesn't have a pool defined runs in pool 1 (legacy style)do you have a workable example of a non-pooled escalation jumping to a pool other than 1? On Wed, Aug 20, 2014 at 8:46 AM, William Rentfrow wrentf...@stratacominc.com wrote: ** There's one other thing that can be really vexing when dealing with this problem. Let's decide you go multi-threaded. You put your escalation that needs to run every minute on a new pool (thread) of #4. You set some of the others to 1, 2, and 3. But...if you leave ANY of the escalations undeclared for which pool they should use, they still CAN use #4, and mess up your escalation. I've seen that happen quite a few times. So basically - if you are going to define a pool for one escalation - you might as well do it for ALL of the escalations. *From:* Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] *On Behalf Of *Brian Goralczyk *Sent:* Tuesday, August 19, 2014 6:39 PM *To:* arslist@ARSLIST.ORG *Subject:* Re: Wrong escalation execution time ** One of the tricks that I have found to help is to look at the number of records that are in the table and how many are returned by your escalation. Then decide what is being done to them and does it need to be single threaded? If not, and you just need the escalation to schedule the work it might be something that you can turn multi-threaded in the way it runs by having an escalation for that has one record and performs a push to all the matching records. I can go into this deeper if anyone prefers. But it can definitely improve the performance of escalations. Brian Goralczyk On Tue, Aug 19, 2014 at 1:15 PM, Doug Blair d...@blairing.com wrote: ** Mahmoud, I have done quite a bit of fiddling with just this situation. Simply put, out-of-the-box the Escalation process is single threaded, which means that with no further adjustments only one escalation can operate at any given time. A long running escalation will delay the start of others, and a very long running escalation can cause some cases of the shorter ones to be skipped entirely. To fix this you can add threads to the escalation process (390603). This will allow more than one escalation to run at the same time. This will allow more of your escalations to complete without blocking each other, but still might allow some to be delayed. There is also the chance that some escalations depend on other escalations to be completed before they will do what is expected. The notification engine has a couple cases like this. These sorts of escalations can be grouped together using escalation pools. Please do not be tempted to add one thread or pool for every escalation! That would work, but would waste a lot of resources and potentially slow things down. You will need to turn on escalation logging and see how many escalations are ready too fire each minute, then adjust the number of threads so that more of them will fire and complete. Then group the ones which should not be blocked into unique pools. You can experiment with all of these pools and threads a bit, and remember that each thread, whether in an escalation queue or any other queue will tax the system somewhat. You want those threads to be mostly busy, and for there to be at least one thread/pool combination to be available every minute for your essential one. One way to be certain this happens might be to isolate your critical escalation in a pool by itself (let’s say pool 3), set your escalation threads to 3, and set all the other escalations to either pool NULL (which is the default) or pools 1-2. Anything in pool 1 or 2 will run on one of the first two available threads, and your essential one will be the only thing that runs in thread 3. You might have several escalations which need to fire every minute. As long as those don’t take a long time to run they could be all in the same pool. If you find that running all the escalations assigned to pool 3 takes longer than a minute, you’ll need to look at more threads or more pools. You can also investigate scheduling of the escalations. It is very common to find that a lot are scheduled to run at :00 in each hour (the default value). Perhaps some of these can be mored to another time so they do not all trigger at once. All that said, there is also the possibility that some of your escalations might be poorly written and just be doing things very inefficiently. Look closely at the RUNIF qualifications of those that seem to take a long time to complete, and turn those just as you would an inefficient filter qualification or search for a report or other lookup… Hope this helps! Doug Blair On Aug 19, 2014, at 4:04 AM, Mahmoud Mahdy-Mohamed, Vodafone Egypt mahmoud.mahdy-moha...@vodafone.com wrote: ** Dears, Kindly help as I’m
Re: Wrong escalation execution time
I thought undeclared escalations went into pool 1 by default as well. That being said I would agree that if you are going to the trouble to create separate pools it would be worth the effort IMO to analyze all your escalations and parse them out into separate pools based on scheduled execution time and expected run time to prevent bottlenecks. I have done that myself but only for custom escalations, not any of the ITSM workflow. -Rick From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Wednesday, August 20, 2014 8:22 AM To: arslist@ARSLIST.ORG Subject: Re: Wrong escalation execution time ** William, I have never seen that, I have experienced that any escalation that doesn't have a pool defined runs in pool 1 (legacy style)do you have a workable example of a non-pooled escalation jumping to a pool other than 1? On Wed, Aug 20, 2014 at 8:46 AM, William Rentfrow wrentf...@stratacominc.commailto:wrentf...@stratacominc.com wrote: ** There's one other thing that can be really vexing when dealing with this problem. Let's decide you go multi-threaded. You put your escalation that needs to run every minute on a new pool (thread) of #4. You set some of the others to 1, 2, and 3. But...if you leave ANY of the escalations undeclared for which pool they should use, they still CAN use #4, and mess up your escalation. I've seen that happen quite a few times. So basically - if you are going to define a pool for one escalation - you might as well do it for ALL of the escalations. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG] On Behalf Of Brian Goralczyk Sent: Tuesday, August 19, 2014 6:39 PM To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG Subject: Re: Wrong escalation execution time ** One of the tricks that I have found to help is to look at the number of records that are in the table and how many are returned by your escalation. Then decide what is being done to them and does it need to be single threaded? If not, and you just need the escalation to schedule the work it might be something that you can turn multi-threaded in the way it runs by having an escalation for that has one record and performs a push to all the matching records. I can go into this deeper if anyone prefers. But it can definitely improve the performance of escalations. Brian Goralczyk On Tue, Aug 19, 2014 at 1:15 PM, Doug Blair d...@blairing.commailto:d...@blairing.com wrote: ** Mahmoud, I have done quite a bit of fiddling with just this situation. Simply put, out-of-the-box the Escalation process is single threaded, which means that with no further adjustments only one escalation can operate at any given time. A long running escalation will delay the start of others, and a very long running escalation can cause some cases of the shorter ones to be skipped entirely. To fix this you can add threads to the escalation process (390603). This will allow more than one escalation to run at the same time. This will allow more of your escalations to complete without blocking each other, but still might allow some to be delayed. There is also the chance that some escalations depend on other escalations to be completed before they will do what is expected. The notification engine has a couple cases like this. These sorts of escalations can be grouped together using escalation pools. Please do not be tempted to add one thread or pool for every escalation! That would work, but would waste a lot of resources and potentially slow things down. You will need to turn on escalation logging and see how many escalations are ready too fire each minute, then adjust the number of threads so that more of them will fire and complete. Then group the ones which should not be blocked into unique pools. You can experiment with all of these pools and threads a bit, and remember that each thread, whether in an escalation queue or any other queue will tax the system somewhat. You want those threads to be mostly busy, and for there to be at least one thread/pool combination to be available every minute for your essential one. One way to be certain this happens might be to isolate your critical escalation in a pool by itself (let’s say pool 3), set your escalation threads to 3, and set all the other escalations to either pool NULL (which is the default) or pools 1-2. Anything in pool 1 or 2 will run on one of the first two available threads, and your essential one will be the only thing that runs in thread 3. You might have several escalations which need to fire every minute. As long as those don’t take a long time to run they could be all in the same pool. If you find that running all the escalations assigned to pool 3 takes longer than a minute, you’ll need to look at more threads or more pools. You can also investigate scheduling of the escalations. It is very common to find
Re: Wrong escalation execution time
I think there was a bug that was fixed, but I can’t remember which patch Of course the documentation doesn’t really cover this (It mentions Escalations assigned to a pool with no thread, but not Escalations not assigned to any pool when multiple pools are defined) Escalations can be assigned to pools so the escalations from each pool run in parallel on separate threads within the escalation queue. To use escalation pools, you must first configure multiple threads for the escalation queue as described in AR System server queues. If you assign an escalation to a pool that has no thread configured, the escalation is run by the first thread. Fred From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Westbrock Sent: Wednesday, August 20, 2014 10:47 AM To: arslist@ARSLIST.ORG Subject: Re: Wrong escalation execution time ** I thought undeclared escalations went into pool 1 by default as well. That being said I would agree that if you are going to the trouble to create separate pools it would be worth the effort IMO to analyze all your escalations and parse them out into separate pools based on scheduled execution time and expected run time to prevent bottlenecks. I have done that myself but only for custom escalations, not any of the ITSM workflow. -Rick From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Wednesday, August 20, 2014 8:22 AM To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG Subject: Re: Wrong escalation execution time ** William, I have never seen that, I have experienced that any escalation that doesn't have a pool defined runs in pool 1 (legacy style)do you have a workable example of a non-pooled escalation jumping to a pool other than 1? On Wed, Aug 20, 2014 at 8:46 AM, William Rentfrow wrote: ** There's one other thing that can be really vexing when dealing with this problem. Let's decide you go multi-threaded. You put your escalation that needs to run every minute on a new pool (thread) of #4. You set some of the others to 1, 2, and 3. But...if you leave ANY of the escalations undeclared for which pool they should use, they still CAN use #4, and mess up your escalation. I've seen that happen quite a few times. So basically - if you are going to define a pool for one escalation - you might as well do it for ALL of the escalations. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG] On Behalf Of Brian Goralczyk Sent: Tuesday, August 19, 2014 6:39 PM To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG Subject: Re: Wrong escalation execution time ** One of the tricks that I have found to help is to look at the number of records that are in the table and how many are returned by your escalation. Then decide what is being done to them and does it need to be single threaded? If not, and you just need the escalation to schedule the work it might be something that you can turn multi-threaded in the way it runs by having an escalation for that has one record and performs a push to all the matching records. I can go into this deeper if anyone prefers. But it can definitely improve the performance of escalations. Brian Goralczyk On Tue, Aug 19, 2014 at 1:15 PM, Doug Blair wrote: ** Mahmoud, I have done quite a bit of fiddling with just this situation. Simply put, out-of-the-box the Escalation process is single threaded, which means that with no further adjustments only one escalation can operate at any given time. A long running escalation will delay the start of others, and a very long running escalation can cause some cases of the shorter ones to be skipped entirely. To fix this you can add threads to the escalation process (390603). This will allow more than one escalation to run at the same time. This will allow more of your escalations to complete without blocking each other, but still might allow some to be delayed. There is also the chance that some escalations depend on other escalations to be completed before they will do what is expected. The notification engine has a couple cases like this. These sorts of escalations can be grouped together using escalation pools. Please do not be tempted to add one thread or pool for every escalation! That would work, but would waste a lot of resources and potentially slow things down. You will need to turn on escalation logging and see how many escalations are ready too fire each minute, then adjust the number of threads so that more of them will fire and complete. Then group the ones which should not be blocked into unique pools. You can experiment with all of these pools and threads a bit, and remember that each thread, whether in an escalation queue or any other queue will tax the system somewhat. You want those threads to be mostly busy, and for there to be at least one thread/pool combination to be available
Re: Wrong escalation execution time
I haven't seen it for a while, but we did have multiple copies of logs where this was happening a year or so ago. If (as another poster said) it's a bug that has been fixed, perhaps that's why I haven't seen it for a while. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Westbrock Sent: Wednesday, August 20, 2014 10:47 AM To: arslist@ARSLIST.ORG Subject: Re: Wrong escalation execution time ** I thought undeclared escalations went into pool 1 by default as well. That being said I would agree that if you are going to the trouble to create separate pools it would be worth the effort IMO to analyze all your escalations and parse them out into separate pools based on scheduled execution time and expected run time to prevent bottlenecks. I have done that myself but only for custom escalations, not any of the ITSM workflow. -Rick From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Wednesday, August 20, 2014 8:22 AM To: arslist@ARSLIST.ORG Subject: Re: Wrong escalation execution time ** William, I have never seen that, I have experienced that any escalation that doesn't have a pool defined runs in pool 1 (legacy style)do you have a workable example of a non-pooled escalation jumping to a pool other than 1? On Wed, Aug 20, 2014 at 8:46 AM, William Rentfrow wrentf...@stratacominc.commailto:wrentf...@stratacominc.com wrote: ** There's one other thing that can be really vexing when dealing with this problem. Let's decide you go multi-threaded. You put your escalation that needs to run every minute on a new pool (thread) of #4. You set some of the others to 1, 2, and 3. But...if you leave ANY of the escalations undeclared for which pool they should use, they still CAN use #4, and mess up your escalation. I've seen that happen quite a few times. So basically - if you are going to define a pool for one escalation - you might as well do it for ALL of the escalations. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG] On Behalf Of Brian Goralczyk Sent: Tuesday, August 19, 2014 6:39 PM To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG Subject: Re: Wrong escalation execution time ** One of the tricks that I have found to help is to look at the number of records that are in the table and how many are returned by your escalation. Then decide what is being done to them and does it need to be single threaded? If not, and you just need the escalation to schedule the work it might be something that you can turn multi-threaded in the way it runs by having an escalation for that has one record and performs a push to all the matching records. I can go into this deeper if anyone prefers. But it can definitely improve the performance of escalations. Brian Goralczyk On Tue, Aug 19, 2014 at 1:15 PM, Doug Blair d...@blairing.commailto:d...@blairing.com wrote: ** Mahmoud, I have done quite a bit of fiddling with just this situation. Simply put, out-of-the-box the Escalation process is single threaded, which means that with no further adjustments only one escalation can operate at any given time. A long running escalation will delay the start of others, and a very long running escalation can cause some cases of the shorter ones to be skipped entirely. To fix this you can add threads to the escalation process (390603). This will allow more than one escalation to run at the same time. This will allow more of your escalations to complete without blocking each other, but still might allow some to be delayed. There is also the chance that some escalations depend on other escalations to be completed before they will do what is expected. The notification engine has a couple cases like this. These sorts of escalations can be grouped together using escalation pools. Please do not be tempted to add one thread or pool for every escalation! That would work, but would waste a lot of resources and potentially slow things down. You will need to turn on escalation logging and see how many escalations are ready too fire each minute, then adjust the number of threads so that more of them will fire and complete. Then group the ones which should not be blocked into unique pools. You can experiment with all of these pools and threads a bit, and remember that each thread, whether in an escalation queue or any other queue will tax the system somewhat. You want those threads to be mostly busy, and for there to be at least one thread/pool combination to be available every minute for your essential one. One way to be certain this happens might be to isolate your critical escalation in a pool by itself (let’s say pool 3), set your escalation threads to 3, and set all the other escalations to either pool NULL (which is the default) or pools 1-2. Anything in pool 1 or 2 will run on one of the first two available
Re: Wrong escalation execution time
Hi, This is presumably caused by a queuing situation where other slow escalations has to complete before the one under scrutiny is executed. 1. Check if other escalations are competing about execution time 2. Check that your escalation executes in less than 1 minute 3. Move your escalation to another, or a new, escalation thread Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13): * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se. Dears, Kindly help as I'm facing a critical issue, the escalations are running randomly regardless the execution time that it should execute in. For example I have escalation that has to run every minute however it is running after 30 min which causes a delay in other related work flows. Note:- I'm using 7.6.04 SP4 Thanks, Best Regards, Mahmoud Mahdy Mohammed,PMP | Business Process Automation Technology | Products Services Delivery Phone: +20(0)1004999638 Mail: mahmoud.mahdy-moha...@vodafone.commailto:mohamed.abdel-haf...@vodafone.com * The content of this document is classified as Vodafone Egypt S.A.E. Confidential and Proprietary Information. The recipient hereby is committed to hold in strict confidence the contents of this (e-mail, document, information) and not to disclose to any third party without the prior written consent of Vodafone Egypt S.A.E. Recipient will be held liable for any unauthorized disclosure. If you have received this message in error, please notify the sender by return e-mail and delete the message in its entirety, including any attachments. http://www.vodafone.com.eg * ___ 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: Wrong escalation execution time
Mahmoud, I have done quite a bit of fiddling with just this situation. Simply put, out-of-the-box the Escalation process is single threaded, which means that with no further adjustments only one escalation can operate at any given time. A long running escalation will delay the start of others, and a very long running escalation can cause some cases of the shorter ones to be skipped entirely. To fix this you can add threads to the escalation process (390603). This will allow more than one escalation to run at the same time. This will allow more of your escalations to complete without blocking each other, but still might allow some to be delayed. There is also the chance that some escalations depend on other escalations to be completed before they will do what is expected. The notification engine has a couple cases like this. These sorts of escalations can be grouped together using escalation pools. Please do not be tempted to add one thread or pool for every escalation! That would work, but would waste a lot of resources and potentially slow things down. You will need to turn on escalation logging and see how many escalations are ready too fire each minute, then adjust the number of threads so that more of them will fire and complete. Then group the ones which should not be blocked into unique pools. You can experiment with all of these pools and threads a bit, and remember that each thread, whether in an escalation queue or any other queue will tax the system somewhat. You want those threads to be mostly busy, and for there to be at least one thread/pool combination to be available every minute for your essential one. One way to be certain this happens might be to isolate your critical escalation in a pool by itself (let’s say pool 3), set your escalation threads to 3, and set all the other escalations to either pool NULL (which is the default) or pools 1-2. Anything in pool 1 or 2 will run on one of the first two available threads, and your essential one will be the only thing that runs in thread 3. You might have several escalations which need to fire every minute. As long as those don’t take a long time to run they could be all in the same pool. If you find that running all the escalations assigned to pool 3 takes longer than a minute, you’ll need to look at more threads or more pools. You can also investigate scheduling of the escalations. It is very common to find that a lot are scheduled to run at :00 in each hour (the default value). Perhaps some of these can be mored to another time so they do not all trigger at once. All that said, there is also the possibility that some of your escalations might be poorly written and just be doing things very inefficiently. Look closely at the RUNIF qualifications of those that seem to take a long time to complete, and turn those just as you would an inefficient filter qualification or search for a report or other lookup… Hope this helps! Doug Blair On Aug 19, 2014, at 4:04 AM, Mahmoud Mahdy-Mohamed, Vodafone Egypt mahmoud.mahdy-moha...@vodafone.com wrote: ** Dears, Kindly help as I’m facing a critical issue, the escalations are running randomly regardless the execution time that it should execute in. For example I have escalation that has to run every minute however it is running after 30 min which causes a delay in other related work flows. Note:- I’m using 7.6.04 SP4 Thanks, Best Regards, Mahmoud Mahdy Mohammed,PMP | Business Process Automation Technology | Products Services Delivery Phone: +20(0)1004999638 Mail: mahmoud.mahdy-moha...@vodafone.com * The content of this document is classified as Vodafone Egypt S.A.E. Confidential and Proprietary Information. The recipient hereby is committed to hold in strict confidence the contents of this (e-mail, document, information) and not to disclose to any third party without the prior written consent of Vodafone Egypt S.A.E. Recipient will be held liable for any unauthorized disclosure. If you have received this message in error, please notify the sender by return e-mail and delete the message in its entirety, including any attachments. http://www.vodafone.com.eg * _ARSlist: Where the Answers Are and have been for 20 years_ Doug -- Doug Blair d...@blairing.com +1 224-558-5462 1208 East Fremont Street Arlington Heights, Illinois 60004 ITILv3 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Wrong escalation execution time
One of the tricks that I have found to help is to look at the number of records that are in the table and how many are returned by your escalation. Then decide what is being done to them and does it need to be single threaded? If not, and you just need the escalation to schedule the work it might be something that you can turn multi-threaded in the way it runs by having an escalation for that has one record and performs a push to all the matching records. I can go into this deeper if anyone prefers. But it can definitely improve the performance of escalations. Brian Goralczyk On Tue, Aug 19, 2014 at 1:15 PM, Doug Blair d...@blairing.com wrote: ** Mahmoud, I have done quite a bit of fiddling with just this situation. Simply put, out-of-the-box the Escalation process is single threaded, which means that with no further adjustments only one escalation can operate at any given time. A long running escalation will delay the start of others, and a very long running escalation can cause some cases of the shorter ones to be skipped entirely. To fix this you can add threads to the escalation process (390603). This will allow more than one escalation to run at the same time. This will allow more of your escalations to complete without blocking each other, but still might allow some to be delayed. There is also the chance that some escalations depend on other escalations to be completed before they will do what is expected. The notification engine has a couple cases like this. These sorts of escalations can be grouped together using escalation pools. Please do not be tempted to add one thread or pool for every escalation! That would work, but would waste a lot of resources and potentially slow things down. You will need to turn on escalation logging and see how many escalations are ready too fire each minute, then adjust the number of threads so that more of them will fire and complete. Then group the ones which should not be blocked into unique pools. You can experiment with all of these pools and threads a bit, and remember that each thread, whether in an escalation queue or any other queue will tax the system somewhat. You want those threads to be mostly busy, and for there to be at least one thread/pool combination to be available every minute for your essential one. One way to be certain this happens might be to isolate your critical escalation in a pool by itself (let’s say pool 3), set your escalation threads to 3, and set all the other escalations to either pool NULL (which is the default) or pools 1-2. Anything in pool 1 or 2 will run on one of the first two available threads, and your essential one will be the only thing that runs in thread 3. You might have several escalations which need to fire every minute. As long as those don’t take a long time to run they could be all in the same pool. If you find that running all the escalations assigned to pool 3 takes longer than a minute, you’ll need to look at more threads or more pools. You can also investigate scheduling of the escalations. It is very common to find that a lot are scheduled to run at :00 in each hour (the default value). Perhaps some of these can be mored to another time so they do not all trigger at once. All that said, there is also the possibility that some of your escalations might be poorly written and just be doing things very inefficiently. Look closely at the RUNIF qualifications of those that seem to take a long time to complete, and turn those just as you would an inefficient filter qualification or search for a report or other lookup… Hope this helps! Doug Blair On Aug 19, 2014, at 4:04 AM, Mahmoud Mahdy-Mohamed, Vodafone Egypt mahmoud.mahdy-moha...@vodafone.com wrote: ** Dears, Kindly help as I’m facing a critical issue, the escalations are running randomly regardless the execution time that it should execute in. For example I have escalation that has to run every *minute* however it is running after *30 min* which causes a delay in other related work flows. Note:- I’m using 7.6.04 SP4 *Thanks,* *Best Regards,* *Mahmoud Mahdy Mohammed,PMP* | Business Process Automation *Technology | Products Services Delivery* *Phone:* +20(0)1004999638 *Mail:* *mahmoud.mahdy-moha...@vodafone.com mohamed.abdel-haf...@vodafone.com* * The content of this document is classified as Vodafone Egypt S.A.E. Confidential and Proprietary Information. The recipient hereby is committed to hold in strict confidence the contents of this (e-mail, document, information) and not to disclose to any third party without the prior written consent of Vodafone Egypt S.A.E. Recipient will be held liable for any unauthorized disclosure. If you have received this message in error, please notify the sender by return e-mail and delete the message in its
