On 2013-11-19 08:09, Dr.x wrote:
hi ,
i have smp with config as below :
###########SMP oPTIONS#####################
dns_v4_first on
workers 3
########################################################
cpu_affinity_map process_numbers=1,2,3,4 cores=2,4,6,8
======================================
cache_dir rock /CACHE1 20000 max-size=32768 swap-timeout=350
max-swap-rate=350
cache_dir rock /CACHE2 20000 max-size=32768 swap-timeout=350
max-swap-rate=350
==================================================================
*to be honest , i did alot of killall -9 squid while squid was starting
and
building files !!!!!*
and just addedd directive logfile_rotate 0
that wt i remebers before i saw that new error in cache.log !!!
but today after that modification i see alot of "FATAL: Received
Segment
Violation...dying."
especially for kid 3 !!!!!
and seems that kid 3 killed then started agian , killed then started
again
and so on .
dont know shoulld i remove logrotate directive , or may the rock db
damaged and cause this dying signal ???!!!
Either event may have corrupted it slightly. Squid is supposed to
contain sufficient checksum protection in rock to cope with most forms
of corruption, but nobody's perfect.
So, please try to get a core dump, or stack trace of the problem before
going any further. This will help us to isolate where the problem is
occuring. If it is corruption related we will be needing to try and add
better protection for that case.
*after* that, please try:
* shutting Down your Squid by any means necessary to ensure there are 0
processes running.
* *move* the caches to somewhere they can be analysed later if
necessary.
* rebuild the configured cache_dir with squid -z
* wait until -z process completed *AND* there are 0 processes still
running in the background
* restart the main Squid
This entire process should not take more than a minute.
If the problem remains after doing that you will have successfully
eliminated cache corruption as a cause and we go back to needing a
backtrace to figure it out.
Amos
