Bug 50146 - DansGuardian proxy filter painfully slow with glibc 2.2.2-10
DansGuardian proxy filter painfully slow with glibc 2.2.2-10
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
7.1
i586 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-07-27 04:57 EDT by Sergey Shanygin
Modified: 2016-11-24 10:01 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-10-03 05:33:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Sergey Shanygin 2001-07-27 04:57:33 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)

Description of problem:
Hardware-pentium 133 w. 64 MB Ram, RH 7.1 distribution obtained from RH 
ftpsite running Squid 2.4stable1 with SquidGuard and DansGuardian. On the 
text-laden pages DansGuardian processes extremely slow, cirka 5 minutes 
for less than 200k of text.

Upon discussion in the DG forum, the problem was pinpointed to glibc. (see 
except at the bottom). I downloaded and replaced glibc with the version 
2.2.3-14 (rpm -Fvh did not work, it complained at the dependencies.) I 
used rpm -Fvh --nodeps, it installed OK.

Unfortunately, (day after) I see it broke at least samba (mount -t smbfs -
o username=xxx,password=yyy /mnt/zzz //winserver/share does not work 
anymore, and who knows what else).

Anyway, the original problem (slowness of DG) was cured with this 
crude "upgrade".

Oh, yes, in wait for RH 7.2 - I-ll appreciate any good advice how to 
correct broken dependencies... I am not overly expert in Linux, working 
mostly with Windows so far, although by far not linux-illiterate.
Best wishes. Sergey.

Except of original discussion with Daniel Barron, author of DG follows:
> On Wed, Jul 18, 2001 at 10:58:27PM +0000, Daniel Barron wrote:
> > Without any problems, I am able to completely replicate the slowness 
problem.
> > 
> > It does not lie in nb++, or DansGuardian.  The problem occurs with 
both DG1 and DG2.  nb++ is not used in DG2.
> > 
> > When the following function is called:
> > #include <regex.h>
> > int regexec(const   regex_t  *preg,  const  char  *string,
> >             size_t  nmatch,   regmatch_t   pmatch[],   int flags);
> > 
> > ...in either nb++(DG1) or DG2, it maxes the cpu out for ages.  It does 
return, eventually, and it does return the correct answer.
> > > 
> > I strongly suspect it is a bug in RH7.1 now.  Can anyone help?
> 
> This function is defined in glibc, so you'll need a glibc upgrade to fix 
it.


How reproducible:
Always

Steps to Reproduce:
1.Install RH7.1, Squid 2.4stable1, DansGuardian 1.1.4

Actual Results:  access heavy-laden with text website, observe the 
slowness. Top indicates how dansguardian maxes the CPU, tying the machine.

Expected Results:  reasonable processing

Additional info:

rpm -Fvh --nodeps glibc 2.2.3-14, reboot, repeat access to web, observe 
that slowness goes away.

This bug does not exist in RH 6.2 (I heard not in 7.0 either)
Comment 1 Jakub Jelinek 2001-08-03 12:58:06 EDT
glibc in RHL 7.1 has multi-byte character set support in regex, the one in
rawhide has most of regex code compiled in twice, once for single-byte
character sets which is considerably faster and once for multi-byte character
sets.
I don't know which dependencies was rpm complaining about, but it certainly
matters a lot, --nodeps has to be used with care.
Were you rpm -Fvh glibc and glibc-common at the same time at least?
Comment 2 Sergey Shanygin 2001-08-14 03:28:04 EDT
>Were you rpm -Fvh glibc and glibc-common at the same time at least?
Yes, I took glibc, glibc-common and glibc-devel just to be sure.
Comment 3 Ulrich Drepper 2003-10-03 05:33:05 EDT
The slowdown might indeed be caused by regex with multibyte char support.  Star
tthe process in the C locale if you don't need internationalization.  In any
case, this is old code.  Try a recent version.  I close this as not a bug since
the slowdown is expected and can be avoided where possible.

Note You need to log in before you can comment on or make changes to this bug.