Reminder: Squid slowdown still present

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.