August 30, 2007 at 11:55 · Filed under news
An excerpt from an MSNBC article about China and another crazy law:
In one of history’s more absurd acts of totalitarianism, China has banned Buddhist monks in Tibet from reincarnating without government permission. According to a statement issued by the State Administration for Religious Affairs, the law, which goes into effect next month and strictly stipulates the procedures by which one is to reincarnate, is “an important move to institutionalize management of reincarnation.”
How odd.
August 23, 2007 at 22:48 · Filed under Musings
I’ll be taking a blog-break due to workload at work… Back soon! In the mean time listen to some decent music. Ssssh! It’s Secret!
August 20, 2007 at 20:12 · Filed under os, unix
Jonathan Schwartz the SUN CTO detailed on his blog about the new deal between Sun and IBM that allows IBM to offer Solaris x86 as a supported OS on their hardware. What does this mean for sysadmins around the world? More Solaris. That’s OK in my books. The less windows servers the better.
Someone should tell IBM about their new interest.
August 20, 2007 at 18:24 · Filed under unix
A friend was trying to compile cvsgraph on his Mac (10.4.10 intel) the other day and was receiving the error
configure: error: C compiler cannot create executables
By chance he also tried installing a Fink package by source that day as well, and received the same error. We checked out the GCC version
gcc -v
and it showed GCC 3.3. Some google time later, and it turns out this is an older GCC for the current XCode SDK he has installed. Somehow the system needed to be told what GCC to use, so this is the command that saved the day
sudo gcc_select 4.0
Simple fix really.
August 20, 2007 at 18:23 · Filed under MQ, unix
Recently I posted about our Websphere MQ MQCONN 2195 errors, and how we needed to apply the minimal recommended Solaris Kernel tuning for Websphere MQ. Well, we applied the changes, rebooted and connection problems were gone. Our application was able to spawn multiple connections to MQ without the errors we were seeing before.
However, we were still getting climbing response times when doing load tests between a request message being sent and a reply message arriving back. In conjunction with these times, we saw (using iostat) very high inferred disk utilisation from the SAN devices we had MQ and our application on.
So the team looked through the configuration of our clustered queue managers, and the logs, and application tuning (Triple writing vs. Single writing in MQ), and so on….
Our specialist tester had written a customised load harness to test response and throughput, and his graphs showed a bottleneck somewhere in the system. We knew the environment was good, as a “cloned” development queue manager and application on the pre-production system was getting response times at around a 10 millisecond median.
We tried it in a number of combinations, but finally found that the configuration had DEFPSIST(YES) on all local and alias queues. Changing all these to DEFPSIST(NO) led to near perfect response times. A mean response time of 20 milliseconds!!!!
DESCRIPTIVE STATISTICS --
--------------------------------------------------------------------------
RESPONSE TIME THROUGHPUT
(millisecs) (transactions/sec)
MEDIAN : 10.00 19.05
LOWER QUARTILE : 10.00 19.05
UPPER QUARTILE : 30.00 19.05
95th PERCENTILE : 50.00 19.05
MINIMUM : 0.00 0.00
MAXIMUM : 200.00 19.05
RANGE : 200.00 19.05
IQR : 20.00 0.00
COUNT : 2,000.00 2,000.00
MEAN : 20.45 19.02
STD DEV : 15.66 0.74
--------------------------------------------------------------------------
We are going to need to do some tuning – as persistence turned on across the board appears to be the major performance hog, and yet we need some persistence to cover queues where that functionality is needed. But at least we found the two major causes to our bottleneck and 2195 errors.
