RE: Memory operations on Sun/Oracle M class servers vs T class servers
Date: Tue, 6 Jan 2015 16:03:30 +0000
Message-ID: <6837D1E9EB637E41AF54220483D53D377551EA57_at_exchm-omf-23.exelonds.com>
In case somebody is interested, here's the reply I've gotten from Oracle's hardware/OS guys. Essentially they're saying this is expected and we should rewrite the application to be multithreaded so it performs better. This is a 5 year old m5000 vs a brand new t52.
The speed of the application is dependent on the single thread throughput of the M5000 (32 threads on 8 2.150GHz SPARC64 cpus) vs. the T5-2 (256 threads on 2 3.600GHz SPARC-T5 cpus).
Effective single thread throughput of the M5000 is 538MHz and the T5-2 is 400MHz. That approximately accounts for what was observed.
This document may be helpful in understanding why the performance of a single threaded process is worse on the newer system:
Analyzing Performance of Chip Multi-Threading (CMT) Servers ( Doc ID 1343999.1 )
Thanks,
Finn
-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Jorgensen, Finn:(BSC)
Sent: Wednesday, December 17, 2014 12:51 PM
To: Oracle List List
Subject: RE: Memory operations on Sun/Oracle M class servers vs T class servers
Thanks to Tanel, Stefan and Mark for their replies. The explanation of what the EXEC call covers helps a lot in understanding this issue.
I was aware of the "original" design goal of the T series servers/CPU's as I've worked with the sucky T5220/T5240's for far too long. However, my impression from the server group at my company was that the T5's solved these issues. It would appear that is not completely true. They may have gotten better at masking and hiding the issues but they are not resolved.
What blows my mind is that a database company chooses to abandon one CPU architecture (The SPARC processors produced by Fujitsu) in favor of something that works worse for their core business, which is databases. You simply cannot buy servers from Oracle anymore with SPARC CPU's in them. You can buy a Fujitsu server with SPARC X/X+ CPU's called M10-4 which runs Solaris but nothing from Oracle.
Thanks,
Finn
-----Original Message-----
From: Stefan Koehler [mailto:contact_at_soocs.de]
Sent: Wednesday, December 17, 2014 5:13 AM
To: Jorgensen, Finn:(BSC)
Cc: Oracle List List
Subject: Re: Memory operations on Sun/Oracle M class servers vs T class servers
Hi Finn,
in addition to Tanel's awesome reply.
The current SCN is assigned to the cursor in the EXEC phase as well, which results in (fixed) SGA memory access (variable kcsgscn_) for each EXEC call.
P.S.: I stumbled across this M- and T-series stuff round about one year ago as well, while doing a database migration from Sun Solaris (SPARC) to Sun Solaris (x86) as the production was running on T-series and the export was much much slower. I was told (as i am not very familiar with the SUN CPU architecture) that the T-series was not designed for single thread performance, but for short parallel requests like a typical load with web sites. This description is covered now by Tanel's great CPU explanation.
Best Regards
Stefan Koehler
Oracle performance consultant and researcher
Homepage: http://www.soocs.de
Twitter: @OracleSK
> Tanel Poder <tanel_at_tanelpoder.com> hat am 17. Dezember 2014 um 03:55 geschrieben:
>
> And reading your original email all the way to the end - depending on
> the exec plan the FETCH part may be the easy part - EXEC for example
> needs to pin the cursor, put binds in place in memory, walks through the execution plan "initializes" various row sources that may mean memory allocation (but for SELECTs, the actual plan execution and row production starts in FETCH)...
>
> So, can't assume that EXEC is less memory intensive than a 4 logical IO-doing fetch that follows it.
>
> Tanel
>
This e-mail and any attachments are confidential, may contain legal, professional or other privileged information, and are intended solely for the addressee. If you are not the intended recipient, do not use the information in this e-mail in any way, delete this e-mail and notify the sender. -EXCIP i 0 zX + n { +i ^ †Ûiÿü0ÁúÞzX¬¶Ê+ƒü n– {ú+iÉ^ Received on Tue Jan 06 2015 - 17:03:30 CET