[Date Prev][Date Next][Thread Prev][Thread Next][Interchange by date
][Interchange by thread
]
Re: [ic] workaround found for 99%CPU usage problem in Vend/SessionFile.pm: "::uneval($ref);" fixes it
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
_______________________________________________
interchange-users mailing list
interchange-users@interchange.redhat.com
http://interchange.redhat.com/mailman/listinfo/interchange-users