squid-2.5.9 after about 24hrs of running eats up all ram (1 gigabyte). It didn't happend with 2.5.8
please post the ps output proving that.
I am unable to reproduce this problem on my amd64 or x86 systems/servers - running for far longer that 24 hours, and only one of them has 1GB of RAM. emerge info would also be helpful.
Created attachment 53784 [details] Daily cache memory usage
Created attachment 53785 [details] Cache memory usage weekly
Created attachment 53786 [details] Weekly memory usage for whole server
I can't give you ps output, I have only mrtg graphs which I am attaching. You can clearly see from them where I switched to 2.5.9 and back. My emerge info: Portage 2.0.51.19 (default-linux/x86/2004.3, gcc-3.3.5, glibc-2.3.4.20041102-r1, 2.6.9 i686) ================================================================= System uname: 2.6.9 i686 Intel(R) Xeon(TM) CPU 2.66GHz Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 18 2005, 23:48:42)] dev-lang/python: 2.3.4-r1 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.5, 1.8.5-r3, 1.6.3, 1.7.9-r1, 1.4_p6, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r1 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=pentium4 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=pentium4 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 acl apache2 bcmath berkdb bzlib crypt ctype curl dio ftp gdbm iconv ipv6 maildir mime mmap mmx mysql ncurses nls nptl offensive pampcre perl php posix python readline shared sharedmem slang snmp sse sse2 ssl sysvipc tcpd vhosts" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, PORTDIR_OVERLAY
Till now you are the only one complaining about memory leaks, which, you must admit, it is a little incredible with a popular web caching server such as squid. I can't reproduce this either and also have several x86 servers running the latest stable version of squid. What squid.conf do you have - maybe you set memory limit too high? How can you be sure that squid is to blame and not other service? A well-formated ps or a top capture, sorted by memory, could prove that.
I am sorry, maybe I didn't state it clearly - two first attachments are graphs from mrtg, which are read directly from squid via SNMP. So it is the real memory usage of squid, and I think that ps output is useless. But if you really do want to have it I can get it in a week or so, because I need to wait until my customers irritation gets below some level :D. And yes, I am aware of that if there was a memory leak, everybody would know and squid would be fixed, but maybe it is a rare case (you need to remember that previous versions of squid HAD memory leaks). But keeping in mind that squid is quite well tested (or at least it should be) I was even guessing that it was caused by a intrudocution of some new configuration parametere, but it wasnt (in 2.5.9 there was only one new option about retrying errors). In my situation it goes like that: - upgrade of squid to 2.5.9 - adding line access_log /var/log/squid/access.log squid which is required by a new version - starting it and watching memory usage grows... - downgrading to squid 2.5.8 - removing access_log /var/log/squid/access.log squid - starting and watching memory usage always below 200MB So are you still sure that it isn't squid related?
ok, lets clear a possible cause. in 2.5.8-r1 I've added a special patch (customlog). this patch is also applied to every following versions so it may be the thing to blame. what I want from you is to use 2.5.8-r1 for awhile and to tell me if this version also appears to have memory leaks. again, what you claim is hard to believe so forgive my skepticism. please take all the usual measures to be sure your machine is in a consistent state (e.g. emerge --newuse world && emerge -uD world && revdep-rebuild)
I went trough my emerge log and those were version I have used: www-proxy/squid-2.5.7 www-proxy/squid-2.5.7-r1 www-proxy/squid-2.5.7-r2 www-proxy/squid-2.5.7-r3 www-proxy/squid-2.5.7-r4 www-proxy/squid-2.5.7-r5 www-proxy/squid-2.5.8 www-proxy/squid-2.5.9 And 2.5.9 had only trouble, so you may be right. I will check it on monday (sorry I have school on weekdays). I went trough newuse, depclean, revdep rebuild and nothing was there.
Created attachment 54066 [details] 2.6.8-r1 memory usage
I have just attached graph from 2.6.8-r1 and as you can see it is slowly leaking memory (I switched it about 11:00 AM). Here is ps -aux | grep squid output: root@sauron alchemyx # ps aux | grep squid root 15343 0.0 0.1 5748 1684 ? Ss 10:52 0:00 /usr/sbin/squid -DYC squid 15345 95.4 28.7 302360 298104 ? S 10:52 415:57 (squid) -DYC squid 15348 3.1 0.0 2164 776 ? Rs 10:52 13:48 diskd 15713280 15713281 15713282 squid 18063 0.0 0.0 1212 280 ? Ss 11:27 0:00 (unlinkd) root 7032 0.0 0.0 1492 496 pts/0 S+ 18:08 0:00 grep squid In few days I will try to install 2.6.9 without customlog patch and we will see whats wrong.
Created attachment 54133 [details] 2.5.9 squid without customlog patch memory usage
I have just attached next graph. You can clearly see that when using 2.5.9 without customlog patch everything is fine (11:00 AM until about 6:30 PM it was 2.5.8-r1 with customlog, and then without). it is output from ps: root@sauron alchemyx # ps aux | grep squid root 27390 0.0 0.1 5736 1684 ? Ss Mar21 0:00 /usr/sbin/squid -DYC squid 27392 49.1 21.8 230360 226652 ? D Mar21 366:06 (squid) -DYC squid 27394 0.0 0.0 1212 280 ? Ss Mar21 0:00 (unlinkd) squid 27395 1.3 0.0 2160 776 ? Ss Mar21 10:00 diskd 28049408 28049409 28049410 root 22219 0.0 0.0 1488 496 pts/0 S+ 09:50 0:00 grep squid So... There is a memory leak in squid, for sure. It may or may not happen always, maybe it depends on something - traffic, requests number or anything else. I think that the best way of doing this would be adding "customlog" or "nocustomlog" USE flag so anybody can tweak it for themselves.
I've added the USE flag. begginging with version 2.5.9-r2, customlog patch will be applied only if customlog flag is set.
This fix lead to servers being unusable :/ Scenario: 1. installed 2.5.8-r1, there was no customlog useflag atm. logformat was used. 2. after 3 weeks upgrade to 2.5.9 - customlog is new useflag at default disabled 3. restart of server, and squid does not work - logformat is not recognized :( not comptabile downgrade of options should be at least ewarn'ed at emerge (better jest, customlog should be enabled by default). Sorry if i missed something (writing in hurry, during fixing and recompiling few squids :)
And that is purpose of etc-update.
sorry, but I don't see how could squid become unusable. it should install a new squid.conf, without customlog settings. also, I don't think customlog should be enabled by default. it isn't an official patch and its userbase is small.
i agree, that customlog should not be enabled by default, but being enabled before in stable relase, caused problems later. as to etc-update, squid.conf (which is _large_ single conf file) is a perfect example of etc-update method deficiency: 1. size of default squid.conf causes output of etc-update completly useless. every relase of squid adds to much changes to it. 2. if you dont use squid.conf based on default (which i presume is a only sane way in large, custom, squid installation) etc-update is no help at all. anyway, i just write previous comment to point out that changing default package options in stable arch without any notice for users is a bad practice, and should be avoided.
Maybe I did a mistake when I've unconditionally applied customlog patch, presuming that if it works for me it will work flawlessly for all, but... what is indeed bad practice is to ignore the last IMPORTANT message at the end of update, the one who tell ya that you have n files who needs your attention. what do you want from me? to go door to door and say "guys, remember squid? don't forget to run etc-update next time you update it!"? c'mon, this is a well known fact! I take it as known even when I'm dealing with rookies. Personally I'm happy with dispatch-conf, even though it has failed to do its duty now and then. Btw, I use it for updating amavisd.conf which is far more complicated that overcommented squid.conf. In fact, I found usefullness of dispatch-conf direct proportional with lenght of config file ^ 2.
