Thursday February 22, 2007
nicstat - now for Linux, too
Just a quick one to flag that I have released a version of nicstat for Linux (see latest blog on nicstat).
I do not have a myriad of Linux systems to test it on, so if anyone finds any issues, please let me know.
Posted at 05:45PM Feb 22, 2007 by timc in Performance |
Wednesday February 14, 2007
nicstat - the Solaris Network Monitoring Tool You Did Not Know You Needed
This is a placeholder entry - see the latest blog on nicstat, for the current source and binaries.
Posted at 05:29PM Feb 14, 2007 by timc in Performance |
Tuesday January 23, 2007
The Compiler Detective - What Compiler and Options Were Used to Build This Application?
Performance engineers often look at improving application performance by getting the compiler to produce more efficient binaries from the same source. This is done by changing what compiler options are used. In this modern era of Open Source Software, you can often get your hands on a number of binary distributions of an application, but if you really want to roll your sleeves up, the source is there, just waiting to be compiled with the latest compiler and optimisations.
Now, it might be useful to have as a reference the compiler version and flags that were originally used on the binary distribution you tried out, or you just might be interested to know. Read on for details on the forensic tools.
Solaris supports 64 and 32-bit programming models on SPARC and x86. You may need to know which one an application is using - it's easy enough to find out.
$ file *.o xxx.o: ELF 64-bit LSB relocatable AMD64 Version 1 yyy.o: ELF 32-bit LSB relocatable 80386 Version 1 [SSE2]
Note: yyy.o was built using "-native", informing the compiler that it can use the SSE2 instruction set extensions supported by the CPUs on the build system.
Some more examples, including a binary built on a SunOS 4.x system:
$ file gobble.* gobble.sunos4: Sun demand paged SPARC executable dynamically linked gobble.sparcv9: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, not stripped gobble.i386: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped gobble.amd64: ELF 64-bit LSB executable AMD64 Version 1 [SSE FXSR FPU], dynamically linked, not stripped
The command to use is:
$ /usr/ccs/bin/mcs -p executable | object
Here are some examples. The "ld:" entries should indicate what release of Solaris the executable was built on, which is a good indicator of the oldest version of Solaris it will run on.
acomp: Sun C 5.8 2005/10/13
iropt: Sun Compiler Common 11 2005/10/13
as: Sun Compiler Common 11 2005/10/13
ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.477
@(#)SunOS 5.3 Generic September 1993
GCC: (GNU) 2.5.8
as: SC3.0 early access 01 Sep 1993
ld: (SGU) SunOS/ELF (LK-1.3)
@(#)stdio.h 1.78 99/12/08 SMI
acomp: WorkShop Compilers 5.0 98/12/15 C 5.0
ld: Software Generation Utilities - Solaris-ELF (4.0)
@(#)SunOS 5.7 Generic October 1998
as: WorkShop Compilers 5.0 Alpha 03/27/98 Build
GCC: (GNU) 2.8.1
ld: Software Generation Utilities - Solaris/ELF (3.0)
GCC: (GNU) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
There is a non-linear relationship between versions of the compiler ("Sun C") and the development suite ("Sun Studio", "Forte Developer", "Sun WorkShop", etc.). You can figure it out using Sun Studio Support Matrix.
It depends on what compiler was used, and whether you have objects.
"dwarfdump" and "dumpstabs" are available with the Sun Studio suite.
Some examples:
$ dwarfdump -i gobble.sparcv9
...
DW_AT_name gobble.c
DW_AT_language DW_LANG_C99
DW_AT_comp_dir /home/tc35445/tools/c/gobble
DW_AT_SUN_command_line /usr/dist/share/sunstudio_sparc,
v11.0/SUNWspro/prod/bin/cc -xO3 -xarch=v9 -c gobble.c
DW_AT_SUN_compile_options Xa;O;R=Sun C 5.8 2005/10/13;
backend;raw;cd;
$ dumpstabs -s test
5: .stabs "Xa ; g ; V=3.1 ; R=Sun WorkShop 6 2000/04/07 C 5.1
; G=$XAB0qnBB6
6: .stabs "/net/vic/export/home/timc/tools/c/interposition;
/opt/Forte6/SUNWspro/bin/../WS6/bin/cc -g -c test.c
-W0,-xp\$XAB0qnBB6hh5S_R.",N_CMDLINE,0x0,0x0,0x0
$ dumpstabs -s getwd
1: .stabs "Xa ; V=3.1 ; R=WorkShop Compilers 4.2 30 Oct 1996 C 4.2",
N_OPT,0x0,0x0,0x0
2: .stabs "/home/staff/timc/tools/c/getwd;
/opt/SUNWspro/bin/../SC4.2/bin/cc -c getwd.c -W0,-xp",N_CMDLINE,0x0,0x0,0x0
$ dumpstabs mysqladmin | grep RPATH 13: Tag = 15 (RPATH) /usr/sfw/lib/mysql:/usr/sfw/lib
Yes, just use "ldd":
$ ldd mysqladmin
libmysqlclient.so.12 => /usr/sfw/lib/libmysqlclient.so.12
libz.so.1 => /usr/lib/libz.so.1
librt.so.1 => /usr/lib/librt.so.1
libcrypt_i.so.1 => /usr/lib/libcrypt_i.so.1
libgen.so.1 => /usr/lib/libgen.so.1
libsocket.so.1 => /usr/lib/libsocket.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libm.so.2 => /usr/lib/libm.so.2
libthread.so.1 => /usr/lib/libthread.so.1
libc.so.1 => /usr/lib/libc.so.1
libaio.so.1 => /usr/lib/libaio.so.1
libmd5.so.1 => /usr/lib/libmd5.so.1
libmp.so.2 => /usr/lib/libmp.so.2
libscf.so.1 => /usr/lib/libscf.so.1
libdoor.so.1 => /usr/lib/libdoor.so.1
libuutil.so.1 => /usr/lib/libuutil.so.1
/platform/SUNW,Sun-Fire-15000/lib/libc_psr.so.1
/platform/SUNW,Sun-Fire-15000/lib/libmd5_psr.so.1
Posted at 05:16PM Jan 23, 2007 by timc in Performance | Comments[2]
Wednesday September 13, 2006
How the T2000 handles 20,000 Database Connections
I have recently changed careers at Sun, moving from a pre/post-sales technical role to an engineer role. I now work in Sun's PAE (Performance Availability & Architecture Engineering) group.
You could say I am definitely enjoying the change, getting to play with real geeky stuff :)
Both jobs had the opportunity to play with new hardware, but the new job should see me get much more play time with pre-release systems, which I find very interesting.
Anyway, I had the chance to do some testing on one of our new systems that many customers have also had a great chance to test on - the T2000.
The workload I am using is designed to replicate a database query load that is common for some parts of modern on-line retail operations - almost exclusive relatively simple queries, running pretty much fully cached in the RAM of the database server. The queries come from a very large population of clients (5 - 20 thousand).
As a highly analytical fact-oriented engineer, you need to realise that up until my first opportunity to experience the T2000 first-hand, I remained just a little sceptical that it could deliver something like the promise of what I had heard. It has been covered that the T2000 suits some workloads better than others - I was keen to get a quantitative understanding of this to support the qualitative things I had heard.
My base system I had been doing tests on was an 8-CPU (16 core) E2900. I expected this would provide a pretty fair comparison to a system that has 8 cores in its single CPU. In fact I knew of some preliminary numbers for the T2000 which made be think the E2900 would come out slightly ahead.
I need to update my thinking. The advantage of four threads per core is proven by reality, with the 8-core T2000 showing it certainly had greater throughput for my workload than the 16-core E2900.
As you can see in the graph, the T2000's CPU consumption is well ahead of the E2900 (lower is better). Also, as I scale up the number of connections (keeping the overall throughput the same), the T2000 does not see as much of a penalty for the increase.

References:
Posted at 04:10PM Sep 13, 2006 by timc in Performance |