[users at i-scream] statgrab freezes Solaris 10

[Jens Rehsack]

2011/7/20 CISSE Amadou <cisse.amadou.9 at gmail.com>:

Hi,

first a word on netiquette:
please always CC the list (use reply all), otherwise I will assume a business
support request to me which needs to be agreed and signed before I answer
any mail.

> On Tue, Jul 19, 2011 at 2:37 PM, Jens Rehsack <rehsack at googlemail.com>
> wrote:
>>
>> 2011/7/19 CISSE Amadou <cisse.amadou.9 at gmail.com>:
>> > Hi,
>>
>> Hi,
>>
>> > I'm using libstatgrab with solaris 10,
>> > whenever i launch the statgrab program, solaris10 freezes for a while 6+
>> > minutes, before statgrab shows the result.
>>
>> Without comparing my local "fixes" with the 0.17 release state, do you
>> test in a zone with some resources capped?
>>
>> Does the system really freezes or does statgrab simply takes a while to
>> display the results?
>
> The system freezes until statgrab returns (successfully with the results)
> which takes 6+ minutes
>
>>
>> What kind of machine do you use for testing (E250?)
>>
>
> Right now, i'm testing on a virtualbox solaris 10 2010.09.

Well, we (me and some friends) noticed that Solaris doesn't run very well
in VirtualBox. I can confirm that everything running on a test installation
of Solaris 10 in VirtualBox runs very slow, but I can't detect specific slowdown
of any stagrab function.

Probably you can use truss (or dtrace, when it seems to be library internal)
to detect where it waits in your specific situation.

> However, i did
> the same tests on other solaris10 on sparc servers with the same result(the
> system blocks until statgrab returns).

Sounds scary to me. We noticed a process block when calling
sysconf(_SC_PHYS_PAGES)
and sysconf(_SC_AVPHYS_PAGES) in some Solaris zones, when resource capping on
memory is used. But this blocking comes from the system call and will
affect every
process calling this.

Please use truss (or dtrace) to evaluate where it wastes time.

>> > 1. I install libstatgrab 0.17 from source.
>> > 2. i run it manually for each query, cpu. mem. etc., they each caused
>> > the
>> > system to freeze the same but for lesser amounts of time.
>> > I'm sort of a newbie on solaris, if anyone has had a similar problem
>> > before,
>> > please help.
>>
>> Can you verify if it takes the same time when using the statgrab from
>> http://www.netbsd.org/~sno/smart-snmpd/?
>>
>
> I tried to compile 2011-06.09-libstatgrab but got the following errors (gcc
> version is 3.4.3):
> In file included from err.c:2:
> testlib.h:51: error: syntax error before "bool"
> testlib.h:51: warning: no semicolon at end of struct or union
> testlib.h:51: warning: no semicolon at end of struct or union
> testlib.h:53: error: syntax error before '}' token
> testlib.h:53: error: conflicting types for 'optarg'
> /usr/include/unistd.h:342: error: previous declaration of 'optarg' was here
> testlib.h:53: error: conflicting types for 'optarg'
> /usr/include/unistd.h:342: error: previous declaration of 'optarg' was here
> testlib.h:53: warning: data definition has no type or storage class
> testlib.h:54: error: syntax error before '}' token
> *** Error code 1
> make: Fatal error: Command failed for target `err.o'
> Current working directory /Libstatgrab/libstatgrab/tests/testlib
> *** Error code 1
> The following command caused the error:
> fail= failcom='exit 1'; \
> for f in x $MAKEFLAGS; do \
>   case $f in \
>     *=* | --[!k]*);; \
>     *k*) failcom='fail=yes';; \
>   esac; \
> done; \
> dot_seen=no; \
> target=`echo all-recursive | sed s/-recursive//`; \
> list='testlib single_threaded multi_threaded'; for subdir in $list; do \
>   echo "Making $target in $subdir"; \
>   if test "$subdir" = "."; then \
>     dot_seen=yes; \
>     local_target="$target-am"; \
>   else \
>     local_target="$target"; \
>   fi; \
>   (CDPATH="${ZSH_VERSION+.}:" && cd $subdir && make  $local_target) \
>   || eval $failcom; \
> done; \
> if test "$dot_seen" = "no"; then \
>   make  "$target-am" || exit 1; \
> fi; test -z "$fail"
> make: Fatal error: Command failed for target `all-recursive'
> So i commented out the docs and tests folder from the macros DIST_SUBDIRS
> and SUBDIR in the Makefile.

This was a bug and is fixed in the recent uploaded snapshot. Thanks
for reporting.

> The compilation now works but the result is the
> same (the entire system freezes while statgrab runs):
> $ time statgrab
> ...
> real    3m46.741s
> user    0m0.019s
> sys     3m46.007s

# time src/statgrab/statgrab | wc -l
     363

real    0m0.504s
user    0m0.170s
sys     0m0.295s

On a Ultra-60 machine (UltraSparc IIi 233MHz). Seems not a statgrab problem.

Best regards,
Jens

>> > Cheers.
>> > --
>> > Amadou CISSE
>> > Software Engineer
>> > Tel: +212 656 524 294
>>
>> Best regards,
>> Jens
>
> cheers.
>
> --
> Amadou CISSE
> Software Engineer
> Tel: +212 656 524 294
>