| From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
|---|---|
| To: | David Boreham <david_list(at)boreham(dot)org> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Why facebook used mysql ? |
| Date: | 2010-11-10 00:05:03 |
| Message-ID: | AANLkTikrUGMHfdUvH05c8Dffytn8FAXFg=E_mD4=fdT7@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Tue, Nov 9, 2010 at 4:12 PM, David Boreham <david_list(at)boreham(dot)org> wrote:
>
> I don't think you should be looking at process partitioning and core
> affinity unless you have already proved that
> you have processes that don't scale over the cores you have, to deliver the
> throughput you need.
Note that you're likely to get FAR more out of processor affinity with
multiple NICs assigned each to its own core / set of cores that share
L3 cache and such. Having the nics and maybe RAID controllers and /
or fibre channel cards etc on their own set of cores in one group can
make a big difference.
Processor affinity doesn't seem to make much difference for me with
pgsql. Modern linux schendulers are pretty good at keeping things on
the same core for a while without predefined affinity.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Boreham | 2010-11-10 00:21:26 | Re: Why facebook used mysql ? |
| Previous Message | Merlin Moncure | 2010-11-10 00:03:36 | Re: Thoughts on a surrogate key lookup function? |