Can you please post the utilisation graph of r5.24xlarge too?

Deepak
"The greatness of a nation can be judged by the way its animals are treated
- Mahatma Gandhi"

+91 73500 12833
deic...@gmail.com

Facebook: https://www.facebook.com/deicool
LinkedIn: www.linkedin.com/in/deicool

"Plant a Tree, Go Green"

Make In India : http://www.makeinindia.com/home


On Wed, Sep 7, 2022 at 3:08 PM Stamatis Zampetakis <zabe...@gmail.com>
wrote:

> Hi Laurence,
>
> It's hard to say just by seeing the graphs. Moreover Hive 2.3.1 is a quite
> old version so there are many things that may go wrong.
>
> I would suggest checking the logs and taking jstacks overtime and/or use a
> profiler (such as async-profiler[1]) to see what HS2 is actually doing
> while CPU usage grows.
>
> Best,
> Stamatis
>
> [1] https://github.com/jvm-profiling-tools/async-profiler
>
> On Mon, Sep 5, 2022 at 2:17 PM Laurence Brown via user <
> user@hive.apache.org> wrote:
>
>>
>>
>> Hi
>>
>> We’re using Hive 2.3.1, we recently migrated our production amazon EC2
>> instance types from r5.24xlarge to r6i.32xlarge
>>
>> on the r6 instance we have seen steady cpu usage growth that can all be
>> attributed to our org.apache.hive.service.server.HiveServer2
>>
>> Even when this change is unreleased and this process is going effectively
>> unused the CPU usage grows slowly until we restart that process
>>
>>
>>
>> In the attached graph you can see that CPU usage grows until we restart
>> HiveServer2 after that it remains stable for a while and then usage starts
>> growing on HiveServer2 .
>> After we restarted that process we failed back to our previous server
>> (leaving this server unused) but the CPU usage on HiveServer2 on this
>> server continue to grow
>>
>>
>>
>> We’ve since built instances in dev with both r5 and r6i  and all the r6i
>> instances have the above problem and all the r5 do not…..
>>
>> Does anyone have any idea why this might be?
>>
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------
>> This email and any attachment is confidential. If you are not the
>> intended recipient, please delete this message. Macquarie does not
>> guarantee the integrity of any emails or attachments. For important
>> disclosures and information about the incorporation and regulated status of
>> Macquarie Group entities please see: www.macquarie.com/disclosures
>>
>

Reply via email to