There are clear advantages to separate process space for servers.
1. Separate threads can stomp on each other's memory space. (e.g.
imagine a wild, home-brew C function gone bad).
2. Separate processes can have separate user ids, and [hence] different
rights for file access. A threaded server will have to either be
started at the level of the highest user who will attach or will have to
impersonate the users in threads. Impersonation is very difficult to
make portable.
3. Separate processes die when they finish, releasing all resources to
the operating system. Imagine a threaded server with a teeny-tiny
memory leak, that stays up 24x7. Eventually, you will start using disk
for ram, or even use all available disk and simply crash.

Threaded servers have one main advantate:
Threads are lightweight processes and starting a new thread is faster
than starting a new executable.

The thread advantage can be partly mitigated by pre-launching a pool of
servers.

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Dann,
I'm not advocating a multi-threaded PostgreSQL server (been there, done
that :-). But I still must come to the defense of multi-threaded systems
in general.

You try to convince us that a single threaded system is better because
it is more tolerant to buggy code. That argument is valid and I agree, a
multi-threaded environment is more demanding in terms of developer
skills and code quality.

But what if I don't write crappy code or if I am prepared to take the
consequences of my bugs, what then? Maybe I really know what I'm doing
and really want to get the absolute best performance out of my server.

Not all servers allow home-brewed C functions. And even when they do,
not all home-brewers will write crappy code. This is only a clear
advantage when buggy code is executed.

Yes, this is true and a valid advantage if you ever want access external
and private files. Such access is normally discouraged though, since you
are outside of the boundaries of your transaction.

negative impact on single threaded systems as well. I'm sure you will
find memory leak examples that are fatal only in a multi-threaded 24x7
environment but they are probably very few overall.

1. Threads communicate much faster than processes (applies to locking
and parallel query processing).
2. All threads in a process can share a common set of optimized query plans.
3. All threads can share lots of data cached in memory (static but
frequently accessed tables etc.).
4. In environments built using garbage collection, all threads can share
the same heap of garbage collected data.
5. A multi-threaded system can apply in-memory heuristics for self
adjusting heaps and other optimizations.
6. And lastly, my favorite; a multi-threaded system can be easily
integrated with, and make full use of, a multi-threaded virtual
execution environment such as a Java VM.
....

Regards,
Thomas Hallgren


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

On Wed, Oct 27, 2004 at 10:07:48PM +0200, Thomas Hallgren wrote:
A lot of these advantages are due to sharing an address space, right?
Well, the processes in PostgreSQL share address space, just not *all*
of it. They communicate via this shared memory.

PostgreSQL could do this too, but I don't think anyone's looked into
sharing query plans, probably quite difficult.

Table data is already shared. If two backends are manipulating the same
table, they can lock directly via shared memory rather than some OS
primitive.

I can't really comment on these.

I think PostgreSQL has nicely combined the benefits of shared memory
with the robustness of multiple processes...
--
Martijn van Oosterhout <kleptog (AT) svana (DOT) org> http://svana.org/kleptog/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFBgAbAY5Twig3Ge+YRAv58AKDbbz0HGGGVqwEMs2DHrO 0uS4eKWgCfcOWV
dpSlITmq68nZqpkWj8gBEkQ=
=sotm
-----END PGP SIGNATURE-----

Martijn van Oosterhout wrote:
that you need to synchronize shared memory access is much more expensive
than the mechanisms used to synchronize threads.

generated, it should not be that difficult. But managing the mutable
area where the plans are cached again calls for expensive inter-process
synchronization.

consumes more resources and the mutexes are a lot slower.

So do I. I've learned to really like PostgreSQL and the way it's built,
and as I said in my previous mail, I'm not advocating a switch. I just
react to the unfair bashing of multi-threaded systems.

Regards,
Thomas Hallgren


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

On Thu, Oct 28, 2004 at 12:13:41AM +0200, Thomas Hallgren wrote:
Now you've piqued my curiosity. You have two threads of control (either
two processes or two threads) which shared a peice of memory. How can
the threads syncronise easier than processes, what other feature is
there? AFAIK the futexes used by Linux threads is just as applicable
and fast between two processes as two threads. All that is required is
some shared memory.

Or are you suggesting the only difference is in switching time (which
is not that significant).

Also, I admit that on some operating systems, threads are much faster
than processes, but I'm talking specifically about linux here.

Thanks in advance,
--
Martijn van Oosterhout <kleptog (AT) svana (DOT) org> http://svana.org/kleptog/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFBgMK4Y5Twig3Ge+YRAndzAKDdCZJvwjiTbC/YRAwunRheLhsKKQCdFP4S
zMQx1t08h5ldwjdq/BhPNHI=
=TjK5
-----END PGP SIGNATURE-----

On Thu, 28 Oct 2004 Richard_D_Levine (AT) raytheon (DOT) com wrote:

Quick answers:
- there won't be any I/O wait;
- there won't be any semaphore-related wait;
- in my previous message, I've never mentioned the kernel scheduler;
- no, the kernel knows nothing about PostgreSQL sessions.

It seems quite obvious to me that in the "one flow of execution per CPU"
model, all I/O is non-blocking. Everything is event-driven.

With session "scheduler" I was referring to the (generic) operation
of serving multiple sessions. On a 1-way system we do want to serve more
than one client. Right now, we relay on the kernel in choosing which one
to run at a given moment. We _do_ know better of it in many cases, see
the priority inversion problem mentioned a few days ago on the list.

The above is true for most N-ways systems, since we still want to serve
M sessions, where usually M >> N.

..TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo (AT) ESI (DOT) it

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org

On Thu, Oct 28, 2004 at 04:32:34PM +0200, Marco Colombo wrote:
Ok, let me think here. I think what you are suggesting is like the way
IRC servers work. They have one process with a few thousand sockets and
simply process the messages as they come in.

Only you want to do it in a system that actually needs to do a lot of
processing. Basically, you'd need to make all I/O non-blocking and all
the code would probably need to be converted to callback routines or
something similar. If you have no global variables this is quite
doable, though of questionable benefit. The issues I can think of:

1. non-blocking is nice, but lots of OSes (eg POSIX) don't support it
on disk I/O unless you use a completely different interface.

2. If one of your 'processes' decides to do work for half an hour (say,
a really big merge sort), you're stuck. At least with multiple
processes the kernel will preempt you eventually.

3. On Linux anyway, most process scheduling occurs on I/O waits anyway.
Forcable preemption can only really occur up to 100 times per second
and unless someone else is available to run (ie not I/O wait) nothing
will change.

I honestly don't think you could really do a much better job of
scheduling than the kernel. The kernel has a much better idea of what
processes are waiting on, and more importantly, what other work is
happening on the same machine that also needs CPU time.
--
Martijn van Oosterhout <kleptog (AT) svana (DOT) org> http://svana.org/kleptog/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFBhMuWY5Twig3Ge+YRAiKLAJ4sNKIA3kEpJp0sh6T5p4 tuhSpCFQCglnUm
QTVbE0XZi1Im8/+SbQs5ysA=
=Ex7y
-----END PGP SIGNATURE-----

Martijn,
days ago, although for some reason it was never received by the mailing
list.

----

Marco,


Sounds very much like a description of the preemption points that a
user-space thread scheduler would use.


In order to determine from where an event origins, say an I/O complete
event, you need to associate some structure with the I/O operation. That
structure defines the logical flow of all events for one particular
session or query, and as such it's not far from a lightweigth thread.
The only difference is that your "thread" resumes execution in a logical
sense (from the event loop) rather than a physical program counter
position. The resource consumption/performance would stay more or less
the same.


Criteria based prioritisation is very interesting but I think your model
has some flaws:
- Since the kernel has no idea your process servers a lot of sessions
_it_ will be considered a "big" process.
- If a process/thread will do lots of I/O waits (likely for a "big"
query) it's unlikely that the kernel will consider it a CPU hog.
- Most big queries are read-only and hence, do not lock a lot of things.
- PostgreSQL uses MVCC which brings the concurrent lock problem down to
a minimum, even for queries that are not read-only.
- Giving big queries a lot of resources is not the desired behavior in
many cases.
- Your scheduler is confined to one CPU and cannot react to the system
as a whole.

I think it is more important that the scheduler can balance _all_
sessions among _all_ available resources on the machine.

Regards,
Thomas Hallgren




---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

I don't see the big difference between what Marco is suggesting and user
threads -- or to be more precise, I think user threads and event-based
programming are just two sides of the same coin. A user thread just
represents the state of a computation -- say, a register context and
some stack. It is exactly that *state* that is passed to a callback
function in the event-based model. The only difference is that with user
threads the system manages context for you, whereas the event-based
model lets the programmer manage it. Which model is better is difficult
to say.

Martijn van Oosterhout wrote:
We could implement I/O via something like POSIX AIO or a pool of worker
threads that do the actual I/O in a synchronous fashion. But yeah,
either way it's a major change.

It would be relatively easy to insert yield points into the code to
prevent this from occurring. However, preemptive scheduling would come
in handy when running "foreign" code (e.g. user-defined functions in C).

I think we could do better than the kernel by taking advantage of
domain-specific knowledge, I'm just not sure we could beat the kernel by
enough to make this worth doing.

BTW, I think this thread is really interesting -- certainly more
informative than a rehash of the usual "processes vs. threads" debate.

-Neil

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[Cc: list minimized]

On Tue, 2 Nov 2004, Neil Conway wrote:

Well, the difference is that in a pure event-driven model, you
(the programmer) have full control over what the state is. Any thread
library offers a "general purpose" thread, which may be more than
what you want/need.
Of course, very often userland threads are good implementation of
an even-driven model. Think of GUIs.

The problem is not threads or not. The problem is one thread/process
per session, as opposed to a few specialized threads or one thread per
outstanding query. We can start another "thread" :-) on threads in
general but it would be largely off-topic here.

Thanks, that was the whole point.

I thought that the even-driven model was well-understood, I personally
consider it an established alternative to the threads/processes one.
I'd do a bad and pointless job in further explaining it. Please let me
just throw a few URLs in...

http://www.usenix.org/events/usenix0...tml/index.html

A random quote to attract readers: :-)

In general, thread-per-connection servers have the drawback of large
forking and context-switching overhead. In addition, the memory usage
due to threads' individual stack space can become huge for handling
large number of concurrent connections. The problem is even more
pronounced if the operating system does not support kernel-level
threads, and the application has to use processes or user-level
threads. It has been shown that thread-based servers do not scale well
at high loads [7]. Hence, many servers are structured as event-based
applications, whose performance is determined by the efficiency of event
notification mechanisms they employ. Pure event-based servers do not
scale to multiprocessor machines, and hence, on SMP machines, hybrid
schemes need to be employed, where we have a multi-threaded server
with each thread using event-handling as a mechanism for servicing
concurrent connections. Even with a hybrid server, the performance of
event-based mechanisms is an important issue. Since efficient event
dispatching is at the core of both event-based and hybrid servers,
we will focus on the former here.


http://www.kegel.com/c10k.html

This paper is very complete, it covers almost all possible techniques
to implement even-driver servers, and it's a very interesting reading
anyway.
Please note that the rationale behind it is the "C10k problem", which
I _don't_ think we're facing here. There are some nice properties
of even-driven servers other than being able to handle 100K connections,
IMHO.

All this started from the priority inversion problem, a few messages ago
on this list. The problem was to 'slow down' a query.
In general, I've been thinking about a not-so-cooperative environment,
which demands for some active measures to limit resources used by a
session (other than the DBA yelling at the (mis)user). Think of high
density web services, with hundreds of sites on the same host.
Even-driven servers easily allow to take full control over the resources
allocated to each session.

..TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo (AT) ESI (DOT) it

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings