UNIX for Advanced & Expert Users

You may greatly increase speed with:

Code:

find /opt/app/websphere -type d -name myfolder -perm -600 | wc -l

Some points:

If "myfolder" is a directory try limiting the search with -type d

I suspect the websphere directory has loads of files and subdirectories. Some filesystems like ufs lose performance as the number of files in a directory grows in size.

The only other possibility I can think of is your inode cache is horribly small.

Code:

echo ufs_ninode/D |mdb -k

run as root in the global zone will show what the ufs inode cache is set to.
I cannot recommend a good value offhand, but if it less than 129797 which is the default with 2048 set as maxusers, then it needs help.
For inode hit rate see if the sar -g column %ufs_ipf shows several non-zero entries in a 2 hour period. If so, bump ufs_ninode by 50%.

Code:

# sar -g

SunOS sun-m4k-02 5.10 Generic_144488-14 sun4u    11/10/2014

00:00:01  pgout/s ppgout/s pgfree/s pgscan/s %ugs_ipf

Of all of these I vote for the "too many files" in a directory problem.

Is that with the find actually running? Not much IO going on...

OK, so what does a few sets of output from "mpstat 1" show?

And if you have root, what does "echo ::memstat | mdb -k" show?

---------- Post updated at 05:33 PM ---------- Previous update was at 05:27 PM ----------

FWIW, I don't think using the "-type d" argument to find is going to help at all as "find" is going to have to do a stat() call on every entry in the directory tree anyway. That's just filtering the output.

I was thinking the problem was caused by having to wade through all the stat() calls on every file in the directory tree, with disk IOs being the dominant performance problem. But the iostat output doesn't seem to show that.

A simple

Code:

find /opt/app/websphere | wc -l

would be informative.

Me too, but i'd like to offer another possibility: a filesystem (or several FSes) mounted with concurrent I/O. This would bypass OS caching completely and while it speeds database operations with concurrent writer processes it reduces random (non-concurrent) I/O to awfully slow. Check the mount options for the FSes involved to find out if this is the case.

I hope this helps.

bakunin