ubuntu 10.10 + ssd = lassu?

Ubuntu Linux

hello,

jon a GSoC, igy megint felkerult egy ubuntu, ugyanis a qemu itt a legkenyelmesebb ;-)

viszont ami nagyon gaz, es nem ertem miert, hogy ha elkezdem nyuzni a diszket (egy F60as corsair SSD),
akkor mar viszonylag kis terheles mellett is 100% a diszk terheles az iostat szerint.
ext4, minden default, csak a discardot raktam be a mount opciokhoz, hogy legyen TRIM.

jelen felallasban, win7 aloli vmwareben gyorsabb a diszk, mint igy :(

egyeb otlet?

  • 3072 megtekintés

( mspike | 2011. 03. 15., k – 12:48 )

nekem a következő dolgok vannak még:

elevator=noop az /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT-hoz adva.

ext4 journal kikapcsolva.

discard-dal mountolva minden....

/var/log, /tmp, és a userem cache könyvtára tmpfs-en...

aszem ennyi történt... meg amit még úgy tudom érdemes, hogy nálam 64GB-ből csak 50-van leparticionálva, így megmarad az a bizonyos szabad hely az ssd-nek...

Nem emlékszem miket csináltam telepítésnél, de ezeket biztos.

semmit nem er, a performancia igyis a win7esnek a toredeke.

pl ha torlok egy konyvtarat (most epp 1.5G forraskod), akkor utana meg percekig 100% iowaitem van; most 3 szalon forgatok, de az iostat szerint kozel sincs kihajtva a diszk, megis 100%on all az iowait.

van errol egy jo regi kernel bug is. korbekerdeztem most, es talaltam meg 3 embert, akinel linux+ssd = rossz teljesitmeny... elkeserito, igy, 2011ben.


[dap@dh tmp]$ df -T .
Filesystem    Type    Size  Used Avail Use% Mounted on
/dev/mapper/ssd1vg-root
              ext4     20G   13G  6.0G  69% /

[dap@dh tmp]$ find linux-2.6.38|wc -l
38089

[dap@dh tmp]$ time (rm -r linux-2.6.38 && /bin/sync)
real	0m2.918s
user	0m0.054s
sys	0m1.617s

A linux forrás másolása is megvolt egy pillanat alatt (490MB), a törlés meg pláne, a sync után abszolút nincs IO, se iowait. 2.6.35.11-83.fc14.x86_64 a kernel, az SSD:
Model=KINGSTON SNV425S264GB, FwRev=C091126a, SerialNo=07MA30091774

dd if=/dev/sda of=test.bin bs=1024 count=$((1024*1024))

alatt felment 40% utána egyből 0%

real 0m6.579s
user 0m0.150s
sys 0m2.990s

Ami nem olyan húúú de gyors de mondjuk 1 GB-t felolvastam és kiírtam ugyan oda...

rm test.bin alatt meg semmi....

másik próba:

time dd if=/dev/core of=test.bin bs=1024 count=$((1024*1024))
1048576+0 records in
1048576+0 records out
1073741824 bytes (1.1 GB) copied, 5.7905 s, 185 MB/s

real 0m6.066s
user 0m0.110s
sys 0m2.820s

Kevés az adat ? Mondj valamit, mennyit kéne legyilkolni ? Vagy több fálj kéne... ?
Ha kell eltudom küldeni milyen kernel, milyen config...
Oldjuk meg, mert így nem jó neked ! :)

+infó
végig dolgozok közbe :) megy egy csomó ssh, chrome, mp3... etc.

Controller:
00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI Controller (rev 03)

SSD:

ATA device, with non-removable media
Model Number: KINGSTON SNV425S264GB
Serial Number: xxxxxxxxx
Firmware Revision: C091126a
Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6
Standards:
Supported: 8 7 6 5
Likely used: 8
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 125045424
LBA48 user addressable sectors: 125045424
Logical Sector size: 512 bytes
Physical Sector size: 512 bytes
Logical Sector-0 offset: 0 bytes
device size with M = 1024*1024: 61057 MBytes
device size with M = 1000*1000: 64023 MBytes (64 GB)
cache/buffer size = unknown
Form Factor: 2.5 inch
Nominal Media Rotation Rate: Solid State Device
Capabilities:
LBA, IORDY(can be disabled)
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = 16
Advanced power management level: 254
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* SMART feature set
Security Mode feature set
* Power Management feature set
* Write cache
* Look-ahead
* Host Protected Area feature set
* WRITE_BUFFER command
* READ_BUFFER command
* DOWNLOAD_MICROCODE
* Advanced Power Management feature set
SET_MAX security extension
* 48-bit Address feature set
* Device Configuration Overlay feature set
* Mandatory FLUSH_CACHE
* FLUSH_CACHE_EXT
* SMART error logging
* SMART self-test
* General Purpose Logging feature set
* WRITE_{DMA|MULTIPLE}_FUA_EXT
* WRITE_UNCORRECTABLE_EXT command
* Gen1 signaling speed (1.5Gb/s)
* Gen2 signaling speed (3.0Gb/s)
* Phy event counters
* Software settings preservation
* Data Set Management TRIM supported
Security:
Master password revision code = 65534
supported
not enabled
not locked
frozen
not expired: security count
supported: enhanced erase
12min for SECURITY ERASE UNIT. 12min for ENHANCED SECURITY ERASE UNIT.
Checksum: correct

http://www.kingston.com/ukroot/ssd/v_series.asp

Remélem segít valamit.

igy van mountolva: 


/dev/sda5 on / type ext4 (rw,noatime,discard,errors=remount-ro,commit=0)

netbsd forraskoddal jatszok: 


zoltan@petsy:~/netbsd$ find testsrc | wc -l
152261
zoltan@petsy:~/netbsd$ time (rm -r testsrc && /bin/sync)

real	2m34.789s
user	0m0.210s
sys	0m3.500s
zoltan@petsy:~/netbsd$

a torles alatti idoszakok: 


root@petsy:~# iostat -x 5 sda | grep sda
sda               4.65   225.59   41.08   17.59   872.96  2751.01    61.77     0.34    5.75   1.51   8.86
sda               0.00     0.00    0.00   22.40     0.00  1000.00    44.64     1.00   45.00  44.64 100.00
sda               0.00     0.00    0.00   22.00     0.00   929.60    42.25     1.00   45.45  45.45 100.00
sda               0.00     0.00    0.00   22.60     0.00   489.60    21.66     1.02   44.87  44.25 100.00
sda               0.00     0.00    0.00   22.20     0.00   756.80    34.09     1.00   45.05  45.05 100.00
sda               0.00   458.40    0.00   28.40     0.00 57918.40  2039.38     1.07   37.61  35.21 100.00
sda               0.00   437.00    0.40   47.80     8.00 73558.40  1526.27     1.25   25.89  19.05  91.80
sda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda               0.00     0.80    0.00    1.20     0.00    16.00    13.33     0.00    3.33   3.33   0.40

most a sync lefutott, es most nem lattam nagy iowaitet, ellenben az a 2 es fel perc eleg siralmas.

sync nelkul: 


zoltan@petsy:~/netbsd$ time rm -rf testsrc

real	0m3.316s
user	0m0.150s
sys	0m2.990s
zoltan@petsy:~/netbsd$

illetve mit mutat most az iostat (vege a torlesnek, ugye, de a rendszer
hasznalhatatlan): 


oot@petsy:~# iostat -x 5 sda | grep sda
sda               4.47   297.68   39.95   20.12   849.90  3911.66    79.27     0.45    7.44   1.65   9.90
sda               0.00     0.40    0.00   23.40     0.00 10075.20   430.56     1.01   43.50  42.74 100.00
sda               0.00     0.00    0.00   22.60     0.00   715.20    31.65     1.00   44.25  44.25 100.00
sda               0.00     0.00    0.00   22.80     0.00   667.20    29.26     1.00   43.60  43.86 100.00
sda               0.00    21.40    0.00   23.40     0.00  1427.20    60.99     1.02   43.68  42.74 100.00
sda               0.00     0.00    0.00   23.00     0.00   776.00    33.74     1.00   43.57  43.48 100.00
sda               0.00    21.40    0.00   23.40     0.00  1950.40    83.35     1.02   43.59  42.74 100.00
sda               0.00     0.00    0.00   23.20     0.00  2984.00   128.62     1.00   43.10  43.10 100.00
sda               0.00    21.60    0.00   23.60     0.00  2097.60    88.88     1.02   43.47  42.37 100.00
sda               0.00     0.00    0.00   23.00     0.00  2198.40    95.58     1.00   43.48  43.48 100.00

Nem tudom mi lehet a baj a TRIM-el, nekem a KINGSTON SNV425S264GB discard-al is jól működik, szóval nem általános a probléma.

Szerintem nyithatnál egy bugreportot, pontosan leírva a vasak és firmware-ek típusát, ez jól körülírható és könnyen reprodukálható probléma, esélyes hogy foglalkoznak vele, az iostat-ból azonnal látszik hogy nem PEBKAC. blktrace-el érdemes még leloggolni, hogy alacsony szinten mi történik, csatolni a bugreporthoz.

Érdemes lehet megírni a gyártónak is, simán lehet hogy megnézik.


discard		Controls whether ext4 should issue discard/TRIM
357	nodiscard(*)		commands to the underlying block device when
358				blocks are freed.  This is useful for SSD devices
359				and sparse/thinly-provisioned LUNs, but it is off
360				by default until sufficient testing has been done.

eszerint még tesztelik.
http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt

Megpróbáltam reprodukálni: 

$ uname -a
Linux goldbirke 2.6.35-27-generic #48-Ubuntu SMP Tue Feb 22 20:25:46 UTC 2011 x86_64 GNU/Linux
$ grep DESCRIPTION /etc/lsb-release 
DISTRIB_DESCRIPTION="Ubuntu 10.10"
$ sudo hdparm -i /dev/sda |grep Model
 Model=INTEL SSDSA1M160G2LE, FwRev=2CV102M3, SerialNo=CVPO102403TE160CGN

$ mount |grep ' / '
/dev/sda5 on / type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=0)
$ find testsrc |wc -l
190446
$ time ( time rm -r testsrc/ && time sync )

real	0m3.205s
user	0m0.110s
sys	0m2.700s

real	0m0.649s
user	0m0.000s
sys	0m0.010s

real	0m3.855s
user	0m0.110s
sys	0m2.710s

Közben iostat: 

$ iostat -x 5 /dev/sda |grep sda
sda               0.00     1.00    0.00    1.40     0.00    19.20    13.71     0.00    0.00   0.00   0.00
sda               0.00  4842.60    0.00   82.60     0.00 39401.60   477.02     9.34  113.05   2.28  18.80
sda               0.00     0.80    0.00    1.80     0.00    20.80    11.56     0.00    0.00   0.00   0.00

Ezután: 

$ sudo mount -o remount,discard /
$ time ( time rm -r testsrc/ && time sync )

real	0m3.422s
user	0m0.160s
sys	0m2.770s

real	0m6.989s
user	0m0.000s
sys	0m0.020s

real	0m10.411s
user	0m0.160s
sys	0m2.790s

Közben iostat: 

sda               0.00     1.00    0.00    1.60     0.00    20.80    13.00     0.00    0.00   0.00   0.00
sda               0.00  1606.80    0.00   55.20     0.00 80832.00  1464.35     2.04   36.88   2.32  12.80
sda               0.00  2405.00    0.00  542.80     0.00 816982.40  1505.13     5.37    9.90   1.81  98.20
sda               0.00   813.40    0.00  354.00     0.00 129304.00   365.27     1.92    5.43   1.49  52.80
sda               0.00     1.00    0.00    1.60     0.00    20.80    13.00     0.00    0.00   0.00   0.00

Szóval discarddal számottevően lassabb, de nem nagyságrenendekkel.

( atomheart v | 2011. 03. 16., sze – 12:30 )

subs

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

( turul16 v | 2011. 03. 17., cs – 11:59 )

SATA vezerlod milyen ?
AHCI BIOS-ban be van -e kapcsolva ?

latancytop mutat -e valami erdekeset az akcio kozben ?

firmware frissitesen gondolkoztal -e ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( bambano | 2011. 03. 17., cs – 12:23 )

hagy offoljak egy kicsit: a múltkori kérdésemre is egy csomó ssd jött válaszul. Ha van elég ramod, miért nem jobb a block cache, mint az ssd?

( ang | 2011. 03. 17., cs – 17:54 )

https://wiki.archlinux.org/index.php/SSD#Tips_for_Maximizing_SSD_Perfor…

nem mind1 mivel keszul a particio ... Information: Moved requested sector from 34 to 2048 in order to align on 2048-sector boundaries.

Gyanitom nalad ez lehet a hiba oka... de lehet mas is ;P

ocz vertex v2 60gb ssd-vel ezt a leirast kovetve, gdiskel gpt particionalva, rendes kernel driverekkel (lspci -v), ext4 fs-t, hozza tune2fs -o discard /dev/sdXN , noatime mountopcioval, phenom procival elhanyagolhato cpu loaddal parhuzamosan hajtottam ki a 2x256mb/s atvitelt (ket ures ssd-vel, ha megtelik 70%-ra, leesik 180mb/s korulre ez a tipus)

( tompos v | 2011. 03. 18., p – 11:20 )

Nos, most belefutottam egy hasonlo problemaba en is.

Model Number: PQI SSD 32GB

CentOS 5.4-gyel minden problema nelkul mukodott. Most Ubuntu 10.04 van rajta es nagy load alatt (backup szerver rendszer HDD-je) beall, mint a szog. Backports-bol felrakott Maverick-es kernellel ugyanez, nems zamit, hogy van discard vagy nincs.

A gepen backuppc fut. Ha kiadok egy sync-et, akkor all a vegtelensegig. Ha leallitom a backuppc job-okat, akkor egy ido utan visszakpom a promptot, es utana mar gyors is a sync. Viszont ha dpkg-val csomagot telepitek, akkor az ugy beall, hogy mar nem szamit, hogy utana 0 lett a load.

A backuppc egyebkent egy teljesen kulon raid tombre dolgozik, es amugy nem csinal kulonosen nagy forgalmat, meg csupan az initial mentesek futnak, csak a load nagy.

Otlet?

10x

t