The Domain So, at the $DAYJOB, we were faced with building a large operational data store. Large has many meanings to many people. I’ve written about this before, but I’ll reiterate the scope: (> 1TB data, thousands of tables, several tables with around one billion rows). So, for a variety of reasons, we chose PostgreSQL. I’ve written about that choice a few times, but didn’t write about the choice to use Solaris.
If you use Oracle and you use Perl, then you likely have compiled DBD::Oracle before. Typically, this is a simple "install DBD::Oracle" via the CPAN shell and you are good to go. Well, installing DBD::Oracle on 64-bit Solaris 10 on amd64 was more challenge than usual. It took me the better part of two hours to get it right and I figured if I could save someone that time then I'd be a better person -- you all know I'm always trying to be a better person ;-) heh.
So, I used dtrace to diagnose a pretty subtle performance problem with Ecelerity a while ago and just got around to implementing an enhancement to obviate that bottleneck. This would be asynchronous socket shutdowns and closes under situations that were "challenging" before.
I built out a generalized asynchronous socket shutdown and close framework and deployed it throughout the application. On Solaris, our event system now handles the socket() calls, the port_associates() and port_diassociates(), read/write/readv/writev/send/recv/etc.
Get your Solaris 5.11... sorta. OpenSolaris is finally a secret no longer. Many months of hard work by a small team of people (mostly at Sun) has produced an almost completely open future development branch of the truly enterprise class operating system we all know an love (or least me and it's my blog) Solaris! Solaris has been in my life since I started computing in college in 1994.
We do alot of software builds on various Solaris versions. One thing we find frustrating is that during a typical build process many processes are invoked via shell scripts and makefiles etc and isaexec takes over for all the multi-architecture packages -- it's bad. So... say I'm building a a software product (and of course are rolling sparcv8, sparcv9, i386, and amd64). By simply setting the compiler flags and linker flags appropriately and we can get our binaries for the appropriate architecture.
