Re: [squid-users] FATAL: xcalloc

On Friday 18 November 2005 14:23, Tomas Palfi wrote:
> Denis,
>
> That's a fair comment but it doesn't look as if it's running out of
> memory. It's like as if the OS did not want to release more memory for
> squid or something. But just for information that's top output.
>
> last pid: 21404; load averages: 0.00, 0.01, 0.00 up 36+23:31:29 12:11:02
> 55 processes: 1 running, 54 sleeping
> CPU states: 0.0% user, 0.0% nice, 1.2% system, 7.8% interrupt, 91.1% idle
> Mem: 515M Active, 1106M Inact, 189M Wired, 68M Cache, 112M Buf, 125M Free
> Swap: 5120M Total, 5120M Free
>
> PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
> 18208 squid 96 0 344M 343M select 1:59 0.00% 0.00% squid

This is the normally-running squid I guess. Suppose there's a bug
and squid tries to alloc a million of 4k blocks. It will swell enormously
and then die, you won't see it in top.

1. Upgrade to latest squid.
2. Run a daemon which logs system memory consumption every second,
   save output to file. Watch for memory usage spikes. Do they coincide
   with squid deaths?
3. Increase squid logging.
4. Instrument xcalloc/free routines to report totals, etc...

(memory logger source is attached)

> 405 root 96 0 2964K 1424K select 0:41 0.00% 0.00% ntpd
> 433 root 96 0 3472K 2256K select 0:28 0.00% 0.00% sendmail
> 450 root 8 0 1364K 928K nanslp 0:07 0.00% 0.00% cron
> 298 root 96 0 1324K 804K select 0:03 0.00% 0.00% syslogd
> 378 root 96 0 1244K 684K select 0:02 0.00% 0.00% usbd
> 437 root 20 0 2964K 1428K pause 0:02 0.00% 0.00% ntpd
> 438 smmsp 20 0 3356K 2032K pause 0:01 0.00% 0.00% sendmail
> 18229 squid -8 0 1188K 676K piperd 0:00 0.00% 0.00% unlinkd
> 21358 squid 4 0 2852K 1616K sbwait 0:00 0.00% 0.00% suid_ldap_group
> 21391 root 96 0 2392K 1576K RUN 0:00 0.00% 0.00% top
> 21357 squid 4 0 2752K 1404K sbwait 0:00 0.00% 0.00% squid_ldap_auth
> 21367 squid 4 0 2748K 1400K sbwait 0:00 0.00% 0.00% squid_ldap_group
> 21362 squid 4 0 2748K 1400K sbwait 0:00 0.00% 0.00% squid_ldap_group
> 21350 squid 4 0 2752K 1404K sbwait 0:00 0.00% 0.00% squid_ldap_auth
> 21348 squid 4 0 2856K 1600K sbwait 0:00 0.00% 0.00% squid_ldap_auth
> 21364 squid 4 0 2748K 1400K sbwait 0:00 0.00% 0.00% squid_ldap_group
> 21356 squid 4 0 2752K 1404K sbwait 0:00 0.00% 0.00% squid_ldap_auth
>
> Tomas
>
> --
> tp
>
>
>
>
> -----Original Message-----
> From: Denis Vlasenko [mailto:vda@ilport.com.ua]
> Sent: 18 November 2005 11:42
> To: squid-users@squid-cache.org
> Cc: Tomas Palfi
> Subject: Re: [squid-users] FATAL: xcalloc
>
> On Friday 18 November 2005 12:54, Tomas Palfi wrote:
> > To all,
> >
> > Every so often, almost daily, I get this message in logs and squid
> > reloads.
> >
> > FATAL: xcalloc: Unable to allocate 1 blocks of 4108 bytes!
> >
> > Squid Cache (Version 2.5.STABLE10): Terminated abnormally.
> > CPU Usage: 167.029 seconds = 122.739 user + 44.290 sys
> > Maximum Resident Size: 526264 KB
> > Page faults with physical i/o: 0
> >
> > I have checked almost all references to this problem and some of them
> > are pointing to not enough memory on the server, which is not my case
> as
> > I have plenty of that. What puzzles me is the amount of memory being
> > allocated to a squid process by FreeBSD. I am running several other
> > caches without any such problems, however, this one is the biggest
> > cache.
>
> You did not actually show any numbers on amount of used memory. top
> etc...
> --
> vda
>
> _______________________________________________________________________
>
> This e-mail has been scanned by Messagelabs
> _______________________________________________________________________
>
> PRIVACY & CONFIDENTIALITY
>
> This e-mail is private and confidential. If you have, or suspect you have received this message in error please notify the sender as soon as possible and remove from your system. You may not copy, distribute or take any action in reliance on it. Thank you for your co-operation.
>
> Please note that whilst best efforts are made, neither the company nor the sender accepts any responsibility for viruses and it is your responsibility to scan the email and attachments (if any).
>
> This e-mail has been automatically scanned for viruses by MessageLabs.
>
>