LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* Linux and SSD and how to decrease io delay : question, please
@ 2008-02-20 0:02 Mariella Petrini
2008-02-28 20:30 ` Bill Davidsen
0 siblings, 1 reply; 2+ messages in thread
From: Mariella Petrini @ 2008-02-20 0:02 UTC (permalink / raw)
To: linux-kernel
Hi All,
I have been running Linux kernel 2.6.23 with Debian on
a 2 CPUs Dual-Core AMD Opteron(tm) Processor 2218.
I have been using an SSD drive (MTRON) connected to a
raid controller (LSI MegaRAID 8704ELP) to contain
data stored on several databases.
Each database contains 20,000 files and there are 50
databases total (1,000,000 files distributed across 50
directories on the filesystem on the ssd).
The database server uses the databases very "write"
intensively.
An approximate percentage could be 20% reads versus
80% random writes.
No matter which filesystem type is used (I have tried
ext3, xfs, jfs, reiserfs) I see every few seconds
snapshots (the could last in the worst case up to 200
seconds, depending on the filesystem type)
where the iowait on the ssd device goes approximately
over 50% (up to 100%) and
the database server threads go to wait (get
suspended).
Is there any Linux kernel parameter or any Linux
parameter that could be varied that could help to
decrease the time spent to sync all the data to the
SSD device ?
Thanks in advance for your help,
Mariella
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Linux and SSD and how to decrease io delay : question, please
2008-02-20 0:02 Linux and SSD and how to decrease io delay : question, please Mariella Petrini
@ 2008-02-28 20:30 ` Bill Davidsen
0 siblings, 0 replies; 2+ messages in thread
From: Bill Davidsen @ 2008-02-28 20:30 UTC (permalink / raw)
To: Mariella Petrini; +Cc: linux-kernel
Mariella Petrini wrote:
> Hi All,
>
> I have been running Linux kernel 2.6.23 with Debian on
>
> a 2 CPUs Dual-Core AMD Opteron(tm) Processor 2218.
> I have been using an SSD drive (MTRON) connected to a
> raid controller (LSI MegaRAID 8704ELP) to contain
> data stored on several databases.
> Each database contains 20,000 files and there are 50
> databases total (1,000,000 files distributed across 50
> directories on the filesystem on the ssd).
>
> The database server uses the databases very "write"
> intensively.
> An approximate percentage could be 20% reads versus
> 80% random writes.
>
> No matter which filesystem type is used (I have tried
> ext3, xfs, jfs, reiserfs) I see every few seconds
> snapshots (the could last in the worst case up to 200
> seconds, depending on the filesystem type)
> where the iowait on the ssd device goes approximately
> over 50% (up to 100%) and
> the database server threads go to wait (get
> suspended).
>
> Is there any Linux kernel parameter or any Linux
> parameter that could be varied that could help to
> decrease the time spent to sync all the data to the
> SSD device ?
>
I may misunderstand the problem, but have you tried tuning the
parameters /proc/sys/vm/dirty_* to help this? It sounds as if you may be
filling write cache and then flushing. Of course you didn't measure the
disk i/o rates along with this, so it's hard to see what's happening.
--
Bill Davidsen <davidsen@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2008-02-28 20:26 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-02-20 0:02 Linux and SSD and how to decrease io delay : question, please Mariella Petrini
2008-02-28 20:30 ` Bill Davidsen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).