Re: Broken Pipe Exception - failed reporting to console

Hi Lei,

You may want to check the number of file descriptors you can have open.
 IIRC, if you run out of descriptors or locks you will get broken pipe
exceptions.  A message should also be logged in /var/log/syslog (which is
always a good place to start troubleshooting these types of errors....) and
with any luck it will provide some additional information around the
exception.  Make sure you check the syslogs on both the console and agent
machines.

See
http://glassonionblog.wordpress.com/2013/01/27/increase-ulimit-and-file-descriptors-limit/
for details on setting ulimits and max number of locks.

Hope this helps.

-Marc






On Tue, Aug 26, 2014 at 3:30 PM, Lei <[email protected]> wrote:

> On Mon, Aug 25, 2014 at 7:18 AM, Gary Mulder <[email protected]>
> wrote:
>
>> On 25 August 2014 08:34, Joan Picanyol i Puig <[email protected]>
>> wrote:
>>
>>> * Lei <[email protected]> [20140823 16:20]:
>>
>>  > However once the agent start testing, it failed reporting to console
>>> with
>>> > below Broken Pipe exception.
>>>
>>> My bet is that you are trying to create processes and/or threads
>>> too fast and overloading your agent. I suggest trying to diagnose wether
>>> it is a maximum agent load issue or a rate issue (i.e.: wether you can
>>> create the intended load over a longer timeframe).
>>>
>>
>> To confirm whether Joan's theory is correct run some commands on the
>> agent to measure load. On Linux run:
>>
>>  $ vmstat 3
>> procs -----------memory---------- ---swap-- -----io---- -system--
>> ----cpu----
>>  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy
>> id wa
>>  5  1      0 26217732 149992 2266752    0    0     0     3    8   10  0
>>  0 100  0
>>  7  0      0 26217116 149992 2266780    0    0     0     1 76425 91969 13
>> 14 73  0
>>
>> The r column shows how many threads want to run on average. lsof -i is
>> another useful command to confirm you're not running out of TCP/IP sockets
>> (maximum 32K allowed).
>>
>> Of course if you're running Windows it might be harder to see if you're
>> hitting resource limits...
>>
>> Regards.
>> Gary
>>
>>
> Thank you pica and Gary!
>
> I didn't see the heavy load on the console. Looks like once the agent gets
> some load (more than 100 TCP connections), the connection between agent and
> console becomes unstable.
>
> I have tested different configuration from grinder properties. Here are
> some observations:
>
> Reduce the number of below two properties to some small number, the
> problem goes a way. But it defeat the purpose of load testing.
>
>  grinder.processes
>  grinder.threads
>
> Reducing grinder.processIncrement and grinder.initialProcesses and
> increasing grinder.processIncrementInterval can mitigate or delay this
> problem sometimes.
>
> Since I didn't find any better way to resolve this issue, I might just go
> with agent without console, and use "grinder to graphite" (
> https://bitbucket.org/travis_bear/grinder_to_graphite) for collecting
> testing result.
>
> Thanks,
> Lei
>
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> grinder-use mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/grinder-use
>
>

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/

_______________________________________________
grinder-use mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/grinder-use