Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien
Toon posts:

mdadm softraid met 2x Samsung F4EG > Rare snelheden

Pagina: 1
Acties:

woensdag 29 juni 2011 12:31

Acties:
  • iMars
  • Registratie: Augustus 2001
  • Laatst online: 14:55

iMars

Full time prutser

Topicstarter
Om te beginnen, mijn hardware:

Moederbord: SuperMicro X7SPA-H-D525
Geheugen: 2x 2GB DDR3
Harddisk: 1x Patriot 32GB SSD (Voor OS: Ubuntu 11.04), 1x 320GB, 4x 2TB Samsung HD204UI
Behuizing: Chenbro ES34069

Ik heb hierop Ubuntu 11.04 Server geinstalleerd. Nu wil ik met mdadm de 4x 2TB in raid 5 zetten.
Dit gaat goed, en werkt. Maar nu ben ik wat aan het spelen en testen om een goede performance eruit te halen. Daarvoor heb ik het script van Q gebruikt met de volgende instellingen:
code:
1
2
3
4
5
6
7
8
9
10
11

DEVICES="/dev/sd[c-f]"
NO_OF_DEVICES=4
ARRAY=/dev/md5
CHUNKS="4 8 16 32 64 128 256 512 1024"
MOUNT=/pool
LOG=/var/log/raid-test.log
LOGDEBUG=/var/log/raid-test-debug.log
LEVEL="5"
TESTFILE=$MOUNT/test.bin
TESTFILESIZE=10000
TRIES=3

Dit was het resultaat:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

marcel@iServer:~$ cat /var/log/raid-test*
| CHUNKS | LEVEL | WRITE | READ |
       4       5     218    149
       4       5     436    297
       4       5     649    446
       8       5     220     83
       8       5     442    164
       8       5     659    244
      16       5     225     82
      16       5     449    166
      16       5     665    249
      32       5     214    112
      32       5     426    223
      32       5     638    337
      64       5     204    142
      64       5     411    297
      64       5     623    445
     128       5     190    178
     128       5     380    357
     128       5     570    535
     256       5     162    204
     256       5     323    406
     256       5     485    610
     512       5     145    261
     512       5     287    524
     512       5     430    787
    1024       5     113    259
    1024       5     229    518
    1024       5     345    777
| CHUNKS | LEVEL | WRITE | READ |
       4       5     216    148
       8       5     219     81
      16       5     221     83
      32       5     212    112
      64       5     207    148
     128       5     190    178
     256       5     161    203
     512       5     143    262
    1024       5     115    259
marcel@iServer:~$

Tijdens het runnen van de script kreeg ik de volgende meldingen op het scherm (zowel bij 512 als bij 1024):
code:
1
2

log stripe unit (524288 bytes) is too large (maximum is 256KiB)
log stripe unit adjusted to 32KiB

Na wat pluiswerk kwam ik er achter dat dat niet door mdadm kwam, maar door het formateren van de array:
code:
1
2
3

root@iServer:~# mkfs.xfs /dev/md5
log stripe unit (524288 bytes) is too large (maximum is 256KiB)
log stripe unit adjusted to 32KiB

Als ik het resultaat in een overzicht zet, krijg ik het volgende:
ChunkLevelWriteRead
45216148Beste keuze voor write performance
8512981No go, te lage read
16522183No go, te lage read
325212112Chunksize 4 betere keuze
645207148Chunksize 4 betere keuze
1285190178Beste gemiddelde
2565161203Beste keuze voor read performance
5125143262No go, te grote chunksize
10245115259No go, te grote chunksize

Ik had Q om advies gevraagd:
Hoi,

Ik denk dat je reden hebt om een topic te starten in het IO forum want de beste writes heb je rond de 64 terwijl de reads achter blijven. Dat vind ik vreemd. 64 kb chunk geeft tot nu toe bij mij het beste resultaat.

Kijk nu naar die 512, de write is iets slechter, maar de read is vele malen beter. Hoe kan dat nou? Misschien kan er iets getweaked worden.

De test run zal wel even duren, maar afhankelijk van de hoeveelheid ram zou ik ook eens met 20 GB testen ipv 10. Dan in de range van 64 - 1024.

Theoretisch moeten die 4 disks 4x 100MB/s doen, maar met RAID 5 heb je er maar 3, dus 300 MB/s. Dan zou 260 MB/s heel redelijk zijn qua read. Write op 140 is niet eens zo slecht dan. Maar wat er nu precies met MDADM gebeurt op het moment dat je die 'ongeldige' waarde kiest, is wel interessant.
Toen Q antwoordde, wist ik nog niet dat mkfs.xfs de melding gaf en dat het niet van MDADM was ;)

Gisteravond/nacht heb ik nogmaals de test laten draaien, maar nu 10x ipv 3x:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103

root@iServer:~# tail -f /var/log/raid-test-debug.log 
| CHUNKS | LEVEL | WRITE | READ |
       4       5     213    148
       4       5     428    293
       4       5     644    440
       4       5     857    581
       4       5    1071    720
       4       5    1284    854
       4       5    1501    990
       4       5    1717   1126
       4       5    1934   1262
       4       5    2147   1404
       8       5     214     80
       8       5     432    155
       8       5     648    226
       8       5     863    297
       8       5    1082    369
       8       5    1302    441
       8       5    1515    514
       8       5    1733    587
       8       5    1953    667
       8       5    2173    751
      16       5     217     85
      16       5     439    168
      16       5     660    252
      16       5     882    334
      16       5    1101    416
      16       5    1322    498
      16       5    1535    578
      16       5    1751    659
      16       5    1970    740
      16       5    2189    824
      32       5     220    108
      32       5     433    221
      32       5     647    327
      32       5     860    437
      32       5    1075    551
      32       5    1291    661
      32       5    1505    773
      32       5    1724    884
      32       5    1940    996
      32       5    2155   1109
      64       5     207    152
      64       5     414    297
      64       5     624    453
      64       5     831    611
      64       5    1035    769
      64       5    1240    915
      64       5    1449   1068
      64       5    1662   1217
      64       5    1866   1355
      64       5    2075   1494
     128       5     188    178
     128       5     379    356
     128       5     566    539
     128       5     755    721
     128       5     943    904
     128       5    1132   1089
     128       5    1320   1276
     128       5    1509   1463
     128       5    1703   1648
     128       5    1892   1835
     256       5     160    218
     256       5     320    439
     256       5     478    649
     256       5     636    861
     256       5     793   1047
     256       5     952   1239
     256       5    1110   1434
     256       5    1265   1616
     256       5    1420   1783
     256       5    1577   1953
     512       5     135    225
     512       5     273    455
     512       5     410    671
     512       5     547    895
     512       5     688   1129
     512       5     828   1366
     512       5     970   1598
     512       5    1114   1816
     512       5    1255   2049
     512       5    1398   2308
    1024       5     114    247
    1024       5     226    494
    1024       5     339    738
    1024       5     451    987
    1024       5     559   1212
    1024       5     670   1443
    1024       5     782   1679
    1024       5     897   1907
    1024       5    1009   2134
    1024       5    1119   2365 
root@iServer:~# tail -f /var/log/raid-test.log 
| CHUNKS | LEVEL | WRITE | READ |
       4       5     214    140
       8       5     217     75
      16       5     218     82
      32       5     215    110
      64       5     207    149
     128       5     189    183
     256       5     157    195
     512       5     139    230
    1024       5     111    236

Zo goed als dezelfde resultaten dus.

Zit nu op werk en kan alleen via mijn iPad ssh-en naar mijn bak (firewall op werk).
Heb even getest om de array met chunksize 512 aan te maken (hier kwam ik er achter dat de foutmelding niet door MDADM kwam, maar door het formateren):
Afbeeldingslocatie: http://tweakers.net/ext/f/vUASP5ssPTqX2bhntmlG9gPF/thumb.png Afbeeldingslocatie: http://tweakers.net/ext/f/TJ9EgDIq4gFgYRTXs3oA2QtY/thumb.png

Koop hier mijn P1 reader :)

woensdag 29 juni 2011 15:42

Acties:

Verwijderd

Ik zie het script niet volledig; kun je dit nog aanpassen?

Bijvoorbeeld het dd commando, is deze ingesteld om 8 keer je RAM te testen? Met 4GiB RAM moet je dus 32GiB verplaatsen voor nauwkeurige resultaten. Eventueel kun je ook gebruik maken van een commando om de cache weg te donderen; weet dat niet uit mijn hoofd maar kan ik voor je opzoeken.

En je gebruikt XFS, kun je daarbij de read-ahead aanpassen? Je moet zeker bij hogere stripesizes de read-ahead aanpassen. Met 4 disks in RAID5 met 512 kilobyte stripe wordt dat 3x 512KiB = 1.5MiB waarbij waarschijnlijk 128K standaard read-ahead is; flink verhogen in zo'n geval dus.

Caches wegdonderen:
sync; echo 3 > /proc/sys/vm/drop_caches;

[ Voor 33% gewijzigd door Verwijderd op 29-06-2011 15:49 ]

woensdag 29 juni 2011 21:50

Acties:
  • iMars
  • Registratie: Augustus 2001
  • Laatst online: 14:55

iMars

Full time prutser

Topicstarter
Dit is het script:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

#!/bin/bash

DEVICES="/dev/sd[c-f]"
NO_OF_DEVICES=4
ARRAY=/dev/md5
CHUNKS="4 8 16 32 64 128 256 512 1024"
MOUNT=/pool
LOG=/var/log/raid-test.log
LOGDEBUG=/var/log/raid-test-debug.log
LEVEL="5"
TESTFILE=$MOUNT/test.bin
TESTFILESIZE=10000
TRIES=3

echo "| CHUNKS | LEVEL | WRITE | READ |" > $LOG
echo "| CHUNKS | LEVEL | WRITE | READ |" > $LOGDEBUG

for x in $CHUNKS
do
    for y in $LEVEL
    do
        i=0
        READ=0
        WRITE=0
        while [ "$i" -lt $TRIES ]
        do
            umount $MOUNT
            mdadm -S $ARRAY
            mdadm --zero $DEVICES
            yes | mdadm --create $ARRAY --assume-clean --level $y --chunk $x --raid-devices $NO_OF_DEVICES $DEVICES
            sleep 5
            mkfs.xfs $ARRAY -f 2>&1 >> /dev/null
            mount $ARRAY $MOUNT

            TMP_W=`dd if=/dev/zero of=$TESTFILE bs=1M count=$TESTFILESIZE 2>&1 | grep bytes | awk '{ print $8 }' | cut -d "." -f 1`
            WRITE=$(($WRITE+$TMP_W))
            TMP_R=`dd if=$TESTFILE of=/dev/null bs=1M count=$TESTFILESIZE 2>&1 | grep bytes | awk '{ print $8 }' | cut -d "." -f 1`
            READ=$(($READ+$TMP_R))
            printf "%8.0f %7.0f %7.0f %6.0f\n" $x $y $WRITE $READ >> $LOGDEBUG
            ((i++))
        done 
        WRITE=$(($WRITE/$TRIES))
        READ=$(($READ/$TRIES))
        printf "%8.0f %7.0f %7.0f %6.0f\n" $x $y $WRITE $READ >> $LOG
    done
done


Ik weet eigenlijk nog niks van read-ahead. Ik heb het bovenstaande script gebruikt :)

Het is nu met 32k chunk aangemaakt:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

root@iServer:~# cat /proc/mdstat 
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md5 : active raid5 sdf[3] sde[2] sdd[1] sdc[0]
      5860540224 blocks super 1.2 level 5, 32k chunk, algorithm 2 [4/4] [UUUU]
      
unused devices: <none>
root@iServer:~# dd if=/pool/test.bin of=/dev/null bs=1M count=20000
20000+0 records in
20000+0 records out
20971520000 bytes (21 GB) copied, 171.428 s, 122 MB/s
root@iServer:~# sync
root@iServer:~# echo 3 > /proc/sys/vm/drop_caches 
root@iServer:~# dd if=/pool/test.bin of=/dev/null bs=1M count=20000
20000+0 records in
20000+0 records out
20971520000 bytes (21 GB) copied, 167.464 s, 125 MB/s
root@iServer:~#

[ Voor 19% gewijzigd door iMars op 29-06-2011 22:01 ]

Koop hier mijn P1 reader :)

donderdag 30 juni 2011 09:56

Acties:
  • iMars
  • Registratie: Augustus 2001
  • Laatst online: 14:55

iMars

Full time prutser

Topicstarter
Ik heb het volgende script gevonden (bron) (deze is nog niet aangepast op mijn systeem):
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154

#!/bin/bash
###############################################################################
#  simple script to set some parameters to increase performance on a mdadm
# raid5 or raid6. Ajust the ## parameters ##-section to your system!
#
#  WARNING: depending on stripesize and the number of devices the array might
# use QUITE a lot of memory after optimization!
#
#  27may2010 by Alexander Peganz
###############################################################################


## parameters ##
MDDEV=md51              # e.g. md51 for /dev/md51
CHUNKSIZE=1024          # in kb
BLOCKSIZE=4             # of file system in kb
NCQ=disable             # disable, enable. ath. else keeps current setting
NCQDEPTH=31             # 31 should work for almost anyone
FORCECHUNKSIZE=true     # force max sectors kb to chunk size > 512
DOTUNEFS=false          # run tune2fs, ONLY SET TO true IF YOU USE EXT[34]
RAIDLEVEL=raid5         # raid5, raid6


## code ##
# test for priviledges
if [ "$(whoami)" != 'root' ]
then
  echo $(date): Need to be root >> /data51/smbshare1/#tuneraid.log
  exit 1
fi

# set number of parity devices
NUMPARITY=1
if [[ $RAIDLEVEL == "raid6" ]]
then
  NUMPARITY=2
fi

# get all devices
DEVSTR="`grep \"^$MDDEV : \" /proc/mdstat` eol"
while \
 [ -z "`expr match \"$DEVSTR\" '\(\<sd[a-z]1\[[12]\?[0-9]\]\((S)\)\? \)'`" ]
do
  DEVSTR="`echo $DEVSTR|cut -f 2- -d \ `"
done

# get active devices list and spares list
DEVS=""
SPAREDEVS=""
while [ "$DEVSTR" != "eol" ]; do
  CURDEV="`echo $DEVSTR|cut -f -1 -d \ `"
  if [ -n "`expr match \"$CURDEV\" '\(\<sd[a-z]1\[[12]\?[0-9]\]\((S)\)\)'`" ]
  then
    SPAREDEVS="$SPAREDEVS${CURDEV:2:1}"
  elif [ -n "`expr match \"$CURDEV\" '\(\<sd[a-z]1\[[12]\?[0-9]\]\)'`" ]
  then
    DEVS="$DEVS${CURDEV:2:1}"
  fi
  DEVSTR="`echo $DEVSTR|cut -f 2- -d \ `"
done
NUMDEVS=${#DEVS}
NUMSPAREDEVS=${#SPAREDEVS}

# test if number of devices makes sense
if [ ${#DEVS} -lt $[1+$NUMPARITY] ]
then
  echo $(date): Need more devices >> /data51/smbshare1/#tuneraid.log
  exit 1
fi

# set read ahead
RASIZE=$[$NUMDEVS*($NUMDEVS-$NUMPARITY)*2*$CHUNKSIZE]   # in 512b blocks
echo read ahead size per device: $RASIZE blocks \($[$RASIZE/2]kb\)
MDRASIZE=$[$RASIZE*$NUMDEVS]
echo read ahead size of array: $MDRASIZE blocks \($[$MDRASIZE/2]kb\)
blockdev --setra $RASIZE /dev/sd[$DEVS]
#blockdev --setra $RASIZE /dev/sd[$SPAREDEVS] ## uitgezet: heb geen sparedevs
blockdev --setra $MDRASIZE /dev/$MDDEV

# set stripe cache size
STRCACHESIZE=$[$RASIZE/8]                               # in pages per device
echo stripe cache size of devices: $STRCACHESIZE pages \($[$STRCACHESIZE*4]kb\)
echo $STRCACHESIZE > /sys/block/$MDDEV/md/stripe_cache_size

# set max sectors kb
DEVINDEX=0
MINMAXHWSECKB=$(cat /sys/block/sd${DEVS:0:1}/queue/max_hw_sectors_kb)
until [ $DEVINDEX -ge $NUMDEVS ]
do
  DEVLETTER=${DEVS:$DEVINDEX:1}
  MAXHWSECKB=$(cat /sys/block/sd$DEVLETTER/queue/max_hw_sectors_kb)
  if [ $MAXHWSECKB -lt $MINMAXHWSECKB ]
  then
    MINMAXHWSECKB=$MAXHWSECKB
  fi
  DEVINDEX=$[$DEVINDEX+1]
done
if [ $CHUNKSIZE -le $MINMAXHWSECKB ] &&
  ( [ $CHUNKSIZE -le 512 ] || [[ $FORCECHUNKSIZE == "true" ]] )
then
  echo setting max sectors kb to match chunk size
  DEVINDEX=0
  until [ $DEVINDEX -ge $NUMDEVS ]
  do
    DEVLETTER=${DEVS:$DEVINDEX:1}
    echo $CHUNKSIZE > /sys/block/sd$DEVLETTER/queue/max_sectors_kb
    DEVINDEX=$[$DEVINDEX+1]
  done
  DEVINDEX=0
  until [ $DEVINDEX -ge $NUMSPAREDEVS ]
  do
    DEVLETTER=${SPAREDEVS:$DEVINDEX:1}
    echo $CHUNKSIZE > /sys/block/sd$DEVLETTER/queue/max_sectors_kb
    DEVINDEX=$[$DEVINDEX+1]
  done
fi

# enable/disable NCQ
DEVINDEX=0
if [[ $NCQ == "enable" ]] || [[ $NCQ == "disable" ]]
then
  if [[ $NCQ == "disable" ]]
  then
    NCQDEPTH=1
  fi
  echo setting NCQ queue depth to $NCQDEPTH
  until [ $DEVINDEX -ge $NUMDEVS ]
  do
    DEVLETTER=${DEVS:$DEVINDEX:1}
    echo $NCQDEPTH > /sys/block/sd$DEVLETTER/device/queue_depth
    DEVINDEX=$[$DEVINDEX+1]
  done
  DEVINDEX=0
  until [ $DEVINDEX -ge $NUMSPAREDEVS ]
  do
    DEVLETTER=${SPAREDEVS:$DEVINDEX:1}
    echo $NCQDEPTH > /sys/block/sd$DEVLETTER/device/queue_depth
    DEVINDEX=$[$DEVINDEX+1]
  done
fi

# tune2fs
if [[ $DOTUNEFS == "true" ]]
then
  STRIDE=$[$CHUNKSIZE/$BLOCKSIZE]
  STRWIDTH=$[$CHUNKSIZE/$BLOCKSIZE*($NUMDEVS-$NUMPARITY)]
  echo setting stride to $STRIDE blocks \($CHUNKSIZEkb\)
  echo setting stripe-width to $STRWIDTH blocks \($[$STRWIDTH*$BLOCKSIZE]kb\)
  tune2fs -E stride=$STRIDE,stripe-width=$STRWIDTH /dev/$MDDEV
fi

# exit
echo $(date): Success >> /data51/smbshare1/#tuneraid.log
exit 0

De parameters moeten nog aangepast worden:
code:
1
2
3
4
5
6
7
8
9

## parameters ##
MDDEV=md51 -> wordt md5             # e.g. md51 for /dev/md51
CHUNKSIZE=1024 -> chunksize array?  # in kb
BLOCKSIZE=4                         # of file system in kb
NCQ=disable                         # disable, enable. ath. else keeps current setting
NCQDEPTH=31                         # 31 should work for almost anyone
FORCECHUNKSIZE=true                 # force max sectors kb to chunk size > 512
DOTUNEFS=false -> false ivm xfs     # run tune2fs, ONLY SET TO true IF YOU USE EXT[34]
RAIDLEVEL=raid5                     # raid5, raid6


Aan het script te zien, haalt ie de devices uit '/proc/mdstat' dus op een bestaande array. Lijkt mij dat er niks mis kan gaan, daar er toch geen data op mijn array staat.

Kan ik dit gewoon runnen? En zo ja, welk chunksize kan ik het beste hanteren? Want zoals het in mijn TS staat, kom ik er niet uit, behalve dan mijn keuze (wat mij logisch lijkt) 128 moet zijn.

Edit:
Ik heb zojuist de array opnieuw gemaakt met een 128 chunksize, opnieuw geformateerd, een 'sync; echo 3 > /proc/sys/vm/drop_caches' gedaan en opnieuw een enkele write & read test van 21GB gedaan:
code:
1
2
3
4
5
6
7
8
9

root@iServer:~# dd if=/dev/zero of=/pool/test.bin bs=1M count=20000
20000+0 records in
20000+0 records out
20971520000 bytes (21 GB) copied, 116.731 s, 180MB/s
root@iServer:~# dd if=/pool/test.bin of=/dev/null bs=1M count=20000
20000+0 records in
20000+0 records out
20971520000 bytes (21 GB) copied, 101.305s, 207MB/s
root@iServer:~#


De write is van 189MB/s naar 180MB/s gegaan
De read is van 183MB/s naar 208MB/s gegaan

De snelheden zijn acceptabel, maar vind het toch leuk om te tweaken zodat er meer uitgehaald kan worden.
(Het gaat over Gblan, dus dat is de bottleneck ;))

Het zou toch mogelijk moeten zijn om zowel de read als write >220MB/s te pushen?

[ Voor 7% gewijzigd door iMars op 30-06-2011 12:37 ]

Koop hier mijn P1 reader :)

donderdag 30 juni 2011 21:24

Acties:
  • Q
  • Registratie: November 1999
  • Laatst online: 11:14

Q

Au Contraire Mon Capitan!

Ik haal met 6 disks van 500 GB per stuk in RAID 5 255 MB/s write dat is effectief 50 mb/s voor 5 disks.

Bij 3 disks verwacht ik een write van ongeveer 150 MB/s maar bij jou moet dat hoger liggen omdat je veel grotere en nieuwere schijven gebruikt. Rond de 180 - 200 write zou moeten lukken.

De read snelheid van 6 disks, effectief dus 5 = 353 MB/s = 70 MB/s lezen per disk. Jij zou dus met lezen minimaal op 3 x 70 = 210 moeten komen.

Eigenlijk zijn je waarden zo gek nog niet, als je bedenkt dat het effectief maar 3 disks zijn. Mijn aanname dat die waarden gek zijn is misschien niet terecht.

Zeker als het 5400 rpm disks zijn denk ik dat de waarden wel ok zijn eigenlijk.

donderdag 30 juni 2011 22:57

Acties:
  • iMars
  • Registratie: Augustus 2001
  • Laatst online: 14:55

iMars

Full time prutser

Topicstarter
Je hebt gelijk, maar toch wil ik even wat posten, want met read-ahead kan je best veel performance winnen.

Het script werkte niet, mijn devices worden niet herkend (en ik ben niet zo'n ster in scripten ;))
Dus heb ik het aangepast.

Het script blijft hangen op de while-do regel 41-44. Het enige wat dat gedeelte doet, is de devices uitlezen en filteren. Dat heb ik aangepast door tussen regel 60 en 61 het volgende toe te voegen:
code:
1
2
3
4

done
DEVS="cdef" ## <-- toegevoegd
NUMDEVS=${#DEVS}
NUMSPAREDEVS=${#SPAREDEVS}


Ik run het script, doe een sync en leeg de cache:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

root@iServer:~# ./benchmark.sh 
read ahead size per device: 3072 blocks (1536kb)
read ahead size of array: 12288 blocks (6144kb)
stripe cache size of devices: 384 pages (1536kb)
setting max sectors kb to match chunk size
setting NCQ queue depth to 1
Thu Jun 30 22:43:06 CEST 2011: Success
root@iServer:~# sync
root@iServer:~# echo 3 > /proc/sys/vm/drop_caches 
root@iServer:~# dd if=/dev/zero of=/pool/test.bin bs=1M count=2000
2000+0 records in
2000+0 records out
2097152000 bytes (2.1 GB) copied, 7.64675 s, 274 MB/s
root@iServer:~# dd if=/pool/test.bin of=/dev/null bs=1M count=2000
2000+0 records in
2000+0 records out
2097152000 bytes (2.1 GB) copied, 2.08171 s, 1.0 GB/s
root@iServer:~# dd if=/dev/zero of=/pool/test.bin bs=1M count=20000
20000+0 records in
20000+0 records out
20971520000 bytes (21 GB) copied, 95.7748 s, 219 MB/s
root@iServer:~# dd if=/pool/test.bin of=/dev/null bs=1M count=20000
20000+0 records in
20000+0 records out
20971520000 bytes (21 GB) copied, 55.4384 s, 378 MB/s
root@iServer:~#


Dat zijn betere snelheden :)

Hoe kan het dat kleinere bestanden (count=2000) gelezen wordt met 1GB/s :S

Het laatste read van 21GB... 378 MB/s :9~ >:)

Koop hier mijn P1 reader :)

donderdag 30 juni 2011 23:20

Acties:
  • iMars
  • Registratie: Augustus 2001
  • Laatst online: 14:55

iMars

Full time prutser

Topicstarter
Heb het script verder getuned en gedebugged :)

Het werkte niet omdat het script rekening hield met partities. Echter heb ik geen partities ;)

Dus het script is nu:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154

#!/bin/bash
###############################################################################
#  simple script to set some parameters to increase performance on a mdadm
# raid5 or raid6. Ajust the ## parameters ##-section to your system!
#
#  WARNING: depending on stripesize and the number of devices the array might
# use QUITE a lot of memory after optimization!
#
#  27may2010 by Alexander Peganz
###############################################################################


## parameters ##
MDDEV=md5               # e.g. md51 for /dev/md51
CHUNKSIZE=128           # in kb
BLOCKSIZE=4             # of file system in kb
NCQ=disable             # disable, enable. ath. else keeps current setting
NCQDEPTH=31             # 31 should work for almost anyone
FORCECHUNKSIZE=true     # force max sectors kb to chunk size > 512
DOTUNEFS=false          # run tune2fs, ONLY SET TO true IF YOU USE EXT[34]
RAIDLEVEL=raid5         # raid5, raid6


## code ##
# test for priviledges
if [ "$(whoami)" != 'root' ]
then
  echo $(date): Need to be root >> tuneraid.log ### path weggehaald
  exit 1
fi

# set number of parity devices
NUMPARITY=1
if [[ $RAIDLEVEL == "raid6" ]]
then
  NUMPARITY=2
fi

# get all devices
DEVSTR="`grep \"^$MDDEV : \" /proc/mdstat` eol"
while \
 [ -z "`expr match \"$DEVSTR\" '\(\<sd[a-z]\[[12]\?[0-9]\]\((S)\)\? \)'`" ] ### was (\<sd[a-z]1\[[12]\?[0-9]\]\((S)\)\? \)
do
  DEVSTR="`echo $DEVSTR|cut -f 2- -d \ `"
done

# get active devices list and spares list
DEVS=""
SPAREDEVS=""
while [ "$DEVSTR" != "eol" ]; do
  CURDEV="`echo $DEVSTR|cut -f -1 -d \ `"
  if [ -n "`expr match \"$CURDEV\" '\(\<sd[a-z]\[[12]\?[0-9]\]\((S)\)\)'`" ] ### was (\<sd[a-z]1\[[12]\?[0-9]\]\((S)\)\)
  then
    SPAREDEVS="$SPAREDEVS${CURDEV:2:1}"
  elif [ -n "`expr match \"$CURDEV\" '\(\<sd[a-z]\[[12]\?[0-9]\]\)'`" ] ### was (\<sd[a-z]1\[[12]\?[0-9]\]\)
  then
    DEVS="$DEVS${CURDEV:2:1}"
  fi
  DEVSTR="`echo $DEVSTR|cut -f 2- -d \ `"
done
NUMDEVS=${#DEVS}
NUMSPAREDEVS=${#SPAREDEVS}

# test if number of devices makes sense
if [ ${#DEVS} -lt $[1+$NUMPARITY] ]
then
  echo $(date): Need more devices >> tuneraid.log ### path weggehaald
  exit 1
fi

# set read ahead
RASIZE=$[$NUMDEVS*($NUMDEVS-$NUMPARITY)*2*$CHUNKSIZE]   # in 512b blocks
echo read ahead size per device: $RASIZE blocks \($[$RASIZE/2]kb\)
MDRASIZE=$[$RASIZE*$NUMDEVS]
echo read ahead size of array: $MDRASIZE blocks \($[$MDRASIZE/2]kb\)
blockdev --setra $RASIZE /dev/sd[$DEVS]
#blockdev --setra $RASIZE /dev/sd[$SPAREDEVS] ## uitgezet: heb geen sparedevs
blockdev --setra $MDRASIZE /dev/$MDDEV

# set stripe cache size
STRCACHESIZE=$[$RASIZE/8]                               # in pages per device
echo stripe cache size of devices: $STRCACHESIZE pages \($[$STRCACHESIZE*4]kb\)
echo $STRCACHESIZE > /sys/block/$MDDEV/md/stripe_cache_size

# set max sectors kb
DEVINDEX=0
MINMAXHWSECKB=$(cat /sys/block/sd${DEVS:0:1}/queue/max_hw_sectors_kb)
until [ $DEVINDEX -ge $NUMDEVS ]
do
  DEVLETTER=${DEVS:$DEVINDEX:1}
  MAXHWSECKB=$(cat /sys/block/sd$DEVLETTER/queue/max_hw_sectors_kb)
  if [ $MAXHWSECKB -lt $MINMAXHWSECKB ]
  then
    MINMAXHWSECKB=$MAXHWSECKB
  fi
  DEVINDEX=$[$DEVINDEX+1]
done
if [ $CHUNKSIZE -le $MINMAXHWSECKB ] &&
  ( [ $CHUNKSIZE -le 512 ] || [[ $FORCECHUNKSIZE == "true" ]] )
then
  echo setting max sectors kb to match chunk size
  DEVINDEX=0
  until [ $DEVINDEX -ge $NUMDEVS ]
  do
    DEVLETTER=${DEVS:$DEVINDEX:1}
    echo $CHUNKSIZE > /sys/block/sd$DEVLETTER/queue/max_sectors_kb
    DEVINDEX=$[$DEVINDEX+1]
  done
  DEVINDEX=0
  until [ $DEVINDEX -ge $NUMSPAREDEVS ]
  do
    DEVLETTER=${SPAREDEVS:$DEVINDEX:1}
    echo $CHUNKSIZE > /sys/block/sd$DEVLETTER/queue/max_sectors_kb
    DEVINDEX=$[$DEVINDEX+1]
  done
fi

# enable/disable NCQ
DEVINDEX=0
if [[ $NCQ == "enable" ]] || [[ $NCQ == "disable" ]]
then
  if [[ $NCQ == "disable" ]]
  then
    NCQDEPTH=1
  fi
  echo setting NCQ queue depth to $NCQDEPTH
  until [ $DEVINDEX -ge $NUMDEVS ]
  do
    DEVLETTER=${DEVS:$DEVINDEX:1}
    echo $NCQDEPTH > /sys/block/sd$DEVLETTER/device/queue_depth
    DEVINDEX=$[$DEVINDEX+1]
  done
  DEVINDEX=0
  until [ $DEVINDEX -ge $NUMSPAREDEVS ]
  do
    DEVLETTER=${SPAREDEVS:$DEVINDEX:1}
    echo $NCQDEPTH > /sys/block/sd$DEVLETTER/device/queue_depth
    DEVINDEX=$[$DEVINDEX+1]
  done
fi

# tune2fs
if [[ $DOTUNEFS == "true" ]]
then
  STRIDE=$[$CHUNKSIZE/$BLOCKSIZE]
  STRWIDTH=$[$CHUNKSIZE/$BLOCKSIZE*($NUMDEVS-$NUMPARITY)]
  echo setting stride to $STRIDE blocks \($CHUNKSIZEkb\)
  echo setting stripe-width to $STRWIDTH blocks \($[$STRWIDTH*$BLOCKSIZE]kb\)
  tune2fs -E stride=$STRIDE,stripe-width=$STRWIDTH /dev/$MDDEV
fi

# exit
echo $(date): Success >> tuneraid.log ### path weggehaald
exit 0


edit:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

root@iServer:~# ./tuneraid.sh;sync;echo 3 > /proc/sys/vm/drop_caches
read ahead size per device: 3072 blocks (1536kb)
read ahead size of array: 12288 blocks (6144kb)
stripe cache size of devices: 384 pages (1536kb)
setting max sectors kb to match chunk size
setting NCQ queue depth to 1
root@iServer:~# dd if=/dev/zero of=/pool/test.bin bs=1M count=32000
32000+0 records in
32000+0 records out
33554432000 bytes (34 GB) copied, 155.475 s, 216 MB/s
root@iServer:~# dd if=/pool/test.bin of=/dev/null bs=1M count=32000
32000+0 records in
32000+0 records out
33554432000 bytes (34 GB) copied, 90.7514 s, 370 MB/s
root@iServer:~#


216MB/s write == 72MB/s per schijf
370MB/s read == 123,33MB/s per schijf

Niet onaardig denk ik :)

[ Voor 7% gewijzigd door iMars op 30-06-2011 23:42 ]

Koop hier mijn P1 reader :)

vrijdag 1 juli 2011 01:03

Acties:
  • Q
  • Registratie: November 1999
  • Laatst online: 11:14

Q

Au Contraire Mon Capitan!

Dat lijkt mij uitstekend, ik heb zelf ook nog eens met blockdev lopen spelen.

lineare read zoals we nu testen komt nu op 370 MB/s voor 6-1 = 5 disks is 74 read per disk. Disks van 3 tot 4 jaar oud van 0.5 TB. Prima dus.

Write komt opeens met wat gekloot op 51 Mb/s per disk wat ongeveer 256 MB/s write geeft.

blockdev is interessant, wat ncq nog uitmaakt weet ik niet.

vrijdag 1 juli 2011 09:10

Acties:
  • iMars
  • Registratie: Augustus 2001
  • Laatst online: 14:55

iMars

Full time prutser

Topicstarter
Q schreef op vrijdag 01 juli 2011 @ 01:03:
Dat lijkt mij uitstekend, ik heb zelf ook nog eens met blockdev lopen spelen.

lineare read zoals we nu testen komt nu op 370 MB/s voor 6-1 = 5 disks is 74 read per disk. Disks van 3 tot 4 jaar oud van 0.5 TB. Prima dus.

Write komt opeens met wat gekloot op 51 Mb/s per disk wat ongeveer 256 MB/s write geeft.

blockdev is interessant, wat ncq nog uitmaakt weet ik niet.
Ik wist niet eens wat het betekende ;)

Wikipedia: Native Command Queuing

Koop hier mijn P1 reader :)

donderdag 14 juli 2011 11:56

Acties:

Verwijderd

Wat heb je nodig om dit script te draaien? Kan ik gewoon met lvm een partitie maken en dan het script hierop loslaten of ga je uit van een filesystem op /dev/mdX?

donderdag 14 juli 2011 12:39

Acties:
  • iMars
  • Registratie: Augustus 2001
  • Laatst online: 14:55

iMars

Full time prutser

Topicstarter
Verwijderd schreef op donderdag 14 juli 2011 @ 11:56:
Wat heb je nodig om dit script te draaien? Kan ik gewoon met lvm een partitie maken en dan het script hierop loslaten of ga je uit van een filesystem op /dev/mdX?
Je moet de parameters instellen. Dus wat voor raid je hebt (RAID5 in mijn geval) en welk blockdevice de raid array is (in mijn geval /dev/md5). De devices worden door het script vanzelf gedetecteerd (regel 39 t/m 62).

Koop hier mijn P1 reader :)

donderdag 14 juli 2011 12:47

Acties:

Verwijderd

Thanks, hoelang duurt het voordat de eerste output in de logfile zou moeten verschijnen? Ik heb het script opgestart, maar er lijkt niet veel te gebeuren. Het script verbruikt een paar procent cpu in top en dat is het :)

Ik heb op md0 verder geen filesystem staan, maar de boel geinitialiseerd met lvm en daar een paar partities op aangemaakt.

[ Voor 22% gewijzigd door Verwijderd op 14-07-2011 12:51 ]

donderdag 14 juli 2011 13:00

Acties:
  • Sleepkever
  • Registratie: Juni 2007
  • Laatst online: 10:59

Sleepkever

Script zelf draait binnen een paar seconden. Er zit echter een bugje in het originele script met betrekking tot het detecteren van devices wat een loopje veroorzaakt. De laatste versie van iMars werkt wel gewoon prima.
Ik heb op md0 verder geen filesystem staan, maar de boel geinitialiseerd met lvm en daar een paar partities op aangemaakt.
Heb ik zelf ook, script geeft dan een fout aan het einde als je de filesystem optimalisaties aanzet. Je zou zelf even de tune2fs kunnen verwijzen naar t juiste block device (gok dm-?) om die alsnog te krijgen. Maar het levert voor de rest geen problemen op

Hier ook maar eens gedraaid, krijg alleen rare resultaten. Met een 10gb copy krijg ik ~200mb/s write en ~100mb/s read op een raid5 array met 4x 2tb samsung ecogreens. Stripe size is wel de default ubuntu 512kb. Misschien dat dat te groot is maar dan zou je verwachten dat de read toch goed zou blijven. Het is in ieder geval een verbetering op wat het eerst was. Ben nu even tests aan het draaien met een iets grotere copy om te kijken of die waardes wat logischer zijn.

EDIT2:
Okay, ook met een grotere copy bleven de waardes raar. Wat blijkt, het script zet netjes overal readahead values voor. Maar niet als je nog een LVM laag eroverheen hebt liggen. Als je daar niet de readahead values apart voor zet dan levert dit alsnog problemen op en blijft de performance bagger.

Oplossing is om het scriptje even iets aan te passen en de $MDRASIZE ook toe te passen op je LVM blockdevice. En ook de tune2fs naar je LVM block device te wijzen in plaats van de mdadm device.

Writes bereiken trouwens maar 70% belasting van de schijven volgens atop, is waarschijnlijk CPU limited op mijn i3.
code:
1
2
3
4
5
6
7
8

~$ dd if=/dev/zero of=/media/Storage/test/test.bin bs=1M count=50000
50000+0 records in
50000+0 records out
52428800000 bytes (52 GB) copied, 298.883 s, 175 MB/s
~$ dd of=/dev/null if=/media/Storage/test/test.bin bs=1M count=50000
50000+0 records in
50000+0 records out
52428800000 bytes (52 GB) copied, 262.766 s, 200 MB/s

Niet slecht voor raid5 met LVM als je rekent dat de hardware een i3 is met 4 samsung ecogreen schijfjes.

[ Voor 72% gewijzigd door Sleepkever op 14-07-2011 13:43 . Reden: LVM commentaar toegevoegd en resultaten ]

donderdag 14 juli 2011 15:05

Acties:
  • iMars
  • Registratie: Augustus 2001
  • Laatst online: 14:55

iMars

Full time prutser

Topicstarter
Vind het eerlijk gezegd laag, ervan uitgaande dat ik ook 4x Samsung EcoGreen heb, en geen i3, maar een Atom. Ik haalde er meer uit:
code:
1
2
3
4
5
6
7
8
9

root@iServer:~# dd if=/dev/zero of=/pool/test.bin bs=1M count=32000
32000+0 records in
32000+0 records out
33554432000 bytes (34 GB) copied, 155.475 s, 216 MB/s
root@iServer:~# dd if=/pool/test.bin of=/dev/null bs=1M count=32000
32000+0 records in
32000+0 records out
33554432000 bytes (34 GB) copied, 90.7514 s, 370 MB/s
root@iServer:~#

Koop hier mijn P1 reader :)

donderdag 14 juli 2011 15:32

Acties:
  • Sleepkever
  • Registratie: Juni 2007
  • Laatst online: 10:59

Sleepkever

Dan is het wel een wezenlijk verschil inderdaad. De write snelheden vallen opzich nog wel mee. Echter de bijna gehalveerde leessnelheid is wel apart. Ik zal wel wat verkeerd hebben gedaan met sector alignments, stripe sizes of iets dergelijks op mijn schijven dan. Echter heb ik de mijne al vol data staan op het moment dus even uitproberen zit er helaas niet bij. Gok dat dat niet lekker samen speelt met de LVM blocks die nog onder het bestandssysteem liggen.

Alles lijkt voor zo ver ik kan zien gewoon alligned, Raid array data begint op 2048 sectors en de LVM data begint op byte 0. LVM blocks zijn ook deelbaar door 4k, namelijk 4mb. Dus in theorie zou het alligned moeten zijn... Nja, het is ook geen ramp voor mij dat de performance wat minder is dus ik ga hier denk ik verder geen tijd in steken (tenzij iemand nog een geniaal idee heeft), maar vreemd is het wel.

[ Voor 30% gewijzigd door Sleepkever op 14-07-2011 16:03 ]

donderdag 14 juli 2011 16:39

Acties:
  • iMars
  • Registratie: Augustus 2001
  • Laatst online: 14:55

iMars

Full time prutser

Topicstarter
ik heb geen partities genomen, gewoon gehele harddisk er aan toegevoegd:
code:
1

mdadm --create /dev/md5 --assume-clean --level=5 --chunk=128 --raid-devices=4 /dev/sd[c-f]

Koop hier mijn P1 reader :)

donderdag 14 juli 2011 16:58

Acties:

Verwijderd

Ik ga er vanavond nog eens naar kijken, maar voor alsnog wil het script hier totaal niet draaien. Vanavond eens verder pielen :)

donderdag 14 juli 2011 17:48

Acties:
  • iMars
  • Registratie: Augustus 2001
  • Laatst online: 14:55

iMars

Full time prutser

Topicstarter
Verwijderd schreef op donderdag 14 juli 2011 @ 16:58:
Ik ga er vanavond nog eens naar kijken, maar voor alsnog wil het script hier totaal niet draaien. Vanavond eens verder pielen :)
Als je /dev/sda1 en sdb1 etc gebruikt, dan werkt het niet, dan moet je het eerst geposte script nemen. Omdat ik geen partities gebruik, (dus alleen /dev/sda, sdb, sec etc) heb ik dat uit het script gehaald ;)

Mijn advies is ook om geen partities te gebruiken, maar zoals ik het in mijn vorige bericht meldde ;)

Koop hier mijn P1 reader :)

vrijdag 15 juli 2011 11:08

Acties:
  • Sleepkever
  • Registratie: Juni 2007
  • Laatst online: 10:59

Sleepkever

Nee tuurlijk, mdadm op partities is al helemaal dodelijk voor de performance. Echter heb ik ook gewoon de hele schijven in de mdadm array zitten. Alleen ligt boven op die gecreerde ruimte met mdadm nog een LVM met ext4. Gok dat jij ook ext4 gebruikt dus dan zal het performance verschil hem wel in LVM zitten. Kan het alleen helaas niet testen ivm de data die er al op staat...

Het enige verschil is dat je het script zoals het hierboven gepost is niet geschikt is om uit te voeren op een RAID + LVM + FS combinatie omdat het script geen rekening houd met LVM. Daar zul je dus even zelf de read ahead op moeten toepassen en de filesystem optimalisaties even doorverwijzen naar het juiste LVM block device aangezien het filesystem (LVM) op de raid array niet herkend wordt.

vrijdag 15 juli 2011 11:38

Acties:
  • OMX2000
  • Registratie: Januari 2001
  • Laatst online: 11:38

OMX2000

By any means necessary...

Sleepkever schreef op vrijdag 15 juli 2011 @ 11:08:
Nee tuurlijk, mdadm op partities is al helemaal dodelijk voor de performance. Echter heb ik ook gewoon de hele schijven in de mdadm array zitten. Alleen ligt boven op die gecreerde ruimte met mdadm nog een LVM met ext4. Gok dat jij ook ext4 gebruikt dus dan zal het performance verschil hem wel in LVM zitten. Kan het alleen helaas niet testen ivm de data die er al op staat...

Het enige verschil is dat je het script zoals het hierboven gepost is niet geschikt is om uit te voeren op een RAID + LVM + FS combinatie omdat het script geen rekening houd met LVM. Daar zul je dus even zelf de read ahead op moeten toepassen en de filesystem optimalisaties even doorverwijzen naar het juiste LVM block device aangezien het filesystem (LVM) op de raid array niet herkend wordt.
Onderbouw dat eens. Ik heb nu een Raid 5 array met mdadm die draait op 4 schijven. Iedere schijf heeft 1 partitie over de hele disk. Kan me niet voorstellen dat dat een stuk trager is dan direct de schijf benaderen zonder partitie.

Dè developers podcast in je moerstaal : CodeKlets Podcast

vrijdag 15 juli 2011 11:42

Acties:

Verwijderd

Ik heb op de schijven een partitie van type fd, Linux RAID autodetect gezet. Daarop draait dan mdadm met de RAID5 functionaliteit en daar bovenop draait dan weer LVM met zijn partities. Dit lijkt mij de correcte manier?

vrijdag 15 juli 2011 11:44

Acties:
  • Sleepkever
  • Registratie: Juni 2007
  • Laatst online: 10:59

Sleepkever

1 partitie per schijf zal inderdaad niet veel uitmaken, meerdere partities op 1 schijf en daar een mdadm van bouwen is leuk voor testen maar performance wise natuurlijk dodelijk. Denk echter dat het verschil tussen een raid op 1 partitie per disk of raid op de hele disk inderdaad niets uitmaakt voor de performance. Ik heb hier echter niet eens raid autodetect labels op mijn aparte schijven hangen zag ik net, al zal het superblock genoeg zijn voor de kernels van tegenwoordig gok ik.

vrijdag 15 juli 2011 20:39

Acties:
  • iMars
  • Registratie: Augustus 2001
  • Laatst online: 14:55

iMars

Full time prutser

Topicstarter
OMX2000 schreef op vrijdag 15 juli 2011 @ 11:38:
[...]


Onderbouw dat eens. Ik heb nu een Raid 5 array met mdadm die draait op 4 schijven. Iedere schijf heeft 1 partitie over de hele disk. Kan me niet voorstellen dat dat een stuk trager is dan direct de schijf benaderen zonder partitie.
Wat er mis kan gaan is als de partities niet goed gealigned zijn dat je array corrupt kan raken. Ik heb geen partities aangemaakt. Was beter op advies (heb niet heel veel erevaring nog). En waarom een partitie maken, als je toch de gehele schijf gebruikt ;)

Koop hier mijn P1 reader :)

zaterdag 6 augustus 2011 17:23

Acties:
  • IntToStr
  • Registratie: December 2003
  • Laatst online: 16:33

IntToStr

Ik heb mijn raid array aangemaakt met hetzelfde commando als iMars hierboven heeft gebruikt aangezien ik bijna dezelfde setup heb, namelijk 4x Samsung 2Tb schijven op ubuntu server 11.04. Processor is een E8400.
code:
1

 sudo mdadm --create /dev/md0 --assume-clean --level=5 --chunk=128 --raid-devices=4 /dev/sd[a-d]


Dit krijg ik als resultaat:
x@nas:/storage$ sudo dd if=/dev/zero of=/storage/test.bin bs=1M count=32000
32000+0 records in
32000+0 records out
33554432000 bytes (34 GB) copied, 173,2 s, 194 MB/s
x@nas:/storage$ sudo dd if=/storage/test.bin of=/dev/null bs=1M count=32000
32000+0 records in
32000+0 records out
33554432000 bytes (34 GB) copied, 354,515 s, 94,6 MB/s
Hoe kan ik zien waarom ik zo'n lage leessnelheid heb? Ik zal zo eerst nog eens opnieuw opstarten en later nog eens proberen, maar dit ziet er niet al te best uit.

zaterdag 6 augustus 2011 19:11

Acties:
  • iMars
  • Registratie: Augustus 2001
  • Laatst online: 14:55

iMars

Full time prutser

Topicstarter
IntToStr schreef op zaterdag 06 augustus 2011 @ 17:23:
Ik heb mijn raid array aangemaakt met hetzelfde commando als iMars hierboven heeft gebruikt aangezien ik bijna dezelfde setup heb, namelijk 4x Samsung 2Tb schijven op ubuntu server 11.04. Processor is een E8400.
code:
1

 sudo mdadm --create /dev/md0 --assume-clean --level=5 --chunk=128 --raid-devices=4 /dev/sd[a-d]


Dit krijg ik als resultaat:

[...]

Hoe kan ik zien waarom ik zo'n lage leessnelheid heb? Ik zal zo eerst nog eens opnieuw opstarten en later nog eens proberen, maar dit ziet er niet al te best uit.
Heb je ook het script gedraaid die verschillende chunksize probeert?
Bij mij kwam er uit dat ik chunksize 128K moest nemen, bij andere zie ik weer dat ze 64K nemen... probeer het uit ;)

Koop hier mijn P1 reader :)

zaterdag 6 augustus 2011 19:39

Acties:
  • FireDrunk
  • Registratie: November 2002
  • Laatst online: 17-11 19:31

FireDrunk

Run eens in een 2e terminal terwijl je DD runt:
iostat -x 1


En kijk eens of elke disk op dezelfde manier word aangesproken en op dezelfde manier data levert.

PS: iostat installeren met apt-get install sysstat

[ Voor 19% gewijzigd door FireDrunk op 06-08-2011 19:57 ]

Even niets...

zaterdag 6 augustus 2011 20:01

Acties:
  • Q
  • Registratie: November 1999
  • Laatst online: 11:14

Q

Au Contraire Mon Capitan!

Als je het geen punt vindt om je computer een dagje te laten stampen dan weet je snel wat de beste configuratie voor je is:

Ik spam hier even het scriptie waarmee je kunt testen. Edit het script wel even naar je eigen situatie.

http://louwrentius.com/bl...raid-benchmarking-script/

zaterdag 6 augustus 2011 20:44

Acties:
  • OMX2000
  • Registratie: Januari 2001
  • Laatst online: 11:38

OMX2000

By any means necessary...

Q schreef op zaterdag 06 augustus 2011 @ 20:01:
Als je het geen punt vindt om je computer een dagje te laten stampen dan weet je snel wat de beste configuratie voor je is:

Ik spam hier even het scriptie waarmee je kunt testen. Edit het script wel even naar je eigen situatie.

http://louwrentius.com/bl...raid-benchmarking-script/
Kan dat zonder dataverlies?

Dè developers podcast in je moerstaal : CodeKlets Podcast

zaterdag 6 augustus 2011 21:12

Acties:
  • FireDrunk
  • Registratie: November 2002
  • Laatst online: 17-11 19:31

FireDrunk

Uhm, hij heeft het een pagina terug al over dat script...

Even niets...

zondag 7 augustus 2011 00:34

Acties:
  • iMars
  • Registratie: Augustus 2001
  • Laatst online: 14:55

iMars

Full time prutser

Topicstarter
OMX2000 schreef op zaterdag 06 augustus 2011 @ 20:44:
[...]

Kan dat zonder dataverlies?
Volgens mij niet (niet het script wat iedere keer de raid array opnieuw aanmaakt). En altijd backupen ;)

Edit: de volgende regel zegt mij met zekerheid dat je AL je DATA verliest:
code:
1

mkfs.xfs $ARRAY -f 2>&1 >> /dev/null

Je formatteert de array namelijk ;)
FireDrunk schreef op zaterdag 06 augustus 2011 @ 21:12:
Uhm, hij heeft het een pagina terug al over dat script...
:Y

[ Voor 15% gewijzigd door iMars op 07-08-2011 00:36 ]

Koop hier mijn P1 reader :)

zondag 7 augustus 2011 11:40

Acties:
  • Q
  • Registratie: November 1999
  • Laatst online: 11:14

Q

Au Contraire Mon Capitan!

Spamkoning Q (Sorry)

[ Voor 25% gewijzigd door Q op 07-08-2011 12:56 ]

zondag 7 augustus 2011 14:54

Acties:
  • IntToStr
  • Registratie: December 2003
  • Laatst online: 16:33

IntToStr

Hmm, nu krijg ik dit terug met het script uit de topic start (met kleine aanpassingen):
code:
1
2
3
4
5
6
7
8

| CHUNKS | LEVEL | WRITE | READ |
       4       5     291    125
       8       5     251      1
      16       5     240      0
      32       5     232      2
      64       5     221      2
     128       5     194     35
     256       5     150    114

Ik heb ext4 als filesystem ingesteld. In de topic start staat xfs als filesystem. Maakt dit zoveel uit?

Die waarde bij 16, 32, 64 en 128 lijken me toch niet de bedoeling...

zondag 7 augustus 2011 18:24

Acties:
  • Q
  • Registratie: November 1999
  • Laatst online: 11:14

Q

Au Contraire Mon Capitan!

Test eens met xfs en zie of je daar het zelfde probleem mee ziet.

zondag 7 augustus 2011 19:21

Acties:
  • iMars
  • Registratie: Augustus 2001
  • Laatst online: 14:55

iMars

Full time prutser

Topicstarter
Q schreef op zondag 07 augustus 2011 @ 18:24:
Test eens met xfs en zie of je daar het zelfde probleem mee ziet.
Het originele script doet een xfs format, probeer dat eens ;)

Koop hier mijn P1 reader :)

zondag 7 augustus 2011 21:04

Acties:
  • IntToStr
  • Registratie: December 2003
  • Laatst online: 16:33

IntToStr

Hij draait nu met xfs. De resultaten van chunksize 4 zijn iets beter dan die met ext4. Redelijk vergelijkbaar met die van iMars. De resultaten met chunksize 8 gaat echter meteen weer mis, read is slechts 5. Ik laat m gewoon verder lopen, maar ben toch benieuwd wat hier nu mis gaat.

Heb overigens ook wat meegekeken met iostat zoals hierboven aangegeven. Alle cijfertjes lijken redelijk gelijk over de 4 schijven. Zoiets:
code:
1
2
3
4
5
6
7

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda            1079,00     0,00  969,00    0,00 16392,00     0,00    33,83     1,78    1,84    1,84    0,00   0,72  70,00
sdc            1068,00     0,00  980,00    0,00 16392,00     0,00    33,45     1,83    1,87    1,87    0,00   0,71  70,00
sde               0,00     0,00    0,00    0,00     0,00     0,00     0,00     0,00    0,00    0,00    0,00   0,00   0,00
sdb            1089,00     0,00  960,00    0,00 16408,00     0,00    34,18     1,94    2,02    2,02    0,00   0,77  74,00
sdd            1097,00     0,00  951,00    0,00 16368,00     0,00    34,42     1,90    2,00    2,00    0,00   0,75  71,00
md5               0,00     0,00 8192,00    0,00 65536,00     0,00    16,00     0,00    0,00    0,00    0,00   0,00   0,00

Kan iemand die belachelijke waardes voor de read verklaren bij bepaalde chunksizes?

zondag 7 augustus 2011 23:26

Acties:
  • iMars
  • Registratie: Augustus 2001
  • Laatst online: 14:55

iMars

Full time prutser

Topicstarter
IntToStr schreef op zondag 07 augustus 2011 @ 21:04:
Hij draait nu met xfs. De resultaten van chunksize 4 zijn iets beter dan die met ext4. Redelijk vergelijkbaar met die van iMars. De resultaten met chunksize 8 gaat echter meteen weer mis, read is slechts 5. Ik laat m gewoon verder lopen, maar ben toch benieuwd wat hier nu mis gaat.

Heb overigens ook wat meegekeken met iostat zoals hierboven aangegeven. Alle cijfertjes lijken redelijk gelijk over de 4 schijven. Zoiets:
code:
1
2
3
4
5
6
7

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda            1079,00     0,00  969,00    0,00 16392,00     0,00    33,83     1,78    1,84    1,84    0,00   0,72  70,00
sdc            1068,00     0,00  980,00    0,00 16392,00     0,00    33,45     1,83    1,87    1,87    0,00   0,71  70,00
sde               0,00     0,00    0,00    0,00     0,00     0,00     0,00     0,00    0,00    0,00    0,00   0,00   0,00
sdb            1089,00     0,00  960,00    0,00 16408,00     0,00    34,18     1,94    2,02    2,02    0,00   0,77  74,00
sdd            1097,00     0,00  951,00    0,00 16368,00     0,00    34,42     1,90    2,00    2,00    0,00   0,75  71,00
md5               0,00     0,00 8192,00    0,00 65536,00     0,00    16,00     0,00    0,00    0,00    0,00   0,00   0,00

Kan iemand die belachelijke waardes voor de read verklaren bij bepaalde chunksizes?
Het enige wat mij gelijk opvalt is dat sde niet werkt... is deze 'dood'? Als de eens sec met sde omwisselt kan je zien of het aan de port ligt, of aan de harddisk.

Of staat er al data op de array?

Koop hier mijn P1 reader :)

zondag 7 augustus 2011 23:29

Acties:
  • Q
  • Registratie: November 1999
  • Laatst online: 11:14

Q

Au Contraire Mon Capitan!

Hij / zijn heeft maar 4 devices in de array, sde is een andere disk (boot?).

in de iostat snapshot zie ik een lees performance van 65 MB/s en dat is traag. Maar wat is de status van de array?

mdadm -D /dev/md5

?

Test eens rechtstreeks naar het device met


dd if=/dev/md5 of=/dev/null bs=1M count=10000

Je hoeft conform het script niet 5x te testen, je kunt het terug schroeven naar bijv 1x of 2x. Dan gaat het testen sneller.

[ Voor 40% gewijzigd door Q op 07-08-2011 23:33 ]

zondag 7 augustus 2011 23:55

Acties:
  • iMars
  • Registratie: Augustus 2001
  • Laatst online: 14:55

iMars

Full time prutser

Topicstarter
Dit is mijn mdadm -D /dev/md5 (eventueel ter vergelijking)
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

/dev/md5:
        Version : 1.2
  Creation Time : Sun Jul 10 12:35:09 2011
     Raid Level : raid5
     Array Size : 5860540032 (5589.05 GiB 6001.19 GB)
  Used Dev Size : 1953513344 (1863.02 GiB 2000.40 GB)
   Raid Devices : 4
  Total Devices : 4
    Persistence : Superblock is persistent

    Update Time : Sun Aug  7 22:55:15 2011
          State : clean
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 128K

           Name : iServer:5  (local to host iServer)
           UUID : bc72e363:49472487:907f1dd8:4d76739c
         Events : 11

    Number   Major   Minor   RaidDevice State
       0       8       32        0      active sync   /dev/sdc
       1       8       48        1      active sync   /dev/sdd
       2       8       64        2      active sync   /dev/sde
       3       8       80        3      active sync   /dev/sdf

Koop hier mijn P1 reader :)

maandag 8 augustus 2011 09:58

Acties:
  • IntToStr
  • Registratie: December 2003
  • Laatst online: 16:33

IntToStr

Dit is mijn net weer nieuw aangemaakte array:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

/dev/md5:
        Version : 1.2
  Creation Time : Mon Aug  8 09:42:09 2011
     Raid Level : raid5
     Array Size : 5860540032 (5589.05 GiB 6001.19 GB)
  Used Dev Size : 1953513344 (1863.02 GiB 2000.40 GB)
   Raid Devices : 4
  Total Devices : 4
    Persistence : Superblock is persistent

    Update Time : Mon Aug  8 09:50:16 2011
          State : clean
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 128K

           Name : nas:5  (local to host nas)
           UUID : 6d19db70:b8f5c2ac:c4abb2f1:ecbe4042
         Events : 2

    Number   Major   Minor   RaidDevice State
       0       8        0        0      active sync   /dev/sda
       1       8       16        1      active sync   /dev/sdb
       2       8       32        2      active sync   /dev/sdc
       3       8       48        3      active sync   /dev/sdd

Verschil is dus die Minor waardes.

Overigens krijg ik dit te zien bij het tune script: (maar geeft wel success aan)
code:
1
2
3
4
5
6
7
8
9

read ahead size per device: 3072 blocks (1536kb)
read ahead size of array: 12288 blocks (6144kb)
stripe cache size of devices: 384 pages (1536kb)
setting max sectors kb to match chunk size
setting NCQ queue depth to 1
./tuneraid.sh: line 130: /sys/block/sdd/device/queue_depth: Permission denied
./tuneraid.sh: line 130: /sys/block/sdc/device/queue_depth: Permission denied
./tuneraid.sh: line 130: /sys/block/sdb/device/queue_depth: Permission denied
./tuneraid.sh: line 130: /sys/block/sda/device/queue_depth: Permission denied

En het testje rechtstreeks op /dev/md5:
code:
1
2
3
4

root@nas:/home# dd if=/dev/md5 of=/dev/null bs=1M count=10000
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 82,136 s, 128 MB/s


En sde is inderdaad een boot schijf en het is "hij" ;)

Toevoeging ter vergelijking:
code:
1
2
3
4
5
6
7
8

root@nas:/home# dd if=/dev/zero of=/storage/test.bin bs=1M count=10000
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 61,5658 s, 170 MB/s
root@nas:/home# dd if=/storage/test.bin of=/dev/null bs=1M count=10000
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 66,6885 s, 157 MB/s

[ Voor 8% gewijzigd door IntToStr op 08-08-2011 10:04 ]

maandag 8 augustus 2011 10:10

Acties:
  • FireDrunk
  • Registratie: November 2002
  • Laatst online: 17-11 19:31

FireDrunk

Ik vind je request size een beetje laag (je iostat verhaal, 7e kolom.) Dat is de hoeveelheid data die per commando aan de disk gevraagd word. Het klinkt alsof er ergens een misalignment ofzo zit op chunk of stripe sizes. Hoe dat te vinden, kan ik zo even niet bedenken...

is 1 disk wel snel?

dd if=/dev/sda of=/dev/null bs=1M count=10240

Even niets...

maandag 8 augustus 2011 10:24

Acties:
  • IntToStr
  • Registratie: December 2003
  • Laatst online: 16:33

IntToStr

Los lijken ze normale resultaten te geven:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

root@nas:~# dd if=/dev/sda of=/dev/null bs=1M count=10240
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 76,9905 s, 139 MB/s
root@nas:~# dd if=/dev/sdb of=/dev/null bs=1M count=10240
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 74,6231 s, 144 MB/s
root@nas:~# dd if=/dev/sdc of=/dev/null bs=1M count=10240
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 74,4365 s, 144 MB/s
root@nas:~# dd if=/dev/sdd of=/dev/null bs=1M count=10240
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 72,2342 s, 149 MB/s

maandag 8 augustus 2011 10:36

Acties:
  • FireDrunk
  • Registratie: November 2002
  • Laatst online: 17-11 19:31

FireDrunk

Dat ziet er keurig uit. Zou je die tests eens allemaal tegelijk op meerdere ssh sessies kunnen doen?
Misschien zitten ze elkaar wel in de weg. (wat ik niet verwacht, maar zeker weten is altijd beter...)

Even niets...

maandag 8 augustus 2011 10:58

Acties:
  • IntToStr
  • Registratie: December 2003
  • Laatst online: 16:33

IntToStr

Een stukje iostat van alle 4 tegelijk:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0,50    0,00   38,50   61,00    0,00    0,00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda           23276,00     0,00  752,00    0,00 96256,00     0,00   256,00    18,16   24,24   24,24    0,00   1,33 100,00
sdc           23808,00     0,00  765,00    0,00 97920,00     0,00   256,00    18,01   23,46   23,46    0,00   1,31 100,00
sde               0,00     0,00    0,00    0,00     0,00     0,00     0,00     0,00    0,00    0,00    0,00   0,00   0,00
sdb           23064,00     0,00  734,00    0,00 93952,00     0,00   256,00    18,14   24,93   24,93    0,00   1,36 100,00
sdd           23808,00     0,00  765,00    0,00 97920,00     0,00   256,00    17,85   23,20   23,20    0,00   1,31 100,00
md5               0,00     0,00    0,00    0,00     0,00     0,00     0,00     0,00    0,00    0,00    0,00   0,00   0,00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0,50    0,00   33,50   65,50    0,00    0,50

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda           22320,00     0,00  721,00    0,00 92288,00     0,00   256,00    18,32   25,35   25,35    0,00   1,39 100,00
sdc           23064,00     0,00  739,00    0,00 94592,00     0,00   256,00    17,85   24,32   24,32    0,00   1,35 100,00
sde               0,00     6,00    0,00    4,00     0,00    40,00    20,00     0,05   12,50    0,00   12,50  12,50   5,00
sdb           22320,00     0,00  720,00    0,00 92160,00     0,00   256,00    18,15   25,21   25,21    0,00   1,39 100,00
sdd           22692,00     0,00  740,00    0,00 94720,00     0,00   256,00    18,19   24,65   24,65    0,00   1,35 100,00
md5               0,00     0,00    0,00    0,00     0,00     0,00     0,00     0,00    0,00    0,00    0,00   0,00   0,00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0,00    0,00   31,50   68,00    0,00    0,50

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda           21948,00     0,00  701,00    0,00 89728,00     0,00   256,00    18,28   26,23   26,23    0,00   1,43 100,00
sdc           22836,00     0,00  741,00    0,00 94680,00     0,00   255,55    17,98   24,21   24,21    0,00   1,35 100,00
sde               0,00     0,00    0,00    0,00     0,00     0,00     0,00     0,00    0,00    0,00    0,00   0,00   0,00
sdb           21352,00     0,00  698,00    0,00 89192,00     0,00   255,56    17,90   25,54   25,54    0,00   1,43 100,00
sdd           23436,00     0,00  759,00    0,00 97152,00     0,00   256,00    18,21   23,99   23,99    0,00   1,32 100,00
md5               0,00     0,00    0,00    0,00     0,00     0,00     0,00     0,00    0,00    0,00    0,00   0,00   0,00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0,00    0,00   37,50   62,50    0,00    0,00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda           23064,00     0,00  750,00    0,00 96000,00     0,00   256,00    18,01   23,67   23,67    0,00   1,33 100,00
sdc           23064,00     0,00  747,00    0,00 95616,00     0,00   256,00    18,39   24,54   24,54    0,00   1,34 100,00
sde               0,00     0,00    0,00    0,00     0,00     0,00     0,00     0,00    0,00    0,00    0,00   0,00   0,00
sdb           23436,00     0,00  751,00    0,00 96128,00     0,00   256,00    17,85   23,64   23,64    0,00   1,33 100,00
sdd           23436,00     0,00  748,00    0,00 95744,00     0,00   256,00    17,99   24,12   24,12    0,00   1,34 100,00
md5               0,00     0,00    0,00    0,00     0,00     0,00     0,00     0,00    0,00    0,00    0,00   0,00   0,00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0,00    0,00   37,00   63,00    0,00    0,00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda           24552,00     0,00  789,00    0,00 100992,00     0,00   256,00    18,11   23,23   23,23    0,00   1,27 100,00
sdc           23064,00     0,00  741,00    0,00 94848,00     0,00   256,00    18,08   24,57   24,57    0,00   1,35 100,00
sde               0,00     0,00    0,00    0,00     0,00     0,00     0,00     0,00    0,00    0,00    0,00   0,00   0,00
sdb           24332,00     0,00  782,00    0,00 99960,00     0,00   255,65    18,08   23,32   23,32    0,00   1,28 100,00
sdd           23436,00     0,00  757,00    0,00 96896,00     0,00   256,00    18,08   23,90   23,90    0,00   1,32 100,00
md5               0,00     0,00    0,00    0,00     0,00     0,00     0,00     0,00    0,00    0,00    0,00   0,00   0,00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0,00    0,00   36,50   63,50    0,00    0,00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda           22692,00     0,00  737,00    0,00 94336,00     0,00   256,00    17,84   24,15   24,15    0,00   1,36 100,00
sdc           23064,00     0,00  746,00    0,00 95488,00     0,00   256,00    17,94   23,94   23,94    0,00   1,34 100,00
sde               0,00     0,00    0,00    0,00     0,00     0,00     0,00     0,00    0,00    0,00    0,00   0,00   0,00
sdb           22692,00     0,00  737,00    0,00 94336,00     0,00   256,00    18,36   24,88   24,88    0,00   1,36 100,00
sdd           23064,00     0,00  746,00    0,00 95488,00     0,00   256,00    18,14   24,18   24,18    0,00   1,34 100,00
md5               0,00     0,00    0,00    0,00     0,00     0,00     0,00     0,00    0,00    0,00    0,00   0,00   0,00

top geeft wel een load van boven de 3.0 aan.

De resultaten van alle vier tegelijk zijn ongeveer 100 MB/s voor alle vier de schijven.

maandag 8 augustus 2011 11:20

Acties:
  • FireDrunk
  • Registratie: November 2002
  • Laatst online: 17-11 19:31

FireDrunk

Dat is erg vreemd... Je request size ziet er hier prima uit (256) en je disks doen 95MB/s per stuk. Dat zou neer moeten komen op 250-300MB/s voor je RAID5 array (4 disk - 1 parity). Klinkt als een issue met MDADM...

Even niets...

maandag 8 augustus 2011 12:09

Acties:
  • IntToStr
  • Registratie: December 2003
  • Laatst online: 16:33

IntToStr

Iemand die weet in welke richting ik moet zoeken? Ik draai nu ubuntu server 11.04. Kan ik op een eenvoudige manier mdadm opnieuw installeren bijvoorbeeld?

Het is ook een optie om ubuntu helemaal opnieuw te installeren, maar ik ga liever niet weer alles door het huis slepen en aan een monitor hangen...

maandag 8 augustus 2011 12:26

Acties:
  • iMars
  • Registratie: Augustus 2001
  • Laatst online: 14:55

iMars

Full time prutser

Topicstarter
IntToStr schreef op maandag 08 augustus 2011 @ 12:09:
Iemand die weet in welke richting ik moet zoeken? Ik draai nu ubuntu server 11.04. Kan ik op een eenvoudige manier mdadm opnieuw installeren bijvoorbeeld?

Het is ook een optie om ubuntu helemaal opnieuw te installeren, maar ik ga liever niet weer alles door het huis slepen en aan een monitor hangen...
Helemaal opnieuw installeren is imho helemaal niet nodig. Probeer anders eens mdadm te verwijderen en opnieuw te installeren.

de permission denied meldingen komt waarschijnlijk omdat je het script niet als root/super user runt.

Koop hier mijn P1 reader :)

maandag 8 augustus 2011 12:27

Acties:
  • IntToStr
  • Registratie: December 2003
  • Laatst online: 16:33

IntToStr

Ik ga het zo eens proberen te verwijderen, maar de scripts zijn wel als root gedraaid.

maandag 8 augustus 2011 12:28

Acties:
  • iMars
  • Registratie: Augustus 2001
  • Laatst online: 14:55

iMars

Full time prutser

Topicstarter
IntToStr schreef op maandag 08 augustus 2011 @ 12:27:
Ik ga het zo eens proberen te verwijderen, maar de scripts zijn wel als root gedraaid.
Oh, dat is wel raar dan... :?

Koop hier mijn P1 reader :)

maandag 8 augustus 2011 13:39

Acties:
  • FireDrunk
  • Registratie: November 2002
  • Laatst online: 17-11 19:31

FireDrunk

Hoe heb je ze als root gedraaid?

sudo ./tunescript.sh
of

sudo -s
./tunescript.sh

In het geval van het eerste, probeer het 2e eens...

Even niets...

maandag 8 augustus 2011 13:47

Acties:
  • IntToStr
  • Registratie: December 2003
  • Laatst online: 16:33

IntToStr

Het was het tweede geval. Die eerste gaat inderdaad commando's uitvoeren als de gewone user.

maandag 8 augustus 2011 14:04

Acties:
  • jimmy87
  • Registratie: December 2006
  • Laatst online: 09:22

jimmy87

Ik heb chunks van 32 gepakt omdat dat het script aangaf als beste gemiddelde. En het klopte :) Ik haal nu 50MB/s meer dan met 128K

maandag 8 augustus 2011 14:14

Acties:
  • FireDrunk
  • Registratie: November 2002
  • Laatst online: 17-11 19:31

FireDrunk

Ik denk dat de issue niet zijn chunks zijn, als de disks bij activiteit gewoon 95MB/s doen, maar dat resulteert op filesystem niveau op bagger performance gaat daartussenin iets verkeerd...

Had je XFS al geprobeerd? Kun je eens een xfs info posten?


root@ZEUS:~# xfs_info /dev/md1
meta-data=/dev/md1               isize=256    agcount=32, agsize=91570912 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=2930269184, imaxpct=5
         =                       sunit=32     swidth=192 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=521728, version=2
         =                       sectsz=512   sunit=32 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0


Zoiets dus...

Even niets...

maandag 8 augustus 2011 14:16

Acties:
  • IntToStr
  • Registratie: December 2003
  • Laatst online: 16:33

IntToStr

Ik had bij mijn latere pogingen xfs gebruikt. Ben nu mdadm opnieuw aan het installeren tussen m'n werk door. Als ik een nieuwe array heb gebouwd zal ik de xsf_info eens posten.

maandag 8 augustus 2011 14:26

Acties:
  • IntToStr
  • Registratie: December 2003
  • Laatst online: 16:33

IntToStr

code:
1
2
3
4
5
6

root@nas:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md5 : active raid5 sdd[3] sdc[2] sdb[1] sda[0]
      5860540224 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/4] [UUUU]

unused devices: <none>

code:
1
2
3
4
5
6
7
8
9

root@nas:~# xfs_info /dev/md5
meta-data=/dev/md5               isize=256    agcount=32, agsize=45785456 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=1465134592, imaxpct=5
         =                       sunit=16     swidth=48 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=521728, version=2
         =                       sectsz=512   sunit=16 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

maandag 8 augustus 2011 14:37

Acties:
  • FireDrunk
  • Registratie: November 2002
  • Laatst online: 17-11 19:31

FireDrunk

Ziet er allemaal keurig uit. je SUNIT en SWIDTH kloppen ook prima... heel vreemd...
EXT3 had je geprobeerd? of EXT4?

Even niets...

maandag 8 augustus 2011 14:53

Acties:
  • IntToStr
  • Registratie: December 2003
  • Laatst online: 16:33

IntToStr

Ik had eerst ext4 en later xfs geprobeerd. De recentere posts zijn allemaal xfs, maar de resultaten verschillen niet echt.

maandag 8 augustus 2011 15:19

Acties:
  • iMars
  • Registratie: Augustus 2001
  • Laatst online: 14:55

iMars

Full time prutser

Topicstarter
IntToStr schreef op maandag 08 augustus 2011 @ 14:26:
code:
1
2
3
4
5
6

root@nas:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md5 : active raid5 sdd[3] sdc[2] sdb[1] sda[0]
      5860540224 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/4] [UUUU]

unused devices: <none>

code:
1
2
3
4
5
6
7
8
9

root@nas:~# xfs_info /dev/md5
meta-data=/dev/md5               isize=256    agcount=32, agsize=45785456 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=1465134592, imaxpct=5
         =                       sunit=16     swidth=48 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=521728, version=2
         =                       sectsz=512   sunit=16 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
Even vergeleken met mijn xfs_info:
code:
1
2
3
4
5
6
7
8
9

marcel@iServer:~$ xfs_info /dev/md5
meta-data=/dev/md5               isize=256    agcount=32, agsize=45785440 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=1465134080, imaxpct=5
         =                       sunit=32     swidth=96 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=16384, version=2
         =                       sectsz=512   sunit=32 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

Het enige echte verschil wat ik zie, is dat ik het dubbele sunit en swidth heb.

edit:
IntToStr schreef op maandag 08 augustus 2011 @ 13:47:
Het was het tweede geval. Die eerste gaat inderdaad commando's uitvoeren als de gewone user.
toch niet ;)
code:
1
2
3
4

marcel@iServer:~$ whoami
marcel
marcel@iServer:~$ sudo whoami
root

sudo ./tunescript.sh zou moeten werken ;)

[ Voor 9% gewijzigd door iMars op 08-08-2011 15:33 ]

Koop hier mijn P1 reader :)

maandag 8 augustus 2011 15:32

Acties:
  • iMars
  • Registratie: Augustus 2001
  • Laatst online: 14:55

iMars

Full time prutser

Topicstarter
oeps, dubbele post sorry 8)7

[ Voor 94% gewijzigd door iMars op 08-08-2011 15:32 ]

Koop hier mijn P1 reader :)

maandag 8 augustus 2011 15:38

Acties:
  • FireDrunk
  • Registratie: November 2002
  • Laatst online: 17-11 19:31

FireDrunk

Sunit en swidth klopt. Sunit is stripe unit, stripe deel per data-disk.
swidth is stripe over alle datadisks heen
4 disk raid 5 geef sunit 32 en swidth 96 (3 x 32).
8 disk raid 6 geeft sunit 32 en swidth 192 (6 x 32)

Mocht je ooit je array gaan growen kan het zo zijn dat je dat moet wijzigen...

[ Voor 15% gewijzigd door FireDrunk op 08-08-2011 15:49 ]

Even niets...

maandag 8 augustus 2011 16:22

Acties:
  • IntToStr
  • Registratie: December 2003
  • Laatst online: 16:33

IntToStr

iMars schreef op maandag 08 augustus 2011 @ 15:19:
[...]

toch niet ;)
code:
1
2
3
4

marcel@iServer:~$ whoami
marcel
marcel@iServer:~$ sudo whoami
root

sudo ./tunescript.sh zou moeten werken ;)
Ik bedoelde dat commando's in het script soms uitgevoerd worden onder de normale user. Het commando waar je sudo voor zet wordt uiteraard wel als root uitgevoerd.

Als ik het script voor het testen van de chunksizes run geeft ie zoals eerder al gemeld hele rare waardes terug. Als ik handmatig hetzelfde doe krijg ik wel zinnige resultaten. Ik hoop dat ik er 1 kan vinden die acceptabel is, maar het voelt allemaal nog niet echt lekker.

Kan het misschien aan het OS liggen? Ik gebruik nu ubuntu server 11.04 64 bit. Wat gebruiken jullie als OS?

Wat zouden redelijke waardes zijn voor een raid 5 array van 4 disks van 2Tb?

maandag 8 augustus 2011 16:30

Acties:
  • FireDrunk
  • Registratie: November 2002
  • Laatst online: 17-11 19:31

FireDrunk

Ik heb exact zelfde OS.

Redelijk zou ik 250-300MB/s vinden, afhankelijk van je CPU (belasting).
Ik zie net dat je een Atom hebt... heb je de CPU load al eens bekeken tijdens het kopieren?

(top) :)

[ Voor 34% gewijzigd door FireDrunk op 08-08-2011 16:31 ]

Even niets...

maandag 8 augustus 2011 17:09

Acties:
  • Nielson
  • Registratie: Juni 2001
  • Laatst online: 18:31

Nielson

Draai hier ook 11.04 x64 en haal ongeveer 280/200 MB/s read/write met 5x 1TB F2EG in raid5.
FireDrunk schreef op maandag 08 augustus 2011 @ 16:30:
Ik zie net dat je een Atom hebt... heb je de CPU load al eens bekeken tijdens het kopieren?
Volgens deze post een E8400, iMars had dacht ik een Atom.

[ Voor 79% gewijzigd door Nielson op 08-08-2011 17:26 ]

maandag 8 augustus 2011 17:48

Acties:
  • IntToStr
  • Registratie: December 2003
  • Laatst online: 16:33

IntToStr

Hier overigens een snapshot van top tijdens het uitvoeren van de dd commando's (schrijven):
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14

top - 17:44:48 up 1 day,  1:46,  3 users,  load average: 1.27, 0.56, 0.35
Tasks: 125 total,   1 running, 123 sleeping,   0 stopped,   1 zombie
Cpu(s):  0.2%us, 24.7%sy,  0.0%ni, 31.5%id, 32.5%wa,  0.0%hi, 11.2%si,  0.0%st
Mem:   1921752k total,  1906064k used,    15688k free,    57520k buffers
Swap:  1960956k total,        0k used,  1960956k free,  1546384k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 6386 root      20   0     0    0    0 S   30  0.0   0:18.84 md5_raid5
 6404 root      20   0 10948 1696  600 D   19  0.1   0:08.71 dd
 6405 root      20   0     0    0    0 D   13  0.0   0:05.87 flush-9:5
   27 root      20   0     0    0    0 S    5  0.0   2:54.65 kswapd0
 6016 root      20   0     0    0    0 S    1  0.0   0:01.09 kworker/0:0
 6320 root      20   0     0    0    0 S    1  0.0   0:00.45 kworker/1:2
 1124 tomcat6   20   0  547m  67m 1752 S    0  3.6   0:23.40 java

Bij het lezen zijn de waardes iets lager.

Het gaat overigens inderdaad om een E8400.

maandag 8 augustus 2011 20:26

Acties:
  • FireDrunk
  • Registratie: November 2002
  • Laatst online: 17-11 19:31

FireDrunk

Sorteer eens op geheugen... 19MB vrij en 55MB cached klinkt als vol geheugen...

Even niets...

maandag 8 augustus 2011 21:28

Acties:
  • IntToStr
  • Registratie: December 2003
  • Laatst online: 16:33

IntToStr

Ben voor de zekerheid toch maar begonnen met een reinstall van ubuntu en heb de bios op failsafe defaults gezet.

Een paar plaatjes uit de bios. Ziet iemand hier iets vreemds aan?
Afbeeldingslocatie: http://dl.dropbox.com/u/35758578/nas/IMAG0050.jpg
Afbeeldingslocatie: http://dl.dropbox.com/u/35758578/nas/IMAG0051.jpg
En een screenshot van memtest
Afbeeldingslocatie: http://dl.dropbox.com/u/35758578/nas/IMAG0053.jpg

Na de install ga ik verder kijken naar geheugengebruik. Het geheugen is wel wat ouder, maar voor een nas zou dit toch voldoende moeten zijn lijkt me.

Het moederbord is een http://tweakers.net/pricewatch/262629/zotac-g43itx-a-e.html

[ Voor 7% gewijzigd door IntToStr op 08-08-2011 22:09 . Reden: url fix ]

maandag 8 augustus 2011 21:42

Acties:
  • Nielson
  • Registratie: Juni 2001
  • Laatst online: 18:31

Nielson

Je plaatjes werken hier niet, staan misschien niet op een publiek gedeelte van je dropbox?

maandag 8 augustus 2011 22:17

Acties:
  • IntToStr
  • Registratie: December 2003
  • Laatst online: 16:33

IntToStr

Per ongeluk verkeerde url gecopypasted...

Reinstall gaat ook verre van vlekkeloos. Is al een paar keer blijven hangen. Hij lijkt wel telkens iets verder te komen bij nieuwe poging. Gaat lekker zo... Eerste install paar dagen geleden ging wel gewoon in 1x goed.

Bij het installeren vanaf usb lijkt me dat alles in het geheugen wordt geladen totdat de schijf geformatteerd en klaar is. Misschien dat er toch iets met het geheugen is, ondanks dat memtest geen problemen leek te geven.

Morgen nog maar eens wat kabels en zo langslopen ook.

[ Voor 25% gewijzigd door IntToStr op 08-08-2011 22:36 ]

dinsdag 9 augustus 2011 10:31

Acties:
  • iMars
  • Registratie: Augustus 2001
  • Laatst online: 14:55

iMars

Full time prutser

Topicstarter
FireDrunk schreef op maandag 08 augustus 2011 @ 15:38:
Sunit en swidth klopt. Sunit is stripe unit, stripe deel per data-disk.
swidth is stripe over alle datadisks heen
4 disk raid 5 geef sunit 32 en swidth 96 (3 x 32).
8 disk raid 6 geeft sunit 32 en swidth 192 (6 x 32)

Mocht je ooit je array gaan growen kan het zo zijn dat je dat moet wijzigen...
Maar IntToStr heef ook 4x 2TB (toch???) en hij heeft 16 / 48 ...
Nielson schreef op maandag 08 augustus 2011 @ 17:09:
Draai hier ook 11.04 x64 en haal ongeveer 280/200 MB/s read/write met 5x 1TB F2EG in raid5.


[...]
Volgens deze post een E8400, iMars had dacht ik een Atom.
Klopt, ik heb een D525 (dual core 1.8GHz)
IntToStr schreef op maandag 08 augustus 2011 @ 21:28:
Ben voor de zekerheid toch maar begonnen met een reinstall van ubuntu en heb de bios op failsafe defaults gezet.

Een paar plaatjes uit de bios. Ziet iemand hier iets vreemds aan?
[afbeelding]
[afbeelding]
En een screenshot van memtest
[afbeelding]

Na de install ga ik verder kijken naar geheugengebruik. Het geheugen is wel wat ouder, maar voor een nas zou dit toch voldoende moeten zijn lijkt me.

Het moederbord is een http://tweakers.net/pricewatch/262629/zotac-g43itx-a-e.html
Ik heb SATA op ahci mode gezet, en niet op IDE mode...

Weet niet of het uit maakt (lijkt mij logisch van niet, maar weet dat niet zeker) of je je bootdisk op port 4 of 5 zet? Bij mij staat op SATA0 mijn ssd bootdisk, SATA1 is momenteel vrij en SATA2/3/4/5 4x de F4EG (sd[c-e]).

Koop hier mijn P1 reader :)

dinsdag 9 augustus 2011 23:11

Acties:
  • IntToStr
  • Registratie: December 2003
  • Laatst online: 16:33

IntToStr

Net in een half uurtje kast opengeschroefd, sata kabels omgewisseld zodat boot schijf met OS sda wordt (en dat valt niet mee in een volle Lian Li Q08), bios aangepast op paar punten (waaronder ahci ipv ide), OS opnieuw geïnstalleerd en klaar gezet voor morgen zodat ik vanaf mijn werk af en toe wat scripts kan runnen en zo.

Alles verliep soepel en snel en dat is al heel wat met dit project. Hopelijk nu morgen ook mooie resultaten...

Edit: overigens inderdaad dezelfde setup als iMars, maar dan met E8400 cpu. Moederbord en geheugen zijn mogelijk wel wat ouder hier.

[ Voor 13% gewijzigd door IntToStr op 09-08-2011 23:13 ]

woensdag 10 augustus 2011 15:04

Acties:
  • IntToStr
  • Registratie: December 2003
  • Laatst online: 16:33

IntToStr

Iedereen bedankt voor alle geleverde hulp! d:)b De wijzigingen die ik gisterenavond nog even snel had gedaan zijn succesvol gebleken. Voor mij bleek een chunksize van 512kb de beste te zijn (toevallig(?) de default):
code:
1
2
3
4
5
6
7

root@nas:/# dd if=/dev/zero of=/storage/test.bin bs=1M count=10000; dd if=/storage/test.bin of=/dev/null bs=1M count=10000
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 31.1943 s, 336 MB/s
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 27.8664 s, 393 MB/s

*O*
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

root@nas:/# mdadm -D /dev/md5
/dev/md5:
        Version : 1.2
  Creation Time : Wed Aug 10 14:24:30 2011
     Raid Level : raid5
     Array Size : 5860538880 (5589.05 GiB 6001.19 GB)
  Used Dev Size : 1953512960 (1863.02 GiB 2000.40 GB)
   Raid Devices : 4
  Total Devices : 4
    Persistence : Superblock is persistent

    Update Time : Wed Aug 10 14:40:48 2011
          State : clean
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

           Name : nas:5  (local to host nas)
           UUID : 1e18f31d:297d5e55:16245dff:ce1c1ae8
         Events : 2

    Number   Major   Minor   RaidDevice State
       0       8       16        0      active sync   /dev/sdb
       1       8       32        1      active sync   /dev/sdc
       2       8       48        2      active sync   /dev/sdd
       3       8       64        3      active sync   /dev/sde

Ook geen gekke foutmeldingen meer met ncq queue depth bij het tune raid script. NCQ gaf trouwens alleen maar mindere resultaten bij mij in zo'n beetje alle gevallen die ik heb uitgeprobeerd.

Heb voor de chunksizes 64 t/m 512 alles getest met ext4 vs xfs en dus wel/niet ncq. In alle gevallen was ext4 sneller dan xfs, dus ik heb nu voor ext4 gekozen.

Ben alleen vergeten om update-initramfs -u te draaien voordat ik reboot intypte... -O- Nu dus maar wachten tot vanavond zodat ik dat ding weer fatsoenlijk op kan starten en alsnog dat commando kan draaien...

woensdag 10 augustus 2011 16:34

Acties:
  • iMars
  • Registratie: Augustus 2001
  • Laatst online: 14:55

iMars

Full time prutser

Topicstarter
IntToStr schreef op woensdag 10 augustus 2011 @ 15:04:
Iedereen bedankt voor alle geleverde hulp! d:)b De wijzigingen die ik gisterenavond nog even snel had gedaan zijn succesvol gebleken. Voor mij bleek een chunksize van 512kb de beste te zijn (toevallig(?) de default):
code:
1
2
3
4
5
6
7

root@nas:/# dd if=/dev/zero of=/storage/test.bin bs=1M count=10000; dd if=/storage/test.bin of=/dev/null bs=1M count=10000
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 31.1943 s, 336 MB/s
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 27.8664 s, 393 MB/s

*O*
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

root@nas:/# mdadm -D /dev/md5
/dev/md5:
        Version : 1.2
  Creation Time : Wed Aug 10 14:24:30 2011
     Raid Level : raid5
     Array Size : 5860538880 (5589.05 GiB 6001.19 GB)
  Used Dev Size : 1953512960 (1863.02 GiB 2000.40 GB)
   Raid Devices : 4
  Total Devices : 4
    Persistence : Superblock is persistent

    Update Time : Wed Aug 10 14:40:48 2011
          State : clean
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

           Name : nas:5  (local to host nas)
           UUID : 1e18f31d:297d5e55:16245dff:ce1c1ae8
         Events : 2

    Number   Major   Minor   RaidDevice State
       0       8       16        0      active sync   /dev/sdb
       1       8       32        1      active sync   /dev/sdc
       2       8       48        2      active sync   /dev/sdd
       3       8       64        3      active sync   /dev/sde

Ook geen gekke foutmeldingen meer met ncq queue depth bij het tune raid script. NCQ gaf trouwens alleen maar mindere resultaten bij mij in zo'n beetje alle gevallen die ik heb uitgeprobeerd.

Heb voor de chunksizes 64 t/m 512 alles getest met ext4 vs xfs en dus wel/niet ncq. In alle gevallen was ext4 sneller dan xfs, dus ik heb nu voor ext4 gekozen.

Ben alleen vergeten om update-initramfs -u te draaien voordat ik reboot intypte... -O- Nu dus maar wachten tot vanavond zodat ik dat ding weer fatsoenlijk op kan starten en alsnog dat commando kan draaien...
Gefeli! d:)b Ik gok dat het probleem lag bij de bios instelling AHCI vs IDE

Koop hier mijn P1 reader :)

woensdag 10 augustus 2011 16:44

Acties:
  • IntToStr
  • Registratie: December 2003
  • Laatst online: 16:33

IntToStr

iMars schreef op woensdag 10 augustus 2011 @ 16:34:
[...]

Gefeli! d:)b Ik gok dat het probleem lag bij de bios instelling AHCI vs IDE
Denk het ook. Die optie zat vrij goed verstopt in de bios. Hij stond op auto en pas nadat ie op enhanced stond kon ik voor ahci kiezen geloof ik.

woensdag 10 augustus 2011 20:18

Acties:
  • IntToStr
  • Registratie: December 2003
  • Laatst online: 16:33

IntToStr

Toch nog een vraagje over het tune scriptje. Ik merk dat je dit elke keer na een reboot moet draaien. Heb net een aantal reboots gedaan en als ik het script niet draai haal ik zo'n 50MB/s minder. Elke keer dat ik het script wel draai haal ik dus wel mooie waardes.

Hebben jullie dit toegevoegd aan een opstartscript of mis ik een configuratie iets om dit automatisch te laten gebeuren?

woensdag 10 augustus 2011 21:02

Acties:
  • iMars
  • Registratie: Augustus 2001
  • Laatst online: 14:55

iMars

Full time prutser

Topicstarter
IntToStr schreef op woensdag 10 augustus 2011 @ 20:18:
Toch nog een vraagje over het tune scriptje. Ik merk dat je dit elke keer na een reboot moet draaien. Heb net een aantal reboots gedaan en als ik het script niet draai haal ik zo'n 50MB/s minder. Elke keer dat ik het script wel draai haal ik dus wel mooie waardes.

Hebben jullie dit toegevoegd aan een opstartscript of mis ik een configuratie iets om dit automatisch te laten gebeuren?
Poe, ja ik reboot bijna nooit ;)

Koop hier mijn P1 reader :)

woensdag 10 augustus 2011 22:03

Acties:
  • FireDrunk
  • Registratie: November 2002
  • Laatst online: 17-11 19:31

FireDrunk

Ja, ik heb het script aan rc.local toegevoegd.

Even niets...

Pagina: 1
Reageer

Apple iPhone 17 LG OLED evo G5 Google Pixel 10 Samsung Galaxy S25 Star Wars: Outlaws Nintendo Switch 2 Apple AirPods Pro (2e generatie) Sony PlayStation 5 Pro

Tweakers is onderdeel van DPG Media B.V.
Alle rechten voorbehouden - Auteursrecht © 1998 - 2025 • Hosting door TrueFullstaq