This isn't something we've seen before. Can you tell me the OS the
server is running on? Is this a virtual machine (VM)?
We do no special "time changes" in FusionReactor (eg for timezone) and
only take the system time. Therefore the only reason I can come up
with is that your system clock may have been wrong and then updated
itself (eg from ntpd) to correct it resulting in the time on your
system being moved back. Time issues are common on VMs, especially
when running on older hardware. If you're running VMWare check out
this helpful PDF - htpp://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf
As for the pages running for a long time but doing different
processes, it's likely they're all waiting on the same application
lock and/or DB lock and that's why you see them all take a long time.
You could enable the timeout "Crash Protection" feature which would
email you a stack trace of the running code when a request takes this
long to execute - this would help you explain the problem. The very
high values may also point to a system time change.
If you require assistance with this, we offer a consulting service
offered through our http://www.cfconsultant.com brand.
Best regards,
David Stockton
Fusion Support Team
On Nov 26, 7:41 pm, Roberto <roberto.marziale...@gmail.com> wrote:
> Hi all
>
> i'm a novice of fusion reactor.
> i've got two question:
>
> 1. on Slow Requests e Longest Request pages there are some records with
> date in the future!
> (my server set a date about 1h and 30min before). In other pages the date
> is correct.
>
> 2. on Slow Requests and Longest Request some request take very very long
> time...
> The processing time of this request is about the same (4,398,--), This page
> is
> different from each other, and with different queries inside.
>
> here for more detailhttp://i.imgur.com/4X5Z8.png
> 2. on Slow Requests and Longest Request some request take long time...
> The processing time of this request is about the same (4,398,--), This page
for future...
long requests are caused by a linux kernel bug...
http://archives.postgresql.org/pgsql-general/2011-07/msg00300.php