Long time user of RHEL, new to other OS's. Doing some searches on many different servers. I am working with RHEL, AIX, HP-UX, and Solaris. Really not happy with any of them using the find command. I am doing simple find commands like:
find / -group 1234
find / -user PEBKAC
RHEL 4 - Fastest, like by a long shot, but always seems to pull up something like this:
find: /proc/11845/task/11845/fd/4: No such file or directory
Is there a way to filter out these within the find command itself?
Sun/Solaris 5.1 - Slower than RHEL... same issue
AIX 5.3 and 6.1 - fairly clean, but slow.
HP- UX 11- So slow, I need to get up and walk around while it searches. I end up throwing up multiple sessions/servers, while waiting, and then lose track of what I am doing.
So, either find just sucks, or I am doing it wrong. More so on the supposedly "better" OS's and hopefully someone can point out a superior method. I am used to running RHEL, and always just dealt with the garbage, but the slowness of these other OS's are just a killer! Especially AIX...
/proc is a special filesystem that is very transitionary as it mirrors the state of the O/S, and has no "real" files, so I would recommend not running the find against it...You can remove it from the list by using something like:
find / -name proc -prune -o -group 1234 -print
The speed of the find is linked to the speed of the filesystem, the speed of the hardware it is running on, the tuning of the O/S (filesystem and inode cache sizes, etc), and the other work the server is doing.
I would recommend installing the GNU "findutils" and use "locate" if you are doing this on a regular basis.
The performance of the "find" program itself is pretty consistent across various editions of unix.
The Linux "locate" command is quick because it maintains a file index (similar to the Windows Search option) but maintaining this index itself becomes an issue on fast-changing systems.
Back to "find".
Given knowledge of the contents and structure of the filesystems it is a last resort to issue a "find" from root. Even then you need the "-follow" (links) switch to force "find" to search everywhere - thought this can cause "find" to report the same file more than once where there are linked directories.
On a mature O/S you could find yourself trawling through hundreds of thousands of irrelevant files and directories (like patch repositories etc.) or even files on other computers when NFS is involved.
Take note of the "-xdev" parameter to "find" (sometimes called "-mount" on old versions) which confines your "find" to a single filesystem.
Look at the inode count from "df -i" (or "bdf -i") to see how maby inodes are in use on each filesystem. This could explain some speed differences which cannot be accounted for by hardware differences or filesystem type.
Say if you are only interested in files in say "/home" issue "find /home -xdev " not "find /" .
Is a little misleading and needs some qualification.
Although the find program generally works in a similar way across most UNIX/Linux variants, the performance of it is wildly different depending upon lots of factors (filesystem type/performance, filesystem tuning, hardware, O/S tuning etc). Solaris for example is notoriously slow on its UFS performance.
I will qualify this qualification with some statistics:
My solaris 8 box running IDE drives is currently doing around 4940 files per second on a given find.
My solaris 10 box running striped SCSI U320 drives is currently doing around 4854 files per second.
My AIX 5.3 43p-170 box with U160 drives on JFS is getting 4766 files per second.
My HP-UX 11.11 C3600 with U160 drives on VXFS is getting 5220 files per second.
My HP-UX 11.23 Integrity box with U320 drives on VFXS 8461 files per second.
My OpenSuSE 11.2 Lenovo W500 laptop running a SATA II drive @ 7200RPM on an EXT4 filesystem is getting 13736.
As you can see - wildly different results on wildly different platforms, with my laptop being the fastest!
This is why performance tuning and benchmarking can be one of the most complex areas of computing, due to the multitude of factors involved.
