Loading ...
Sorry, an error occurred while loading the content.

Help!

Expand Messages
  • Mike Cantone
    I have one remaining, but somewhat glaring problem. After I use my ASP application for a little while (not really that long actually - maybe a dozen
    Message 1 of 5 , Oct 7, 2004
    • 0 Attachment
      I have one remaining, but somewhat glaring problem. After I use my ASP
      application for a little while (not really that long actually - maybe a
      dozen transactions), the exact same user behavior seems to cause the
      transaction to hang. The response times seem to get a bit worse and a
      bit worse until finally it changes doesn't come back. I usually end up
      restarting the web server at this point (hard to do in production!)
      and it doesn't seem to die easily. I issue a couple of stops - sometimes
      as many as 3-4 until it reports actually being stopped. Then I clear out
      the session cache, restart and it seems fine. If I don't clear out the
      session cache, I think it predictably is still in a funky state -
      certainly much of the time it is.

      I thought maybe the Reload directive I was using for development (to
      force the Perl Modules to get reloaded when they have been changed)
      might be using up a lot of memory, but commenting this out doesn't
      really seem to help things.

      The application I'm testing doesn't store a lot in session though I've
      specified MLDBM for StateDB. If the session data *were* growing too
      large, is there any warning? Do I just lose session data or do I
      crash/hang? As I said though, I am using the recommended MLDBM.

      P.S. This is considerably lower priority (unless it is related to the
      above somehow), but is there any difference between using IncludesDir
      directive and PerlSwitches -I directives? Advantages/disadvantages?

      ---------------------------------------------------------------------
      To unsubscribe, e-mail: asp-unsubscribe@...
      For additional commands, e-mail: asp-help@...
    • Warren Young
      ... Stop guessing and measure! Does your platform have a top command? You can use that to see CPU time and memory usage. If not, you may have sar or some
      Message 2 of 5 , Oct 7, 2004
      • 0 Attachment
        Mike Cantone wrote:
        > might be using up a lot of memory,

        Stop guessing and measure! Does your platform have a top command? You
        can use that to see CPU time and memory usage. If not, you may have sar
        or some other system load testing utility.

        ---------------------------------------------------------------------
        To unsubscribe, e-mail: asp-unsubscribe@...
        For additional commands, e-mail: asp-help@...
      • Josh Chamas
        ... MLDBM is not a valid setting for StateDB. Try DB_File or GDBM_File if you are storing a lot of data there, but if you are, know that it will slow things
        Message 3 of 5 , Oct 8, 2004
        • 0 Attachment
          Mike Cantone wrote:
          >
          > The application I'm testing doesn't store a lot in session though I've
          > specified MLDBM for StateDB. If the session data *were* growing too
          > large, is there any warning? Do I just lose session data or do I
          > crash/hang? As I said though, I am using the recommended MLDBM.
          >

          MLDBM is not a valid setting for StateDB. Try DB_File or GDBM_File
          if you are storing a lot of data there, but if you are, know that it
          will slow things down considerably.

          Also, heed Warren's advice on measuring, not guessing.

          If you need a trace level view of Apache::ASP execution, set "PerlSetVar Debug -3"
          in your httpd.conf, and restart your web server. There should be low level
          execution traces occuring then in your apache error_log.

          Regards,

          Josh

          ---------------------------------------------------------------------
          To unsubscribe, e-mail: asp-unsubscribe@...
          For additional commands, e-mail: asp-help@...
        • Mike Cantone
          I m optimistic I am on the crux of solving this problem with the help of some collective knowledge. My ASP application can handle between 20-40 transactions -
          Message 4 of 5 , Oct 11, 2004
          • 0 Attachment
            I'm optimistic I am on the crux of solving this problem with the help of
            some collective knowledge.

            My ASP application can handle between 20-40 transactions - then it seems
            to turn into a runaway process. The memory consumption according to top
            is well under 1%, however the CPU for httpd goes into the high 90th
            percentile. My application calls swish-e indexing and I found a very
            interesting reference on the net which describes what seems to be the
            identical problem here: http://mathforum.org/epigone/modperl/fraplahswo
            . One of their recommendations is to put an AUTOLOAD in mod perls
            startup.pl to see what is happening and, as was the case in the thread,
            I can now see that lots of DESTROYs are not getting found.

            The majority of these DESTROYs however probably don't really exist, but
            a method that can't be found that looks like a real problem is
            Apache::Connection::fileno. Josh mentioned fixing this in some of his
            change notes for versions of modperl that didn't support this. I don't
            know who is looking for this method - I don't know whether it is ASP or
            not. I am using Apache 2.0.x which doesn't allow me to use modperl 1.0
            (seems to want Apache 1.3), so I am using modperl "2.0" - the dev
            version. Where I can find the Apache::Connection.pm module, fileno truly
            is not defined, but what is not clear to me is what I can do about it.
            Moving to a 1.3 version of Apache is not an option for me - too many
            others rely on 2.0. Any ideas?

            -Mike



            Josh Chamas wrote:
            > Mike Cantone wrote:
            >
            >>
            >> The application I'm testing doesn't store a lot in session though I've
            >> specified MLDBM for StateDB. If the session data *were* growing too
            >> large, is there any warning? Do I just lose session data or do I
            >> crash/hang? As I said though, I am using the recommended MLDBM.
            >>
            >
            > MLDBM is not a valid setting for StateDB. Try DB_File or GDBM_File
            > if you are storing a lot of data there, but if you are, know that it
            > will slow things down considerably.
            >
            > Also, heed Warren's advice on measuring, not guessing.
            >
            > If you need a trace level view of Apache::ASP execution, set "PerlSetVar
            > Debug -3"
            > in your httpd.conf, and restart your web server. There should be low level
            > execution traces occuring then in your apache error_log.
            >
            > Regards,
            >
            > Josh
            >
            > ---------------------------------------------------------------------
            > To unsubscribe, e-mail: asp-unsubscribe@...
            > For additional commands, e-mail: asp-help@...
            >


            ---------------------------------------------------------------------
            To unsubscribe, e-mail: asp-unsubscribe@...
            For additional commands, e-mail: asp-help@...
          • Josh Chamas
            ... I would recommend looking into BSD::Resource for per process limits setting. IF Apache::Resource has been ported to mod_perl 2.0, I would look at that too,
            Message 5 of 5 , Oct 12, 2004
            • 0 Attachment
              Mike Cantone wrote:
              > I'm optimistic I am on the crux of solving this problem with the help of
              > some collective knowledge.
              >
              > My ASP application can handle between 20-40 transactions - then it seems
              > to turn into a runaway process. The memory consumption according to top
              > is well under 1%, however the CPU for httpd goes into the high 90th
              > percentile. My application calls swish-e indexing and I found a very
              > interesting reference on the net which describes what seems to be the
              > identical problem here: http://mathforum.org/epigone/modperl/fraplahswo
              > . One of their recommendations is to put an AUTOLOAD in mod perls
              > startup.pl to see what is happening and, as was the case in the thread,
              > I can now see that lots of DESTROYs are not getting found.
              >

              I would recommend looking into BSD::Resource for per process limits setting.
              IF Apache::Resource has been ported to mod_perl 2.0, I would look
              at that too, which wraps around BSD::Resource nicely.

              > The majority of these DESTROYs however probably don't really exist, but
              > a method that can't be found that looks like a real problem is
              > Apache::Connection::fileno. Josh mentioned fixing this in some of his
              > change notes for versions of modperl that didn't support this. I don't
              > know who is looking for this method - I don't know whether it is ASP or
              > not. I am using Apache 2.0.x which doesn't allow me to use modperl 1.0
              > (seems to want Apache 1.3), so I am using modperl "2.0" - the dev
              > version. Where I can find the Apache::Connection.pm module, fileno truly
              > is not defined, but what is not clear to me is what I can do about it.
              > Moving to a 1.3 version of Apache is not an option for me - too many
              > others rely on 2.0. Any ideas?

              The code that references fileno should be safe, even if it does not exist:

              # Apache::ASP::Response->IsClientConnected
              my $fileno = eval { $conn->fileno };

              If you really want this code to not do what its doing,
              then you could define this after loading Apache::ASP:

              sub Apache::ASP::Response::IsClientConnected {
              shift->{IsClientConnected} = 1;
              }

              And your application should work fine still regardless of whether
              this is a real fix for your problem. I am guessing that the real
              root of this problem is something else, and you will find your fix
              best in BSD::Resource. Also, if you are using worker mpm, I probably
              wouldn't, and would be wary of using BSD::Resource in this case.
              I would stick with the prefork mpm in Apache 2.

              Regards,

              Josh

              ---------------------------------------------------------------------
              To unsubscribe, e-mail: asp-unsubscribe@...
              For additional commands, e-mail: asp-help@...
            Your message has been successfully submitted and would be delivered to recipients shortly.