[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

2012/6/3 Toni Mueller wrote:

>> First, there can be rather large session directory, you probably don't
>> want ~365595 files to be always eating your RAM.
> Well, I much rather want that, or store the session data in memcache,
> which is almost the same thing, only with a different label.

Memcache? (0_o) Imho, that's even worse than store it on tmpfs, since
memcache can just push your data off the cache and you'll get it lost even
without reboot. I can think of session data in memcache only as some hack
for load-balanced servers, but it requires careful memory configuration,
otherwise users may find themselves logged off in the middle of a chat.

> Mind you, all these things are done to *prevent* the application from
> going to disk, and force it to stay in RAM. And that's exactly what
> I want.

You already have a filesystem cache for that. Session data stays in RAM
if it is used. But it does not get lost when inactive for a few hours.

> Why not? I could not care less for the loss of session data every once
> in a while. People will log in again if their CMS backends really logged
> them out because of that, if anything

Plain users I've seen expect their session to stay alive for days. I.e.
they have just checked the forum and then turned off PC. When tomorrow
they turn it on they expect to be still logged in. They expect this to
be true for everything (forums, blogs, web-email, etc). It's a disaster
for them to be logged off, it takes hours to find a piece of paper where
they wrote the password. They become angry if 10 minutes ago they were
logged in and now they aren't, they don't care that I had to reboot the

It could be that your users are different.

> but session data is created for about every visitor, or spider, that
> hits the site(s), and will be forcefully cleaned up by cron-jobs,
> anyway. Not my code, so blame someone else.

Using tmpfs for session data was your decision, so you're to blame. :)

> I am unconvinced. You can store your session data wherever you like, but
> I prefer RAM.

As usual it's up to you. You may have reasons for that. I'm just saying
that having session data lost may be a bad thing, and having it lost by
default is definitely a bad thing.

>> No need to. You only need to add -pipe to your *FLAGS. You don't build
>> software with default autotools flags (-g -O2) anyway, I guess.
> Well, usually I do, except that I usually only compile C & friends, not
> write it.

Oh, you're missing a lot of interesting things. :) Even skipping the
Hardeding[1] stuff, you could get your soft faster just by specifying
your exact arch (-march=native). Also for example -fomit-frame-pointer
option for x86 can make short functions twice shorter and faster...

[1] http://wiki.debian.org/Hardening

Reply to: