Re: Backroom process tt00 top process

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