Re: Status Shared Memory

[Justin Erenkrantz <je...@ebuilt.com>]

On Sat, Jul 14, 2001 at 08:56:31AM +0200, Rivium wrote:
> Hi,
> 
> By Browsing through throught the source code, i notified several Anti-Shared
> memory comments, as well a negative advices about using it.

Shared memory at least on Unix has many limitations on it that hinder
its effectiveness.  It can only be used in very specific circumstances
portably.  (The issue is primarily about the size of the memory you can
allocate with shmem.)  Ideally, the new SMS code in APR will allow us 
to implement a shared-memory backbone for the allocation algorithms in 
httpd.  That means that almost any data structure coded to use pools 
(aka SMS) can then be used with shared memory.  Nobody is working on
that yet though (no itches there yet - although Ian has talked about 
wanting it).

However, it would be impossible to have every allocation in httpd
residing in shared memory due to all of the platform limitations.

I'm wondering if you are talking about something other than shared
memory as most of us Unix geeks know it.  You're comments about 
Visual Studio .NET make me wonder what your definition of shared 
memory is.  =-)  -- justin

Re: Status Shared Memory

[Ian Holsman <ia...@cnet.com>]

On 13 Jul 2001 23:58:12 -0700, Justin Erenkrantz wrote:
> On Sat, Jul 14, 2001 at 08:56:31AM +0200, Rivium wrote:
> > Hi,
> > 
> > By Browsing through throught the source code, i notified several Anti-Shared
> > memory comments, as well a negative advices about using it.
> 
> Shared memory at least on Unix has many limitations on it that hinder
> its effectiveness.  It can only be used in very specific circumstances
> portably.  (The issue is primarily about the size of the memory you can
> allocate with shmem.)  Ideally, the new SMS code in APR will allow us 
> to implement a shared-memory backbone for the allocation algorithms in 
> httpd.  That means that almost any data structure coded to use pools 
> (aka SMS) can then be used with shared memory.  Nobody is working on
> that yet though (no itches there yet - although Ian has talked about 
> wanting it).
I think I said I couldn't see how it could be done via SMS so that the
requester could use it without explicitly knowing it was shared memory.

In general read-only shared memory structues scale pretty well, as you
only need 1 instance per machine, but you have to make concessions.

In the APR implmetaton for unix:
you can't expand the area
you can't attach to it from a seperate process	(which isn't the
creator's child)


have a look at memory mapped files, or things like berkleyDB or TDB

if you are just wanting a methoud of passing control information between
processes then there are other better methouds that Justin mentioned.

if you want cross-machine shared information, have a look at spread
(www.spread.org)

> 
> However, it would be impossible to have every allocation in httpd
> residing in shared memory due to all of the platform limitations.
> 
> I'm wondering if you are talking about something other than shared
> memory as most of us Unix geeks know it.  You're comments about 
> Visual Studio .NET make me wonder what your definition of shared 
> memory is.  =-)  -- justin
--
Ian Holsman
Performance Measurement & Analysis
CNET Networks    -    415 364-8608

Re: Status Shared Memory

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

----- Original Message ----- 
From: "Justin Erenkrantz" <je...@ebuilt.com>
To: <ne...@apache.org>
Sent: Saturday, July 14, 2001 3:03 AM
Subject: Re: Status Shared Memory


> On Sat, Jul 14, 2001 at 09:40:59AM +0200, Rivium wrote:
> > But my Main Goal is to speed things -really- up. So i was talking about
> > segment of shared memory, on the same machine
> > (I love the current Memory prices!)
> 
> Shared memory has major problems.  Consider the fact that you can't 
> store any pointers in shared memory nor can you expand the memory once
> you have allocated it (with most implementations AFAIK).

1. Yes, you can store offsets, rather than pointers.  This makes it impossible
   to store APR structures (e.g., an apr_table), but quite possible to store
   your own data.

2. All clients need to re-map when the memory is expanded.  The simplest 
   mechansim is a shmem section of memory, with a tag.

> The reason that you can't use pointers is that users of the shmem will *not* 
> receive the memory at the same location in each process.  So, about 
> the only thing you can store is raw text or arrays of known size in 
> shared memory (like the scoreboard which isn't that big and has known 
> size at compile-time).  

Very true.  Stash the bounds, or size, inside the structure.

> IMHO, you're better off using true IPC mechanisms - especially when 
> you are concerned about scalability (as you seem to be).  Shared 
> memory doesn't scale.  If I'm wrong, please correct me.  =)  In
> your scenario, mmap() *may* provide a better alternative and remains 
> file-based, and will be significantly faster than plain read()/write() 
> (as long as you don't run out of address space).  -- justin

MMAP shouldn't be significantly faster at run time, only during allocation.
Most systems have memory backed by a file, only it's a swap image, rather
than a shmem file.

Re: Status Shared Memory

[Justin Erenkrantz <je...@ebuilt.com>]

On Sat, Jul 14, 2001 at 09:40:59AM +0200, Rivium wrote:
> But my Main Goal is to speed things -really- up. So i was talking about
> segment of shared memory, on the same machine
> (I love the current Memory prices!)

Shared memory has major problems.  Consider the fact that you can't 
store any pointers in shared memory nor can you expand the memory once
you have allocated it (with most implementations AFAIK).  The reason 
that you can't use pointers is that users of the shmem will *not* 
receive the memory at the same location in each process.  So, about 
the only thing you can store is raw text or arrays of known size in 
shared memory (like the scoreboard which isn't that big and has known 
size at compile-time).  

IMHO, you're better off using true IPC mechanisms - especially when 
you are concerned about scalability (as you seem to be).  Shared 
memory doesn't scale.  If I'm wrong, please correct me.  =)  In
your scenario, mmap() *may* provide a better alternative and remains 
file-based, and will be significantly faster than plain read()/write() 
(as long as you don't run out of address space).  -- justin

Re: Status Shared Memory

[Rivium <ri...@tser.org>]

Hi,

> However, it would be impossible to have every allocation in httpd
> residing in shared memory due to all of the platform limitations.
So the choice of the platform should be done with caution...


> I'm wondering if you are talking about something other than shared
> memory as most of us Unix geeks know it.  You're comments about
> Visual Studio .NET make me wonder what your definition of shared
> memory is.  =-)
A Piece of common used memory, where each client would get the same
information, if they looked up in that part of memory, not nessecary stored
on the same machine. (so for that purpose... a sql database , or something
done with a soap call could even be called shared memory hehehehe).

But my Main Goal is to speed things -really- up. So i was talking about
segment of shared memory, on the same machine
(I love the current Memory prices!)

My situation is that i'f got a bunch of users simultationously logged into
my module, and that they'r all chatting and babbling with each other, and
what to know where there friends hang around.

I used to have "OnlineTracking" Filesystem based access method for that, for
4 years now, But as more users log into, The negative drawbacks of that are
slowely popping up.


I'm going to try building an as empty possible module,that is just using
shared memory, and will see where i end. Hope you guys can comment a little
bit if i post " one and then " a version for comment.

Maybe it will not run on every system then, but at least on my target
platforms.

        Regards,
                    R.