Quick Fix to the Linker Error - ld: fatal: library -lgcc_s: not found

Symptom(s):

When building some of the open source applications like MySQL Cluster Carrier Grade Edition with the GCC compiler, the linking step may fail with the fatal error message library -lgcc_s: not found despite the fact that the gcc_s library is available on the system and is in the linker search path -- for example, LD_LIBRARY_PATH on Solaris.

Quick Fix / Workaround:

1. Add the absolute path to the gcc_s library on the link line, OR
   
   
2. (Recommended) If the library's filename has any major and minor version numbers appended to it, simply create a soft link to the library in the same location without the major and minor version numbers in the target filename.

eg.,

On a Solaris 10 system, by default, the gcc_s library might be available under /usr/sfw/lib (32-bit SPARC and x86 copy), /usr/sfw/lib/sparcv9 (64-bit SPARC copy) and /usr/sfw/lib/amd64 (64-bit x64 copy). If all you can find is the gcc_s library with the version number(s) in the filename like libgcc_s.so.1, simply run the command 'ln -s libgcc_s.so.1 libgcc_s.so' in the same directory where you found the libgcc_s.so.1.

Note:

Probably this particular error message may show up on any OS platform with any compiler, and the workaround mentioned in this post may work on all those failed cases. I cannot guarantee that, but I know for sure that it works on Solaris (both SPARC and x86/x64 versions).

_______________
Technorati Tags:
Linker | Linking | Troubleshooting

Read More

Consolidating Siebel CRM 8.0 on a Single Sun SPARC Enterprise Server, T5440

.. blueprint document is now available on wikis.sun.com. Here is the direct link to the blueprint:
            Consolidating Oracle Siebel CRM 8 on a Single Sun SPARC Enterprise Server.

Siebel 8.0 Platform Sizing and Performance Program (PSPP) benchmark workload was used in running all the performance tests using Solaris Containers and Logical Domains (LDoms) on a single Sun SPARC Enterprise T5440 server running Solaris 10 5/08 (containers) and 10/08 (LDoms). The focus of the blueprint is around 3 major configurations -- performance numbers at 3500 users (small configuration), 7000 users (medium configuration) and 14000 user (large configuration) loads. Hence this blueprint document complements the 14,000 user Siebel 8.0 benchmark that we published earlier back in October 2008.

The blueprint has details around the resource allocations for all the tiers of a typical Siebel deployment to support 3500, 7000 and 14000 concurrent users, offers performance tuning tips that are specific to Solaris and Sun CMT systems, and shows the results from the 3500, 7000 and 14000 user performance tests using Solaris 10's virtualization technologies - Solaris Containers and the Logical Domains.

Notes:

1. All the performance tests were conducted either with Solaris Containers or with the Logical Domains, but not with a mix of both of those technologies.
   
   
2. Resource allocations were identical in both cases -- that is, with the Solaris Containers and the Logical Domains.

(Originally posted on blogs.sun.com at:
http://blogs.sun.com/mandalika/entry/consolidating_siebel_crm_8_0)
_______________
Technorati Tags:
Sun| Solaris | Oracle| Siebel | CRM | T5440| UltraSPARC | Consolidation

Read More

Yet Another Siebel 8.0 PSPP Benchmark on Sun CMT Hardware ..

.. Sun SPARC Enterprise T5240.

(This blog entry also serves as a summary page for all the Siebel 8.0 benchmarks that Sun published so far.)

On November 14, 2008 Sun published a brand new 10,000 user Siebel 8.0 benchmark result using a combination of T5240 and T5120 servers. In this benchmark, a Sun SPARC Enterprise T5240 server equipped with two 1.2 GHz, 8-Core UltraSPARC T2 Plus processors served as the system under test on which we ran the Siebel Gateway and Enterprise application servers. Two Sun SPARC Enterprise T5120 servers equipped with one 1.2 GHz, 8-Core UltraSPARC T2 processor were configured to run the Oracle database and the Sun Java System Web servers.

A copy of the latest benchmark publication is available on Oracle Applications' benchmark web site at:
        Siebel CRM Release 8.0 Industry Applications and Oracle 10g R2 DB on Sun SPARC Enterprise T5120 & T5240 servers running Solaris 10

For some reason, the topology diagram in the benchmark publication document was messed up esp. the fonts -- probably the odt -> doc -> pdf conversion. The clean copy of the diagram is shown below.



Significance of the Siebel 8.0 on T5240 benchmark

In case if anyone wonder why do we need another Siebel 8.0 benchmark on CMT hardware esp. when we already published couple of Siebel 8.0 benchmarks on T5220 and T5440 systems -- 10,000 users on T5120/T5220 and 14,000 users on T5440, the answer is simple: to show linear scalability.

In the first benchmark that Sun published in January 2008, we showed the scalability of the application, Siebel, on T5220 systems. We were able to scale up to 5,000 concurrent users on a single T5220 system (running the Siebel application servers) with 1.2 GHz, 8-Core US-T2 processor. We've used two such systems to publish the 10,000 user benchmark in the first installment.

The goal of the second benchmark that we published in October 2008 during the T5440 server launch showcases how to consolidate multiple workloads on a T5440 server. We demonstrated it by deploying the whole Siebel Enterprise -- Sun Java System Web Server along with the Siebel Web Server plug-in Siebel Web Engine (SWE), Siebel Gateway Server, Siebel Application Server and the Oracle Database Server -- on a single Sun SPARC Enterprise T5440 server equipped with four 1.4 GHz, 8-Core UltraSPARC T2 Plus processors. We ran 14,000 concurrent virtual users against this setup to make it a benchmark publication. Since we ran all tiers of Siebel Enterprise on the same box, it is hard to compare the scalability numbers from this benchmark against the numbers that we published in the 10,000 user benchmark on T5120/T5220 servers.

In April 2008, Sun has launched the first multi-processor CMT system, Sun SPARC Enterprise T5240. T5240 holds two UltraSPARC T2 Plus processors, and is supposed to exhibit 2x performance[1] as that of a T5220. In other words, two T5220 servers can be consolidated onto a single T5240. To prove this, we re-ran the 10,000 user benchmark that we published back in January 2008 by replacing the two T5220 servers in the application tier with a T5240 server, and keeping the remaining hardware configuration for the web and database servers intact. The results from this benchmark speak for themselves - but for your convenience here is the quick summary of the results.

#users	#units x Server Model	Business Transactions Throughput/hour	Projected Daily Transactions	Benchmark Publication URL & Date
10,000	2 x T5220	142,061	1,136,488	10K/T5220, 01/2008
10,000	1 x T5240	141,205	1,129,640	10K/T5240, 11/2008

If you are a Sun-Oracle customer, make sure to check the Siebel on Sun CMT hardware : Best Practices web page for some useful tips.

Related entries:

1. Siebel 8.0 on Sun SPARC Enterprise T5440 - More Bang for the Buck!!
   
2. Sun publishes 10,000 user Siebel 8.0 PSPP benchmark on Niagara 2 systems
   
3. Siebel CRM 8.0 PSPP UltraSPARC T2 beats POWER6 and sets World Record
   

---

[1] There is no unique definition for the word 'performance' -- it has different meanings based on the context.

(Originally published on blogs.sun.com at:
http://blogs.sun.com/mandalika/entry/yet_another_siebel_8_0)

_______________
Technorati Tags:
Sun| Solaris | Oracle| Siebel | CRM | T5240| UltraSPARC | Benchmark

Read More

Ramifications of the Solaris 10 kernel patch 137111

Summary

A recent code change in Solaris 10 inadvertantly exposed an inherent bug in some of the 32-bit applications that rely on their own memory allocators. Due to this, some of the 3rd party applications which were working earlier without the KU 137111 may crash on Solaris 10/SPARC with the KU 137111 (any revision).

Symptoms & the Cause

It was identified that majority of such application failures are mainly due to the applications' custom memory allocator that incorrectly returns 4-byte aligned mutexes in place of the required 8-byte aligned mutexes. In Solaris, mutex_t and pthread_mutex_t structures have been defined to be aligned on an 8-byte boundary. Both of those structures contain the upad64_t member, which is a double even for the 32-bit applications. The natural alignment of a double is 8 bytes; and per the SPARC Compliance Definition 2.4, the structures must be aligned according to their strictest member. That is, applications which create 4-byte aligned mutexes are technically non-compliant on Solaris/SPARC (for the sake of simplicity, such code will be referred to as the non-complying code for the remainder of this blog entry).

Due to a change in the implementation of the userland mutexes introduced by CR 6296770 in KU 137111-01, objects of type mutex_t and pthread_mutex_t must start at 8-byte aligned addresses. If this requirement is not satisfied, all non-compliant applications on Solaris/SPARC may fail with the signal SEGV with a callstack similar to the following one or with similar callstacks containing the function mutex_trylock_process.

  *_atomic_cas_64(0x141f2c, 0x0, 0xff000000, 0x1651, 0xff000000, 0x466d90)
  set_lock_byte64(0x0, 0x1651, 0xff000000, 0x0, 0xfec82a00, 0x0)
  fast_process_lock(0x141f24, 0x0, 0x1, 0x1, 0x0, 0xfeae5780)
  ...

Patches & the Next Steps

Note that only non-compliant 32-bit applications will be affected by the KU 137111. All other complying 32-bit applications continue to run as expected even with the KU 137111 - hence the customers, partners, ISVs and the other software vendors must understand the fact that it is not a Solaris issue. Customers running into this issue must work with the respective software vendors to obtain a patch/fix. We suggest the ISVs and the rest of the software vendors to pro-actively check their 32-bit native code for any discrepancies like the one mentioned in this blog entry.

In our testing of some of the enterprise applications, we have identified Oracle's Siebel CRM as one of the potential applications that is vulnerable to the KU 137111. It appears that IBM's Lotus Domino Server is also prone to a crash on Solaris 10 with the same kernet patch. Speaking of these two known cases, Oracle/Siebel and IBM/Lotus Domino customers (running Solaris) should approach Oracle and IBM Corporations respectively but not Sun Microsystems for a proper fix.

As it may take some time for the ISVs / software vendors to identify and fix the non-complying code in their applications, Sun is planning to provide an interim fix to the mutex byte alignment issue in the form of a Solaris kernel patch. As of this writing, we expect the fix to be integrated into the KU 137137-07. The fix is already available in the latest update of the Solaris, Solaris 10 10/08. Those who cannot upgrade to Solaris 10 10/08 from the prior versions of Solaris 10 must wait for the patch KU 137137-07.

One must note that the fix in Solaris is a tentative one that allows the non-complying code to run on SPARC hardware for the time being. There is no guarantee that the non-complying code continues to run 'as is' in the future with new Solaris kernel patches and/or major updates/releases of the Solaris operating system. So the best long term solution is for the software vendors to fix the non-compliant code before it is too late.

Acknowledgments

Steve S and Roger F of Sun Microsystems.

(Originally posted at:
http://blogs.sun.com/mandalika/entry/ramifications_of_the_solaris_10)
________________
Technorati Tags:
Sun | Solaris | Kernel Patch | Oracle | Siebel | IBM | Lotus Domino

Read More

Siebel on Sun CMT hardware : Best Practices

The following suggested best practices are applicable to all Siebel deployments on CMT hardware (Tx00, T5x20, T5x40) running Solaris 10 [Note: some of this tuning applies to Siebel running on conventional hardware running Solaris]. These recommendations are based on our observations from the 14,000 user benchmark on Sun SPARC Enterprise T5440. Your mileage may vary.

All Tiers

• Ensure that the system's firmware is up-to-date.
  
  
  Check the Sun System Firmware Release Hub for the latest firmware.
  
  
  
• Upgrade to the latest update release of Solaris 10.
  
  
  Note to the customers running Siebel on Solaris 5/08: apply the kernel patch 137137-07 as soon as it is available on sunsolve.sun.com web site. Patch 137137-07 and later revisions, Solaris 10 10/08 will have the workaround to a critical Siebel specific bug. Oracle Corporation will eventually fix the bug in their codebase - in the meantime Solaris is covering for Siebel and all other 32-bit applications with their own memory allocators that return unaligned mutexes. Check the RFE 6729759 Need to accommodate non-8-byte-aligned mutexes and Oracle's Siebel support document 735451.1 Do NOT apply Kernel Patch 137111-04 on Solaris 10 for more details.
  
  
  
• Enable 256M large pages on all nodes. By default, the latest update of Solaris 10 will use a maximum of 4M pages even when 256M pages are a good fit.
  
  
  256M pages can be enabled with the following /etc/system tunable.

  * 256M pages
  set max_uheap_lpsize=0x10000000

  
  
• Pro-actively avoid running into stdio's 256 file descriptors limitation.
  
  
  Set the following in a shell or add the following lines to the shell's profile (bash/ksh).

  ulimit -n 2048
  export LD_PRELOAD_32=/usr/lib/extendedFILE.so.1:$LD_PRELOAD_32

  Technically the file descriptor limit can be set to as high as 65536. However from the application's perspective, 2048 is a reasonable limit.
  
  
  
• Improve scalability with MT-hot memory allocation library, libumem or libmtmalloc.
  
  To improve the scalability of the multi-threaded workloads, preload MT-hot object-caching memory allocation library like libumem(3LIB), mtmalloc(3MALLOC).
  
  
  eg., To preload the libumem library, set the LD_PRELOAD_32 environment variable in the shell (bash/ksh) as shown below.

  export LD_PRELOAD_32=/usr/lib/libumem.so.1:$LD_PRELOAD_32

  Web and the Application servers in the Siebel Enterprise stack are 32-bit. However Oracle 10g or 11g RDBMS on Solaris 10 SPARC is 64-bit. Hence the path to the libumem library in the PRELOAD statement differs slightly in the database-tier as shown below.

  export LD_PRELOAD_64=/usr/lib/sparcv9/libumem.so.1:$LD_PRELOAD_64

  
  Be aware that the trade-off is the increase in memory footprint -- you may notice 5 to 20% increase in the memory footprint with one of these MT-hot memory allocation libraries preloaded. Also not every Siebel application module benefits from MT-hot memory allocators. The recommendation is to experiment before implementing in production environments.
  
  
• TCP/IP tunables
  
  Application fared well with the following set of TCP/IP parameters on Solaris 10 5/08.
  

  ndd -set /dev/tcp tcp_time_wait_interval 60000
  ndd -set /dev/tcp tcp_conn_req_max_q 1024
  ndd -set /dev/tcp tcp_conn_req_max_q0 4096
  ndd -set /dev/tcp tcp_ip_abort_interval 60000
  ndd -set /dev/tcp tcp_keepalive_interval 900000
  ndd -set /dev/tcp tcp_rexmit_interval_initial 3000
  ndd -set /dev/tcp tcp_rexmit_interval_max 10000
  ndd -set /dev/tcp tcp_rexmit_interval_min 3000
  ndd -set /dev/tcp tcp_smallest_anon_port 1024
  ndd -set /dev/tcp tcp_slow_start_initial 2
  ndd -set /dev/tcp tcp_xmit_hiwat 799744
  ndd -set /dev/tcp tcp_recv_hiwat 799744
  ndd -set /dev/tcp tcp_max_buf  8388608
  ndd -set /dev/tcp tcp_cwnd_max  4194304
  ndd -set /dev/tcp tcp_fin_wait_2_flush_interval 67500
  ndd -set /dev/udp udp_xmit_hiwat 799744
  ndd -set /dev/udp udp_recv_hiwat 799744
  ndd -set /dev/udp udp_max_buf 8388608

Siebel Application Tier

• All T-series systems (T1000/T2000, T5120/T5220, T5120/T5240, T5440) support the 256M page size. However Siebel's siebmtshw script restricts the page size to 4M. Comment out the following lines in $SIEBEL_HOME/siebsrvr/bin/siebmtshw.
  

  # This will set 4M page size for Heap and 64 KB for stack
  MPSSHEAP=4M
  MPSSSTACK=64K
  MPSSERRFILE=/tmp/mpsserr
  LD_PRELOAD=/usr/lib/mpss.so.1
  export MPSSHEAP MPSSSTACK MPSSERRFILE LD_PRELOAD

  
  
• Experiment with less number of Siebel Object Managers.
  
  
  Configure the Object Managers in such a way that each OM will be handling at least 200 active users. Siebel's standard recommendation of 100 or less users per Object Manager is suitable for conventional systems but not ideal for CMT systems like Tx000, T5x20, T5x40, T5440. Sun's CMT systems are ideal for running multi-threaded processes with tons of LWPs per process. Besides, there will be significant improvement in the overall memory footprint with less number of Siebel Object Managers.
  
  
  
• Try Oracle 11g R1 client in the application-tier. Oracle 10g R2 clients may crash under high load. For the symptoms of the crash, check Solaris/SPARC: Oracle 11gR1 client for Siebel 8.0.
  
  
  Oracle 10g R2 10.2.0.4 32-bit client is supposed to have a fix for the process crash issue - however it wasn't verified in our test environment.

Siebel Database Tier

• Eliminate double buffering by forcing the file system to use direct I/O.
  
  Oracle database caches the data in its own cache within the shared global area (SGA) known as the database block buffer cache. Database reads and writes are cached in block buffer cache so the subsequent accesses for the same blocks do not need to re-read the data from the operating system. On the other hand, file systems on Solaris default to reading the data though the global file system cache for improved I/O operations. That is, by default each read is cached potentially twice - one copy in the operating system's file system cache, and the other copy in Oracle's block buffer cache. In addition to double caching, there is also some extra CPU overhead for the code which manages the operating system's file system cache. The solution is to eliminate double caching by forcing the file system to bypass the OS file system cache when reading and writing to the disk.
  
  
  In the 14,000 user benchmark setup, the UFS file systems (holding the data files and the redo logs) were mounted with the forcedirectio option.
  eg.,

  mount -o forcedirectio /dev/dsk/<partition> <mountpoint>

  
  
• Store data files separate from the redo log files -- If the data files and the redo log files are stored on the same disk drive and if that disk drive fails, the files cannot be used in the database recovery procedures.
  
  
  In the 14,0000 user benchmark setup, there are two Sun StorateTek 2540 arrays connected to the T5440 - one array was holding the data files, where as the other was holding the Oracle redo log files.
  
  
• Size online redo logs to control the frequency of log switches.
  
  
  In the 14,0000 user benchmark setup, two online redo logs were configured each with 10 GB disk space. When all 14,000 concurrent users are on-line, there is only one log switch in a 60 minute period.
  
  
  
• If the storage array supports the read-ahead feature, enable it. When 'read-ahead enabled' is set to true, the write will be committed to the cache as opposed to the disk, and the OS signals the application that the write has been committed.
  
  Oracle Database Initialization Parameters
  
  
• Set Oracle's initialization parameter DB_FILE_MULTIBLOCK_READ_COUNT to appropriate value. DB_FILE_MULTIBLOCK_READ_COUNT parameter specifies the maximum number of blocks read in one I/O operation during a sequential scan.
  
  
  In the 14,0000 user benchmark configuration, DB_BLOCK_SIZE was set to 8 kB. During the benchmark run, the average reads are around 18.5 kB per second. Hence setting DB_FILE_MULTIBLOCK_READ_COUNT to a high value does not necessarily improve the I/O performance. A value of 8 for the database init parameter DB_FILE_MULTIBLOCK_READ_COUNT seems to perform better.
  
  
  
• On T5240 and T5440 servers, set the database initialization parameter CPU_COUNT to 64. Otherwise, by default Oracle RDBMS assumes 128 and 256 for the CPU_COUNT on T5240 and T5440 respectively. Oracle's optimizer might use a completely different execution plan when it notices such a large number for the CPU_COUNT; and the resulting execution plan need not necessarily be an optimal one. In the 14,000 user benchmark, setting CPU_COUNT to 64 produced optimal execution plans.
  
  
• On T5240 and T5440 servers, explicitly set the database initialization parameter _enable_NUMA_optimization to FALSE. On these multi-socket servers, _enable_NUMA_optimization will be set to TRUE by default. During the 14,000 user benchmark run, we noticed intermittent shadow process crashes with the default behavior. We didn't realize any additional gains either with the default NUMA optimizations.

Siebel Web Tier

• Upgrade to the latest service pack of Sun Java Web Server 6.1 (32-bit).
  
  
• Run the Sun Java Web Server in multi-process mode by setting the MaxProcs directive in magnus.conf to a value that is greater than 1. In the multi-process mode, the web server can handle requests using multiple processes with multiple threads in each process.
  
  
  When you specify a value greater than 1 for the MaxProcs, the web server relies on the operating system to distribute connections among/between multiple web server processes. However many modern operating systems including Solaris do not distribute connections evenly, particularly when there are a small number of concurrent connections.
  
  
• Tune the maximum simultaneous requests by setting the RqThrottle parameter in the magnus.conf file to appropriate value. A value of 1024 was used in the 14,000 user benchmark.

(Originally posted at: http://blogs.sun.com/mandalika/entry/siebel_on_sun_cmt_hardware) _______________ Technorati Tags: Sun| Solaris | Oracle| Siebel | CRM | UltraSPARC | CMT | Best Practices | Performance Tuning

Read More

Siebel 8.0 on Sun SPARC Enterprise T5440 - More Bang for the Buck!!

Recently Sun announced the 14,000 user Siebel 8.0 PSPP benchmark results on a single Sun SPARC Enterprise T5440. An Oracle white paper with Sun's 14,000 user benchmark results is available on Oracle's Siebel benchmark web site. The content in this blog post complements the benchmark white paper.

Some of the notes and highlights from this competitive benchmark are as follows:

• Key specifications for the Sun SPARC Enterprise T5440 system under test, are: 4 x UltraSPARC T2 Plus processors, 32 cores, 256 compute threads and 128 GB of memory in a 4RU space.
  
  
• The entire Siebel 8.0 solution was deployed on a single Sun SPARC Enterprise T5440 including the web, gateway, application, and database servers.
  
  
  9 load driver clients with dual-core Opteron and Xeon processors were used to load up 14,000 concurrent users
  
  
• Web, Application and the Database servers were isolated from each other by creating three Solaris Containers (non-global zones or local zones) dedicated one each for all those servers.
  
  
  Solaris 10 Binary Application Guarantee Program guarantees the binary compatibility for all applications running under Solaris native host operating system environments as well as Solaris 10 OS running as a guest operating system in a virtualized platform environment.
  
  
• Siebel Gateway server and the Siebel Application servers were installed and configured in one of the three Solaris Containers. Two identical copies of Siebel Application server instances were configured to handle 7,000 user load by each of those instances.
  
  
  From our experiments with the Siebel 8.0 benchmark workload, it appears that a single instance of Siebel Application server could scale up to 10,000 active users. Siebel Connection Broker (SCBroker) component becomes the bottleneck at the peak load in a single instance of the Siebel Application server.
  
  
• To keep it simple, the benchmark publication white paper limits itself to an overview of the system configuration. The full details are available in the diagram below.
  
  Topology Diagram
  
  
  
  The breakdown of the approximate averages of CPU and memory utilization by each tier is shown below.
  
  

  Tier	CPU	Memory
  Web	78%	4.50 GB
  App	76%	69.00 GB
  DB	72%	20.00 GB

  
  
  System-wide averages are as follows:
  
  

  Tier	CPU	Memory
  Web + App + DB	82%	93.5 GB

  
  
  
• 1276 watts is the average power consumption when all the 14,000 concurrent users are in the steady state of the benchmark test. That is, in the case of similarly configured workloads, T5440 supports 10.97 users per watt of the power consumed; and supports 3500 users per rack unit.

Based on the above notes: Sun SPARC Enterprise T5440 is inexpensive, requires: less power and data center footprint, ideal for consolidation and equally importantly scales well.

Vendor-to-Vendor comparison

How does Sun's new 14,000 user benchmark result compare with the high watermark benchmark results published by other vendors using the same Siebel 8.0 PSPP workload?

Besides Sun, IBM and HP are the only other vendors who published benchmark results so far with the Siebel 8.0 PSPP benchmark workload. IBM's highest user count is 7,000; where as 5,200 is HP's. Here is a quick comparison of the throughputs based on the results published by Sun, IBM and HP with the highest number of active users.

Sun Microsystems' 14,000 user benchmark on a single T5440 outperformed:

• IBM's 7,000 user benchmark result by 1.9x
  
  IBM published the 7,000 user result with 3 x p570 systems running AIX.
  
  
• HP's 5,200 user benchmark result by 2.5x
  
  HP published the 5,200 user result with a combination of 2 x BL460c running Windows Server 2003 and 1 x rx6600 HP system running HP-UX.
  
  
• Sun's own 10,000 user benchmark result on a combination of 2 x T5120 and 2 x T5220s by 1.4x

From the operating system perspective, Solaris outperformed AIX, Windows Server 2003 and HP-UX. Linux is nowhere to be found in the competitive landscape.

A simple comparison of all the published Siebel 8.0 benchmark results (as of today) by all vendors justifies the title of this blog post. As IBM and HP do not post the list price of all of their servers, I am not even attempting to show the price/performance comparison in here. On the other hand, Sun openly lists out all the list prices at store.sun.com web site.

CAUTION

Although T5440 possesses a ton of great qualities, it might not be suitable for deploying workloads with heavy single-threaded dependencies. The T5440 is an excellent hardware platform for multi-threaded, and moderately single-threaded/multi-process workloads. When in doubt, it is a good idea to leverage Sun Microsystems' Try & Buy program to try the workloads on this new and shiny T5440 before making the final call.

---

I would like to share the tuning information from the OS and the underlying hardware perspective for couple of reasons -- 1. Oracle's benchmark white paper does not include any of the system specific tuning information, and 2. it may take quite a bit of time for Oracle Corporation to update the Siebel Tuning Guide for Solaris with some of the tuning information that you find in here.

Check the second part of this blog post for the best practices running Siebel on Sun CMT hardware.

(Originally posted at:
http://blogs.sun.com/mandalika/entry/siebel_8_0_on_sun)
_______________
Technorati Tags:
Sun| Solaris | Oracle| Siebel | CRM | T5440| UltraSPARC | Benchmark

Read More

New Kid on the Block, LWS

.. Life with Solaris, that is. I just noticed a new web site called Life with Solaris that appears to be evolving in the footsteps of Blastwave and OpenCSW. As of today, the folks at LWS seem to have built some of the popular open source media players like Xine, VLC for different distributions of Solaris - Solaris 10, Solaris Nevada and OpenSolaris 2008.05

The first step in installing the packages from LWS is to install the pkg-admin tool (a perl script). To install pkg-admin, simply run the following command as 'root' user.

# pkgadd -G -d http://lifewithsolaris.jp/uploads/pkg/LWSpkg-admin-0.1.pkg

The tool will be installed under /opt/LWS/bin/. Adjust the PATH appropriately so you don't have to specify the absolute path everytime you try to install some package.

Syntax and an example to install the packages with pkg-admin:

# pkg-admin install <package_name>

eg., to install VLC Media Player, run:

# pkg-admin install LWSvlc

The following screenshot shows VNC media player running on Solaris Nevada build 95.



While we are at it, check out Dennis Clarke's blog post around playing videos with MPlayer on OpenSolaris. With little luck, the same binary might work on Solaris Nevada or even on Solaris 10 running on similar processor architecture. I tried the same binary (that was intended for OpenSolaris distribution) on my laptop running Solaris Nevada build 95 (snv_95); and it works great. Check the screenshot out.



Tip for Solaris/Linux users:

Just in case if the resulting screenshot is completely painted blue in the window area where you are supposed to see the actual image of the video playing at that moment, try passing the arguments "-vo gl" to mplayer. For example:

% mplayer -really-quiet -vo gl <video_filename>

_______________
Technorati Tags:
Solaris | OpenSolaris | Media Player

Read More