I cannot start V3.2.2.
Squid seems to die in
Ipc::StoreMap::openForReadingAt() - Ipc::ReadWriteLock::lockShared()
at start or first request.
If I undo this change (from
http://www.squid-cache.org/Versions/v3/3.2/changesets/squid-3.2-11649.patch):
-Slot slots[]; /// slots storage
+
I've seen right now the Improve CLANG support and Portable flexible arrays
instead of r12255 threads on squid-dev, that seems exactly to be the issue
that broke SMP, so maybe we get this fixed soon.
Daniel
Daniel Beschorner wrote
I cannot start V3.2.2.
Squid seems to die in
Ipc
Amos Jeffries squ...@treenet.co.nz wrote
On 16.10.2012 10:26, Daniel Beschorner wrote:
I've seen right now the Improve CLANG support and Portable
flexible arrays instead of r12255 threads on squid-dev, that seems
exactly to be the issue that broke SMP, so maybe we get this fixed
soon
On 7/09/2012 2:54 a.m., Daniel Beschorner wrote:
The shared memory cache is harder to follow in its memory use than in 3.1,
Storage Mem size: 2997120 KB
Storage Mem capacity: 95.3% used, 4.7% free
Mean Object Size: 0.00 KB
total used
Thank you for the advice!
We don't use a disk cache, but anyway good to know.
Daniel
031701cd8cc3$c626b7f0$527427d0$@hyperia.com:
Greetings,
For migrating to 3.1 to 3.2 did you have to reinitialize the squid dir.
Had tried to move from 3.1 to 3.2 a couple of times but was unsuccessful.
On 7/09/2012 2:54 a.m., Daniel Beschorner wrote:
The shared memory cache is harder to follow in its memory use than in 3.1,
am I right that the cached value of the free output is somehow related
due to shared mem?
Where are you spotting this?
I'm trying to get the feel of tuning
Congratulations on the 3.2 release!
It seems quite stable in our 1000 client environment, good work!
Some first impressions after using it for some days (Linux x64, no disk cache,
SMP mode with 2 workers):
On an old server (SLES 10) the load sharing between workers (2 or 4) is pretty
bad, in
There is also a strange 1-byte body attached. It could be the body
pipeline or network I/O functions hung waiting for more data in order to
prevent single-byte packets.
Amos
Hi Amos,
exactly this seems to be the point, but in an other way!
I think the patch fails to do the contentSize =
I think the patch fails to do the contentSize = 1 handling correctly,
because the bytesWanted call returns ambiguously 0 in case of contentSize =
1.
Daniel
Filed by another user as http://bugs.squid-cache.org/show_bug.cgi?id=3466
So we can close this here.
Thank you!
Daniel
One month ago I reported an ICAP regression in 3.1.17/18.
In meantime I tracked down the problem to patch 10403 (Bug 2619).
Maybe it helps to find the issue.
Thank you
Daniel
After upgrading to 3.1.18 (+adaption compile patch) the following url =
never stops loading in the browser
After upgrading to 3.1.18 (+adaption compile patch) the following url never
stops loading in the browser
http://x.ligatus.com/cgi-bin/ivw/CP/11260-365/83-1056/129647-107545-_129709-105679-_128565-101085-//
If I bypass the ICAP server for this url (which is indeed a redirect to
We use Squid 3.1.12 with TrendMicro IWSVA as ICAP server and early responses
enabled.
I see a lot of ICAP connections hanging in FIN_WAIT1 state (with large
Send-Q) on IWSVA and CLOSE_WAIT state on squid box (with large Recv-Q).
Cache manager shows them as idle connections.
Can it be one
http://www.squid-cache.org/Versions/v3/3.1/changesets/squid-3.1-10323.patch
seems to break my not-IPV6-enabled system on start:
comm_open: socket failure: (97) Address family not supported by protocol
FATAL: Could not create a DNS socket
Daniel
No. Squid should be draining its queue, even if leaving the connections
idle. Being in the idle pool sets a read to abort/close the socket on
FIN or on excess data.
This does sound like those ICAP incomplete reply problems. Though how
its getting into Squids idle pool without the act of
Just for interest I'll give icap_persistent_connections off a try.
Daniel
Now it looks in cache manager like that (former idle):
81 Socket0 7097799383 ICAP-Server:1344
icap://ICAP-Server/RespMod-Service
No asterisk
Daniel
Connections with FIN_WAIT1 state on ICAP server side seem ESTABLISHED at
squid.
ICAP-closed connection.
Idle pconn in Squid have readers set listening for FIN to arrive and
close the FD. This is strange but not conclusive.
Looks a bit like the FIN never arrived.
Squid
Which manager report? idle connections is a bit messy in the current
stables. It should only refer to the persistent, open, but not currently
in-use connections. The tag is left set sometimes and shows up on closed
ones.
Under File Descriptor Allocation.
If Squid actually sees them as
We use Squid 3.1.12 with TrendMicro IWSVA as ICAP server and early responses
enabled.
I see a lot of ICAP connections hanging in FIN_WAIT1 state (with large Send-Q)
on IWSVA and CLOSE_WAIT state on squid box (with large Recv-Q).
Cache manager shows them as idle connections.
Can it be one of the
18 matches
Mail list logo
