Reminder: Squid slowdown still present

chronos00

I noticed that download speeds through squid became quite slow, compared to that obtained going directly through pfSense.

This problem was well described here:
http://forum.pfsense.org/index.php/topic,7538.0.html
and here:
http://forum.pfsense.org/index.php/topic,7186.0.html

In those threads, the solution is posted by member chudy:

To Fix Squid

add this to the /boot/loader.conf

kern.ipc.nmbclusters=32768
kern.maxfiles=65536
kern.maxfilesperproc=32768
net.inet.ip.portrange.last=65535

or just delete it and replace with

autoboot_delay="1"
#kern.ipc.nmbclusters="0"
hint.apic.0.disabled=1
kern.hz=100
#for squid
kern.ipc.nmbclusters="32768"
kern.maxfiles="65536"
kern.maxfilesperproc="32768"
net.inet.ip.portrange.last="65535"

you might ask why squid is so slow? its because default configuration of pfsense is router not as a server
thats why kern.ipc.nmbclusters="0" <- is set to zero. if you just simply remove this squid will be just fine.

but to tune the squid i add this
kern.ipc.nmbclusters: 32768
kern.maxfiles=65536
kern.maxfilesperproc=32768
net.inet.ip.portrange.last: 65535

i just figure out why squid is slow. but i don't like the binary package of squid. i'll be using the squid HEAD bec of the store_rewrite feature for caching youtubes videos and other video files and mp3.

The aim of this thread is to remind developers that no one has yet corrected this in the squid package, so as to correct this problem for future installations.
I would be glad to do it myself If I had any clue on how to do it, but I feel I can at least contribute by reminding the problem is still there.

Regards, and thanks for the great work you are doing!

chronos00

Perhaps I hurried into saying that the solution was what I posted earlier…

I also ran into this problem, but after applying the suggested solution (and rebooting), the problem persisted.
I am using pfSense 1.2.3 (release - built on Sun Dec 6 23:21:36 EST 2009 ) and squid 2.7.9_4. My original "/boot/loader.conf" was:

autoboot_delay="3"
vm.kmem_size="435544320"
vm.kmem_size_max="535544320"
kern.ipc.nmbclusters="0"

and the problem persisted after changing the last line to kern.ipc.nmbclusters="32768", and rebooting, as suggested. This configuration was verified with the following command:

# sysctl kern.ipc.nmbclusters
kern.ipc.nmbclusters: 32768

I am lost here… Any other suggestions?

mhab12

There are lots of other threads on the subject - several of which suggest commenting out the kern.ipc.nmbclusters argument altogether, i.e.:

autoboot_delay="1"
vm.kmem_size="435544320"
vm.kmem_size_max="535544320"
#kern.ipc.nmbclusters="0"

chronos00

Thanks for your reply mhab12.

I have read every thread in the forum that mentioned the line you are talking about, and still got no working solution to this problem.
I tried commenting the whole line, all together, but the result is the same. I even verified the status with:

# sysctl kern.ipc.nmbclusters
error: "kern.ipc.nmbclusters" is an unknown key

Which was odd… but possible.

Just to clarify the problem I am seeing:
When using the transparent proxy, I use "wget" to download any big file. The transfer starts by using all of my ISP's available bandwidth (675 KB/s). After some time (between 5 and 30 seconds) the transfer speed drops to EXACTLY to 9.10 KB/s, every time. This slow speed remains for another period of time (again, between 5 and 30 secs) and after that, it resumes to full throttle. This cycle repeats itself, with varying times periods, until the transfer is over.

For a normal file transfer, this behavior is not terribly uncomfortable, but when surfing the web it becomes horribly tedious, to the point of needing to disable the transparent proxy.

Any other insights I could use to trouble shoot this problem?

mhab12

I just checked our other box, and it has no text at all in loader.conf. You might try commenting out all the directives there and see what happens. I have been able to correct this problem 100% of the time through loader.conf, though others have suggested that the 'Hard Disk Cache System' can play an important rule in this slowdown. We have one box on aufs (was the old default) and another on diskd (I believe this is the new default). Both plod along at almost exactly our max bandwidth, albeit a measly 5mb.

jimp

It's not the package's job to make loader.conf changes. It's a well-documented suggestion (on the doc wiki and the forum) for people to try if they need encounter performance issues.

Just because these changes are safe in this situation doesn't mean that an important file like loader.conf should be touched by a package. :)

_igor_

I think you're right with that statement, BUT (oh yes, everytime this f*** big but has to come over) with every update i make, specially from within beta-versions, all changes are vain, because are deleted.

So it wold be a great thing if any changes are kept or if not, there should be an information about the respective files which are affected. Its enough to have this info at the log-files for example.
I've been looking around lots of times because its a mess to do a diff on every file which i changed and which changes were discarded on updating the system…

But i think, certain files are blown away without looking for changes.

Other way - much better to my opinion - would be a section at the config where i can put in my changes with the respective files and they get restored on every update like package-settings. I don't know about the work which has to be done for implementing this, but maybe some people with programming-skills would like this kind of featuure too.

jimp

@_igor_:

I think you're right with that statement, BUT (oh yes, everytime this f*** big but has to come over) with every update i make, specially from within beta-versions, all changes are vain, because are deleted.

Which is why it's also suggested to use loader.conf.local which is not overwritten. (And loader.conf shouldn't be touched in recent snaps either)

@_igor_:

But i think, certain files are blown away without looking for changes.

Some are, yes, but not ones that are suggested to be changed regularly.

@_igor_:

Other way - much better to my opinion - would be a section at the config where i can put in my changes with the respective files and they get restored on every update like package-settings. I don't know about the work which has to be done for implementing this, but maybe some people with programming-skills would like this kind of featuure too.

Ideal, sure, but not so easy in the case of loader.conf - the changes there only apply on boot, so they'd have to be added and then either a reboot forced or nagged until they can be applied.

chronos00

I'm reporting back with results. Unfortunately, not the result I would like…

As mhab12 suggested, I tried cleaning the loader.conf file (commenting every line), but upon reboot the problem persisted.
I also tried switching the "Hard disk cache system" from UFS to AUFS, but again, no changes.

What else could I try to solve this?
@mhab12: what version of squid package are you running?

jimp

There could be other factors affecting it at well, but usually ufs is faster.

Go over this thread as well, check things I mentioned there:
http://forum.pfsense.org/index.php/topic,27512.msg143870.html#msg143870

chronos00

Thanks jimp! I didn't find that post in my searches for the squid problem.
I'll go through it this evening when I'll be able to reboot pfSense as much as I need to and report back.

mhab12

I have two boxes running at near 100% bandwidth through Squid, one is 1.2.3/Squid 2.7.8_1, the other is 1.2.3/Squid 2.7.9_4.