Solaris Update Manager: I'm officially screwed

Before, it was only the NVidia driver that got ticked off by new XOrg version. But among other things that I downloaded there was an update for GNome itself. Today this thing stopped working. Crap... how am I supposed to fix it? Just try rebooting several times and pray it mends? Digging through messageboards in search of a solution does no longer sound like fun way to spend weekend.

Update: rebooting couple of timed did fix it. I wonder how many reboots are left for me to see the system acting deterministically again. OTOH, life is now full of surprises when it comes to booting Solaris...

Java stack size weirdness, JMeter in pain

Now that my workstation is armed with 3GBs of RAM, I wanted to re-run the load test with greater number of threads allocated. This, of course, requires proportionately greater heap size, so there... I understand 64-bit JVM's stack size is quite large, thus I allowed Glassfish to use up to 2 GBs of RAM for the heap, and I instructed it to create up to 2500 threads in pool, having number of requests to process being same 2500. Fired the server up.

Now, load clients. Fired up the Linux machine upstairs (the one on the wireless connection), connected to it using PuTTY, directing X traffic through a tunnel to local X server courtesy of Cygwin X. When I ran JMeter 2.1.1 there last time, configuration was changed there and then, so I was greatly surprised to see "Segmentation fault" as I tried to launch it. Hmm... Increased stack size to 128k: launches fine. And here's the kicker: I exited JMeter, edited its script to _again_ have stack size of 48k and... it worked fine! What is this mystery? Why would Java 1.5 not launch the first time with smaller stack size, but once it had ran with greater stack size, it would have no problem running with the small? Anyway...

And now, JMeter in pain! (Shouted in low voice with reverberation added). So, Glassfish was running happily for some while, utilizing 1.6GB out of allowed 2GB, consuming remainder of 77% CPU idle while supporting slightly in excess of 2k concurrent connections (judging by both "therads busy" and "connections open"). Linux load client was running 800 threads, Windows load client - 1600. And then I decided to peek at Google Analytics statistics for my blog. Jmeter was not too happy to share the resources:
 

But as you can see it recovered.

What else... Ah, yeah, Google Analytics, pertty amazing stuff. It's amusing to know that my other blog entry "The purpose of life", being completely worthless and uninteresting, was in fact viewed by some person from Tulsa.

Opteron system memory scaling (Stream results)

Yesterday went to Fry's and bought a pair of DDR 3200 ECC Registered sticks of RAM 1024 MB each. 1 GB I had before in my Opteron rig felt very yesterday :) So, now I have # GB, but I was wondering about performance effects of having 2 vs 4 memory slots populated. Some documentation (on Crucial's website) made me feel for a moment that having 4 sticks has the effect of memory speeds dropping to 2700 (DDR 333). But at least that is not the case. Re-reading that piece, this only happens when using 2GBs modules in all 4 slots. I do still remember articles on Anandtech and tomshardware (without being able to link to those), and other overclocker's forums, about varying effects of having 4 sticks of RAM vs 2.

The situation is quite common, I should think. You buy a machine with a pair of RAM modules initially, and when you decide to expand, simply doubling initial RAM amount seems somewhat strange. So you end up buying twice the original amount, but how will it work with all 4 memory slots filled, and with memory being of different origin? Anyways, it appeared quite hard to find a benchmark to run to see what my case ends up being... Started with Stream, and here are the results, in MB/s:

	Copy	Scale	Add	Triad
1GB Win32	2012	2037	1899	1891
2GB Win32	2313	2345	2287	2185
3GB Win32	2377	2398	2322	2206
1GB Win64	3773	3699	3226	3039
2GB Win64	4064	4038	3415	3215
3GB Win64	4070	4049	3401	3204

To recap, these tests were produced on Sun Java Workstation W1100z with Opteron 150, using combinations of 2x512 MB and 2x1024 MB RAM modules. 2x512 are original modules shipped, based on Infineon chips. The 2x2048 are Patriot modules with Hynix chips. Good suggestions to run benchmarks that are easy to acquire are welcome. Hopefully those benches should not require extensive setup...

Word of caution to those updating Solaris

Since Sun Update Manager was released, I decided to join other civilized people who, either on Windows or Linux, can scroll through a list of fixes, make selection, download, have it all installed automatically and having one's system in better shape than before after a reboot (not like those neoanderthals who download patches via FTP and install them using command-line tools). It almost worked. One issue was more of a peculiarity: not all of updates installed became effective upon the very next reboot.

But the fact that one of updates was a newer version of XOrg... I should have guessed the outcome :) Of course, with 3rd or 4th reboot, when the change came into force, NVidia's driver refused to load :( Being bad with command line and Solaris, I could not figure out a way to mount an SMB share in Solaris, to access driver installer I have on my NAS... oh well, ended up spoiling a blank CD-R to copy this driver. So if you are about to update your Solaris, make sure driver installer file is there somewhere in the filesystem.