|
From: Leif M. <lei...@ta...> - 2010-07-27 08:56:04
|
Holger,
The main wrapper loop has a 100ms sleep in it, so it loops 10 times
per second. The Wrapper only pings the JVM once every 5 seconds by
default.
The 10 loops per second is low enough that it is trivial with respect
to performance, but the loop is tight enough to make the Wrapper feel
very responsive.
Cheers,
Leif
On Tue, Jul 27, 2010 at 5:38 PM, Isenberg, Holger <ise...@e-...> wrote:
> It doesn't cause any problems, I'm only wondering if the high frequency of calls per second is normal as we have other problems on that system and I just checked with strace. I thought the wrapper only checks about 1 time per second.
>
>
> --
>
> Holger Isenberg
> e-Spirit AG
>
>
>
>> -----Original Message-----
>> From: Leif Mortenson [mailto:lei...@ta...]
>> Sent: Monday, July 26, 2010 1:05 PM
>> To: wra...@li...
>> Subject: Re: [Wrapper-user] Many syscalls per second: EAGAIN
>> (Resourcetemporarily unavailable)
>>
>> Holger,
>> The Wrapper used to be a single threaded application. Its main loop
>> still does non-blocking reads on the pipes and sockets. I believe this
>> is what you are seeing.
>>
>> Is this causing any problems? It is possible to change this logic and
>> use more dedicated threads if necessary. I would appreciate your
>> input here.
>>
>> Cheers,
>> Leif
>>
>> On Mon, Jul 26, 2010 at 6:32 PM, Isenberg, Holger
>> <ise...@e-...> wrote:
>> > Hallo,
>> >
>> > when monitoring the wrapper process with "strace -p
>> Wrapper-PID" on Linux, I'm wondering about the high frequency
>> of read() and recvfrom() calls on the pipe and TCP socket
>> connection to the Java process and each of them returning
>> with "EAGAIN (Resource temporarily unavailable)". The
>> frequency is about 10 per second.
>> >
>> > Is this a bug of strace or does the wrapper calls these
>> functions really that fast and why don't they block when
>> waiting for data?
>> >
>> > STATUS | wrapper | 2009/07/10 12:04:50 | --> Wrapper
>> Started as Daemon
>> > STATUS | wrapper | 2009/07/10 12:04:50 | Java Service
>> Wrapper Standard Edition 64-bit 3.3.5
>> >
>> > Linux [...] 2.6.26-2-amd64 #1 SMP Wed Aug 19 22:33:18 UTC
>> 2009 x86_64 GNU/Linux
>> >
>> > java version "1.6.0_21"
>> > Java(TM) SE Runtime Environment (build 1.6.0_21-b06)
>> > Java HotSpot(TM) 64-Bit Server VM (build 17.0-b16, mixed mode)
>> >
>> > gettimeofday({1280134204, 517914}, NULL) = 0
>> > read(5, 0x7fff030c5130, 1024) = -1 EAGAIN
>> (Resource temporarily unavailable)
>> > gettimeofday({1280134204, 518004}, NULL) = 0
>> > recvfrom(7, 0x7fff030c554f, 1, 0, 0, 0) = -1 EAGAIN
>> (Resource temporarily unavailable)
>> > wait4(30121, 0x7fff030c5544, WNOHANG|WSTOPPED, NULL) = 0
>> > nanosleep({0, 100000000}, NULL) = 0
>> > gettimeofday({1280134204, 618287}, NULL) = 0
>> > read(5, 0x7fff030c5130, 1024) = -1 EAGAIN
>> (Resource temporarily unavailable)
>> > gettimeofday({1280134204, 618392}, NULL) = 0
>> > recvfrom(7, 0x7fff030c554f, 1, 0, 0, 0) = -1 EAGAIN
>> (Resource temporarily unavailable)
>> > wait4(30121, 0x7fff030c5544, WNOHANG|WSTOPPED, NULL) = 0
>> > nanosleep({0, 100000000}, NULL) = 0
>> > gettimeofday({1280134204, 718729}, NULL) = 0
>> > read(5, 0x7fff030c5130, 1024) = -1 EAGAIN
>> (Resource temporarily unavailable)
>> > gettimeofday({1280134204, 718831}, NULL) = 0
>> > recvfrom(7, 0x7fff030c554f, 1, 0, 0, 0) = -1 EAGAIN
>> (Resource temporarily unavailable)
>> > wait4(30121, 0x7fff030c5544, WNOHANG|WSTOPPED, NULL) = 0
>> > nanosleep({0, 100000000}, NULL) = 0
>> > gettimeofday({1280134204, 819092}, NULL) = 0
|