Jump to content


Member Since 21 Dec 2003
Offline Last Active Apr 12 2004 10:49 PM

Topics I've Started

ProIV Spinlocks

21 December 2003 - 08:48 PM

When we recently upgraded the system a ProIV based application runs on from an 8 processor, 900mhz Sun v880 to a Sun 4800 (8 procs, 1200mhz), we started experiencing eratic behaviour which resulted in the sudden appearance of high kernel mode (80-90 %) during busy days. We are using 4.6r213, solaris 8 and oracle 9i.

As a result of this our application supplier suggested us to enable spinlocks, which are mentioned briefly in the ProIV documentation. Since then the kernel mode storm has appeared less frequently, but whenever it appears we have to restart the application for things to settle, which neither makes me nor the users happy.

So far I have not managed to reproduce the behaviour on any of our slower testsystems, however I am able to force that behaviour to happen on the production system by running some nightly batch job, which should run on a total of one processor, but causes up to 90% kernel mode on the entire system. The application is just unusable then.
If I copy the entire application (app+oracle) to a 900mhz machine, the same job consumes almost no kernel resources.

I have been collecting data using isview and the usual unix tools, but havent got a real clue yet.

Looking at /etc/isamdef and isview I have determined that there are actualy 4 spinlock parameters, SL_SPIN (default 100), SL_NAP (default 10), SL_TIMEOUT (default 50), SL_SLEEP (default 2)

Can anyone give me more detailed information about these than "set SL_SPIN=100, SL_NAP=10 on a multiprocessor system" as the Dokumentation does?

If I remove write permissions of the bootstrap files, I can make the inode based locks go away, but experimenting with this (so far on the testsystem only) has not allowed me to create any noticeable difference to what I have with.

If one upgrades to a faster machine, but with the same number of processors one should not experience suddenly increased contention, but we obviously do. Has anyone experinced something similiar yet?