Are you sure that forking a script doubles your memory usage?

I thought that on most systems running a second copy of a program, perl in this case, would only increase overall memory usage by the size of the read-write data area only. As the readonly data and code memory would be shared by the processes. Ditto for all subsequent copies.

If you're using something like top or PS to assess the memory usage, it may be telling you porkies. Try starting one copy and then record the total free memory figure. Then start a second copy and record the total free memory figure again. The difference will be your actual per process consumption, which in many cases will be far less that the figure suggested by ps/top.

it's called copy on write. all the pages used by process are marked this way, whenever one of the process forked try to write to that page a trap is raised and the OS copy the page.

Oha

Yes I know. (On Unix that is. They are just "shared memory segments" on Win32 for example).

But it's not as beneficial as people think for perl processes, because "compiled" Perl code and Perl program data, are both RW memory to the perl executable. And even read references to perl variables can caused write accesses (and therefore COW) to the memory that holds them.

But the main point of my post is that ps/top will often, if not always, count the shared, readonly memory (the perl executable's code and RO data) against each process that shares it, which may be giving the OP a false impression of how much memory is consumed by his existing forking solution.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

If you don't want to rebuild a complete server infrastructure and you have high demand, maybe you could reuse Apache 2. Apache 2 is a server framework with a http server plugged in (roughly spoken). You could insert your own server plugin there.

Or maybe you could tell us what you need that server for, maybe there is an easier way that reuses another server application.

You could use threads instead of forked processes, that should decrease memory usage.

To follow that advice also requires not using Perl. Because Perl's idea of "threads" actually uses more memory than forking (on systems that support real forking not fork emulated using Perl threads, obviously). Perl threads also use the extra memory less efficiently, greatly increasing the cost of thread creation (and destruction).

For this situation, switching to Perl threads would have significant disadvantages and no advantages.

Yes, I realize that you are suggesting using something other than a Perl script as the heart of the server infrastructure. But I felt that your opening sentence required some clarification since it is the completely wrong approach when dealing with a server written in Perl, and that wasn't made clear.

- tye        

First I would recommend having a look at some generic solutions on CPAN, so that you can prototype quickly different approaches: some good ones are Net::Server, IO::Multiplex, IO::SessionSet and IO::SessionData in the lib directory of the perl network programming site (for non-blocking sockets in case you cannot trust your clients which is almost always the case ;))

Secondly if you maintain lots of open connections a select loop might be the way to go. Multiplexing on a few "select-loop " servers could be used to make the approach more scalable ( a request is sent to one of the children in the pool, and that child does the accept and adds the descriptor to the "select" set).

Finally studying part of the code of aproxy (a small TCP port forwarder) could be useful too

btw which platform are you on?

update Humm then there is the question of your bidirectional protocol. It is easy to do that part wrongly. I would suggest a fork for "each request to a connected client" (you need the socket descriptor of that client) IOW a fork for each server write... with COW schemes this does not have to be so costly. You could even prototype with doing a fork-exec of scripts in a server-request/ directory. It all depends on the average time of the request/answer (and your protocol). You'll need also to monitor the number of processes.

cheers --stephan

It probable that the vast majority of that 1MB of memery per dormant thread is being consumed by an wildly over-generous per-thread stack allocation that will likely never be consumed. See Use more threads..

I've had 3000 active threads running (not doing much; incrementing a counter and displaying it at a particular location on a 200x100 console session, but more than sleeping), all in under 1GB.

Greedy in C terms, but not bad for 3000 independant interpreters.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."