Re: Idea: mount /tmp to tmpfs depending on free space and RAM
On Mon, Jun 04, 2012 at 06:34:57AM +0300, Serge wrote:
> 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,
Not to be debated - yes, using memcached does create a headache or two,
but also solves problems that are otherwise hard. Yes, reboots are rare
enough (every few weeks at most) to ignore their adverse side effect on
user's sessions - at least in my use cases.
> but it requires careful memory configuration, otherwise users may find
> themselves logged off in the middle of a chat.
No objections here.
> > 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.
Well, it doesn't. I have copious memory in a box that is highly
underused (< 50%), but still find that interesting files, or file system
data, are deleted from that cache. Which leads to very high access times
in case I need this data.
> 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.
Hmmm. First, I'd say that this assumption on their behalf is wrong.
Secondly, over here, people tend to be forcefully disconnected at least
every 24 hours, forcing a new client IP, anyway. There is no sane way to
keep users logged in under these circumstances.
> 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 server.
Looks like you have a vastly different user population, who also use a
vastly different software. My clients' software packages just
automatically re-connect, and re-login if possible, in the background.
Even Outlook can do it. Not to mention flakey DSL or mobile connections
that break your connection more frequently than that.
> It could be that your users are different.
Looks like it, yes.
> 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...
Uh. Mentioning hardening and suggesting "omit-frame-pointer" in one
sentence makes me shiver. No, I don't optimize for performance at that
level, but rather go for portability and safety, if possible. Also, a
quick Google search turns up this - maybe out of date - article:
> http://timetobleed.com/gcc-optimization-flag-makes-your-64bit-binary-fatter-and-slower/
Also, from
http://gcc.gnu.org/onlinedocs/gcc-4.6.2/gcc/Optimize-Options.html#Type-punning,
it's unclear to me whether omit-frame-pointer will interfere with stack
protection schemes, or which one takes precedence.
I usually resort to trust in my fellow DDs to do the right things
in this area...
Kind regards,
--Toni++
Reply to: