Also remember that in even well developed OS's like FreeBSD, all a
process's threads will execute only on one CPU. This might change in
FreeBSD 5.0, but still a threaded app (such as MySQL) cannot use mutliple
CPUs on a FreeBSD system.
On Fri, 3 Jan 2003, mlw wrote:
> Please no threading threads!!!
> Has anyone calculated the interval and period of "PostgreSQL needs
> threads" posts?
> The *ONLY* advantage threading has over multiple processes is the time
> and resources used in creating new processes.
> That being said, I admit that creating a threaded program is easier than
> one with multiple processes, but PostgreSQL is already there and working.
> Drawbacks to a threaded model:
> (1) One thread screws up, the whole process dies. In a multiple process
> application this is not too much of an issue.
> (2) Heap fragmentation. In a long uptime application, such as a
> database, heap fragmentation is an important consideration. With
> multiple processes, each process manages its own heap and what ever
> fragmentation that exists goes away when the connection is closed. A
> threaded server is far more vulnerable because the heap has to manage
> many threads and the heap has to stay active and unfragmented in
> perpetuity. This is why Windows applications usually end up using 2G of
> memory after 3 months of use. (Well, this AND memory leaks)
> (3) Stack space. In a threaded application they are more limits to stack
> usage. I'm not sure, but I bet PostgreSQL would have a problem with a
> fixed size stack, I know the old ODBC driver did.
> (4) Lock Contention. The various single points of access in a process
> have to be serialized for multiple threads. heap allocation,
> deallocation, etc all have to be managed. In a multple process model,
> these resources would be separated by process contexts.
> (5) Lastly, why bother? Seriously? Process creation time is an issue
> true, but its an issue with threads as well, just not as bad. Anyone who
> is looking for performance should be using a connection pooling
> mechanism as is done in things like PHP.
> I have done both threaded and process servers. The threaded servers are
> easier to write. The process based severs are more robust. From an
> operational point of view, a "select foo from bar where x > y" will take
> he same amount of time.
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly