Prev: [tip:timers/core] Documentation: Add timers/timers-howto.txt
Next: [tip:timers/core] Checkpatch: Prefer usleep_range over udelay
From: Michael Monnerie on 4 Aug 2010 05:30
On Mittwoch, 4. August 2010 Dominik Brodowski wrote:
> The read performance is abysmal. The ata devices can be ruled out, as
> hdparm
>
> resulted in acceptable performance:
> > Timing cached reads: 9444 MB in 2.00 seconds = 4733.59 MB/sec
> > Timing buffered disk reads: 298 MB in 3.02 seconds = 98.73
> > MB/sec

Has that system been running acceptable before? If yes, what has been
changed that performance is down now?

Or is it a new setup? Then why is it in production already?

Can you run bonnie on that system?
What does "dd if=<your device> of=/dev/null bs=1m count=1024" say?
What does "dd if=/dev/zero of=<your device> bs=1m count=1024" say?


--
mit freundlichen Grüssen,
Michael Monnerie, Ing. BSc

it-management Internet Services
http://proteger.at [gesprochen: Prot-e-schee]
Tel: 0660 / 415 65 31

****** Aktuelles Radiointerview! ******
http://www.it-podcast.at/aktuelle-sendung.html

// Wir haben im Moment zwei Häuser zu verkaufen:
// http://zmi.at/langegg/
// http://zmi.at/haus2009/
From: Valdis.Kletnieks on 4 Aug 2010 16:40
On Wed, 04 Aug 2010 12:25:26 +0200, Dominik Brodowski said:

> The "good" news: it also happens on my notebook, even though it has a
> different setup (no raid, disk -> lv/vg -> crypt). On my notebook, I'm
> more than happy to test out different kernel versions, patches etc.
>
> /dev/sd* 17.7 MB/s (100 %)
> /dev/mapper/vg1-* 16.2 MB/s ( 92 %)
> /dev/mapper/*_crypt 3.1 MB/s ( 18 %)

Unfortunately, on my laptop with a similar config, I'm seeing this:

# dd if=/dev/sda bs=8k count=1000000 of=/dev/null
1000000+0 records in
1000000+0 records out
8192000000 bytes (8.2 GB) copied, 108.352 s, 75.6 MB/s
# dd if=/dev/sda2 bs=8k count=1000000 of=/dev/null
1000000+0 records in
1000000+0 records out
8192000000 bytes (8.2 GB) copied, 105.105 s, 77.9 MB/s
# dd if=/dev/mapper/vg_blackice-root bs=8k count=100000 of=/dev/null
100000+0 records in
100000+0 records out
819200000 bytes (819 MB) copied, 11.6469 s, 70.3 MB/s

The raw disk, the LUKS-encrypted partition that's got a LVM on it, and a
crypted LVM partition. The last run spikes both CPUs up to about 50%CPU each.
So whatever it is, it's somehow more subtle than that. Maybe the fact that
in my case, it's disk, crypto, and LVM on the crypted partition, rather than
crypted filesystems on an LVM volume?

 | 
Pages: 1
Prev: [tip:timers/core] Documentation: Add timers/timers-howto.txt
Next: [tip:timers/core] Checkpatch: Prefer usleep_range over udelay