Server upgrade advice [xpost]

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Server upgrade advice [xpost]

Rory Campbell-Lange
Apologies for the cross-post to the general list. I realised I should
have (possibly?) posted here instead. Advice gratefully received.

We've been happy running a database server and replica for some years
with the following details and specs:

    postgres 9.5 (currently)
    supermicro X9DRD-7LN4F
    LSI Megaraid MR9261-8i with BBU
        250gb raid 1 /
        224gb raid 10 /db
    126GB RAM (1066Mhz DDR3)
    2 x Xeon E5-2609 v2 @ 2.5GHz

Services on the server are scaling up quite quickly, so we are running
out of disk space for the several hundred databases in the cluster.
While the disk space is fairly easy to solve, our main issue is CPU
hitting daily 5 minute peaks of 65% plus under load for complex plpgsql
queries, causing query backups. While we don't often spill queries to
disk, running out of RAM is an incipient problem too.

While we could split the cluster there are some management issues to do
with that, together with our having a policy of local and remote
replicas.

Consequently we're thinking of the following replacement servers:

    postgres 11 (planned)
    supermicro 113TQ-R700W
    LSI MegaRAID 9271-8i SAS/SATA RAID Controller, 1Gb DDR3 Cache (PCIE- Gen 3)
        500gb raid 1 /
        2tb raid 10 /db
        with "zero maintenance flash cache protection"
    256GB RAM (2666MHz DDR4)
    2x E5-2680 v4 Intel Xeon, 14 Cores, 2.40GHz, 35M Cache,

This configuration gives us lots more storage, double the RAM (with 8
slots free) and just under 4x CPU (according to passmark) with lots more
cores.

We're hoping to get two to three years of service out of this upgrade,
but then will split the cluster between servers if demand grows more
than we anticipate.

Any comments on this upgrade, strategy or the "zero maintenance" thingy
(instead of a BBU) would be much appreciated.

Rory

Reply | Threaded
Open this post in threaded view
|

Re: Server upgrade advice [xpost]

Ian Harding
The two major version upgrade will bring many happy returns.  That’s all I can contribute.

> On Mar 5, 2019, at 2:03 PM, Rory Campbell-Lange <[hidden email]> wrote:
>
> Apologies for the cross-post to the general list. I realised I should
> have (possibly?) posted here instead. Advice gratefully received.
>
> We've been happy running a database server and replica for some years
> with the following details and specs:
>
>    postgres 9.5 (currently)
>    supermicro X9DRD-7LN4F
>    LSI Megaraid MR9261-8i with BBU
>        250gb raid 1 /
>        224gb raid 10 /db
>    126GB RAM (1066Mhz DDR3)
>    2 x Xeon E5-2609 v2 @ 2.5GHz
>
> Services on the server are scaling up quite quickly, so we are running
> out of disk space for the several hundred databases in the cluster.
> While the disk space is fairly easy to solve, our main issue is CPU
> hitting daily 5 minute peaks of 65% plus under load for complex plpgsql
> queries, causing query backups. While we don't often spill queries to
> disk, running out of RAM is an incipient problem too.
>
> While we could split the cluster there are some management issues to do
> with that, together with our having a policy of local and remote
> replicas.
>
> Consequently we're thinking of the following replacement servers:
>
>    postgres 11 (planned)
>    supermicro 113TQ-R700W
>    LSI MegaRAID 9271-8i SAS/SATA RAID Controller, 1Gb DDR3 Cache (PCIE- Gen 3)
>        500gb raid 1 /
>        2tb raid 10 /db
>        with "zero maintenance flash cache protection"
>    256GB RAM (2666MHz DDR4)
>    2x E5-2680 v4 Intel Xeon, 14 Cores, 2.40GHz, 35M Cache,
>
> This configuration gives us lots more storage, double the RAM (with 8
> slots free) and just under 4x CPU (according to passmark) with lots more
> cores.
>
> We're hoping to get two to three years of service out of this upgrade,
> but then will split the cluster between servers if demand grows more
> than we anticipate.
>
> Any comments on this upgrade, strategy or the "zero maintenance" thingy
> (instead of a BBU) would be much appreciated.
>
> Rory
>