.comment-link {margin-left:.6em;}


Tuesday, February 24, 2009

Removing Shared Memory Segments on Solaris

If you have an application that uses shared memory and crashes without cleaning up the shared memory, then releasing the shared memory can be painful. There are two commands you need to know to clean the shared memory ipcs and ipcrm. (These examples are on Solaris 9.)

Use the ipcs command to identify shared memory ID's and and semaphores that need freeing. Once you identify the ones that need removing you can use the ipcrm command to remove them.

ipcrm -m for the share memory.

ipcrm -s for the semaphores.

The trick of course is being able to identify what memory or semaphores (or message queues) that were in use by your application. Hopefully you can do that by user ID. If all else fails you might have to reboot the server.

Bookmark and Share

Thursday, February 05, 2009

Rows Returned with JDBC

There are two ways to influence the number of rows returned when getting data from a database using JDBC. One is the setFetchSize method, and the other is the setMaxRows method. Both of these methods appear as part of the statement and resultset classes. If set at the statement level it effects all resultsets that result from execution of the statement.

There are three main reasons to want to change these from the driver default setting:
  1. To conserve memory in the Java application by reducing the memory required to store data returned from the database.
  2. Reduction of wait time for obtaining the resultset when retrieving large amounts of data.
  3. If the application is experiencing performance problems because the jdbc driver is getting a small amount of data with each fetch.
One obvious situation where it makes sense to change this value is an application that displays data on the web with X rows per page. If X is 25, it would make sense to set the fetchsize to 25 with a call similar to stmnt.setFetchSize(25);. Of course it is better to use a variable, instead of hard coding the value.

According to Oracle their JDBC driver default fetchsize is 10. That may be an appropriate setting on modern systems if the rows contain large amounts of data, for example in BLOBs. If the rows are small (name and address) a fetchsize of several hundred or several thousand might be more appropriate.

It is also important when using these calls to do some performance testing to make sure the performance is being improved, not made worse. For reference see links to pages at Sun and Oracle. Those pages offer definitions of both the setFetchSize and setMaxRows methods. For more information the following are worth reading: Stackoverflow.com forum discussion, a page on JDBC performance suggestions, and Chapter 16 on JDBC Tuning (PDF).

Bookmark and Share

Wednesday, February 04, 2009

Very Common Coding Flaw

In a past life I worked as a Unix application developer in C and C++. Back in the days before there was a readily available library to do most things for you, I might add. More recently I have been working in corporate web environments tuning the performance of web applications and squashing bugs.

In this web world, I see the same coding error repeated over and over again all through complex systems. I've seen it cascade through four or more levels of servers and application layers – in the application code and in the web application server designs themselves. This common error is not setting a time-out for network communications. When an application is dependent on an other application (web app server, web service, database, etc.) the developer needs to take care to gracefully handle the situation when the back end service "locks up." I have seen such errors permeate through layers of hosting infrastructure and take down whole farms of servers with all resources tied up waiting on a service that accepts connections but never returns.

So for the love of all that is good, set a time-out value on all of your network communications. Your users and customers will be happier as a result.

Bookmark and Share

Tuesday, February 03, 2009

Twitter Fame in USA Today

Over recent months I have been trying to explain to my more luddite friends (meaning folks who spend 50 hours a week in front of a monitor for the last twenty years, but have yet to join twitter) the pros and cons of Twitter.

Yes you can get lots of really cool information from twitter. Yes you can also waste countless hours reading about people's breakfast menus, or telling them about yours. But an article in USA Today sums up how the corporate and social worlds collide on twitter and why it matters for companies.

Tablet Hotels utilizes its Twitter account similarly to JetBlue, keeping an eye on what customers are saying and what they can do improve their experience. "We had one of our TabletPlus members Twitter from the front desk when the hotel was giving her a hard time," Michael Davis, co-founder of Tablet Hotels, said. "We caught it within 30 seconds of posting and our customer service called the hotel to resolve."

"Customer problems can no longer be kept 'quiet' with the emergence of the Web," Davis said. The Marriott hotel group agrees, which is why they have not one, but two Twitter accounts. One serves as public relations and customer service vehicle, while the other focuses on Marriott's efforts to go green.

Bookmark and Share

IBM Rochester building 20 petaflop supercomputer

Good news for employees in Rochester, MN in this depressed economy. IBM's Rochester facility is working on building the most powerful supercomputer for the US government. The "Sequoia" supercomputer is targeted to achieve 20 petaflops which is more powerful than all of the current computers combined on the Top500 supercomputer list. The computer will be used by the US Department of Energy and will reside at Lawrence Livermore National Laboratory.

This should mean plenty of work for the people there – and since IBM Rochester is one of the largest local employers it also means the other companies that provide services to those employees should be able to breathe a sigh of relief that many others are not.

Labels: , , ,

Bookmark and Share