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

SVN Performance Issue

Expand Messages
  • ultravio1et7
    I am having a strange problem with Subversion hanging. I have svnserve set up the same way that is stated in the guide
    Message 1 of 4 , Jun 6, 2008
    • 0 Attachment
      I am having a strange problem with Subversion "hanging." I have
      svnserve set up the same way that is stated in the guide
      (http://www.nslu2-linux.org/wiki/Optware/Svn?from=Unslung.Svn) using
      the inetd.conf method. When I go to preform a checkout on a small
      repository from my workstation it can take up to 1 min for my Slug to
      respond. I logged into the slug to see what might be going on and I
      can see by running a ps -a that the svnserve process is being spawned
      as soon as the request comes in but it just takes forever. I also
      tried shutting down svnserve and starting it back up manually using
      the -d mode but I get the same result.

      The thing that makes this seem really odd to me is that if I am
      browsing around on any of the Samba shares or if I am logged into the
      Slug doing anything that is hitting the disks such as updating with
      ipkg, svnserve does not hang and returns back any of the requests
      immediately.

      Any help tracking this problem down would be greatly appreciated.
      Listed below are the packages I have installed in case it helps
      diagnose this problem.


      adduser - 1.10.2-1
      apr - 1.2.12-1
      apr-util - 1.2.12-1
      cpio - 2.5-r3
      cyrus-sasl-libs - 2.1.20-9
      e2fslibs - 1.40.10-1
      e2fsprogs - 1.40.10-1
      expat - 2.0.1-1
      findutils - 4.1.20-r2
      gdbm - 1.8.3-2
      ipkg - 0.99.154-r2
      ipkg-web - 7-7
      kernel - 2.4.22.l2.3r63-r10
      kernel-image-2.4.22-xfs
      libc6-unslung - 2.2.5-r5
      libdb - 4.2.52-3
      libgcc - 3.4.4-r3
      libipkg - 0.99.154-r2
      libstdc++ - 5.0.7-6
      libxml2 - 2.6.32-1
      neon - 0.24.7-2
      nslu2-linksys-libs - 2.3r63-r2
      openldap-libs - 2.3.27-3
      openssh - 4.3p2-1
      openssl - 0.9.7d-5
      pcre - 7.7-1
      slingbox - 1.00-r8
      svn - 1.4.6-1
      unslung-rootfs - 2.3r63-r11
      update-modules - 1.0-r4
      which - 2.18-1
      zlib - 1.2.3-2
    • Thomas Reitmayr
      Hi uv7, I also experienced this problem now and then, but recently subversion was hardly usable on my slug. I had to research quite a bit to find the cause of
      Message 2 of 4 , Jun 29, 2008
      • 0 Attachment
        Hi uv7,
        I also experienced this problem now and then, but recently subversion was hardly usable on my slug. I had to research quite a bit to find the cause of the problem, which is rather simple but annoying - the apr library uses /dev/random which seems to run out of entropy on a "quiet" system. Also see this bug report: http://subversion.tigris.org/issues/show_bug.cgi?id=2590 including a quick-and-dirty solution in the very last comment.

        Personally I recompiled apr-1.2.12 with an additional
          EXTRA_OECONF = "--with-devrandom=/dev/urandom"
        which fixes the problem nicely.

        I created an OE bug report to track this issue:
        http://bugs.openembedded.net/show_bug.cgi?id=4395

        Regards,
        -Thomas



        ----- Urspr√ľngliche Mail ----
        Von: ultravio1et7 <ultraviolet7@...>
        An: nslu2-linux@yahoogroups.com
        Gesendet: Samstag, den 7. Juni 2008, 00:20:55 Uhr
        Betreff: [nslu2-linux] SVN Performance Issue

        I am having a strange problem with Subversion "hanging." I have
        svnserve set up the same way that is stated in the guide
        (http://www.nslu2- linux.org/ wiki/Optware/ Svn?from= Unslung.Svn) using
        the inetd.conf method. When I go to preform a checkout on a small
        repository from my workstation it can take up to 1 min for my Slug to
        respond. I logged into the slug to see what might be going on and I
        can see by running a ps -a that the svnserve process is being spawned
        as soon as the request comes in but it just takes forever. I also
        tried shutting down svnserve and starting it back up manually using
        the -d mode but I get the same result.

        The thing that makes this seem really odd to me is that if I am
        browsing around on any of the Samba shares or if I am logged into the
        Slug doing anything that is hitting the disks such as updating with
        ipkg, svnserve does not hang and returns back any of the requests
        immediately.

        Any help tracking this problem down would be greatly appreciated.
        Listed below are the packages I have installed in case it helps
        diagnose this problem.

        adduser - 1.10.2-1
        apr - 1.2.12-1
        apr-util - 1.2.12-1
        cpio - 2.5-r3
        cyrus-sasl-libs - 2.1.20-9
        e2fslibs - 1.40.10-1
        e2fsprogs - 1.40.10-1
        expat - 2.0.1-1
        findutils - 4.1.20-r2
        gdbm - 1.8.3-2
        ipkg - 0.99.154-r2
        ipkg-web - 7-7
        kernel - 2.4.22.l2.3r63- r10
        kernel-image- 2.4.22-xfs
        libc6-unslung - 2.2.5-r5
        libdb - 4.2.52-3
        libgcc - 3.4.4-r3
        libipkg - 0.99.154-r2
        libstdc++ - 5.0.7-6
        libxml2 - 2.6.32-1
        neon - 0.24.7-2
        nslu2-linksys- libs - 2.3r63-r2
        openldap-libs - 2.3.27-3
        openssh - 4.3p2-1
        openssl - 0.9.7d-5
        pcre - 7.7-1
        slingbox - 1.00-r8
        svn - 1.4.6-1
        unslung-rootfs - 2.3r63-r11
        update-modules - 1.0-r4
        which - 2.18-1
        zlib - 1.2.3-2



        Gesendet von Yahoo! Mail.
        Dem pfiffigeren Posteingang.
      • Mike (mwester)
        ... might have devices that do have sufficient entropy. So before we make this a SlugOS-specific build-time thing, is there no way we can change this at run
        Message 3 of 4 , Jul 2, 2008
        • 0 Attachment
          Thomas Reitmayr wrote:
          > Hi uv7,
          > I also experienced this problem now and then, but recently subversion
          > was hardly usable on my slug. I had to research quite a bit to find the
          > cause of the problem, which is rather simple but annoying - the apr
          > library uses /dev/random which seems to run out of entropy on a "quiet"
          > system. Also see this bug report:
          > http://subversion.tigris.org/issues/show_bug.cgi?id=2590 including a
          > quick-and-dirty solution in the very last comment.
          >
          > Personally I recompiled apr-1.2.12 with an additional
          > EXTRA_OECONF = "--with-devrandom=/dev/urandom"
          > which fixes the problem nicely.

          :( For SlugOS, it does -- but it's not nice for other OE users who
          might have devices that do have sufficient entropy. So before we make
          this a SlugOS-specific build-time thing, is there no way we can change
          this at run time? (config file, environment variable, something like that?)

          > I created an OE bug report to track this issue:
          > http://bugs.openembedded.net/show_bug.cgi?id=4395
          >
          > Regards,
          > -Thomas

          Mike (mwester)
        • Thomas Reitmayr
          Hi Mike, AFAIK, systems with sufficient entropy will provide the same or similar level of randomness on /dev/urandom and /dev/random as long as there is enough
          Message 4 of 4 , Jul 2, 2008
          • 0 Attachment
            Hi Mike,
            AFAIK, systems with sufficient entropy will provide the same or similar level of randomness on /dev/urandom and /dev/random as long as there is enough "noise" in the system. With urandom you just cannot guarantee that you get the highest possible randomness. At least that's what "man 4 random" suggests.

            I do not know of any runtime settings which could adjust apr's behavior. But looking at the apache bug report https://issues.apache.org/bugzilla/show_bug.cgi?id=44881 apr 1.3.x seems to have switched to preferring /dev/urandom already, so alternatively the apr recipe could patch configure.in according to
            http://svn.apache.org/viewvc/apr/apr/branches/1.3.x/configure.in?r1=652860&r2=652872&pathrev=652872&diff_format=h
            Unfortunately the subversion bug report does not comment on that change in apr yet...

            -Thomas



            ----- Urspr√ľngliche Mail ----
            Von: Mike (mwester) <mwester@...>
            An: nslu2-linux@yahoogroups.com
            CC: ultraviolet7@...
            Gesendet: Mittwoch, den 2. Juli 2008, 18:43:17 Uhr
            Betreff: Re: [nslu2-linux] SVN Performance Issue

            Thomas Reitmayr wrote:

            > Hi uv7,
            > I also experienced this problem now and then, but recently subversion
            > was hardly usable on my slug. I had to research quite a bit to find the
            > cause of the problem, which is rather simple but annoying - the apr
            > library uses /dev/random which seems to run out of entropy on a "quiet"
            > system. Also see this bug report:
            > http://subversion. tigris.org/ issues/show_ bug.cgi?id= 2590 including a
            > quick-and-dirty solution in the very last comment.
            >
            > Personally I recompiled apr-1.2.12 with an additional
            > EXTRA_OECONF = "--with-devrandom= /dev/urandom"
            > which fixes the problem nicely.

            :( For SlugOS, it does -- but it's not nice for other OE users who
            might have devices that do have sufficient entropy. So before we make
            this a SlugOS-specific build-time thing, is there no way we can change
            this at run time? (config file, environment variable, something like that?)

            > I created an OE bug report to track this issue:
            > http://bugs. openembedded. net/show_ bug.cgi?id= 4395
            >
            > Regards,
            > -Thomas

            Mike (mwester)



            Gesendet von Yahoo! Mail.
            Dem pfiffigeren Posteingang.
          Your message has been successfully submitted and would be delivered to recipients shortly.