Re: [squid-users] squid consuming near all (95+ %) CPU, it is normal?

On 22/11/2012 12:32 a.m., Frantisek Hanzlik wrote:
> Amos Jeffries wrote:
>> On 20.11.2012 09:33, Frantisek Hanzlik wrote:
>>> Amos Jeffries wrote:
>>>> On 12.11.2012 03:25, Frantisek Hanzlik wrote:
>>>>> With this squid configuration:
> ...<snip>
>>> And then I found in /var/log/messages these lines
>>> (/var/log/squid/cache.log contained nothing suspicious(*) ):
>>>
>>> Nov 19 16:53:40 172 squid[2834]: Squid Parent: (squid-1) process 32702
>>> exited due to signal 6 with status 0
>> Ouch. That needs to be found and fixed.
>> Are you able to assist with that by running Squid under a debugger and
>> getting a backtrace?
>> (http://wiki.squid-cache.org/SquidFaq/BugReporting#Using_gdb_debugger_on_a_live_proxy_.28with_minimal_downtime.29)
>>
>>
>> <snip repeats>
> ... <snip repeats>
>
> Within several hours I have six core dumps:
> # LANG=C ls -l
> -rw------- 1 squid squid 31424512 Nov 21 06:03 core.15363
> -rw------- 1 squid squid 75161600 Nov 21 06:54 core.17776
> -rw------- 1 squid squid 19992576 Nov 21 06:54 core.18266
> -rw------- 1 squid squid 91512832 Nov 21 07:27 core.18272
> -rw------- 1 squid squid 144785408 Nov 21 07:46 core.18579
> -rw------- 1 squid squid 361881600 Nov 21 09:14 core.18754
> -rw------- 1 squid squid 307638272 Nov 21 11:46 core.19564
>
> Backraces (without core.15363, it was in previous mail) are:
>
> # for i in core.17776 core.18266 core.18272 core.18579 core.18754 core.19564; do echo -e "\n#gdb ./$i :"; gdb -batch -x gdb.commands ./$i; done
<snip duplicate traces>
> #gdb ./core.19564 :
> [New Thread 19564]
> Missing separate debuginfo for
> Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/c4/1c574f31a203492b9389c783adad6ff1989915
> [Thread debugging using libthread_db enabled]
> Core was generated by `(squid-1) -f /etc/squid/squid.conf'.
> Program terminated with signal 6, Aborted.
> #0 0x0032b424 in __kernel_vsyscall ()
> #0 0x0032b424 in __kernel_vsyscall ()
> #1 0x0055f2f1 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #2 0x00560d5e in abort () at abort.c:92
> #3 0x00557c08 in __assert_fail (assertion=0x83cf443 "false", file=0x83ff936 "Address.cc", line=689, function=0x83ffca0 "void Ip::Address::GetAddrInfo(addrinfo*&, int) const") at assert.c:81
> #4 0x082e1b60 in Ip::Address::GetAddrInfo (this=0x177e1f34, dst=@0xbf9db7dc, force=0) at Address.cc:689
> #5 0x082da72b in comm_openex (sock_type=1, proto=6, addr=..., flags=1, tos=0 '\000', nfmark=0, note=0x1b023308 "[2a02:598:1::9999]") at comm.cc:525
> #6 0x0832fd65 in Comm::ConnOpener::start (this=0xe7fdf08) at ConnOpener.cc:164
> #7 0x082d13be in NullaryMemFunT<AsyncJob>::doDial (this=0x1b01e594) at ../../src/base/AsyncJobCalls.h:101
> #8 0x082d15d6 in JobDialer<AsyncJob>::dial (this=0x1b01e594, call=...) at ../../src/base/AsyncJobCalls.h:175
> #9 0x082d1775 in AsyncCallT<NullaryMemFunT<AsyncJob> >::fire (this=0x1b01e578) at ../../src/base/AsyncCall.h:142
> #10 0x082ce34b in AsyncCall::make (this=0x1b01e578) at AsyncCall.cc:36
> #11 0x082d196b in AsyncCallQueue::fireNext (this=0x95966f0) at AsyncCallQueue.cc:54
> #12 0x082d1ae0 in AsyncCallQueue::fire (this=0x95966f0) at AsyncCallQueue.cc:40
> #13 0x0818edc0 in EventLoop::dispatchCalls (this=0xbf9dbbd4) at EventLoop.cc:154
> #14 0x0818eff7 in EventLoop::runOnce (this=0xbf9dbbd4) at EventLoop.cc:131
> #15 0x0818f0e0 in EventLoop::run (this=0xbf9dbbd4) at EventLoop.cc:95
> #16 0x081ff650 in SquidMain (argc=3, argv=0xbf9dbd44) at main.cc:1500
> #17 0x0820076f in SquidMainSafe (argc=3, argv=0xbf9dbd44) at main.cc:1215
> #18 main (argc=3, argv=0xbf9dbd44) at main.cc:1207
>
> Although core dump image are from 20MB to 362MB size, all backtraces are similar.
> Can I, please, do anything further?

Hmm. IPv6 destination address being connected to by an IPv4-only host. Oops.

Squid only fetches A records when IPv6 is disabled which should have
been enough to prevent IPv6 destinations being found. But possibly this
is a DNS resolver packing AAAA results in to an A lookup, or a raw-IP
request from the client. It is possible those might get into the
connection setup list.

Does this patch fix it for you?
http://treenet.co.nz/projects/squid/patches/Hanzlik_crash_s32_mk1.patch

Apply with "patch -p0" on squid 3.2

Amos
Received on Thu Nov 22 2012 - 10:03:07 MST