老原始设备栗子。 [英] The old raw devices chestnut.
问题描述
请注意交叉发布 - 但请不要发生火焰战。
这个问题是由postgres邮件列表上的一个帖子提示的
某人（格雷戈里·威廉姆森）声称
< quote>
原始设备，至少在Solaris上，速度是熟的约10倍
Informix的文件系统。
< quote>
这让我想到了旧的论点，我想知道
目前的思维状态。我的一些知识将来自
日期。
Oracle :(我的主要经验）
在不同时间甲骨文声称（与顾问商量，而不是营销人员），原始设备比文件系统快5-20％。这可能是因为oracle代码的当前状态和/或与b / b
相比较的文件系统而有所不同。 Veritas似乎同意为Oracle生成QuickIO，
声称使用文件系统管理实现原始性能。
我从未充分相信实现一个主要系统
with raw。
Sybase :(一些经验）
Sybase声称文件系统更快，因为操作系统缓冲，但不安全
出于同样的原因。他们只为tempdb建议文件系统。他们
似乎没有听说过fsync（）[1]
DB2：
不知道
Informix：
除了开始此之外的声明之外没有任何想法。
最新的想法是什么，供应商索赔条款和
实际经验？
[1]或任何系统调用强制直写缓存
-
吉姆史密斯
由于他们持续的网络滥用，我忽略来自这些域名（以及其他）.yahoo.com .hotmail的邮件。
。 com .kr .cn .tw
如需解释，请参阅< http：//www.jimsmith.demon.co.uk/spam>
Note the cross-posting - but no flame wars please.
This question was prompted by a thread on the a postgres mailing list
during which someone (Gregory Williamson) claimed
<quote>
raw devices, at least on Solaris, are about 10 times as fast as cooked
file systems for Informix.
<quote>
This made me think about the old arguments, and I wondered about the
current state of thinking. Some of my knowledge will be a bit out of
date.
Oracle: (my main experience)
At various times Oracle have claimed (talking to consultants, not
marketers) that raw devices are 5-20% faster than filesystems. This may
vary on the current state of the oracle code and/or the filesystem being
compared against. Veritas seem to agree by producing QuickIO for Oracle,
claiming "performance of raw with the management of filesystem".
I have never been sufficiently convinced to implement a major system
with raw.
Sybase: (some experience)
Sybase claim filesystems are faster, because of OS buffering, but unsafe
for the same reason. They only ever suggest filesystem for tempdb. They
don''t seem to have heard of fsync()[1]
DB2:
No idea
Informix:
No idea beyond the claim which started this off.
What is the latest thinking, both in terms of vendor claims and
practical experience?
[1] or whatever system call forces write-through caching
--
Jim Smith
Because of their persistent net abuse, I ignore mail from
these domains (among others) .yahoo.com .hotmail.com .kr .cn .tw
For an explanation see <http://www.jimsmith.demon.co.uk/spam>
推荐答案
" Jim Smith" < ji*@jimsmith.demon.co.uk>在消息中写道
新闻：dS ************** @ jimsmith.demon.co.uk ...
"Jim Smith" <ji*@jimsmith.demon.co.uk> wrote in message
news:dS**************@jimsmith.demon.co.uk...
这个问题是由postgres邮件列表上的一个帖子提示
期间某人（Gregory Williamson）声称
< quote>
原始设备，至少在Solaris上，大约是10倍与Informix的烹饪文件系统一样快。
< quote>
This question was prompted by a thread on the a postgres mailing list
during which someone (Gregory Williamson) claimed
<quote>
raw devices, at least on Solaris, are about 10 times as fast as cooked
file systems for Informix.
<quote>
如果我们都能理解到什么，请先看看它是什么？ >
的意思是更快？
I / O请求是否更快？
或整体I / O更快？
或者更少的CPU使用？
这是IME：
1- Raw不能用于更快 I / O。 I / O速度定义为
您的硬件（磁盘+控制器）和原始或煮熟意味着什么没有
在这种情况下。
2- Raw产生更快的I / O响应速度，其他条件相同。
3-然而，这可能会更快或更快。
解释：
如果db正在读取文件系统缓冲区缓存，那么它是非常好的STUPID来声明文件系统 I / O"更快：在这种情况下，没有I / O，只有内存访问！
如果db从磁盘读取到fs缓存然后从那里复制
到db cache然后raw会更快：它不需要复制到fs
缓存中，I / O直接转到db缓存。在这种情况下，一个注意到显示CPU使用率（！）下降而不是通过切换到原始的I / O使用：
块/页面副本没有来便宜或免费。
如果fs缓存允许通过db进程的指针进行引用，那么
则fs I / O的速度几乎与原始但CPU使用率稍高一点：使用间接寻址（通过指针）比使用直接寻址（通过段寻址）更重的资源比资源更重要。 />
然而，fs缓存将处理来自整个系统的请求，而不仅仅是数据库硬件的
。因此，存在严重干扰
db I / O活动的可能性。因此，如果系统不是专用的数据库服务器，那么可以看到I / O响应时间的一些变化，并且系统会有不同的系统
加载。
这一切都取决于测量的内容，时间和方式。
-
干杯
Nuno Souto
wi*******@yahoo.com.au.nosp am
Let''s see first if we can all understand what the heck
is meant by "faster"?
Is it faster I/O requests?
Or faster I/O overall?
Or less CPU used?
Here is IME:
1- Raw does not make for "faster" I/O. I/O speed is defined by
your hardware (disk + controller) and raw or cooked means nothing
in that context.
2- Raw produces overall faster I/O response, all else being equal.
3- However, this can be MUCH faster, or slightly faster.
Explain:
If db is reading off the file system buffer cache, then it is
eminently STUPID to claim "file system I/O" is faster: there is
no I/O in that case, just in-memory access!
If db is reading from disk to fs cache and then copying from there
to db cache then raw will be faster: it doesn''t need to copy into the fs
cache, I/O goes directly to the db cache. In such cases one notices
a marked drop in CPU use(!) rather than I/O use by switching to raw:
the block/page copy doesn''t come cheap or free.
If the fs cache allows for referencing via pointers from the db processes,
then the fs I/O will be almost same speed as raw but CPU use will be a
little higher: use of indirect addressing (via pointers) is slightly
heavier on resources than direct addressing (via segment addressing).
However a fs cache will be servicing requests from the ENTIRE system, not just
the database hardware. So the potential for heavy interference with the
db I/O activity is there. As such if the system is not a dedicated db server,
one can see some wild variations in I/O response times with varying system
loads.
It all depends on what is being measured, and when and how.
--
Cheers
Nuno Souto
wi*******@yahoo.com.au.nospam
" Jim Smith" < ji*@jimsmith.demon.co.uk>在消息中写道
新闻：dS ************** @ jimsmith.demon.co.uk ...
"Jim Smith" <ji*@jimsmith.demon.co.uk> wrote in message
news:dS**************@jimsmith.demon.co.uk...
注意十字架-posting - 但请不要发生火焰战。
这个问题是由postgres邮件列表中的一个帖子提示的，其间有人（Gregory Williamson）声称
< quote>
原始设备，至少在Solaris上，是Informix的熟文件系统的10倍。
< quote>
Note the cross-posting - but no flame wars please.
This question was prompted by a thread on the a postgres mailing list
during which someone (Gregory Williamson) claimed
<quote>
raw devices, at least on Solaris, are about 10 times as fast as cooked
file systems for Informix.
<quote>
我对此有3个想法。
1. FS是db和硬件之间的额外代码层，对于那个
范围如果你比较实际磁盘的直接读数 - 而不是从某个地方的缓存中读取
a - 那么RAW会更快 - 十次似乎是一个
但是很重要。
2.谁关心 - 重要的不是磁盘读取的速度，而是最终用户的响应时间
屏幕/工作 - 当且仅当你能展示
t帽子这很慢，速度是由文件系统引起的，你会不会考虑RAW。
3.向我们展示数字和实验来证明声明。
-
Niall Litchfield
Oracle DBA
审计委员会英国
http://www.niall.litchfield.dial.pipex.com
***************************************** />
请包括版本和平台
和适用的SQL
它让生活更轻松，增加了好的可能性回答
***************************************** *
I have 3 thoughts on this.
1. A FS is an extra layer of code between the db and the hardware, to that
extent if you are comparing a direct read from the actual disk - rather than
a read from a cache somewhere - then RAW will be faster - ten times seems a
hefty claim though.
2. Who cares - what matters isn''t the speed of the disk read, but the
response time for the end users screens/jobs - if and only iff you can show
that this is slow and the speed is caused by a file system would you
consider RAW.
3. show us the numbers and the experiment done to prove the statement.
--
Niall Litchfield
Oracle DBA
Audit Commission UK
http://www.niall.litchfield.dial.pipex.com
*****************************************
Please include version and platform
and SQL where applicable
It makes life easier and increases the
likelihood of a good answer
******************************************
Jim Smith< ji *@jimsmith.demon.co.uk>写在
新闻：dS ************** @ jimsmith.demon.co.uk：
Jim Smith <ji*@jimsmith.demon.co.uk> wrote in
news:dS**************@jimsmith.demon.co.uk:
Sybase： （一些经验）
Sybase声称文件系统更快，因为OS缓冲，但由于同样的原因不安全。他们只建议使用
tempdb的文件系统。他们似乎没有听说过fsync（）[1]
Sybase: (some experience)
Sybase claim filesystems are faster, because of OS buffering, but
unsafe for the same reason. They only ever suggest filesystem for
tempdb. They don''t seem to have heard of fsync()[1]
您在Sybase ASE上的数据已过时。 Sybase允许您使用缓冲的
设备，您可以选择发布写入（DSYNC = on）或
缓冲（DSYNC = off）。 Sybase一直建议使用原始的
设备。
对于所有数据库，我总是使用基于基准测试的原始设备
数字我已经直观地运行了，这很有道理。如果你有一个
读取大多数表，你可以通过使用OS缓冲来获得32位数据库和超过4G的主内存。 （我已经结束了
简化而不是太多）。
我从其中一名团队成员那里学到的基准测试技巧是
对我的原始设备使用符号链接。如果我需要在
特定卷上添加更多磁盘，我可以关闭DBMS，将数据输出到另一个
磁盘，重建卷，然后重新获取数据，启动DBMS。 Voila！
问候，
-
Pablo Sanchez - Blueoak数据库工程公司
http://www.blueoakdb.com
这篇关于老原始设备栗子。的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
