From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Horizontal scalability/sharding |
Date: | 2015-09-01 18:11:21 |
Message-ID: | CA+TgmobquJziFm8nBUtF6hA9L_zMDxzq6_-jL-RTq2zpBysHFw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Sep 1, 2015 at 2:04 PM, Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
> Memory bandwidth, for example. It's quite difficult to spot, because the
> intuition is that memory is fast, but thanks to improvements in storage (and
> stagnation in RAM bandwidth), this is becoming a significant issue.
I'd appreciate any tips on how to spot problems of this type. But
it's my impression that perf, top, vmstat, and other Linux performance
tools will count time spent waiting for memory as CPU time, not idle
time. If that's correct, that wouldn't explain workloads where CPU
utilization doesn't reach 100%. Rather, it would show up as CPU time
hitting 100% while tps remains low.
> Process-management overhead is another thing we tend to ignore, but once you
> get to many processes all willing to work at the same time, you need to
> account for that.
Any tips on spotting problems in that area?
Thanks,
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2015-09-01 18:12:22 | Re: Proposal: Implement failover on libpq connect level. |
Previous Message | Robert Haas | 2015-09-01 18:07:19 | Re: Proposal: Implement failover on libpq connect level. |