Re: ideal CPU/Memory relation

From: Frits Hoogland <frits.hoogland_at_gmail.com>
Date: Fri, 19 Aug 2022 12:25:10 +0200
Message-Id: <749F82AA-9BF9-4D32-A01F-79B8D007023E_at_gmail.com>


There is no single ratio that is optimal for all use cases of any database. But that is the gist of what everybody else is saying here.

Be aware that most benchmarks typically are done for a single use case, and thus allow more to be sized with a fixed ratio, whilst in real life there is no single use case for a database, unless it's very specific (like Martin Klier mentioned).

In fact, I had a huge twitter discussion with the CTO of an OLTP database, where I stated that no real life database strictly is OLTP and not all queries are known and tuned. His persistent view was that 'for OLTP, all the queries are always known and completely tuned'. Oh the irony, as many on this list have been working on getting the issues that come from this solved for many years, and many years to come.

Frits

> On 19 Aug 2022, at 12:17, Stefan Koehler <contact_at_soocs.de> wrote:
>
> Hello Lothar,
> there are such databases like SAP HANA that use such an approach - quoting doc: "Using core-to-memory ratios which can be derived from the certified HANA listings. The memory requirement drives the number of cores required."
>
> ... but I guess you are using Oracle and never have seen such guidelines in the field until yet :-)
>
> Best Regards
> Stefan Koehler
>
> Independent Oracle performance consultant and researcher
> Website:
http://www.soocs.de
> Twitter: _at_OracleSK
>

>> Lothar Flatz <l.flatz_at_bluewin.ch> hat am 19.08.2022 09:02 CEST geschrieben:
>> 
>> 
>> Hi,
>> 
>> had somebody ever heard of a ideal CPU/Memory relation for a database
>> server?
>> A supplier of a customer stated such thing,
>> I suppose they made it up.
>> Any comments?
>> 
>> Thanks
>> 
>> Lothar
>> --
>> http://www.freelists.org/webpage/oracle-l

> --
> http://www.freelists.org/webpage/oracle-l
>
>
--
http://www.freelists.org/webpage/oracle-l
Received on Fri Aug 19 2022 - 12:25:10 CEST

Original text of this message