Thanks Mike, that seems to be the reason. I'm using a system-provided APR
AFAIR and it probably uses the blocking /dev/random for security reasons.
Using this
rngd -r /dev/urandom -o /dev/random -f -t 1
seems to alleviate the problem without recompiling APR.
Found it on this blog:
http://www.chrissearle.org/blog/technical/increase_entropy_26_kernel_linux_box
~Neels
C. Michael Pilato wrote:
> Neels J. Hofmeyr wrote:
>> Stefan Sperling wrote:
>>> On Thu, Oct 09, 2008 at 07:28:43AM +0200, Neels J Hofmeyr wrote:
>>>> Also, I haven't actually checked *all* of the commandline tests. It takes
>>>> ages to complete, with apparent longer breaks of doing nothing at all, when
>>>> watching the CPU and disk activity.
>>>>
>>>> And then I have to run it twice, once for trunk and once for my patch, to be
>>>> able to compare test outcomes. How do you handle this kind of situation?
>>> Use a RAM disk to host temporary test data.
>>> See http://subversion.tigris.org/faq.html#ramdisk-tests
>> So I did that. But still, running merge_tests.py --cleanup in the ramdisk
>> has random pauses of all activity for sometimes as much as 15 seconds.
>> That's ridiculous. Why can't it just race through the tests, idling at most
>> a second at a time? Why is my CPU staying cold?
>>
>> I've also seen that if I run a single test, it goes swiftly. Then, if I run
>> a whole list of them, there appear to be completely random pauses between
>> the tests sometimes, and sometimes not. It's weirding me out...
>
> I'm guessing it's a lack of entropy? See if during your pauses things go
> faster when you jiggle your mouse. (And then try compiling APR with
> --with-devrandom=/dev/urandom so you don't have to do said jiggling all the
> time.)
>
>
Received on 2008-11-01 06:20:22 CET