Hey,
So I finally found the culprit. Turns out to be the THP fighting with
itself.
After running on Ubuntu
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
It instantly went from a loadavg of 30 to 3
Also make sure you re-enable on
On Wed, Feb 27, 2019 at 5:01 PM Michael Lewis wrote:
> If those 50-100 connections are all active at once, yes, that is high.
>> They can easily spend more time fighting each other over LWLocks,
>> spinlocks, or cachelines rather than doing useful work. This can be
>> exacerbated when you have m
Alright will try the upgrade.
> Is it a few transactions updating a lot of rows each, or many transactions
> updating a few rows each?
It is a lot of transaction updating a few rows.
Then will look into a connection pooler.
Thanks for the response.
On Wed, Feb 27, 2019 at 2:01 PM Michael Lewis
>
> If those 50-100 connections are all active at once, yes, that is high.
> They can easily spend more time fighting each other over LWLocks,
> spinlocks, or cachelines rather than doing useful work. This can be
> exacerbated when you have multiple sockets rather than all cores in a
> single sock
On Wed, Feb 27, 2019 at 2:07 PM Scottix wrote:
> Hi we are running a Postgresql Database 9.4.18 and we are noticing a
> high CPU usage. Nothing is critical at the moment but if we were to
> scale up more of what we are doing, I feel we are going to run into
> issues.
>
9.4 is old. A lot of impro
Hi we are running a Postgresql Database 9.4.18 and we are noticing a
high CPU usage. Nothing is critical at the moment but if we were to
scale up more of what we are doing, I feel we are going to run into
issues.
It is a 2 x 6 core machine, 128GB ram, Raid 10 HDD
The iostat metrics for the HDD lo
