You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@oodt.apache.org by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov> on 2012/10/25 23:19:54 UTC
Re: [oodt-dev] Workflow Manager in wengine-branch chews up CPU
Hey Sean,
(CC'ing dev@oodt.a.o on my reply with your permission)
We are seeing this same issue in 0.5 wengine in the trunk for Apache OODT. I've also noticed
that though it eats up 99% of the CPU, it doesn't seem to hamper the machine at all. I think it
might have something to do with the thread spin waiting approach that we're taking in both.
I'll try and do some profiling of it over the next week. I have a few finish line tasks, but
workflow/task level and condition level expansion is fully working in Wengine right now and modulo
OODT-517 [1], OODT-518 [2], and OODT-519 [3], I think we're ready to go with an 0.5 initial release
of it in the next few weeks. I am integrating the system into our Snow Near-Real-Time processing
hopefully next week and should have some more numbers and information to report.
Cheers,
Chris
[1] https://issues.apache.org/jira/browse/OODT-517
[2] https://issues.apache.org/jira/browse/OODT-518
[3] https://issues.apache.org/jira/browse/OODT-519
On Oct 25, 2012, at 11:56 AM, Hardman, Sean H (388J) wrote:
> I figured I would put this out to the internal OODT community first. ACCE is still running off of the wengine-branch [1] of OODT and we have a situation where the Workflow Manager monopolizes a processor on the machine even when it is technically not doing anything. I assumed it has something to do with constant polling, but I can't seem to find a property that governs any timing issues. It doesn't appear to cause any performance issues but the SA for the host machine badgers me about it. Has anyone seen this situation or know of a fix for it?
>
> Thanks,
> Sean
>
> [1] https://svn.apache.org/repos/asf/oodt/branches/wengine-branch/
Re: [oodt-dev] Workflow Manager in wengine-branch chews up CPU
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Brian,
Yep we have that in wengine in OODT 0.5 trunk right now too.
The dirty workflow concept sounds neat -- could you elaborate?
Cheers,
Chris
On Oct 25, 2012, at 2:31 PM, Brian Foster wrote:
> just put a configurable wait seconds between handling each workflow so the thread doesn't run amuck... we really just need to add "dirty" workflow concept... never got a chance when working on wengine
>
> -brian
>
> On Oct 25, 2012, at 02:19 PM, "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov> wrote:
>
>> Hey Sean,
>>
>> (CC'ing dev@oodt.a.o on my reply with your permission)
>>
>> We are seeing this same issue in 0.5 wengine in the trunk for Apache OODT. I've also noticed
>> that though it eats up 99% of the CPU, it doesn't seem to hamper the machine at all. I think it
>> might have something to do with the thread spin waiting approach that we're taking in both.
>>
>> I'll try and do some profiling of it over the next week. I have a few finish line tasks, but
>> workflow/task level and condition level expansion is fully working in Wengine right now and modulo
>> OODT-517 [1], OODT-518 [2], and OODT-519 [3], I think we're ready to go with an 0.5 initial release
>> of it in the next few weeks. I am integrating the system into our Snow Near-Real-Time processing
>> hopefully next week and should have some more numbers and information to report.
>>
>> Cheers,
>> Chris
>>
>> [1] https://issues.apache.org/jira/browse/OODT-517
>> [2] https://issues.apache.org/jira/browse/OODT-518
>> [3] https://issues.apache.org/jira/browse/OODT-519
>>
>> On Oct 25, 2012, at 11:56 AM, Hardman, Sean H (388J) wrote:
>>
>> > I figured I would put this out to the internal OODT community first. ACCE is still running off of the wengine-branch [1] of OODT and we have a situation where the Workflow Manager monopolizes a processor on the machine even when it is technically not doing anything. I assumed it has something to do with constant polling, but I can't seem to find a property that governs any timing issues. It doesn't appear to cause any performance issues but the SA for the host machine badgers me about it. Has anyone seen this situation or know of a fix for it?
>> >
>> > Thanks,
>> > Sean
>> >
>> > [1] https://svn.apache.org/repos/asf/oodt/branches/wengine-branch/
>>
Re: [oodt-dev] Workflow Manager in wengine-branch chews up CPU
Posted by Brian Foster <ho...@me.com>.
just put a configurable wait seconds between handling each workflow so the thread doesn't run amuck... we really just need to add "dirty" workflow concept... never got a chance when working on wengine
-brian
On Oct 25, 2012, at 02:19 PM, "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov> wrote:
Hey Sean,
(CC'ing dev@oodt.a.o on my reply with your permission)
We are seeing this same issue in 0.5 wengine in the trunk for Apache OODT. I've also noticed
that though it eats up 99% of the CPU, it doesn't seem to hamper the machine at all. I think it
might have something to do with the thread spin waiting approach that we're taking in both.
I'll try and do some profiling of it over the next week. I have a few finish line tasks, but
workflow/task level and condition level expansion is fully working in Wengine right now and modulo
OODT-517 [1], OODT-518 [2], and OODT-519 [3], I think we're ready to go with an 0.5 initial release
of it in the next few weeks. I am integrating the system into our Snow Near-Real-Time processing
hopefully next week and should have some more numbers and information to report.
Cheers,
Chris
[1] https://issues.apache.org/jira/browse/OODT-517
[2] https://issues.apache.org/jira/browse/OODT-518
[3] https://issues.apache.org/jira/browse/OODT-519
On Oct 25, 2012, at 11:56 AM, Hardman, Sean H (388J) wrote:
> I figured I would put this out to the internal OODT community first. ACCE is still running off of the wengine-branch [1] of OODT and we have a situation where the Workflow Manager monopolizes a processor on the machine even when it is technically not doing anything. I assumed it has something to do with constant polling, but I can't seem to find a property that governs any timing issues. It doesn't appear to cause any performance issues but the SA for the host machine badgers me about it. Has anyone seen this situation or know of a fix for it?
>
> Thanks,
> Sean
>
> [1] https://svn.apache.org/repos/asf/oodt/branches/wengine-branch/