Open GoogleCodeExporter opened 8 years ago
Very same issue here with similar helper and also another pretty different
setup with an ldap-policy external acl helper I just downloaded from somewhere.
Queue always overloads and the system has to be restarted.
Original comment by eks...@gmail.com
on 8 Aug 2010 at 4:03
Me too \0/ (starred).
I'm in the same trouble, it makes external acl a forbidden feature to me. I use
this approach to send selective traffic to Thunder Cache parent proxy. I have
raised ttl and negative_ttl to 1 week (604800) and it helped a lot for a while.
I was confident it solved the problem, but then the first http virus reached
the network, Queue Overloaded.
I have also tried a helper which would allow simultaneous check. Failed worse,
Queue overloading too.
Original comment by florzinh...@gtempaccount.com
on 9 Aug 2010 at 1:29
Ok. The unfortunate problem? The external ACL helper code sets "queue too long"
as being "more pending requests than number of processes configured."
This likely isn't very good. :-)
I'll investigate it a bit more, but it does look like there's plenty of space
to improve.
You can try fixing this by bumping up the number of pending helper operations.
Edit src/external_acl.c ; find externalAclOverload() (around line 499.) Then
modify:
return def->helper->stats.queue_size > def->helper->n_running;
To something like:
return def->helper->stats.queue_size > (def->helper->n_running + 100);
That way it'll only return overload if there's more than 100 pending operations
+ number of helpers running. I bet you can bump it up a bit more (say to 500? :)
Original comment by adrian.c...@gmail.com
on 19 Oct 2010 at 3:38
Hiya,
Please try updating to r14810 and configuring "external_acl_maxqueue" in
squid.conf to something. Say, configure 16 ACL helpers and set the maxqueue to
256.
Original comment by adrian.c...@gmail.com
on 21 Oct 2010 at 2:02
I have set 8 helpers (2*hw.ncpu) and the new feature external_acl_maxqueue to
100 as per the earlier comment, and it overloaded again very early; I have 'm
raised to 120, 260, and now it's 300. It didnt overload yet but things are
getting slow. It seems that requests are taking too long to get processed. I
will raise helpers to 32, which is 8*hw.ncpu; expect load averages to raise.
Feedback by tomorrow after the "internet rush hour" in GMT-3.
Any suggestions to improve the tests will be configure.
I am using a similar helper as Meyer as posted, but I have hardwritten the
matches into the code to avoid unecessary loops.
It's a 34Mbit/s link with only 12 expressions to be matched.
Original comment by eks...@gmail.com
on 21 Oct 2010 at 6:35
Hm. The helper code looks sensible enough. It does one read and then dequeues
as many responses as it can from the helper. I'll go see if it's actually
enqueueing multiple simultaneous requests to a helper.
Original comment by adrian.c...@gmail.com
on 22 Oct 2010 at 12:54
.. but it looks like it'll only enqueue multiple requests at once if the
concurrency option isn't enabled. Perhaps that is it?
You'll have to edit your helper to work with that. I'll go do some local tests
and get back to you.
Original comment by adrian.c...@gmail.com
on 22 Oct 2010 at 12:58
Yes, concurrency is not enabled. Only multiple helpers. I will look for a
concurrency-ready helper written in any language so I can understand what's the
difference to rewrite my helper.
Original comment by dudu.me...@gmail.com
on 22 Oct 2010 at 11:58
BTW, eksffa is helping on my own server. One of 'em at least. So we are talking
about the same environment.
Original comment by dudu.me...@gmail.com
on 22 Oct 2010 at 12:02
good day sir,
how to convert regex.c to linux bases (gcc)
i try compile on linux fedora filed
cc regex.c -o regex
regex.c: In function âmainâ:
regex.c:219: error: âstruct statâ has no member named âst_mtimespecâ
regex.c:231: error: âstruct statâ has no member named âst_mtimespecâ
regex.c:232: error: âstruct statâ has no member named âst_mtimespecâ
regex.c only for freebsd based (cc) ??
Original comment by fahmi...@gmail.com
on 23 Oct 2010 at 7:56
Original issue reported on code.google.com by
dudu.me...@gmail.com
on 6 Aug 2010 at 10:01