Am 11.06.2014 22:17, schrieb thegeezer:
On 06/11/2014 07:57 PM, Stefan G. Weichinger wrote:
looks promising:
awesome. i did have a look through the diff, there are lots of scsi
drivers selected, storage (block) cgroups but i think the crucial factor
was the HZ was set at 100 previously
hello again ... noone interested? ;-)
I understand in a way ...
Maybe I have something in the kernel misconfigured ...
Right now I get these messages again:
[ 1998.118658] hpet1: lost 1 rtc interrupts
Should I disable HPET in the BIOS and/or via kernel command line?
I never know how to set
On 05/27/2014 02:03 PM, Stefan G. Weichinger wrote:
I think I have some IO-topic going on ... very likely some mismatch of
block sizes ... the hw-raid, then LVM, then the snapshot on top of
that ... and a filesystem with properties as target ... oh my. Chosing
noop as IO-scheduler helps a bit
On 06/11/2014 10:34 AM, Stefan G. Weichinger wrote:
Am 11.06.2014 11:19, schrieb thegeezer:
Hi Stefan,
block size / stripe size mismatches only really penalise random io, if
you are trying to use dd and have slow speeds this would suggest
something else is awry.
I don't know the c600 rad
On 06/11/2014 11:14 AM, thegeezer wrote:
just some extra thoughts
*cough* yeah i meant to keep typing!
the extra thoughts are that the better way of doing this would be to
create up
RAID1 physicaldisks1+2
RAID6 physicaldisks3,4,5,6
then put lvm on there as vg01 with two PVs, one on the raid1
Am 11.06.2014 12:14, schrieb thegeezer:
Basically 3 RAID-6 hw-raids over 6 SAS hdds.
OK so i'm confused again. RAID6 requires minimum of 4 drives.
if you have 3 raid6's then you would need 12 drives (coffee hasn't quite
activated in me yet so my maths may not be right)
or do you have
On 06/11/2014 11:34 AM, Stefan G. Weichinger wrote:
Am 11.06.2014 12:14, schrieb thegeezer:
Basically 3 RAID-6 hw-raids over 6 SAS hdds.
OK so i'm confused again. RAID6 requires minimum of 4 drives.
if you have 3 raid6's then you would need 12 drives (coffee hasn't quite
activated in me
Am 11.06.2014 12:41, schrieb thegeezer:
everything around 380 MB/s ... only ~350 MB/s for
/dev/vg01/winserver_disk0 (which still is nice)
OK here is the clue.
if the LVs are also showing such fast speed, then please can you show
your command that you are trying to run that is so slow ?
On 06/11/2014 11:49 AM, Stefan G. Weichinger wrote:
Am 11.06.2014 12:41, schrieb thegeezer:
everything around 380 MB/s ... only ~350 MB/s for
/dev/vg01/winserver_disk0 (which still is nice)
OK here is the clue.
if the LVs are also showing such fast speed, then please can you show
your
On 06/11/2014 11:49 AM, Stefan G. Weichinger wrote:
Am 11.06.2014 12:41, schrieb thegeezer:
everything around 380 MB/s ... only ~350 MB/s for
/dev/vg01/winserver_disk0 (which still is nice)
OK here is the clue.
if the LVs are also showing such fast speed, then please can you show
your
Am 11.06.2014 13:01, schrieb thegeezer:
yeah this is very very odd.
firstly there should not be such discrepancy between hdparm -t and dd if=
secondly you would imagine that the first dd would be cached and so
would be faster the second time round
please check for the turbo boost disable,
Am 11.06.2014 13:18, schrieb thegeezer:
just out of curiosity, what happens if you do # dd
if=/dev/vg01/amhold of=/dev/null bs=1M count=100 # dd if=/dev/sdc
of=/dev/null bs=1M count=100
booze ~ # dd if=/dev/vg01/amhold of=/dev/null bs=1M count=100
100+0 Datensätze ein
100+0 Datensätze aus
On 06/11/2014 12:21 PM, Stefan G. Weichinger wrote:
Am 11.06.2014 13:18, schrieb thegeezer:
just out of curiosity, what happens if you do # dd
if=/dev/vg01/amhold of=/dev/null bs=1M count=100 # dd if=/dev/sdc
of=/dev/null bs=1M count=100
booze ~ # dd if=/dev/vg01/amhold of=/dev/null
Am 11.06.2014 13:52, schrieb thegeezer:
ok baffling.
sdc i already said would be slower but not this much slower
it certainly should not be slower than the lvm that sits on top of it!
i can't see anything in the cgroups that stands out, maybe someone else
can give a better voice to this.
On 06/11/2014 01:41 PM, Stefan G. Weichinger wrote:
Am 11.06.2014 13:52, schrieb thegeezer:
ok baffling.
sdc i already said would be slower but not this much slower
it certainly should not be slower than the lvm that sits on top of it!
i can't see anything in the cgroups that stands out,
Am 11.06.2014 15:32, schrieb thegeezer:
So my kernel-config seems buggy or I should downgrade to something older?
I suspect that in your fully running system somethingelse(tm) is
stealing the activity. can you start up with no services enabled and
do the test ?
hm, yes. although I had
Am 11.06.2014 15:44, schrieb Stefan G. Weichinger:
Am 11.06.2014 15:32, schrieb thegeezer:
So my kernel-config seems buggy or I should downgrade to something older?
I suspect that in your fully running system somethingelse(tm) is
stealing the activity. can you start up with no services
On 06/11/2014 03:15 PM, Stefan G. Weichinger wrote:
Am 11.06.2014 15:44, schrieb Stefan G. Weichinger:
Am 11.06.2014 15:32, schrieb thegeezer:
So my kernel-config seems buggy or I should downgrade to something older?
I suspect that in your fully running system somethingelse(tm) is
stealing
looks promising:
virt-backup dumps and packs a 12 GB image-file within ~145 seconds to a
non-compressing btrfs subvolume:
a) does a LVM-snapshot
b) dd with bs=4M and through pigz to the target file
The bigger LV with ~250GB is running right now.
The system feels snappier than with the old
On 06/11/2014 07:57 PM, Stefan G. Weichinger wrote:
looks promising:
awesome. i did have a look through the diff, there are lots of scsi
drivers selected, storage (block) cgroups but i think the crucial factor
was the HZ was set at 100 previously and 1000 now. i guess it has
helped kernel-io
Am 27.05.2014 15:03, schrieb Stefan G. Weichinger:
way too slow ...
I think I have some IO-topic going on ... very likely some mismatch of
block sizes ...
the hw-raid, then LVM, then the snapshot on top of that ... and a
filesystem with properties as target ... oh my.
Chosing noop as
additional infos from journalctl.
I don't like the fact with 512-byte logical blocks vs. 4096-byte
physical blocks ... sounds wrong, hm?
-
Jun 10 21:54:31 booze kernel: megaraid_sas :02:00.0: Controller
type: MR,Memory size is: 512MB
Jun 10 21:54:31 booze kernel: scsi7 : LSI SAS based
Found out something about megacli and checked settings for cache and
stuff following
http://highperfpostgres.com/guides/lsi-megaraid-setup-for-postgresql/
Did I set a wrong Strip Size for the third array?
good night, late here ...
Stefan
# megacli -LDInfo -Lall -aALL
Adapter 0 -- Virtual
Am 26.05.2014 21:57, schrieb Stefan G. Weichinger:
Am 26.05.2014 19:47, schrieb Stefan G. Weichinger:
But I somehow think the performance is sub-optimal.
virt-backup is slow as well (using dd and gzip or pigz in my own patched
version). Yes, that LVM stuff again ...
I run 6 SAS disks
Am 24.05.2014 21:24, schrieb Stefan G. Weichinger:
Am 23.05.2014 09:52, schrieb Stefan G. Weichinger:
Greetings,
I have a new Fujitsu TX150 here, with a
Intel(R) C600 SAS Controller
and an LTO4 drive attached to it.
My kernel has support for isci, scsi tape, ahci and all the sas stuff
Am 26.05.2014 19:47, schrieb Stefan G. Weichinger:
But I somehow think the performance is sub-optimal.
virt-backup is slow as well (using dd and gzip or pigz in my own patched
version). Yes, that LVM stuff again ...
I run 6 SAS disks and built hardware raids.
Should I look into the cache
Am 23.05.2014 09:52, schrieb Stefan G. Weichinger:
Greetings,
I have a new Fujitsu TX150 here, with a
Intel(R) C600 SAS Controller
and an LTO4 drive attached to it.
My kernel has support for isci, scsi tape, ahci and all the sas stuff
... but I don't get any st devices.
Do I
Greetings,
I have a new Fujitsu TX150 here, with a
Intel(R) C600 SAS Controller
and an LTO4 drive attached to it.
My kernel has support for isci, scsi tape, ahci and all the sas stuff
... but I don't get any st devices.
Do I need SCSI_PROC_FS set? I just wonder ...
thanks, Stefan
28 matches
Mail list logo
