Re: [squid-users] Squid In Redhat 7.1/SuSE 7

From: Mark Tinka <aknit44@dont-contact.us>
Date: Tue, 21 Aug 2001 04:18:25 -0700 (PDT)

hey guys.. am just gonna digress y'all a bit...

i have a strange experience with Squid and my distro:

i am running SuSE 7.2 with kernel 2.2.19-SMP... here are my other specs:

640MB SDRAM
Dual Ultra 2 SCSI 36GB HDD
Dual 866MHz Pentium III - 1.732GHz of processing power

i noticed that when i started, my RAM usage was about 50MB.. it then rose slowly over the next two days to 638MB, where it has been for the last two weeks...

i monitored memory usage keenly when it had about 2.5MB of RAM left, but i discovered something very interesting... whenever my RAM usage comes down to 2MB, the system automatically frees another 1MB and leaves me with 3MB of RAM to work with... this goes on until Squid has to do its routine validations, after which it can free up to 40MB of RAM... after this, the whole cycle repeats..

what's amazing is that the system never goes below 2MB, however much Squid presses the server, 2MB is least it will go.. what this means is that the system has never used the swap memory.. never...

i am not complainig, i mean, this is good, but can someone explain this for me...?..

i am running Squid 2.3 STABLE3 that came with the SuSE CDs and my cache_mem = 32MB... and get this, this version has not been compiled with the GNU Malloc library.. so i don't have any memory optimisation, and yet the system is working perfectly, with no problems whatsoever, and handling quite a load from my network...

i intend to beef up the RAM to about 1.5GB, and split the cache across both disks... if anyone has the same experience, do let me know whether it has something to with Squid, my distro, or the way my distro compiled and packaged squid..

all returns appreciated.. thanks..

AKNIT

--- Joe Cooper <joe@swelltech.com>
> wrote:
>Have you tried a newer GCC revision? I've found that I can't even build
>an i686 version of Squid 2.4 on the Red Hat 7.1 compiler. It fails with
>an internal compiler error--not a good sign, or a confidence building
>occurence.
>
>Using 2.95 works, as does 3.x, I think. I've upgraded to 2.96-95 (from
>Rawhide), which still fails on a i686 build, but seems to run stable.
>
>Shane T. Ferguson wrote:
>
>> First machine I've installed it on was a PIII 450 with 1GB of RAM. Bought a
>> new Dell Poweredge (1Ghz processor, 1GB RAM - all new), RH7.1, squid 2.4S1,
>> upgraded to 2.4.5 kernel and having same problems.
>>
>> I'm not certain I'm having bad RAM from two different vendors .. but you
>> never know -- I'll try yet more RAM. Thanks for the tip!
>>
>> Shane
>>
>> -----Original Message-----
>> From: Gerben Welter [mailto:gerben@brekelmans.com]
>> Sent: Sunday, August 19, 2001 12:06 PM
>> To: squid-users@squid-cache.org
>> Subject: RE: [squid-users] Squid In Redhat 7.1
>>
>>
>> At 11:45 8/19/2001 -0300, Shane T. Ferguson wrote:
>>
>>>I've been running RH7.1, Squid 2.4S1 for past 4.5 weeks now. At first, I
>>>would get seg faults and it would die (hang) after few hours .. I
>>>installed GNU malloc, and it only seg faults and restarts after around 7-8
>>>days (though does this cleanly).
>>>
>>>Shane
>>>
>>
>> My experiences are much better. I run Squid 2.4S1 with the latest patches
>> on three different boxen running RedHat 7.1 with different workloads.
>> Ranging from a PII-233 with 80 MB for home use to a dual Celeron-400 with
>> 512 MB serving about 1700 users.
>>
>> Never had a problem. All three boxen all performing rock solid. Only
>> downtime is with the occasional kernel upgrade.
>>
>> Have you checked your problems aren't hardware related, like bad ram?
>>
>> Grtz Gerben.
>
>
>
> --
> Joe Cooper <joe@swelltech.com>
> Affordable Web Caching Proxy Appliances
> http://www.swelltech.com

_____________________________________________________________
Be different Get yourself a Globenetcafe.net email ID
Uganda's Newest internet cafe www.globenetcafe.net
Received on Tue Aug 21 2001 - 05:18:27 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:01:52 MST