Rational Clearcase Kernel settings

[Paul Condren]

Morning all (depending on whgere you are!)

We are experiencing some slow response times during peak usage on our 2 Rational Clearcase servers. They are running as a VOB store. (I hope this makes sense as I dont have much to do with this application!).

Looking through the doicumentation theres not much on what our kernel parameters should be. Does anyone have any recomended settings for this package?

The only references I can find are to ninode. Theres no listing like you get for Oracle though which is kinda what I was after.

thanks.

[Peter Nikitka]

Hi,

for each supported OS there is as section in the installation manual about OS release levels, required patches and kernel modifications.
Of course these have to be set according to the number of VOBs, users, ... !

Some Info for CCase7:
http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m0/topic/com.ibm.rational.clearcase.books.cc_ms_install_ux.doc/cc_ms_install05.htm

mfG Peter

[Paul Condren]

Just a bump back to the top as I'm still having slow response at peak times. I cant see any kernel setting that being breacked and during the peaks the swap and process stack etc are fine. Its just slow network speeds that are the symptom of this problem.

We have a gigabit lan & switches etc so I cant see how I can make this any faster?

[Rodney Myers]

Hi Paul,

I use ClearCase on HP-UX 11.23, so I will try to help. I doubt you need to touch the kernel tunables. I have not.

Please post the output of uname -a

Please post the output of cleartool getcache -mvfs

Are these dedicated VOB hosts? Do you also host views and run builds (clearmake) on the machine? What else runs on the machine? How many users and what are they doing? Please also describe the disk storage setup your are using for the VOBs.

Which operations are slow? And how slow?

[Paul Condren]

Rodney,

We have two clearcase servers, both of which are showing slow response times during peak times - first thing in the moring between 8and 9:30 and for about an hour in the evening between 4 and 5. These reports are coming from the users who say the appliaction is slow. These slow down periods corespond to the users ariving at work and checking out code, then checking it back in before they leave. I have ran some ping tests form the servers to the desktop PC's running the client and can see a slowdown in the ping time during these periods.

The cleartool getcache -mvfs output below was produced at 10:50 today. I'll try it again during one of these slow down perionds. I'm not a clearcase expert, can you give me a clue on what this is showing and if its good or bad? thanks.

the VOBs are on EMC SAN storage, again I'm no clearcase expert but a bdf shows the storage as one big filesystem with then seems to be sliced and remounted as the VOBS on /net/server name:

/dev/vg02/vobstore 406790144 378889256 27713896 93% /opt/app/clearcase/vobstore - # vg02 is EMC SAN Disks

net/server_name/opt/app/clearcase/vobstore/sa_pvob.vbs
406790144 378889256 27713896 93% /vobs/sa_pvob
/net/server_name/opt/app/clearcase/vobstore/sa.vbs
406790144 378889256 27713896 93% /vobs/sa
/net/server_name/opt/app/clearcase/vobstore/ppmf_pvob.vbs
406790144 378889256 27713896 93% /vobs/ppmf_pvob
/net/server_name/opt/app/clearcase/vobstore/ppmf_data.vbs
406790144 378889256 27713896 93% /vobs/ppmf_data
/net/server_name/opt/app/clearcase/vobstore/sampl_pvob.vbs
406790144 378889256 27713896 93% /vobs/sampl_pvob

There are 288 /net mounts on the first server and only 24 on the second clearcase server below (second server is newer and not yet fully utilized)

The clearcase team say we have aprox 2000 users. They are reporting general slowdown in clearcase explorer for every function - loooking at views etc and checking in & out.

Server One__________________
uname -a
HP-UX B.11.11 U 9000/800 3910351549 unlimited-user license

model
9000/800/rp3440

./cleartool getcache -mvfs
Mnodes: (active/max) 291/16384 (1.776%)
Mnode freelist: 0/3604 (0.000%)
Cltxt freelist: 0/3604 (0.000%)

DNC: Files: 0/3200 (0.000%)
Directories: 0/800 (0.000%)
ENOENT: 0/3200 (0.000%)

RPC handles: 0/40 (0.000%)

Current MVFS cache enable settings:
Attribute cache: enabled
Close-to-open revalidation: enabled
Name cache: enabled
Readlink cache: enabled
Root version cache: enabled
VOB freelist low-water mark: 3243
Cleartext freelist low-water mark: 3348
Readdir block cache size: 6
MVFS scaling factor: 3

Attribute cache miss summary (for tuning suggestions, see the
documentation for administering ClearCase):
Attribute cache total misses: 0 (100.00%)


Server Two__________________
uname -a
HP-UX B.11.11 U 9000/800 794880399 unlimited-user license

model
9000/800/rp4440

./cleartool getcache -mvfs
Mnodes: (active/max) 27/45056 (0.060%)
Mnode freelist: 0/9912 (0.000%)
Cltxt freelist: 0/6844 (0.000%)

DNC: Files: 0/12800 (0.000%)
Directories: 0/3200 (0.000%)
ENOENT: 0/12800 (0.000%)

RPC handles: 0/160 (0.000%)

Current MVFS cache enable settings:
Attribute cache: enabled
Close-to-open revalidation: enabled
Name cache: enabled
Readlink cache: enabled
Root version cache: enabled
VOB freelist low-water mark: 8920
Cleartext freelist low-water mark: 6812
Readdir block cache size: 6
MVFS scaling factor: 15

Attribute cache miss summary (for tuning suggestions, see the
documentation for administering ClearCase):
Attribute cache total misses: 0 (100.00%)

[Rodney Myers]

Your usage of ClearCase has very little similarity to mine. If the ping times are slow it could mean network link saturation. You are using SAN, so that very well may be the case. You could look at a product called APA if you think that is the problem. Also see if you are following the guidelines in the "tuning for performance" section of the ClearCase admin guide. Is your buffer cache large enough by IBM's guidelines? Are disk spindles dedicated to busy VOBs? There are also lock manager settings that you might need to tweak with 2000 (wow) users, described in the admin guide. You might need a lot of help, and to spend some money on hardware, to get a ClearCase system with 2000 users working well.