Re: Shared memory between workers

["Iñaki Baz Castillo" <ibc@aliax.net>]

2010/4/26 Eric Wong <normalperson@yhbt.net>:

> Hi Iñaki,
>
> First off I wouldn't call Memcached slow...  How many requests do you
> need out of it and what kind of access patterns are you doing?

Well, I want to do as efficient as possible. This is not the main
purpose (if so I wouldn't use Ruby) but it's important.

For example:
- 8 workers.
- A SIP request arrives and it handled by worker 1.
- The server must store in *shared* memory info about such request
(status, last SIP response sereplied for it....). The request
transaction remains in memory for some seconds after sending the
response.
- Due to a non so unusual SIP issue, a retransmission of the previous
request arrives to the server but now it is handled by worker 2.
- Worker 2 must check the request "branch" id into shared memory, find
the previously created entry, check that a response was already sent
for it, and re-send such response.

Well, in fact this is really common in SIP under UDP. Under TCP
usually there are no retransmissions (but they could be so the worker
must check it).



> If you're on a modern Linux 2.6 box, then anything on the local
> filesystem is basically shared memory if you have enough RAM to store
> your working set (and it sounds like you do).

And what about mounting a filesystem under RAM? :would it be ever faster? :)


> If you're willing to be confined to a single box, I've had great
> experiences with TokyoCabinet the past few years.  One system I built
> shares 10G of read-mostly data (on 16G boxes) across 8 Unicorn
> (previously Mongrel) workers.  TokyoCabinet uses mmap and pread/pwrite,
> so you can safely share DB handles across any number of native
> threads/processes.

I didn't know it. I've just read the doc, installed and tested it.
Really impressive!


> Writes in TC need filesystem locking and you can only have one active
> writer, but that was still plenty fast enough in my experience.

If you use a "on memory database" there wouldn't be filesystem locking, right?


> If fsync() becomes a bottleneck, then for non-critical data either:
>
>  1) disable it (TC lets you)
>  2) or use libeatmydata if you choose something that doesn't let
>     you disable fsync()
>
> <soapbox>
>  My personal opinion is that fsync()/O_SYNC are completely overrated.
>  All important machines these days have redundant storage, redundant
>  power supplies, ECC memory, hardware health monitoring/alerting and
>  backup power.  Any remaining hardware/kernel failure possibilities
>  are far less likely than application bugs that corrupt data :)
>
>  But, if you really have critical data, /then/ get an SSD or
>  a battery-backed write cache.
> </soapbox>

Thanks, but the fact is that I don't need persistent storage. This is,
the data I will need to share between Ruby processes (workers) is
about realtime data, so if the server is stopped and restarted I don't
want to retrieve such information. Well, it could be useful for some
cases however, I need to think about it.
I've seen a method "sync" in the Tokyo Tyrant client API which forces
the server to store/sync the on memory data to the file (if a file is
being used).


So thanks a lot. Definitely I'll learn about TokioCabinet as it seems
a really nice solution for my needs.
Regards.


-- 
Iñaki Baz Castillo
<ibc@aliax.net>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying