This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Linux VFS cache hit rate script
On Thu, Apr 21, 2011 at 3:31 PM, William Cohen <wcohen@redhat.com> wrote:
> Found a possible reason got the overflow for the associative array; there is an associative array used for caching names in vfs.stp:
>
> global __devnames
> function __find_bdevname:string(dev:long, bdev:long)
> {
> ? ? ? ?if (dev in __devnames)
> ? ? ? ? ? ? ? ?return __devnames[dev]
> ? ? ? ?else
> ? ? ? ? ? ? ? ?return __devnames[dev] = bdevname(bdev)
> }
>
> The only way that is going to fill up is if there are a lot of different values for dev.
>
> -Will
>
I wrote a quick script to test this:
# cat devnames.stp
probe vfs.read.return {
printf("\tdev: %d\tdevname: %s\n", dev, devname)
}
Output on the affected system:
# stap -DSTP_NO_OVERLOAD devnames.stp -c "sleep 60" | sort | uniq -c
ERROR: Array overflow, check MAXMAPENTRIES near identifier '$file' at
/usr/share/systemtap/tapset/vfs.stp:769:9
WARNING: Number of errors: 1, skipped probes: 2035
Pass 5: run failed. Try again with another '--vp 00001' option.
2 dev: 0 devname: N/A
762956 dev: 16 devname: N/A
520 dev: 18 devname: N/A
4183 dev: 22 devname: N/A
4 dev: 23 devname: N/A
1288 dev: 265289728 devname: dm-0
1 dev: 27 devname: N/A
872 dev: 3 devname: N/A
3094 dev: 5 devname: N/A
380875 dev: 6 devname: N/A
Both this script and the cache-hit-rate.stp script generally die with
that error in 30 seconds or less. The data above is around 30 seconds
or so.
That bizarrely long dev number might be relevant... or maybe that's
just a normal quirk of LVM?
The number of entries when it crashes varies... 10 above, but it's
also stopped on 7,8, or 9 dev's shown. I can't see why the limit would
vary like that, nor why there would be a limit so low.
Jake