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 >> >