Searching Attachments

How long should it take to search attachments if my attachments table is
only 608 rows? Searching the attachments is timing out the 30 second
FastCGI timeout.

Coincidentally, Richard’s problem is the same as mine (apache spins
cpu). I have determined that whenever someone searches for
attachments, the browser times out after a while, but an httpd/mod_perl
process keeps desperately chewing on the problem.

I’m using Postgres 7.3.4. What are you using, Richard?

Is this a known problem?

As per a great hint on the mod_perl man page, I modified RT.pm to dump
stack on receipt of a USR1 signal and signalled a fresh runaway httpd
process after searching by ticket attachment. The results hint where
the problem might be:

(/Library/Perl/Carp.pm:192)
(/usr/local/rt3/lib/RT.pm:253)
/Library/Perl/DBIx/SearchBuilder/Handle/Pg.pm:243
/Library/Perl/DBIx/SearchBuilder.pm:309
/Library/Perl/DBIx/SearchBuilder.pm:211
/Library/Perl/DBIx/SearchBuilder.pm:1284
/usr/local/rt3/lib/RT/Tickets_Overlay.pm:1698
/usr/local/rt3/share/html/Search/Listing.html:104
/usr/local/rt3/share/html/autohandler:163

-Kevin Murphy

-----Original Message-----
From: Kevin Murphy [mailto:murphy@genome.chop.edu]
Sent: Tuesday, September 02, 2003 3:31 PM
To: rt-users@lists.fsck.com
Subject: Re: [rt-users] Searching Attachments

I’m using Postgres 7.3.4. What are you using, Richard?

I’m at Postgres 7.2.1, with Apache/1.3.27 (Unix) Debian GNU/Linux
mod_fastcgi/2.2.10

Oh yeah, and RT 3.0.4

“G. Richard Bellamy” rbellamy@pteradigm.com writes:

How long should it take to search attachments if my attachments table is
only 608 rows? Searching the attachments is timing out the 30 second
FastCGI timeout.

I’ve had the same problem with:

    RT 3.0.5pre3
    PostgreSQL 7.3.4
    Apache 1.3.28
    mod_perl 1.27-r2

When I execute the search, a postmaster process seems to run just for
a few seconds. Then an Apache process spins indefinitely. But the
query never gets logged by PostgreSQL.

I don’t know what the query is, but I tried

SELECT * FROM attachments WHERE content LIKE '%search_term%';

It took over five minutes to complete, but that’s on an attachments
table of 310,000 rows. And at least it did complete–when I do the
search using RT’s web interface, it seems to never complete.

Andrew J. Korty, Principal Security Engineer, GCIA, GCFA
Office of the Vice President for Information Technology
Indiana University

It took over five minutes to complete, but that’s on an attachments
table of 310,000 rows. And at least it did complete–when I do the
search using RT’s web interface, it seems to never complete.

I’m not sure that it ever begins. In my RT 3.0.4 setup with
PostgreSQL, if I search by attachment, the Apache process spins the
CPU, and the query never returns. I learned how to use the perl
debugger within mod_perl and can see that the code is endlessly looping
inside _BuildJoins() in /Library/Perl/DBIx/SearchBuilder/Handle/Pg.pm.
I can see that this is being called in the context of constructing the
query, but don’t yet understand RT internals well enough to figure out
what is creating bad data for _BuildJoins() (or whether there is a
postgres-specific problem somewhere in DBIx::SearchBuilder).

If this is a known problem, hopefully Jesse or someone else could
mention it. Otherwise, if a more knowledgeable programmer doesn’t get
to this first, I wouldn’t mind working on this (slowly, after hours).

-Kevin MurphyOn Wednesday, September 3, 2003, at 08:54 AM, Andrew J. Korty wrote:

“G. Richard Bellamy” rbellamy@pteradigm.com writes:

How long should it take to search attachments if my attachments table
is
only 608 rows? Searching the attachments is timing out the 30 second
FastCGI timeout.

I’ve had the same problem with:

    RT 3.0.5pre3
    PostgreSQL 7.3.4
    Apache 1.3.28
    mod_perl 1.27-r2

When I execute the search, a postmaster process seems to run just for
a few seconds. Then an Apache process spins indefinitely. But the
query never gets logged by PostgreSQL.

I don’t know what the query is, but I tried

SELECT * FROM attachments WHERE content LIKE '%search_term%';