very strange IO issue with FreeBSD 8 and SSD

Jeremy Chadwick freebsd at jdc.parodius.com
Tue May 3 04:17:21 UTC 2011


On Mon, May 02, 2011 at 08:53:00PM -0700, Jan Koum wrote:
> On Mon, May 2, 2011 at 8:26 PM, Adam Vande More <amvandemore at gmail.com>wrote:
> 
> > On Mon, May 2, 2011 at 6:36 PM, Jeremy Chadwick <freebsd at jdc.parodius.com>wrote:
> >
> >> You might also try comparing iostat output to gstat output, though gstat
> >> refreshes the screen continually making this a little difficult.
> >>
> >
> > gstat -b
> >
> 
> 
> sure:
> 
> $ sudo gstat -b
> dT: 1.007s  w: 1.000s
>  L(q)  ops/s    r/s   kBps   ms/r    w/s   kBps   ms/w   %busy Name
>     0    605     33    137    0.4    572   4349   34.7   10.9  ad4
>     0    605     33    137    0.4    572   4349   35.8   10.9  ad4s1
>     0    620     25    149    1.0    595   4280   22.2    9.9  ad5
>     0    605     33    137    0.4    572   4349   36.5   11.0  ad4s1a
>     0      0      0      0    0.0      0      0    0.0    0.0  ad4s1b
>     0     60     18     60    1.1     42    169    2.5    3.6  ad6
>     0    817     30    121    0.2    787   5382   15.9    8.1  ad7
>     0    620     25    149    1.1    595   4280   23.1   10.0  ad5a
>     0     60     18     60    1.1     42    169    2.6    3.7  ad6a
>     0    817     30    121    0.2    787   5382   16.5    8.1  ad7a

To emulate "iostat 1", you will need to run this from inside of a while
loop via the shell.  E.g. in sh or bash:

while true; do gstat -b; sleep 1; done

I believe your concern point that started the thread was that
4MBytes/sec was considered bad performance.  There are indications from
your iostat output that occasionally the writes are buffered and come in
"in a burst" at 10-11MByte/sec, but your overall average is around
4-5MByte/sec.

You can test your disk I/O by simply dd'ing directly to a file on one of
the filesystems, e.g.

cd /place/where/ad5a/is/mounted
dd if=/dev/zero of=test.bin bs=64k

You can change bs to whatever value you'd like (larger or smaller), but
I tend to stick to 64k (64KBytes).  ^C when you're finished, and you'll
see overall I/O statistics.  You can run the gstat loop or iostat at the
same time if you wish.

Here's an example:

icarus# dd if=/dev/zero of=test.bin bs=64k
^C4401+0 records in
4400+0 records out
288358400 bytes transferred in 6.575845 secs (43851155 bytes/sec)

Another window running "iostat -x ada0 1":

                        extended device statistics
device     r/s   w/s    kr/s    kw/s wait svc_t  %b
ada0       0.0   0.0     0.0     0.0    0   0.0   0
                        extended device statistics
device     r/s   w/s    kr/s    kw/s wait svc_t  %b
ada0       0.0   0.0     0.0     0.0    0   0.0   0
                        extended device statistics
device     r/s   w/s    kr/s    kw/s wait svc_t  %b
ada0       0.0  61.9     0.0  7924.2    8  19.2  18
                        extended device statistics
device     r/s   w/s    kr/s    kw/s wait svc_t  %b
ada0       1.0 334.8    15.9 42790.8    8  19.8 100
                        extended device statistics
device     r/s   w/s    kr/s    kw/s wait svc_t  %b
ada0       1.0 338.5    15.9 43102.6    7  19.7 100
                        extended device statistics
device     r/s   w/s    kr/s    kw/s wait svc_t  %b
ada0       2.0 335.2    31.8 42900.5    8  19.7 100
                        extended device statistics
device     r/s   w/s    kr/s    kw/s wait svc_t  %b
ada0       1.0 336.3    15.9 43047.9    5  20.3 100
                        extended device statistics
device     r/s   w/s    kr/s    kw/s wait svc_t  %b
ada0       1.0 331.7    15.8 42455.8    6  20.3 100
                        extended device statistics
device     r/s   w/s    kr/s    kw/s wait svc_t  %b
ada0       2.0 366.2    31.8 42638.6    8  21.0 100
                        extended device statistics
device     r/s   w/s    kr/s    kw/s wait svc_t  %b
ada0       0.0 125.7     0.0 15836.6    0  20.6  37
                        extended device statistics
device     r/s   w/s    kr/s    kw/s wait svc_t  %b
ada0       0.0   0.0     0.0     0.0    0   0.0   0
^C

Controller and disk details:

ahci0: <Intel ICH9 AHCI SATA controller> port 0x1c50-0x1c57,0x1c44-0x1c47,0x1c48-0x1c4f,0x1c40-0x1c43,0x18e0-0x18ff mem 0xdc000800-0xdc000fff irq 17 at device 31.2 on pci0
ahci0: [ITHREAD]
ahci0: AHCI v1.20 with 6 3Gbps ports, Port Multiplier supported

ahcich0: <AHCI channel> at channel 0 on ahci0
ahcich0: [ITHREAD]

ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: <INTEL SSDSA2M040G2GC 2CV102M3> ATA-7 SATA 2.x device
ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 38166MB (78165360 512 byte sectors: 16H 63S/T 16383C)

# camcontrol identify ada0
pass0: <INTEL SSDSA2M040G2GC 2CV102M3> ATA-7 SATA 2.x device
pass0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)

protocol              ATA/ATAPI-7 SATA 2.x
device model          INTEL SSDSA2M040G2GC
firmware revision     2CV102M3
serial number         XXX
WWN                   XXX
cylinders             16383
heads                 16
sectors/track         63
sector size           logical 512, physical 512, offset 0
LBA supported         78165360 sectors
LBA48 supported       78165360 sectors
PIO supported         PIO4
DMA supported         WDMA2 UDMA6
media RPM             non-rotating

Feature                      Support  Enabled   Value           Vendor
read ahead                     yes      yes
write cache                    yes      yes
flush cache                    yes      yes
overlap                        no
Tagged Command Queuing (TCQ)   no       no
Native Command Queuing (NCQ)   yes              32 tags
SMART                          yes      yes
microcode download             yes      yes
security                       yes      no
power management               yes      yes
advanced power management      no       no
automatic acoustic management  no       no
media status notification      no       no
power-up in Standby            no       no
write-read-verify              no       no
unload                         yes      yes
free-fall                      no       no
data set management (TRIM)     yes

I can safely say the conversation is going to immediately turn to "how
does your application work?", including people asking for full source
code and so on.  Unless I misunderstand, that's effectively what you're
asking: "why does our application perform so badly on these SSDs?"

-- 
| Jeremy Chadwick                                   jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.               PGP 4BD6C0CB |



More information about the freebsd-fs mailing list