yes, if course. I understand the solution (that's why I did it), but my
question still stands:
how can it suddenly need (significantly) a lot more than 60 seconds to
generate?
On Apr 11, 2014 4:49 PM, "Les Mikesell" <[email protected]> wrote:

> On Fri, Apr 11, 2014 at 8:45 AM, MtK - SmartMtK <[email protected]> wrote:
> > the judgment is made by the fact that up until recently it worked fine
> with
> > TimeOut = 60, and now it doesn't.
> > it is also not related to APACHE, because switching to NGINX, didn't show
> > any improvement...
>
> If the apache settings you posted earlier really made any difference,
> it would only have been from the number of extra processes you had
> running and how long they ran before restarting.
>
> > I thought it was the RAM, which is not, because double the amount didn't
> > affect at all.
>
> If your host resources are already overcommitted, giving a VM more RAM
> may not actually make that RAM available until it needs to be stolen
> from some other VM or made available by flushing a host disk buffer to
> disk.
>
> > you also think it might be some other resources, but in fact the process
> > seems to be stuck, and not using any resource.
> > if you have any idea how to verify that, it'd be great...
>
> I usually assume that any delay long enough to notice is waiting for a
> disk head to move until proven otherwise - because that is orders of
> magnitude slower than other computer operations. If you have other VMs
> sharing the same disk head, they probably want it to be somewhere
> else.  Since you've said that if you configure apache to wait longer
> it eventually completes it clearly isn't 'stuck', it is just waiting
> for some slow operations.   A brute-force sort-of way to see what a
> process is doing is to run 'strace -p'  with the process id which with
> apache/mod_perl would be one of the httpd instances. With nginx it
> will be whatever you set up to run the cgi program.  You'll get a lot
> of output but you might be able to get an idea of what is taking time
> to complete.  Just keep in mind that with VMs there is another layer
> between the system calls you see and what physically happens.
>
> --
>    Les Mikesell
>       [email protected]
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> BackupPC-users mailing list
> [email protected]
> List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
> Wiki:    http://backuppc.wiki.sourceforge.net
> Project: http://backuppc.sourceforge.net/
>
------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
BackupPC-users mailing list
[email protected]
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

Reply via email to