limits.conf and KDE performance

[molostoff]

I have found that setting a number of open files for a process in ubuntu can increase performance for KDE. I mean ulimit nofile parameter, which is placed in /etc/security/limits.conf and has a default value of 1024. I feel this value too small for my needs and I have tried several bigger values: 2048, 4096, 8192, 16383 etc up to ~64000.

A typical method to see current setting is "ulimit -a".

A reasonably high value I set for myself is 8192. But after several hours of running KDE, I occasionally found this value decreased back to 1024, while limits.conf still contains my directive on nofile=8192.

I have tested this very strange thing by setting nofile to 4096, and all the time (+ several hours of running KDE) this parameter was unchanged.

The cause of this automated decrease is very interesting, but the question is how to set open files limit to 8192 permanently?

Moreover, how to use limits.conf to set nofile to the maximum value allowed by the kernel (how to establish that maximum within limits.conf)?

[martosurf]

Re: limits.conf and KDE performance

Hi molostoff,

can you tell me how your limits.conf looks like? Beacause I too have the 1024 limit but the line isn't there and I'm not sure what to add/touch.

Thanks in advance for this great tweak, best!

[molostoff]

Re: limits.conf and KDE performance

/etc/security/limits.conf:

*        -    nofile     8192
*        -    stack      8192

all other lines are comments and I have stripped them.

nofile - number of open files.

[martosurf]

Re: limits.conf and KDE performance

Hey thanks, way cool

I heard about this longtime ago but completely forget it until you mention this here. Also, may be you want to tweak the swapiness value depending on how much ram do you have:

http://guvnr.com/pc/optimise-swap-swappiness/

Personally I have set it to 10.

Many thanks again and happy Kubunting =D

[molostoff]

Re: limits.conf and KDE performance

Personally I have set it to 10.

Many thanks again and happy Kubunting =D

Regarding to swappiness I prefer vm.swappiness=90

Occasionally I have found the cause - manual calling laptop_mode script changes nofile limit and set it to 1024. I dont know where, but will find.

[martosurf]

Re: limits.conf and KDE performance

But with a 90 swappiness you're writing everything to disk continously and force the system to read almost everything from disk instead from memory! I asume you're low on memory to choose that.

Regarding the nofile issue I wish you luck and please post back anything you research. Best!!

[molostoff]

Re: limits.conf and KDE performance

But with a 90 swappiness you're writing everything to disk continously and force the system to read almost everything from disk instead from memory! I asume you're low on memory to choose that.

Regarding the nofile issue I wish you luck and please post back anything you research. Best!!

Not exact. But a common first: limits restricted for a root subshell session. It means that I have tryed to call ulimit -a in a root shell which is (as usual in linux) accessible via sudo (which is a form of subshell session). After exiting sudo and returning to home shell I have got all limits on a good value. Just a mistake.

With a 90% of swappiness all these percents of memory assumed to be a disk cache, which is useful to me, as I dont like glitches in interactive apps.

Most common and big memory hogs in this release of KDE (i mean 4.4) are nepomuk and akonadi, useful a little, but not enough, so I disabled them after some playing.

Now KDE 4.4 (with akonadi and nepomuk disabled) uses about 400m of memory, with a swapped of 160-180m in use on 1G machine. Everything is fly. Its much better than 4.3 from this point of view.

I hope some version of nepomuk/akonadi will not eat memory so aggresively.

[molostoff]

Re: limits.conf and KDE performance

Now KDE 4.4 (with akonadi and nepomuk disabled)

I have enabled them back after proper configuring page cache flushing in kubuntu:

vm.dirty_expire_centisecs=60000
vm.dirty_writeback_centisecs=30000

(these values 60000 which is eq to 10min - firstly introduced by laptop_mode tools, but it seems to me they are not exactly correct, I have only changed vm.dirty_writeback_centisecs to the twice less)