Re: Backroom process tt00 top process

 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

> 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