Сравниваем вот такие диски То что под цитатой - это OWC Mercury Extreme Pro SSD c sandforce 1200 Ну и Kingstone и, по-моему, jmicron (kingstone не признаются что именно) Тесты без FS OWC # seeker /dev/sdd1 128 180 Seeker v3.0+Fedora, 2009-06-17, http://www.linuxinsight.com/how_fast_is_your_disk.html Benchmarking /dev/sdd1 [78156162 blocks, 40015954944 bytes, 37 GB, 38162 MB, 40 GiB, 40015 MiB] [512 logical sector size, 512 physical sector size] [128 threads] Wait 180 seconds.................................................................................................................................................................................... Results: 4775 seeks/second, 0.209 ms random access time (56320 < offsets < 40015925760) Kingstone # seeker /dev/sdd1 128 180 Seeker v3.0+Fedora, 2009-06-17, http://www.linuxinsight.com/how_fast_is_your_disk.html Benchmarking /dev/sdd1 [125043376 blocks, 64022208512 bytes, 59 GB, 61056 MB, 64 GiB, 64022 MiB] [512 logical sector size, 512 physical sector size] [128 threads] Wait 180 seconds.................................................................................................................................................................................... Results: 3729 seeks/second, 0.268 ms random access time (103424 < offsets < 64022127616) У sandforce производительность выше, время доступа меньше Далее тесты с FS FS в обеих тестах - ext4 without journal По OWC есть тесты с разными FS, но тут отсутствуют Указанная в linux оказалась самой производительной AT> Резюме по SSD с контроллером sandforce AT> Они применимы для серверов AT> Деградации производительности, как у AT> дешевых(пользовательских) SSD не наблюдается Они применимы для серверов Деградации производительности, как у дешевых(пользовательских) SSD не наблюдается НО !!! производительность В РАЗЫ хуже чем у sandforce это при том, что я на kingstone специально форматировал FS с предложенным blocksize 4k - mkfs.ext4 -b 4096 -m0 -i 32768 -T ext4ssd /dev/sdd1 Тип ext4ssd - это ext4 с отключенным журналом # dbench -D /mnt/2 128; tiobench --numruns 3 --dir /mnt/2 --threads 1; tiobench --numruns 3 --dir /mnt/2 --threads 8; tiobench --numruns 3 --dir /mnt/2 --threads 32; tiobench --numruns 3 --dir /mnt/2 --threads 128; tiobench --block 16384 --numruns 3 --dir /mnt/2 --threads 128 Operation Count AvgLat MaxLat ---------------------------------------- NTCreateX 1718720 0.175 1143.580 Close 1261840 0.011 48.071 Rename 72741 2.273 2227.605 Unlink 347536 3.895 2410.606 Qpathinfo 1556345 0.144 1442.756 Qfileinfo 271069 0.005 35.046 Qfsinfo 285580 0.062 52.894 Sfileinfo 139906 0.047 34.169 Find 601606 0.230 836.155 WriteX 847619 82.341 22907.235 ReadX 2693276 0.078 391.332 LockX 5584 0.011 1.608 UnlockX 5584 0.011 4.148 Flush 120366 38.947 2365.874 Throughput 89.134 MB/sec 128 clients 128 procs max_latency=22907.241 ms AT> Operation Count AvgLat MaxLat AT> ---------------------------------------- AT> NTCreateX 6575096 1.219 553.789 AT> Close 4827860 0.092 404.058 AT> Rename 278698 1.790 468.432 AT> Unlink 1329055 2.243 469.951 AT> Qpathinfo 5964493 0.662 518.153 AT> Qfileinfo 1039820 0.032 255.713 AT> Qfsinfo 1093201 0.466 374.434 AT> Sfileinfo 535934 0.230 339.968 AT> Find 2304503 1.656 569.721 AT> WriteX 3248878 12.463 3825.347 AT> ReadX 10316311 0.097 473.059 AT> LockX 21440 0.020 54.085 AT> UnlockX 21440 0.024 51.432 AT> Flush 460886 27.229 506.487 AT> Throughput 341.39 MB/sec 128 clients 128 procs max_latency=3825.354 ms Этот тест просто убивает. Правда на ЭТОЙ FS при тестировании sandforce мой комп стал "похрюкивать" при произгывании музыки, на kingstone процессор был загружен тоже достаточно плотно, но комп отзывался вполне на уровне И, кстати, параллельно весящий в обеих случаях iostat -k 1 для OWC показывал ~4k tps с пиками до 5-ти, а для kingstone около 800 с пиками до 1.6k, тоже показатель No size specified, using 2000 MB Run #3: /usr/bin/tiotest -t 1 -f 2000 -r 4000 -b 4096 -d /mnt/2 -T Unit information ================ File size = megabytes Blk Size = bytes Rate = megabytes per second CPU% = percentage of CPU used during the test Latency = milliseconds Lat% = percent of requests that took longer than X seconds CPU Eff = Rate divided by CPU% - throughput per cpu load Sequential Reads 2.6.36-1.fc15.i686 2000 4096 1 137.28 38.75% 0.083 17.96 0.00000 0.00000 354 Random Reads 2.6.36-1.fc15.i686 2000 4096 1 10.89 11.91% 1.068 8.09 0.00000 0.00000 91 Sequential Writes 2.6.36-1.fc15.i686 2000 4096 1 45.82 15.42% 0.249 4380.25 0.00000 0.00000 297 Random Writes 2.6.36-1.fc15.i686 2000 4096 1 10.92 9.243% 0.031 0.18 0.00000 0.00000 118 AT> No size specified, using 2000 MB AT> Run #3: /usr/bin/tiotest -t 1 -f 2000 -r 4000 -b 4096 -d /mnt/2 -T AT> Unit information AT> ================ AT> File size = megabytes AT> Blk Size = bytes AT> Rate = megabytes per second AT> CPU% = percentage of CPU used during the test AT> Latency = milliseconds AT> Lat% = percent of requests that took longer than X seconds AT> CPU Eff = Rate divided by CPU% - throughput per cpu load AT> Sequential Reads AT> 2.6.36-0.34.rc6.git3.fc15.i6 2000 4096 1 185.74 39.06% 0.061 21.48 0.00000 0.00000 475 AT> Random Reads AT> 2.6.36-0.34.rc6.git3.fc15.i6 2000 4096 1 30.56 14.86% 0.376 3.25 0.00000 0.00000 206 AT> Sequential Writes AT> 2.6.36-0.34.rc6.git3.fc15.i6 2000 4096 1 186.13 55.86% 0.057 779.63 0.00000 0.00000 333 AT> Random Writes AT> 2.6.36-0.34.rc6.git3.fc15.i6 2000 4096 1 16.58 12.62% 0.023 0.10 0.00000 0.00000 131 Чтение запись в один поток. Kingston проигрывает по всем показателям, особенно по непрерывной записи (правда на сервер это скорее редкость) No size specified, using 2000 MB Run #3: /usr/bin/tiotest -t 8 -f 250 -r 500 -b 4096 -d /mnt/2 -T Unit information ================ File size = megabytes Blk Size = bytes Rate = megabytes per second CPU% = percentage of CPU used during the test Latency = milliseconds Lat% = percent of requests that took longer than X seconds CPU Eff = Rate divided by CPU% - throughput per cpu load Sequential Reads 2.6.36-1.fc15.i686 2000 4096 8 116.83 182.8% 0.713 1300.18 0.00000 0.00000 64 Random Reads 2.6.36-1.fc15.i686 2000 4096 8 12.28 96.40% 6.297 606.12 0.00000 0.00000 13 Sequential Writes 2.6.36-1.fc15.i686 2000 4096 8 32.53 98.16% 2.714 16487.44 0.04922 0.00000 33 Random Writes 2.6.36-1.fc15.i686 2000 4096 8 6.44 33.15% 0.059 24.08 0.00000 0.00000 19 AT> No size specified, using 2000 MB AT> Run #3: /usr/bin/tiotest -t 8 -f 250 -r 500 -b 4096 -d /mnt/2 -T AT> Unit information AT> ================ AT> File size = megabytes AT> Blk Size = bytes AT> Rate = megabytes per second AT> CPU% = percentage of CPU used during the test AT> Latency = milliseconds AT> Lat% = percent of requests that took longer than X seconds AT> CPU Eff = Rate divided by CPU% - throughput per cpu load AT> Sequential Reads AT> 2.6.36-0.34.rc6.git3.fc15.i6 2000 4096 8 183.70 234.3% 0.488 1283.50 0.00000 0.00000 78 AT> Random Reads AT> 2.6.36-0.34.rc6.git3.fc15.i6 2000 4096 8 35.77 158.9% 2.128 261.58 0.00000 0.00000 23 AT> Sequential Writes AT> 2.6.36-0.34.rc6.git3.fc15.i6 2000 4096 8 189.72 521.3% 0.437 3192.64 0.00000 0.00000 36 AT> Random Writes AT> 2.6.36-0.34.rc6.git3.fc15.i6 2000 4096 8 15.59 97.90% 0.047 24.28 0.00000 0.00000 16 У sandforce каналов явно больше. На 8-ми потоках практически отсутствует деградация производительность. Kingston опять не порадовал, особенно запись No size specified, using 2000 MB Run #3: /usr/bin/tiotest -t 32 -f 62 -r 125 -b 4096 -d /mnt/2 -T Unit information ================ File size = megabytes Blk Size = bytes Rate = megabytes per second CPU% = percentage of CPU used during the test Latency = milliseconds Lat% = percent of requests that took longer than X seconds CPU Eff = Rate divided by CPU% - throughput per cpu load Sequential Reads 2.6.36-1.fc15.i686 2000 4096 32 113.55 764.2% 2.865 3219.01 0.00000 0.00000 15 Random Reads 2.6.36-1.fc15.i686 2000 4096 32 12.22 229.2% 22.770 1861.47 0.00000 0.00000 5 Sequential Writes 2.6.36-1.fc15.i686 2000 4096 32 21.91 252.2% 14.825 57511.08 0.26028 0.02422 9 Random Writes 2.6.36-1.fc15.i686 2000 4096 32 7.22 119.8% 0.060 38.68 0.00000 0.00000 6 AT> No size specified, using 2000 MB AT> Run #3: /usr/bin/tiotest -t 32 -f 62 -r 125 -b 4096 -d /mnt/2 -T AT> Unit information AT> ================ AT> File size = megabytes AT> Blk Size = bytes AT> Rate = megabytes per second AT> CPU% = percentage of CPU used during the test AT> Latency = milliseconds AT> Lat% = percent of requests that took longer than X seconds AT> CPU Eff = Rate divided by CPU% - throughput per cpu load AT> Sequential Reads AT> 2.6.36-0.34.rc6.git3.fc15.i6 2000 4096 32 194.31 925.1% 1.687 3179.25 0.00000 0.00000 21 AT> Random Reads AT> 2.6.36-0.34.rc6.git3.fc15.i6 2000 4096 32 36.41 292.9% 6.292 1045.39 0.00000 0.00000 12 AT> Sequential Writes AT> 2.6.36-0.34.rc6.git3.fc15.i6 2000 4096 32 185.29 2048.% 1.664 8627.27 0.00395 0.00000 9 AT> Random Writes AT> 2.6.36-0.34.rc6.git3.fc15.i6 2000 4096 32 13.06 314.4% 0.051 41.95 0.00000 0.00000 4 No size specified, using 2000 MB Run #3: /usr/bin/tiotest -t 128 -f 15 -r 31 -b 4096 -d /mnt/2 -T Unit information ================ File size = megabytes Blk Size = bytes Rate = megabytes per second CPU% = percentage of CPU used during the test Latency = milliseconds Lat% = percent of requests that took longer than X seconds CPU Eff = Rate divided by CPU% - throughput per cpu load Sequential Reads 2.6.36-1.fc15.i686 2000 4096 128 90.60 2210.% 13.109 16256.86 0.05412 0.00000 4 Random Reads 2.6.36-1.fc15.i686 2000 4096 128 11.78 478.3% 77.988 3264.03 0.00000 0.00000 2 Sequential Writes 2.6.36-1.fc15.i686 2000 4096 128 18.44 794.8% 55.296 233249.28 0.52165 0.15035 2 Random Writes 2.6.36-1.fc15.i686 2000 4096 128 5.56 294.9% 0.348 1230.47 0.00000 0.00000 2 AT> No size specified, using 2000 MB AT> Run #3: /usr/bin/tiotest -t 128 -f 15 -r 31 -b 4096 -d /mnt/2 -T AT> Unit information AT> ================ AT> File size = megabytes AT> Blk Size = bytes AT> Rate = megabytes per second AT> CPU% = percentage of CPU used during the test AT> Latency = milliseconds AT> Lat% = percent of requests that took longer than X seconds AT> CPU Eff = Rate divided by CPU% - throughput per cpu load AT> Sequential Reads AT> 2.6.36-0.34.rc6.git3.fc15.i6 2000 4096 128 212.64 2386.% 4.188 20913.51 0.02828 0.00000 9 AT> Random Reads AT> 2.6.36-0.34.rc6.git3.fc15.i6 2000 4096 128 37.38 915.3% 19.787 1098.53 0.00000 0.00000 4 AT> Sequential Writes AT> 2.6.36-0.34.rc6.git3.fc15.i6 2000 4096 128 174.50 6801.% 5.716 28443.94 0.07202 0.00000 3 AT> Random Writes AT> 2.6.36-0.34.rc6.git3.fc15.i6 2000 4096 128 14.87 1054.% 0.036 17.33 0.00000 0.00000 1 вот вышеуказанные тесты - это уже похоже на сервер - 128 потоков, и сновая на случайном чтении записи kingston сильно проигрывает No size specified, using 2000 MB Run #3: /usr/bin/tiotest -t 128 -f 15 -r 31 -b 16384 -d /mnt/2 -T Unit information ================ File size = megabytes Blk Size = bytes Rate = megabytes per second CPU% = percentage of CPU used during the test Latency = milliseconds Lat% = percent of requests that took longer than X seconds CPU Eff = Rate divided by CPU% - throughput per cpu load Sequential Reads 2.6.36-1.fc15.i686 2000 16384 128 71.91 1455.% 68.286 23691.20 0.39795 0.00000 5 Random Reads 2.6.36-1.fc15.i686 2000 16384 128 37.33 438.6% 89.256 4588.92 0.00000 0.00000 9 Sequential Writes 2.6.36-1.fc15.i686 2000 16384 128 17.01 546.8% 232.219 252841.60 1.84000 0.69417 3 Random Writes 2.6.36-1.fc15.i686 2000 16384 128 11.21 600.2% 0.732 2392.62 0.02520 0.00000 2 AT> No size specified, using 2000 MB AT> Run #3: /usr/bin/tiotest -t 128 -f 15 -r 31 -b 16384 -d /mnt/2 -T AT> Unit information AT> ================ AT> File size = megabytes AT> Blk Size = bytes AT> Rate = megabytes per second AT> CPU% = percentage of CPU used during the test AT> Latency = milliseconds AT> Lat% = percent of requests that took longer than X seconds AT> CPU Eff = Rate divided by CPU% - throughput per cpu load AT> Sequential Reads AT> 2.6.36-0.34.rc6.git3.fc15.i6 2000 16384 128 244.19 1982.% 13.474 20661.02 0.11231 0.00000 12 AT> Random Reads AT> 2.6.36-0.34.rc6.git3.fc15.i6 2000 16384 128 128.91 777.1% 19.972 1327.90 0.00000 0.00000 17 AT> Sequential Writes AT> 2.6.36-0.34.rc6.git3.fc15.i6 2000 16384 128 177.49 5378.% 22.371 26251.02 0.28971 0.00000 3 AT> Random Writes AT> 2.6.36-0.34.rc6.git3.fc15.i6 2000 16384 128 42.89 1818.% 0.114 55.21 0.00000 0.00000 2 В результате, в ssd с mlc, но разными контроллерами Да, наверное есть проблемы у sandforce, но ни в тестах, ни в реальной (уже 2 недели) эксплуатации я пока на них не нарвался Kingston (наверное, аналогично и Intel) в принципе в сервера можно ставить, но рост производительности далеко не такой как у sandforce Но, в принципе, таких проблем, как у меня с Model Number: TS128GSSD25S-M, когда при записи замирает комп у него нету В принципе, для рабочих машин kingston достаточно не плохое решение, чтение у него вполне себе вменяемо работает, а вот запись к сожалению подкачала -- Best regard, Aleksander Trotsai aka MAGE-RIPE aka MAGE-UANIC My PGP key at ftp://blackhole.adamant.ua/pgp/trotsai.key[.asc] "Одномерный массив" - это предистория "Матрицы"?
И, кстати, после теста решил обнулить диск, так сказать вернуть чистым dd if=/dev/zero of=/dev/sdd bs=4096 count=`expr 62521688 / 4` Условия записи - идеальные Последовательная запись из памяти Так вот скорость колеблется между 130 и 140 MB/s, а аж никак не 170 -- Best regard, Aleksander Trotsai aka MAGE-RIPE aka MAGE-UANIC My PGP key at ftp://blackhole.adamant.ua/pgp/trotsai.key[.asc] Можно прожить жизнь за один день. Hо что тогда делать с оставшимся временем?
On Tue, Nov 02, 2010 at 11:30:39AM +0200, Alexander Trotsai wrote: AT> Так вот скорость колеблется между 130 и 140 MB/s, а аж никак AT> не 170 Забыл что в конце dd статистику дает вот ее скопировано 64022208512 байт (64 GB), 479,504 c, 134 MB/c -- Best regard, Aleksander Trotsai aka MAGE-RIPE aka MAGE-UANIC My PGP key at ftp://blackhole.adamant.ua/pgp/trotsai.key[.asc] Пyсть тебе пpиснится какой-нибyдь ip-пакетик покpасивше
Алик, а ты подумай чтобы обобщить как-то эти результаты в виде коротких рекомендаций - тип нагрузки - тип FS - какой SSD лучше под эту комбинацию - как правильно готовить кошку и в виде некой статейки или howto опубликовать? Сотни людей спасибо скажут. Заранее признателен, я :)
On Tue, Nov 02, 2010 at 11:13:10AM +0200, Alexander Trotsai wrote:
Сравниваем вот такие диски НО !!! производительность В РАЗЫ хуже чем у sandforce это при том, что я на kingstone специально форматировал FS с предложенным blocksize 4k - mkfs.ext4 -b 4096 -m0 -i 32768 -T ext4ssd /dev/sdd1
А раздел - выровнен по 4К ? Обычно - нет. Без такого - падение в раза 2... (вин7 - пропускает 1М) И ещё немного не верится, что страница в MLC=4KB... а не 8/16/32... -- Best regards, Paul Arakelyan.
On Tue, Nov 02, 2010 at 11:30:39AM +0200, Alexander Trotsai wrote:
И, кстати, после теста решил обнулить диск, так сказать вернуть чистым dd if=/dev/zero of=/dev/sdd bs=4096 count=`expr 62521688 / 4` Условия записи - идеальные Последовательная запись из памяти Так вот скорость колеблется между 130 и 140 MB/s, а аж никак не 170 Нифига не идеальные, TRIM'а небыло = оно заткнётся после исчерпания "запасной" памяти (допустим, 2-8ГБ), если не сразу совсем. И блоки по 64К - интереснее для "идеальности".
-- Best regards, Paul Arakelyan.
On Wed, Nov 03, 2010 at 02:31:02AM +0200, Paul Arakelyan wrote: PA> On Tue, Nov 02, 2010 at 11:30:39AM +0200, Alexander Trotsai wrote: PA> > И, кстати, после теста решил обнулить диск, так сказать PA> > вернуть чистым PA> > dd if=/dev/zero of=/dev/sdd bs=4096 count=`expr 62521688 / 4` PA> > Условия записи - идеальные PA> > Последовательная запись из памяти PA> > Так вот скорость колеблется между 130 и 140 MB/s, а аж никак PA> > не 170 PA> Нифига не идеальные, TRIM'а небыло = оно заткнётся после исчерпания PA> "запасной" памяти (допустим, 2-8ГБ), если не сразу совсем. И блоки PA> по 64К - интереснее для "идеальности". Момент интересный Пошут что linux kernel >= 2.6.30 TRIM поддерживает Как проверить - х/з Кстати, по iostat скорость записи на протяжении процесса была равномерная ps. и вообще, у тебя практически такой же - вот и проверишь :) -- Best regard, Aleksander Trotsai aka MAGE-RIPE aka MAGE-UANIC My PGP key at ftp://blackhole.adamant.ua/pgp/trotsai.key[.asc] Нет, я не хакер, просто плохо спал...
On Wed, Nov 03, 2010 at 02:19:13AM +0200, Paul Arakelyan wrote: PA> On Tue, Nov 02, 2010 at 11:13:10AM +0200, Alexander Trotsai wrote: PA> > Сравниваем вот такие диски PA> > НО !!! производительность В РАЗЫ хуже чем у sandforce PA> > это при том, что я на kingstone специально форматировал FS с PA> > предложенным blocksize 4k - PA> > mkfs.ext4 -b 4096 -m0 -i 32768 -T ext4ssd /dev/sdd1 PA> А раздел - выровнен по 4К ? Обычно - нет. Без такого - падение в раза 2... PA> (вин7 - пропускает 1М) linux fdisk первым сектором ставить 2048 (тот же 1M) PA> И ещё немного не верится, что страница в MLC=4KB... а не 8/16/32... Технарь kingston сказал ps. чтоб 2 раза не писать TRIM в linux с 2.6.28 http://www.ibm.com/developerworks/linux/library/l-kernel-advances/index.html -- Best regard, Aleksander Trotsai aka MAGE-RIPE aka MAGE-UANIC My PGP key at ftp://blackhole.adamant.ua/pgp/trotsai.key[.asc] Мечта настоящего программиста - запрограммировать процесс программирования.
On Wed, Nov 03, 2010 at 09:26:13AM +0200, Alexander Trotsai wrote:
On Wed, Nov 03, 2010 at 02:31:02AM +0200, Paul Arakelyan wrote: PA> On Tue, Nov 02, 2010 at 11:30:39AM +0200, Alexander Trotsai wrote: PA> > И, кстати, после теста решил обнулить диск, так сказать PA> > вернуть чистым PA> > dd if=/dev/zero of=/dev/sdd bs=4096 count=`expr 62521688 / 4` PA> > Условия записи - идеальные PA> > Последовательная запись из памяти PA> > Так вот скорость колеблется между 130 и 140 MB/s, а аж никак PA> > не 170 PA> Нифига не идеальные, TRIM'а небыло = оно заткнётся после исчерпания PA> "запасной" памяти (допустим, 2-8ГБ), если не сразу совсем. И блоки PA> по 64К - интереснее для "идеальности".
Момент интересный Пошут что linux kernel >= 2.6.30 TRIM поддерживает TRIM, по идее, работает только если есть file system, куча файлов и эти файлы удалят - пойдёт пачка TRIM-запросов.
ps. и вообще, у тебя практически такой же - вот и проверишь "Айн гроссе тест ин дер прогресс", но в целом - вылезли очевидные косяки имени ZFS и не очень правильных рекомендаций, типа "для mysql database - set recordsize=4K compression=on). Без сжатия, кстати - фиг :(, нужно раза в 2-3 больше места="бабла немеряно".
Как вам скорости записи: 4МБ/с и 6,5МБ/с? (синхронизация зеркала) В идеальных и изменённых условиях - 66МБ/с и где-то раза в 3 меньше. (угадайте, где кто :) в каждом случае). -- Best regards, Paul Arakelyan.
Поглядел я тут интеловским тулбоксом на свои (и не очень) SSD (не все :) ). 80ГБ X-25M - наработка 8500 часов, записано 9,5ТБ, "жить осталось" 92% 80ГБ X-25M - 208 часов, 3ТБ, 98% (стоит в не моём ноуте) 40ГБ X-25V - 2426 часов, 470ГБ, 99% (домашний десктоп, ram drive помогает) 40ГБ X-25V - ~350часов, 3,5ТБ, 97% ("спул постфикса" с недоставляемым, гигов 10-15, UFS2, неделя - "таки да, за год можно убить"). Ещё один X-25M (по идее похож на первый, только ремапов больше) - не смотрел. Влияние "secure erase" (такая хрень, за пару минут сносит нафиг всё, стрёмный момент - "ATA security is enabled, disconnect and reconnect power to the drive, пока тулбокс запущен - страшновато немного было) на скорость записи. синхронизация "идеализированного" зеркала, ~38ГБ X-25M(w/o erase) -> kingston SNVP325 (128ГБ): 10-11min SNVP325 -> X-25M (w/o erase): 30-33min X-25M (w/o erase) -> X25M (erased): 18 min X-25M (erased) -> X-25M(w/o erase): 28 min Итого, видим некоторое влияние скорости чтения с кингстона SNVP325 -- Best regards, Paul Arakelyan.
Не мое Но познавательно и дает пищу для размышлений http://www.thg.ru/storage/ssd_17_2010/index.html On Tue, Nov 02, 2010 at 12:35:49PM +0200, Andrew Stesin wrote: AS> Алик, а ты подумай чтобы обобщить как-то эти результаты в виде AS> коротких рекомендаций AS> - тип нагрузки AS> - тип FS AS> - какой SSD лучше под эту комбинацию AS> - как правильно готовить кошку AS> и в виде некой статейки или howto опубликовать? AS> Сотни людей спасибо скажут. AS> Заранее признателен, AS> я :) -- Best regard, Aleksander Trotsai aka MAGE-RIPE aka MAGE-UANIC My PGP key at ftp://blackhole.adamant.ua/pgp/trotsai.key[.asc] Ты что молчишь, клавиатуру проглотил что ли?
On Fri, Dec 03, 2010 at 10:52:56AM +0200, Alexander Trotsai wrote:
On Tue, Nov 02, 2010 at 12:35:49PM +0200, Andrew Stesin wrote: AS> Алик, а ты подумай чтобы обобщить как-то эти результаты в виде AS> коротких рекомендаций
AS> - тип нагрузки Нагрузка должна быть "предсказуемой" и неплохо отслеживать "предсказанное" и реальность.
AS> - тип FS Может быть любая, но она должна обеспечивать ввод-вывод 4КБ выровненными блоками - а это "хрен вам". ZFS - патчить нужно (и "ничаво харошева из этава ни будит", если сжатие использовать). Иначе - тормоза во всём, только у интела они меньше :). А ещё есть "страница" - например 512К у интела - это минимальный объём флэша, кторый стирают. Итого в идеале блоки лучше по 512К :).
AS> - какой SSD лучше под эту комбинацию Всё "не так просто, как кажется". Я более-менее определился, хотя не тестил, что, например, для ZFS со сжатием противопоказаны на sandforce, в то же время для чего-то "хорошо-сжимаемого" это должно быть "в самый раз" - аппаратная компрессия увеличит время жизни диска в разы. Весь i/o для всех SSD желательно выравнивать и производить кусками по 4КБ - для каких-то это более нужно, чем для других (например, кингстон snvp325 vs intel Gen.2 - разница в скорости записи может достигать 1,5-2 раз в пользу интела при невыровненном вводе-выводе и порой в 2+ раз в пользу кингстона при выровненном).
Если нагрузка типа "что-то пишем" - то крайне нежелательно там (на диске) иметь вагон статичного контента - иначе wear leveling хрена нормально работать будет и износ будет "интересный" - т.е. будут писаться только "свободные" блоки+ "запасные" блоки. При более-менее равномерном износе на intel G2 80GB можно записать порядка 90-120ТБ. Для X-25V 40GB - где-то в 2 раза меньше.
AS> - как правильно готовить кошку Херово она готовится. А "правильная кошка" - X-25E - стоит улётно. Хреновость состоит в том, что без поддержки TRIM в ОС+накопителе - скорость записи таки неслабо проседает (у X-25M G2 после 11ТБ - раза в 1,5, а вот X-25V (с лейбой кингстон) после 3ТБ "ещё заметнее"). В итоге я пришёл к штатной процедуре - вытащить диск из зеркала, "secure erase" (страха - полные штаны. "отключите и подключите питание диска, пока intel SSD toolbox загружен"), вставить обратно и перелить файлы БД по-новой - заодно их ZFS пережмёт и "дефрагментирует".
AS> и в виде некой статейки или howto опубликовать? Принципы работы вроде как всюду разжёваны, далее остаются лишь "личный опыт" и "конкретные случаи". Т.е. если чел с головой дружит - то вполне может принять решение "а надо ли здесь ОНО?" и постараться оптимизировать свой случай для оптимального использования "чуда техники".
Для "тупо бездумно втулить" - ставим Win7 на девайс и радуемся :). Для "вдумчиво втулить" - смотрим на народ с advanced format дисками, и делаем то же самое (или не делаем... Мне, вот их "4КБ патч для ZFS" влетел в либо охрененные потери места на диске, либо в необходимость увеличения recordsize до 64КБ, чтоб соотношение 1:16 между blocksize:recordsize было, т.к. у меня сжатие 2,9:1 - с патчем оно легко превращалось в 2:1 - т.е. 30% места на диске тю-тю). -- Best regards, Paul Arakelyan.
On Fri, Dec 03, 2010 at 10:52:56AM +0200, Alexander Trotsai wrote:
Не мое Но познавательно и дает пищу для размышлений
Аффтар забыл и забил на "write amplification", если не сказать "не знал" - стирание происходит страницами по куче блоков, а не блоками по 4КБ. http://www.thg.ru/storage/ssd_17_2010/ssd_17_2010-04.html "used" - оч. по разному юзать можно, и засимулировать такое быстро - невозможно. Поэтому сей анализ в статье немного оптимистичный, если не сказать "в корне ошибочный" - хотя минимальные значения вполне можно считать за средние в реальной жизни (если TRIM нету). TRIM очень неудобно тем, что восстановить данные, "случайно грохнутые вот токо шо" - невозможно. -- Best regards, Paul Arakelyan.
participants (3)
-
Alexander Trotsai -
Andrew Stesin -
Paul Arakelyan