[ic] workaround found for 99%CPU usage problem in Vend/SessionFile.pm: "::uneval($ref);" fixes it

[Mike Heins]

Quoting Steffen Dettmer (steffen@dett.de):
> > In any case, I am certain if it moves to a local file system
> > the problem will disappear.
> 
> Well, it doesn't.

Did you remove all of your data files? The Storable files can easily
get corrupted. Usually Storable will tell you, though, with error
messages.

> 
> > This is just timing problem. If we can't lock reliably, file-based
> > sessions simply will not work. You could move to DBI sessions.
> 
> Here again a trace excerpt:
> 
> [pid 27204] mremap(0x40290000, 233472, 233472, MREMAP_MAYMOVE) = 0x40290000
> [pid 27204] stat("/usr/local/interchange-4.8.2/lib/auto/Storable/store.al",
> {st_mode=S_IFREG|0444, st_size=532, ...}) = 0
> 
> [pid 27204] mremap(0x40290000, 233472, 233472, MREMAP_MAYMOVE) = 0x40290000
> [pid 27204] stat("/usr/local/interchange-4.8.2/lib/auto/Storable/store.al",
> {st_mode=S_IFREG|0444, st_size=532, ...}) = 0
> 
> [pid 27204] mremap(0x40290000, 233472, 233472, MREMAP_MAYMOVE) = 0x40290000
> [pid 27204] stat("/usr/local/interchange-4.8.2/lib/auto/Storable/store.al",
> {st_mode=S_IFREG|0444, st_size=532, ...}) = 0
> 
> It looks really like and endless loop and not a failed flock(2)
> or so. In the trace file there are successfull accesses to
> store.al. After the same stat(2) call it gets opened and readed
> in with success.
> 

I would suggest updating Storable, or trying to install on a new setup
and seeing if you can duplicate. I have never seen this before,
and I can guarantee it is not a normal mode of operation.

-- 
Red Hat, Inc., 3005 Nichols Rd., Hamilton, OH  45013
phone +1.513.523.7621      <mheins@redhat.com>

Fast, reliable, cheap.  Pick two and we'll talk.  -- unknown