Tuesday Mar 18, 2014

What compiler options were used to create an executable?


Not stripped:

$ cc -O hello.c

$ file a.out

a.out: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, dynamically linked, not stripped

$ strings -a a.out | grep cc

/opt/solarisstudio12.3/prod/bin/cc -O hello.c

$ dwarfdump -i a.out | grep compile_o

DW_AT_SUN_compile_options Xa;O;R=Sun C 5.12 SunOS_sparc Patch 148917-07 2013/10/18;backend;raw;cd;

Stripped:

$ strip a.out

$ file a.out

a.out: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, dynamically linked, stripped

$ strings -a a.out | grep cc

(none)

Friday Jan 24, 2014

Redo Log Switches

In Gathering Database Statistics in a Test Harness I said that use of the Automatic Workload Repository (AWR) is fundamental to understanding Oracle Database performance.

When I finished the scripts for the blog and ran the first test run, the AWR report was quite clear: I need to increase the size of the redo logs:

Report Summary

Top ADDM Findings by Average Active Sessions

Finding Name Avg active sessions of the task Percent active sessions of finding Task Name Begin Snap Time End Snap Time
Top SQL Statements 1.00 80.56 ADDM:1351308822_1_2046 24-Jan-14 11:36 24-Jan-14 11:42
Log File Switches 1.00 5.38 ADDM:1351308822_1_2046 24-Jan-14 11:36 24-Jan-14 11:42


Instance Activity Stats - Thread Activity

  • Statistics identified by '(derived)' come from sources other than SYSSTAT
Statistic Total per Hour
log switches (derived) 13 126.78

Finding 2: Log File Switches
Impact is .05 active sessions, 5.38% of total activity.
-------------------------------------------------------
Log file switch operations were consuming significant database time while
waiting for checkpoint completion.
This problem can be caused by use of hot backup mode on tablespaces.  DML to
tablespaces in hot backup mode causes generation of additional redo.

...

   Recommendation 2: Database Configuration
   Estimated benefit is .05 active sessions, 5.38% of total activity.
   ------------------------------------------------------------------
   Action
      Increase the size of the log files to 1552 M to hold at least 20 minutes
      of redo information.

Original log files and groups:

SQL> select GROUP#,THREAD#,BYTES from v$log;

    GROUP#    THREAD#      BYTES
---------- ---------- ----------
     1         1        52428800
     2         1        52428800
     3         1        52428800

SQL> select MEMBER from v$logfile;

MEMBER
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/orcl/redo03.log
/u01/app/oracle/oradata/orcl/redo02.log
/u01/app/oracle/oradata/orcl/redo01.log

Create new ones:

SQL > ALTER DATABASE
  ADD LOGFILE GROUP 4 ('/u01/app/oracle/oradata/orcl/redo04.log')
      SIZE 5G;

SQL> ALTER DATABASE
  ADD LOGFILE GROUP 5 ('/u01/app/oracle/oradata/orcl/redo05.log')
      SIZE 5G;

SQL> ALTER DATABASE
  ADD LOGFILE GROUP 6 ('/u01/app/oracle/oradata/orcl/redo06.log')
      SIZE 5G;

Drop the old one:

SQL> ALTER SYSTEM SWITCH LOGFILE;
SQL> ALTER SYSTEM SWITCH LOGFILE;
SQL> ALTER DATABASE DROP LOGFILE GROUP 1;
SQL> ALTER DATABASE DROP LOGFILE GROUP 2;
ERROR at line 1:
ORA-01624: log 2 needed for crash recovery of instance orcl (thread 1)
ORA-00312: online log 2 thread 1: '/u01/app/oracle/oradata/orcl/redo02.log'

SQL> ALTER DATABASE DROP LOGFILE GROUP 3;

SQL> alter system checkpoint;
SQL> ALTER DATABASE DROP LOGFILE GROUP 2;

(Dropping group 2 is OK after checkpoint)


Done:

SQL> select GROUP#,THREAD#,BYTES from v$log;

    GROUP#    THREAD#       BYTES
---------- ---------- ----------
     4          1     5368709120
     5          1     5368709120
     6          1     5368709120

Tuesday Apr 14, 2009

Algorithmics Financial Risk Management Software on the Sun Fire X4270


For the past several months, I've been slaving over a new server powered by Intel® Xeon® 5500 Series processors.  I have been using the system to investigate the characteristics of Algorithmics' Risk Analysis application, and I've found that the new server and the Solaris OS run great.  Solaris lets you take advantage of all the great new features of these new CPUs such as TurboBoost and HyperThreading. The big takeaway is that the new version of Algo's software really benefits from the new CPU: this platform runs faster than the other Solaris systems I've tested.

If you don't know Algorithmics, their software analyzes the risk of financial instruments, and financial institutions are using it to help keep the current financial meltdown from worsening. Algo is used by banks and financial institutions in 30 countries. I'm part of the team at Sun that has worked closely with Algorithmics to optimize performance of Algorithmics' risk management solutions on Sun Fire servers running Solaris.

Algo's software has a flexible simulation framework for a broad class of financial instruments.  SLIMs are their newest generation of very fast simulation engines. Different SLIMs are available to simulate interest rate products (swaps, FRAs, bonds, etc.), CDSs and some option products. The simulation performance with the new SLIMs is spectacular.

 Solaris provides everything that is required for Algo to take advantage of the new server line's performance and energy efficiency:
  • Sun Studio Express has been optimized to generate efficient SIMD instructions
  • ZFS provides the high performance I/O
  • Hyperthreading:  Solaris can easily take advantage of the heavily threaded architecture.
  • Turbo Boost.  Yes, it kicks in immediately when a SLIM is launched
  • QuickPath chip-to-chip interconnect.  Solaris is NUMA aware.


 Here are the answers to some questions that you may have about SLIMs on Solaris and the Xeon® Processor 5570:

 Q: Are SLIMs I/O bound or CPU bound?
 A: SLIM's require both the computational and the I/O subsystem to be excellent.  For the data sets that have been provided by Algo running on the X4270 with ZFS striped over 12 internal hard drives, results vary.  The majority of the SLIMs are CPU bound, but a few are I/O bound.  

 Q: What are the computational characteristics of SLIM's running on the X4270?
 A: The number of threads to be used are specified by the user.  Most of the SLIM's scale well up to 8 threads and some scale all the way up to 16 threads.  SLIM's that don't scale to 16 threads on the X4270 with internal hard drives are primarily I/O bound and benefit from even faster storage. (Hint: check this Algo blog again in the future for more discussion regarding faster I/O devices.) 

 Q: What are the I/O characteristics of SLIM's running on the X4270 with ZFS?
 A: The I/O pattern of SLIMs is large block sequential write.  ZFS caches the writes and flushes the cache approximately once every 10 seconds.  Each hard drive hits peaks of 80 MB/second.  With 12 striped internal hard drives, the total system throughput can reach close to 1.0 GB/second. 

 Q: Is external storage required for SLIMs?
 A: 14 internal drives (plus 2 for mirrored OS disks) at 146GB each can hold a data set upwards of 1.7TB.  If your data fits, internal drives will be a cost effective solution.

 Q: Is hardware RAID required for the SLIMs data.  Background:  RAID can potentially fulfill needs including (a) Striping to creating larger storage units from smaller disks, and (b) data redundancy so that you don't loose important data.  (c) Hardware RAID can increasing I/O performance via cacheing and fast checksum block computation.  
 A: No, hardware RAID is not required.  (a) ZFS has a full range of RAID capabilities.   (b) The cube of data produced by SLIMs is normally considered to be temporary data that can be recalculated if necessary,  and therefore redundancy is not required.  (c) If redundancy is required for your installation, RAID-Z has been shown to have a negligible impact on SLIMs' I/O performance. The SLIM's write intensive I/O pattern will blow through cache and be bound by disk write performance, so there is no advantage to adding an additional layer of cache.

 Q: Algo often recommends using Direct I/O filesystems instead of buffering.  Should we use Direct I/O with ZFS?
 A: No.  All ZFS I/O is buffered.  Based on comparisons against QFS with Direct I/O enabled, ZFS is recommended.

 Q: In some cases ZFS performance can be improved by disabling ZIL or by putting ZIL on on a faster device in a ZFS hybrid storage pool.  Does it help SLIMs performance?
 A: No. SLIMs' I/O is not synchronous. SSD for ZIL will not improve SLIMs' performance when writing to direct attached storage.

 Q: Is the use of Power Management recommended?
 A: Yes.   PowerTOP was used to enable and monitor the CPU power management.  When the machine is idle, power is reduced.  When SLIM's are executing, the CPU's quickly jumps into TurboBoost mode.  There was no significant performance difference between running SLIM's with and without power management enabled.

Q: The Sun Fire X4270 DDR3 memory can be configured to run at 800MHz, 1066MHz or 1333MHz.  Does the DDR3 speed effect SLIMs performance?
A: Yes, several of the SLIMs (but not all) run better on systems configured to run DDR3 at 1333MHz.

Q: Would it be better to deploy SLIMs on a blade server (like the X6275 Server Module) or a rack mounted server (like the X4270).
A: Again, the answer resolves around storage.  If the SLIMs time series data fits onto the internal disk drives, the rack mounted server will be a cost effective solution.  If your time series data is greater than 1.5 TB, it will be necessary to use external storage, and the blade server will a more cost effective solution. 



 Platform tested:

     \* Sun Fire X4270 2RU rack-mount server
     \* 2 Intel® Xeon® Processor 5500 Series CPU's
     \* 14 -  146GB 10K RPM disk drives
           o 2 for the operating system
           o 12 for data storage
           o 2 empty slots
     \* Memory configurations ranged from 24GB to 72GB

About

user12620111

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today