This week saw an interesting pair of articles in Computer Business Review Online..
The first article on Monday, had the dramatic title: IBM has lost 80% of Informix users in six years by Jason Stamper. This must have sounded a little strange to anyone who has been paying attention to the rise of Informix in the last 18 months, and the fact that Informix revenue has been growing at a significantly faster rate than database market as a whole.
Sure enough, today the same journalist appears to have accepted the story is entirely false and issued a follow-up.. IBM corrects its own Informix customer figures. "Instead we are now told there are 20,000 in the International Informix User Group, over 100,000 Informix customers, and millions of users." - Good to see a journalist make a humble and gracious apology for releasing a bogus story without checking the facts. Many people in his position would be tempted to blame their sources.
Code line merger seems unlikely
A better-researched analysis of post-merger Informix is offered today by Philip Howard of Bloor Research in his Regdeveloper article: IBM and Informix tie down Cheetah - Code line merger seems unlikely. In it he discusses IBM's evolving strategy when it comes to Informix; contrasting the increasing scope of the last two major IDS releases, versions 10 and 11 and concluding favourably that any initial hints that the DB2 and IDS code lines might merge are off the table. Viewed from the inside, seeing the rate at which the IDS development team is growing, this assessment seems pretty accurate.[Read More]
Administrating and Developing with Informix
Today sees the announcement of Cheetah. Informix Zone has done a nice job of collating the English and German press coverage; the leitmotif of which might be summarized as "global availability".
Yesterday there were meetings and breakfast/lunches to mark the announcement at the major IDS development sites, with an IDS all-hands call hosted in Lenexa by Jerry Keesee (Development) and Bernie Spang (Marketing).
Here in Beaverton the IDS development team met to discuss ways to improve communication between engineers working on IDS at the various sites (e.g. Lenexa, Menlo Park, Beaverton, India, Germany, and various smaller outposts). I was unfortunately unable to participate due to an urgent appointment with Cannon Beach which I'm pleased to report was pleasantly sunny, but it was interesting to look at the meeting minutes. An improved centralized website providing for the needs of IDS development engineers was high on the agenda - it's all too easy to end up with too many partial information solutions in a distributed development environment - a website here, a wiki there, a team room somewhere else. Once in a while someone needs to take a look at the current state of available information and develop a new root site or at least refurbish the old one; with central links to the most important knowledge sources, a decent search engine, and evaluate what information is not readily available. An example of information no longer readily available that was discussed is a centralized ftp server for all internal Informix downloads - something we once had but over the years has devolved into multiple ftp servers and NFS drives. It is good to have these discussions, some of the problems are readily solved with willingness and a few hundred GB of storage.[Read More]
gbowerman 100000B5T0 945 Visits
Not that everyone wasn't happy with the previous system.. but there is a new Maintenance Delivery Vehicle (MDV) for Informix Products called Fix Central - I like the minimalist front page.
Here is the blurb for Informix users:
Beginning June 1, 2007, entitled customers of the most popular Informix products will have a new way of finding and downloading
fixes (fix packs, PIDs and patches (special builds)) via the Fix Central web site.
More information about Fix Central is available here: http://www-1.ibm.com/support/docview.wss?uid=swg21260952.[Read More]
gbowerman 100000B5T0 845 Visits
Do you like nothing better than listening to Informix podcasts on your <insert fashionable portable audio device> while doing your <insert popular contemporary exercise activity such as kick-boxing, pole dancing or driving to work>? I just took a look at the Informix Podcasts site and noticed several new arrivals, the current list is:
gbowerman 100000B5T0 833 Visits
The tadpole cam experiment reached its conclusion yesterday as the last tadpole completed its metamorphosis and entered the complex and daunting world of adult froghood. With a heavy heart I returned the young Pacific Tree frogs to their pond, a brutal realm of garter snakes, bullfrogs and cannibalism, though at least no conference calls. Here are some of the final pictures..
I was CC'd on an interesting VP Private Memory Cache Q&A that helps explain this feature a little further. VP Private Memory Cache was a performance feature announced in IDS 10.00.xC6. There was a slight hiccup due to the default value being uninitialized in that version, which should not distract from the usefulness of this feature..
1. Where is private cache allocated from? in the resident or virtual segment?
2. How is the VP private cache used? From my understanding:
When a VP needs to read some data pages from disk, it will search the VP cache first to check whether there is enough space, if it cannot find the space, it malloc the memory from the buffers.
So I feel now Informix has two level's of cache, the first is vp private cache and the second is buffers. But when one vp needs to access a data page which lies in another vp's private cache, what does it do?
3. After the data page was read into the vp private cache, it maybe updated or deleted, when is the data page is being flushed to disk to mark it clean and accommodate the new data page? in checkpoint?
A.The vp private memory cache is not used for buffers in the buffer pool, or for any pages read from disk. I think that's where the confusion is starting. When a thread needs to allocate memory from its own session pool, for example, that's when this VP-private cache comes in. Think of all the memory that threads allocate from pools like the 'global' pool or the 'rsam' pool or their own session pool (e.g. pool name '125'). It's that memory that goes into the VP-private cache when it's freed.
Here's the big picture. Before we had this VP-private cache feature, every VP would fight every other VP for the same memory in a particular shared memory segment. The memory in that segment had to be protected by a latch. So when Thread 1 on VP 1 needed a block of memory from Segment 1, it first acquired the latch, then took the memory, then released the latch. Meanwhile if Thread 2 on VP 2 needed memory from the same segment it would have to wait for the latch to be released in order to get a block of memory from Segment 1. Typically these threads need these blocks of memory for their session-private pools. Again, this is not related to the buffer pool that contains pages from disk.
You can imagine that in a high-stress environment with a lot of VPs and a lot of threads the latch on Segment 1 would become a performance bottleneck.
The solution we chose was to allow each VP to build its own private cache of memory blocks as blocks were freed. In other words, the first time a memory block was allocated from a segment, it would be allocated the same way it always has been. But if that memory block was freed, where ordinarily it would go back to the segment, now it remains allocated but is tracked by the freeing VP as part of its private cache. The next time a thread on that same VP needs a memory block it does not need to acquire any latch to get it. It simply takes the block from that VP's private cache. We know that no other thread will try to allocate memory from that same cache simultaneously, because only one thread can run on a VP at a time.
The size of an individual VP private cache is limited by the VP_MEMORY_CACHE_KB configuration parameter. In other words if you set VP_MEMORY_CACHE_KB to 1000, no VP-private memory cache in the server can exceed 1000 KB (1 mb) in size. Calculating the maximum amount of memory that an instance can allocate toward all VP-private caches is a matter of multiplying the value of VP_MEMORY_CACHE_KB times the number of VPs.
If you set VP_MEMORY_CACHE_KB to 0, the feature is turned off.
The minimum non-zero value for VP_MEMORY_CACHE_KB is 800, I believe.
Thanks JC.[Read More]
I had a mail from the CSDK team manager saying "I am looking for customer feedback/pain points or any other feature which they would like to see to be addressed in CSDK".
So.. what would you like to see in the Informix Client Software Development Kit? Feel free to leave comments or email me directly.
Off the top of my head I'd like to see: