Re: Backroom process tt00 top process

Nope it didn't exist so I killed it. Thanks for all your help. I learned something new about this flamegraph. Not sure I fully understand it but something I need to read more on.

Jeff

On Tue, Apr 13, 2021 at 11:44 AM Laurentiu Oprea < laurentiu.oprea06_at_gmail.com> wrote:

> Overall that process is just spinning in an infinite loop thus burning the
> CPU. The functions match the bug I mentioned.
>
> Does the process appear in v$process? Has a v$session associated? (most
> probably not). Just kill the process.
>
> În mar., 13 apr. 2021 la 21:29, Jeff Chirco <backseatdba_at_gmail.com> a
> scris:
>
>> What is also interesting is that this PID might be an old orphaned
>> process. ps -ef is showing to process of the same name but the one in
>> question is much older.
>>
>> # ps -ef | grep ora_tt02_polldata
>> root 16849 81676 0 11:26 pts/2 00:00:00 grep --color=auto
>> ora_tt02_polldata
>> oracle 36233 1 52 2020 ? 135-01:46:29 ora_tt02_polldata
>> oracle 57569 1 0 Jan22 ? 05:00:19 ora_tt02_polldata
>>
>> This database was last started on Jan-22. The one consuming CPU (36233)
>> is showing 2020. It has been awhile since this server has been rebooted.
>>
>> On Tue, Apr 13, 2021 at 11:26 AM Laurentiu Oprea <
>> laurentiu.oprea06_at_gmail.com> wrote:
>>
>>> Posible you hit this?
>>> Bug 23492498 - Infinite loop under kgdsdst() when system libraries were
>>> updated (Doc ID 23492498.8)
>>>
>>> În mar., 13 apr. 2021 la 21:21, Jeff Chirco <backseatdba_at_gmail.com> a
>>> scris:
>>>
>>>> I am not sure what I am looking at here.
>>>>
>>>> On Tue, Apr 13, 2021 at 11:17 AM Laurentiu Oprea <
>>>> laurentiu.oprea06_at_gmail.com> wrote:
>>>>
>>>>> you can attach the resulted perf.data file
>>>>>
>>>>> În mar., 13 apr. 2021 la 20:52, Jeff Chirco <backseatdba_at_gmail.com> a
>>>>> scris:
>>>>>
>>>>>> Thanks for this. However I am getting Permission denied errors even
>>>>>> though I captured and running the perf script all as root
>>>>>>
>>>>>> # perf script | ./stackcollapse-perf.pl | ./flamegraph.pl > TT.svg
>>>>>> bash: ./stackcollapse-perf.pl: Permission denied
>>>>>> bash: ./flamegraph.pl: Permission denied
>>>>>>
>>>>>> On Tue, Apr 13, 2021 at 9:50 AM Laurentiu Oprea <
>>>>>> laurentiu.oprea06_at_gmail.com> wrote:
>>>>>>
>>>>>>> Hello Jeff,
>>>>>>>
>>>>>>> Yes you can kill the TT process and oracle will spawn a new one. But
>>>>>>> before doing that try this to see what is doing on CPU:
>>>>>>>
>>>>>>> perf record -g -F 99 --pid pid_number
>>>>>>> -> this will generate a perf.data file (let it run few minutes and
>>>>>>> hit ctrl-c)
>>>>>>> get : https://github.com/brendangregg/FlameGraph
>>>>>>> and run:
>>>>>>> perf script | ./FlameGraph-master/stackcollapse-perf.pl |
>>>>>>> ./FlameGraph-master/flamegraph.pl > TT.svg
>>>>>>> You can send the resultate flamegraph
>>>>>>>
>>>>>>>
>>>>>>> În mar., 13 apr. 2021 la 18:38, Jeff Chirco <backseatdba_at_gmail.com>
>>>>>>> a scris:
>>>>>>>
>>>>>>>> Thanks for those Doc IDs. Those look like they have a symptom of
>>>>>>>> high PGA usage. For me PGA is looking fine but this process is consuming
>>>>>>>> high CPU.
>>>>>>>> Would anything happen if I killed that session? Would another
>>>>>>>> respawn?
>>>>>>>>
>>>>>>>> On Sun, Apr 11, 2021 at 9:10 PM Leng Burgess <lkaing_at_gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi Jeff,
>>>>>>>>>
>>>>>>>>> Check out these bugs:
>>>>>>>>>
>>>>>>>>> Bug 28831971 - PGA Memory Leak On Background Processes Such As
>>>>>>>>> MMNL TT00 Or +APX (Doc ID 28831971.8)
>>>>>>>>> Bug 30719327 - PGA memory leak in TT00, MMNL, and other background
>>>>>>>>> process with patch 28831971 APPLIED (Doc ID 30719327.8)
>>>>>>>>>
>>>>>>>>> HTH,
>>>>>>>>>
>>>>>>>>> Leng.
>>>>>>>>>
>>>>>>>>> > On 10 Apr 2021, at 6:08 am, Jeff Chirco <backseatdba_at_gmail.com>
>>>>>>>>> wrote:
>>>>>>>>> >
>>>>>>>>> > I am running TOP and I am seeing ora_tt00 backroom process at
>>>>>>>>> the top of list consistently (sorting by CPU), I mean it is at the top
>>>>>>>>> steadily. I understand that this has something to do with Redo Transport
>>>>>>>>> but I am not sure in what regards and if there is anything I can or should
>>>>>>>>> do about it. I have 2 databases on this same server both running Data
>>>>>>>>> Guard but this process is showing for only one of the databases. I think
>>>>>>>>> both databases are kind of equal on activity.
>>>>>>>>> >
>>>>>>>>> > Anything else I should be looking at?
>>>>>>>>> >
>>>>>>>>> > Thanks,
>>>>>>>>> > Jeff
>>>>>>>>>
>>>>>>>>>

--
http://www.freelists.org/webpage/oracle-l