[Perfparse-devel-int] Re: [Perfparse-users] perfparsed & CPU usage

[Yves <yme...@pe...>]

> Yves,
> How much do I get if I told you I've found the solution?

31 more characters in the ChangeLog, and some public thanks in the announ=
ce of
pp-0.104.2 that may be released this week :)

> :)

:)

About the 31 characters, I suggest "Tim Wuyts <tim...@gm...>" :)
Do you agree ?

> OK, I admit, it seems odd, but I've encountered this next comment in a
> piece of Perl (yes, Perl) code:
> # Open the fifo read/write, not just read. This is necessary because
> # of the POSIX rules about using select() on named pipes when no writer=
s
> # are present. This is a very key step that is hard to find documentati=
on
> # about.
>
> (note the last sentence!)

I confirm...
My searchs showed me that there was an additionnal bug : before the 1st w=
rite to the
fifo, perfparse would have hanged on that open(fifo, O_RDONLY).
Using O_RDONLY |O_NONBLOCK fixes that bug, but select() still immediately=
 returns.
Using O_RDWR works and O_NONBLOCK is not necessary for open() :)


> So I tried exactly that:
> change
> log_fd[i]->fd =3D open(filename+1, O_RDONLY);
> to
> log_fd[i]->fd =3D open(filename+1, O_RDWR);
>
> and that's it ! Works in 103.2 and 104.1
> (perfparsed 104.1 compiles, but doesn't write anyhting to the db...
> :(, but that's another problem I guess. More tomorrow... )

For the database, the problem is maybe dlopen() not working. A possible r=
eason is
libpp_storage_mysql not being in a PATH that ld.so knows. On GNU/Linux, e=
dit
/etc/ld.so.conf then run ldconfig. On other systems (including GNU/Linux =
if you don't
want to edit /etc/ld.so.conf) change your $LD_LIBRARY_PATH env var.

Could you tell me any error message that you have ? I'd like to find wher=
e I should stop
the execution of perfparse when there is a problem with the db.

> happy coding,

Thanks :)
And you, happy debugging :)

Yvse

> Tim
>
> On Fri, 26 Nov 2004 17:08:42 +0100 (CET), Yves <yme...@pe...>=
 wrote:
>>
>> > Yves,
>> >
>> > Recompiling with the log_source_nonblock(i)  line commented out does
>> > not change anything. The CPU still sky-rockets, and the 4 lines stil=
l
>> > show up (a gazillion times) in strace output.
>>
>> So I just suggest that you upgrade to 0.104.1 this week-end, when Ben =
releases it, and
>> I
>> will try to find out why there is always something to read on the pipe=
 for select().
>>
>> The only thing I can suggest you now, if you really want a hacked solu=
tion, is to put
>> this in log_reader() :
>>
>> while(10 =3D=3D (r=3Dread(...))) {
>>   ...
>> }
>> if((r>0) && (r<10)) {
>>    ...
>> } else if(r =3D=3D 0) {
>>   sleep(1);
>> }
>>
>> Add the 2 last lines to sleep the program when it reads nothing. The C=
PU should still
>> sky-rocket, but passengers will now have 1 second to get inside the ro=
cket :)
>>
>> I will try to find something better for 0.104.2 or 0.105 or course :)
>>
>> Yves
>> PS. uncomment back log_source_nonblock(i) because it may have side eff=
ects.
>>
>> --
>>
>>
>> - Homepage    - http://ymettier.free.fr - http://www.logicacmg.com -
>> - GPG key     - http://ymettier.free.fr/gpg.txt                    -
>> - Maitretarot - http://www.nongnu.org/maitretarot/                 -
>> - Perfparse   - http://perfparse.sf.net/                           -
>>
>>
>
>


--=20
- Homepage    - http://ymettier.free.fr - http://www.logicacmg.com -
- GPG key     - http://ymettier.free.fr/gpg.txt                    -
- Maitretarot - http://www.nongnu.org/maitretarot/                 -
- Perfparse   - http://perfparse.sf.net/                           -