PostgreSQL benchmarks under giant lock free DragonflyBSD
leaf.dragonflybsd.org
PostgreSQL benchmarks under giant lock free DragonflyBSD
1–10 of 15 posts
Re: PostgreSQL benchmarks under giant lock free DragonflyBSD
#2Summary/background: DragonflyBSD split from FreeBSD (partly) over multicore strategy, FreeBSD going with threads and fine-grained kernel locks and DragonflyBSD going with a microkernel and multiple processes (not entirely dissimilar to GNU Hurd.)
This post shows a standard PostgreSQL benchmark on a big machine (2 cpus * 6 cores/cpu * 2 hardware threads/core, 96GB RAM) and the news is that Dragonfly is approaching FreeBSD's performance (while hopefully being more flexible/secure due to the microkernel design).
As an aside, Scientific Linux handily destroys both FreeBSD and DragonflyBSD in localhost benchmarks, but crashes rather a lot. (This seems odd, but the focus is on the DragonflyBSD / FreeBSD comparison anyway.)
Re: PostgreSQL benchmarks under giant lock free DragonflyBSD
#3Summary/background: DragonflyBSD split from FreeBSD (partly) over multicore strategy, FreeBSD going with threads and fine-grained kernel locks and DragonflyBSD going with a microkernel and multiple processes (not entirely dissimilar to GNU Hurd.) This post shows a standard PostgreSQL benchmark on a big machine (2 cpus * 6 cores/cpu * 2 hardware threads/core, 96GB RAM) and the news is that Dragonfly is approaching Fre…
Thanks for the summary. I was drawn in by the magic phrase "PostgreSQL benchmarks" but didn't know enough about DragonflyBSD to know the reason the results presented were of note.
Re: PostgreSQL benchmarks under giant lock free DragonflyBSD
#4Summary/background: DragonflyBSD split from FreeBSD (partly) over multicore strategy, FreeBSD going with threads and fine-grained kernel locks and DragonflyBSD going with a microkernel and multiple processes (not entirely dissimilar to GNU Hurd.) This post shows a standard PostgreSQL benchmark on a big machine (2 cpus * 6 cores/cpu * 2 hardware threads/core, 96GB RAM) and the news is that Dragonfly is approaching Fre…
I don't know that the issues reported can be called "crashes." Rather it is locking up, probably because there are not enough resources reserved for the terminal and therefore the terminal becomes unresponsive while waiting for an opportunity to run.
Re: PostgreSQL benchmarks under giant lock free DragonflyBSD
#5Summary/background: DragonflyBSD split from FreeBSD (partly) over multicore strategy, FreeBSD going with threads and fine-grained kernel locks and DragonflyBSD going with a microkernel and multiple processes (not entirely dissimilar to GNU Hurd.) This post shows a standard PostgreSQL benchmark on a big machine (2 cpus * 6 cores/cpu * 2 hardware threads/core, 96GB RAM) and the news is that Dragonfly is approaching Fre…
One addendum to this benchmark (somewhere else in that thread) shows OpenSolaris mostly outperforming Linux.
Re: PostgreSQL benchmarks under giant lock free DragonflyBSD
#6Summary/background: DragonflyBSD split from FreeBSD (partly) over multicore strategy, FreeBSD going with threads and fine-grained kernel locks and DragonflyBSD going with a microkernel and multiple processes (not entirely dissimilar to GNU Hurd.) This post shows a standard PostgreSQL benchmark on a big machine (2 cpus * 6 cores/cpu * 2 hardware threads/core, 96GB RAM) and the news is that Dragonfly is approaching Fre…
I don't know that the issues reported can be called "crashes." Rather it is locking up, probably because there are not enough resources reserved for the terminal and therefore the terminal becomes unresponsive while waiting for an opportunity to run.
It was also the less stable. I discovered more than once the machine was
completely frozen (blank screen, no keyboard or network response). Even a NMI
couldn't change anything.
Sounds like a rather hard crash to me.
Re: PostgreSQL benchmarks under giant lock free DragonflyBSD
#7Summary/background: DragonflyBSD split from FreeBSD (partly) over multicore strategy, FreeBSD going with threads and fine-grained kernel locks and DragonflyBSD going with a microkernel and multiple processes (not entirely dissimilar to GNU Hurd.) This post shows a standard PostgreSQL benchmark on a big machine (2 cpus * 6 cores/cpu * 2 hardware threads/core, 96GB RAM) and the news is that Dragonfly is approaching Fre…
Scientific Linux uses also a rather old Linux kernel.
Results with a more recent kernel would also be nice to have.
Re: PostgreSQL benchmarks under giant lock free DragonflyBSD
#8Earlier quoted context omitted.
I don't know that the issues reported can be called "crashes." Rather it is locking up, probably because there are not enough resources reserved for the terminal and therefore the terminal becomes unresponsive while waiting for an opportunity to run.
It was also the less stable. I discovered more than once the machine was completely frozen (blank screen, no keyboard or network response). Even a NMI couldn't change anything. Sounds like a rather hard crash to me.
Were database transactions continuing while the terminal was non-responsive? Yes. Thus, its not really crashed.
Re: PostgreSQL benchmarks under giant lock free DragonflyBSD
#9Summary/background: DragonflyBSD split from FreeBSD (partly) over multicore strategy, FreeBSD going with threads and fine-grained kernel locks and DragonflyBSD going with a microkernel and multiple processes (not entirely dissimilar to GNU Hurd.) This post shows a standard PostgreSQL benchmark on a big machine (2 cpus * 6 cores/cpu * 2 hardware threads/core, 96GB RAM) and the news is that Dragonfly is approaching Fre…
Scientific Linux uses also a rather old Linux kernel. Results with a more recent kernel would also be nice to have.
SL is a RHEL clone like CentOS. This was the 6.1 release, which is 2.6.32 (plus a ton of patches) and corresponds closely to Red Hat's latest and greatest. It's not an unreasonable choice if you just want to add a "Linux" line to the graph.
Remember this is a narrow benchmark of multi-core scalability under a SQL load. It's not particularly useful as evidence in OS flames, and the goal isn't to see "how much faster" Linux is, but rather to characterize areas where Dragonfly needs work.
(I will admit I was surprised at how much better Linux did at the heavy-SMP side of the graph though. Edit for clarity: I'm not at all surprised that Linux does well; I live in that world too. I'm surprised that it does so much better than the BSDs. At the right edge of the graph, Linux is still flat where the other kernels are dropping fast due to overhead, and Linux is doing 3x-4x better. That's surprising.)
Re: PostgreSQL benchmarks under giant lock free DragonflyBSD
#10Earlier quoted context omitted.
Scientific Linux uses also a rather old Linux kernel. Results with a more recent kernel would also be nice to have.
SL is a RHEL clone like CentOS. This was the 6.1 release, which is 2.6.32 (plus a ton of patches) and corresponds closely to Red Hat's latest and greatest. It's not an unreasonable choice if you just want to add a "Linux" line to the graph. Remember this is a narrow benchmark of multi-core scalability under a SQL load. It's not particularly useful as evidence in OS flames, and the goal isn't to see "how much faster"…
I'm surprised that you're surprised- there are a lot of people who work on the Linux kernel, more than Dragonfly or FreeBSD, and they generally care much more about this sort of graph than desktop performance.