Software RAID

[tspoon]

Dein Problem werden die 2,5" Platte sein. Die Ansprechzeit wird hier zu gering sein. Der Rechner schreibt also immer zuerst auf die die schnelle Platte und muss dann warten bis die Daten gespiegelt sind. Wenn der Buffer vollläuft ist schicht im Schacht und der PC Idled ohne Last rum.

Du kommste besser die 60GB einzeln laufen zu lassen. Per rsync 1 mal am Tag die Daten auf die 250GB Partition sichern oder per cp -prufv.

 

[tspoon]

hab noch was zum opimieren gefunden fwirkt sehr geil bei großenn ordner und vielen dateien

/etc/samba/smb.conf

[global]

log level = 1
read raw = yes
write raw = yes
oplocks = yes
max xmit = 65535

 

[yourgreatestfear]

Öhm, soweit ich das überschaue sind dies komplett die Defaultwerte der aktuellen Sambaversionen, die Optimierung mit diesen Werten wäre also gleich 0.

oplock würd ich übrigens nur dann global auf Default nutzen, wenn Freigaben für Datenbanken und kritische Dateien (zB shared Workspaces) explizit davon ausgenommen werden.

 

[tspoon]

jep sind default eventuell kann man mit den was rumspielen. aus und ein etc. auch kann es helfen das max ximt herab zusetzen somit werden kleinere datenblöcke übertragen.

 

[yourgreatestfear]

Kaum messbar, wenn man am xmit dreht, außer man geht kleiner 2048. In der Regel verschlechtert ein kleinerer Wert die Performance wegen Overhead.

Log Level = 0 (also Log deaktivieren) sollte auch nix bringen, denn = 1 ist schon absolut rudimentärer Log und man spart sich wirklich nur wenige Entries.

Die 3 restlichen würden nur die Performance senken, wenn sie deaktiviert würden. Die dienen im wesentlichen nur der Beeinflussung der Datenintegrität.

Den größten Einfluß machen heut noch der fragwürdige Cachingkram, aio, die Wahl eines bestimmten FS und strict allocate (FS-abhängig) aus. Aber der Spaß ist im default meist am performantesten.

 

[ghostadmin]

Ich habe auch einiges probiert bei Samba aber viel rausholen kann man nicht. Nichtmal bei den TCP Settings.
Samba hat auch scheinbar Probleme die CPU wirklich ganz zu nützen, vor allem bei Mehrkern.

 

[tspoon]

Hab hier nochmal paar Zeilen zum Testen der Schreib und Leseperformance:
[Achtung: sollten 10GB frei sein gff "count=10240" anpassen]

Schreiben:

dd if=/dev/zero of=/MOUNTPUNKT/10gb.16384k.stripe.out bs=1M count=10240

10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 55,5176 s, 193 MB/s

Lesen:

dd if=/MOUNTPUNKT/10gb.16384k.stripe.out of=/dev/null bs=1M

10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 35,3739 s, 304 MB/s


Optimierungen:

cat /sys/block/md0/md/stripe_cache_size
echo 16384 > /sys/block/md0/md/stripe_cache_size
blockdev --setra 16384 /dev/md0

Werte mit aktuell einen AMD X2 250, 2GB DDR2 RAM, 6x1,5TB Seagate 5900Umin

 

[tomturbo]

Ich bin der Meinung, dass 16384 Pages(!) viel zu viel für die stripe cache size sind.
64 MB readahead ist viel zu viel meiner Meinung nach, es sei denn auf dem Raidset sind ausschließlich Dateien die größer gleich 64 MB sind.

Ich habe ein kleines Skript gefunden, welches die optimalen Werte für cache und stride usw. berechnet und setzt, welches ich auch persönlich anwende.

#!/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
###############################################################################

if [ ! $1 ] 
then
	echo "No parameter device id given, assuming 0"
	ID=0
else
	ID=$1
fi

if [ ! $2 ]
then
	TUNE="false"
else
	TUNE=$2
fi

echo "tuning /dev/md${ID}"
echo "tune2fs ${TUNE}"

## parameters ##
MDDEV=md${ID}           # e.g. md51 for /dev/md51
CHUNKSIZE=64            # in kb
BLOCKSIZE=4             # of file system in kb
NCQ=enable              # 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=${TUNE}        # run tune2fs, ONLY SET TO true IF YOU USE EXT[34]
RAIDLEVEL=raid6         # raid5, raid6


## code ##
# test for priviledges
if [ "$(whoami)" != 'root' ]
then
  echo $(date): Need to be root >> /var/log/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 >> /var/log/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]
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 >> /var/log/tuneraid.log
exit 0

lg
__tom

 

[ghostadmin]

Ich habe nun u.A. ein RAID0 mit 2x 2,5" und siehe da, das Ding lastet Gigabit voll aus.

 

[tspoon]

ich hab bei mir meist isos und filme drauf. kleine dateien sind da eher nicht so von belang.
auch wirkt es sich bei mir nicht weiter aus, dokumenten-ordner werden auch schnell angezeigt und inidziert.

allerdings hat sich die schreib und leseperformance bei großen dateien und entpacken von rar-dateien erheblich gebessert.

 

[ghostadmin]

Bei großen Files wäre eine größere Chunksize sinnvoll. Ich wollte bei XFS ja mehr als 4KiB einstellen aber bei 64KiB konnte ich das Volume nicht mehr mounten also hab ich es bei 4KiB belassen.
mdadm macht ja auch ne Chunksize von 64

 

[tomturbo]

default seit neuesten ist 128kb bei mdadm

lg
__tom

 

[tspoon]

neu ist auch. das die raidpartitionsinformationen an den anfang der platte gesetzt haben, statt ans ende. also wer ein altes raid ins neue system hängen will sollte hier aufpassen, da muss dann nen zusatz in die mdam.cnf irgendwas mit meta 0.90 oder so, sonst wird das raid nicht erkannt.