From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31499 invoked by alias); 21 Apr 2011 23:02:07 -0000 Received: (qmail 31490 invoked by uid 22791); 21 Apr 2011 23:02:06 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-pw0-f41.google.com (HELO mail-pw0-f41.google.com) (209.85.160.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 21 Apr 2011 23:01:52 +0000 Received: by pwi10 with SMTP id 10so154056pwi.0 for ; Thu, 21 Apr 2011 16:01:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.29.166 with SMTP id l6mr701502pbh.294.1303426912343; Thu, 21 Apr 2011 16:01:52 -0700 (PDT) Received: by 10.68.43.72 with HTTP; Thu, 21 Apr 2011 16:01:52 -0700 (PDT) In-Reply-To: <4DB0B049.8070806@redhat.com> References: <4DAF3D59.7020609@redhat.com> <4DB0B049.8070806@redhat.com> Date: Thu, 21 Apr 2011 23:02:00 -0000 Message-ID: Subject: Re: Linux VFS cache hit rate script From: Jake Maul To: William Cohen Cc: systemtap@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2011-q2/txt/msg00146.txt.bz2 On Thu, Apr 21, 2011 at 3:31 PM, William Cohen 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) > { > =A0 =A0 =A0 =A0if (dev in __devnames) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return __devnames[dev] > =A0 =A0 =A0 =A0else > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return __devnames[dev] =3D 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