Mailinglist Archive: opensuse (1470 mails)

< Previous Next >
Re: [opensuse] Why Is Leap 42.1 Benchmarking Poorly?
On 02/25/2016 06:28 AM, Vojtěch Zeisek wrote:
Copy-on-write is terribly slowing down any DB. Also snapshots don't make
for DB (use DB's tools). Maybe there are more problematic points. That is why
Btrfs is the worst for any DB.

back in the days when oracle didn't consider UNIX - Linux didn't exist
then - worth bothering with, it made the case that the DBM should be
managing disk access. Even when, grudgingly, oracle migrated to some of
the Big iron UNIX implementation from SUN/servers, AIX/servers and HP/UX
it still insisted on running on raw partitions and not a file system. I
recall one Oracle support tech telling me that using files was was for
toy databases lie dBase.

The file system is just another layer of indirection. Having to play
COW-games as well is an overhead.

So why bother?
I can think of two principal reasons.

1. Integrated backups.
While the database-on-raw is efficient in one way, it makes backups
awkward. It involves converting tables to files ("exporting") so
that the normal backup tools can be used. Slow, inefficient and
error prone.

2. File systems have got better.
I often refer to the early days, the V7FS, the early Berkeley FFS.
They were easy to understand, in some ways easier than MinixFS.
But they were not by any means efficient even by the metrics of
those days. Modern file systems are not only more efficient but
have facilities that those antediluvian dinosaurs never had, such
as expanded file space and size, large block allocation and
preallocation, journalling and more.

While BtrFS, like LVM and XFS, can span more than one volume, a more
useful multi-spindle approach is available with RAID, again something
that wasn't there when Oracle only ran on IBM mainfrmes.

Ultimately though, the oracle experience is not the beast way of looking
at things. Oracle, like the original DB2, was a huge single processor
with multi-thread. That's not the way UNIX/Linux views things. The
*NIX model is of small, possibly dynamic, processes that have a low
creation overhead. This contrasts heavily with the mainframe and even
the VAX/VMS model of the long lived, fixed number of process 'slots' and
'transient program area' area. Its why, at the time, UNIX was so
revolutionary. UNIX-friendly databases were things like Progress which
had a number of cooperating processes which could be brought up and
discarded much the way that a large shell script might work in
conjunction with there services like the line printer daemon.

Somewhere along the line IBM realised that if it was to run DB2
efficiently on its UNIX-like AIX it had to move away from the monolithic
model to something like Progress. Sort of. At the same time, the AIX
file system - JFS - was very supportive, behaving line an integrated,
journal version of LVM. It was easy to group tables to a logical volume
that was striped and cached in a specific manner; hence tuning was very
flexible. Add to that it being well integrated to IBM's multiprocessor

The "downside", if you want to consider it that way, with MySQL/MariaDB
or Postgress on line is that they are not architected for a specific
filesystem :-) If you don't like that "downside" then go with one of
the proprietary databases on BigIron.

Its worth googling for the performance of databases on XFS, JFS, ext4
and so on. Not just the reports from phoronix, but others as well.

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting frowned upon?

To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >