SSD рулят

lexa - 20/Окт/2009 23:02

Потестировал тут SSD-диск (G.Skill Falcon, 128Gb) на одной read-only задаче. Два дня тестировал.

Если не вдаваться в подробности, то это большая (в примере было 90Gb) база данных со случайным доступом. Запросы к ней бывают короткие и длинные, при этом короткие на обычных дисках упираются в seek, а длинные ограничены и скоростью линейного чтения тоже.

Получилось:

  • Короткие запросы (коих большинство) ускорились примерно в 15 раз.
  • Длинные - в 4-5 раз.

Кроме того, для длинных запросов не падает общий throughput под параллельной нагрузкой (несколько одновременных запросов), тогда как для HDD - падает.

Сравнивалось с зеркалом (round-robin) из двух современных небыстрых десктопных дисков (WD Caviar Green, 2Tb), FreeBSD 8, UFS, холст, масло. Памяти 2 гигабайта, пролетаем мимо кэширования (в реальной жизни памяти на такие данные обычно несколько больше, но не в 10 раз).

Понятно, что если сравнивать с быстрыми SAS, то они в разы быстрее, но не в 15. Ну и дороже десктопных HDD они тоже в разы (и как бы не бОльшие).

Да, ZFS (но с одним диском) тоже смотрел, скорость записи сильно больше, скорость линейного чтения - сильно меньше. Как-то ее надо настраивать, наверное.

Долго потом думал, куды сунуть новое приобретение, в ноутбук или в десктоп. Засунул в ноут, он стал реактивнее десктопа, одно удовольствие работать. Заказал в десктоп еще и чую, что одним дело не закончится (опять же, надо гибридную ZFS потестировать, с ZIL на SSD оптимизированном под линейную запись и L2ARC оптимизированном под произвольное чтение)

Вот так разводят нашего брата.

P.S. Этот угол ноутбука теперь холодный.

Comments

photo_vs (not verified) - 20/Окт/2009 19:19

лучше интела?

lexa - 20/Окт/2009 19:28

Не знаю, у меня же не магазин и не тестовая лаборатория, я тестировал то что есть (адын штук).

А в тесты я не очень верю, очень много тонкостей и на одном и том же оборудовании и (вроде бы) похожих методиках разные лабы меряют сильно разное.

Хотя по идее, последние интелы в качестве read-only стораджа с произвольным доступом должны быть очень очень хороши.

photo_vs (not verified) - 20/Окт/2009 19:39

интел просто гарантирует медленную деградацию флеша из-за "умного" ремаппинга использования ячеек.
другие вендоры могут тупо напихать параллельных микрух и через полгода все помрет.

lexa - 20/Окт/2009 19:51

Другие вендоры озаботились командой TRIM (для Windows7) и гарбадж-коллекторами (для остальных ОС). Не все, но многие.

Совершенно очевидно, что все что есть сейчас - через год-два пойдет на свалку. Потому как объемы будут расти, гигабайт - дешеветь, а контроллеры и фирмварь - умнеть.

scope169 (not verified) - 21/Окт/2009 03:30

>>Потому как объемы будут расти, гигабайт - дешеветь,
К сожалению _пока_ не всё так радостно:
http://www.fclab.ru/2009/10/09/698/

lexa - 21/Окт/2009 08:31

В 1999-м году _мегабайт_ флэша стоил примерно $1.
Сейчас - $2.5-3 за гиг. Ну пусть даже $4.

Это даже чуть быстрее "денежного закона мура" (удешевление вдвое за полтора года), должно было подешеветь в 100 раз за 10 лет, а подешевело в 250 раз. На этом фоне локальное подорожание можно пережить.

scope169 (not verified) - 21/Окт/2009 03:43

Сейчас, думаю, wear levelling против "вытаптывания" флэша
едва-ли не во всех флэш-контроллерах имеется.
По крайней мере, присутствует даже в древнем Silicon Motion SM223,
который в моём, не менее древнем, eeepc-701 стоит...

forajump (not verified) - 04/Фев/2010 00:46

Это Indilinx (чипсет), общепризнанный середнячок, превосходство над конкурирующими устройствами Intel не замечено.

alll (not verified) - 20/Окт/2009 19:22

> если сравнивать с быстрыми SAS, то они в разы быстрее, но не в 15. Ну и дороже десктопных HDD они тоже в разы (и как бы не бОльшие).

А во сколько этот SSD дороже десктопного диска?

lexa - 20/Окт/2009 19:34

А нету сейчас десктопных дисков в 120 гигабайт :)
Если мерять в долларах на гигабайт, то раз в 30 (2.5 бакса за гиг против 8-9 центов у терабайтника)

Поэтому если мерять только на стоимость дисков, то вроде бы невыгодно. Но "дешевые десктопные диски" в стоимости системы занимают процентов ну 20 (100-баксовый терабайтный диск на 500-баксовый системник). Та же конструкция с терабайтным SSD будет в 5-6 раз дороже и в 15 быстрее (если целиться в данную конкретную задачу - большая R/O база данных специфического вида).

grishkind (not verified) - 20/Окт/2009 19:47

так насколько ускорится система в итоге?
если винду поставить на SSD, в харды только как файлохранилище использовать?

3jia5l_ca6aka (not verified) - 20/Окт/2009 19:54

зависит от задачи
от 0% до много

lexa - 20/Окт/2009 19:58

Про винду ничего не могу сказать. Полный интернет тестов, впрочем, время загрузки, разгрузки, такой бенчмарк, сякой.
Макось - летает. Ничего не мерял, просто те операции, которые раздражали - стали мгновенными (ниже психологически-критических времен)

В конкретной серверной задаче (про которую пост) - есть очевидный смысл менять диски. Т.е. сервер удорожается скажем вдвое, а работает в 4-15 раз быстрее.

alll (not verified) - 20/Окт/2009 20:02

Ну, если скорость превыше всего, то есть перцы, продающие RAM-диски - вплоть до полутеррабайта, емнип. Но для домашнего использования это пока немножко перебор. ;)

lexa - 21/Окт/2009 04:17

Там цена сильно другая.

А для домашнего использования не нужен быстрый терабайт, нужно гигабайт 200-300, цена уже вполне разумная для дома.

3jia5l_ca6aka (not verified) - 20/Окт/2009 19:55

я бы использовал его как диск для системы + виртуальной памяти, но эти 100000 циклов перезаписи (сейчас говорят уже 300000, но не суть) меня пугают :\ куда разумней (для этой задачи) - рамдиск

lexa - 20/Окт/2009 19:58

Как любой набор микросхем, его через два года выкидывать, циклов - хватит.

alll (not verified) - 20/Окт/2009 20:05

RAM-диск для виртуальной памяти немножко перебор. :) Масло масляное получается.

poige (not verified) - 20/Окт/2009 23:45

> Масло масляное получается.
Тем не менее, смысл есть засунуть 120 GiB DRAMM в обычную сис. плату не удастся, очевидно [сколько будет стоит 120 GiB DRAMM + настолько необычная сис. плата надо считать :-)]. Так что пусть свопится/пэйджится , несмотря на overhead всё-равно выигрыш в производительности будет

P. S. SSD, для своей Linux-системы, я бы раздал на раздел подкачки и журналы от журналируемых FS'ок [если бы ограничений по r/w-циклам не испугался ;-)].

lexa - 21/Окт/2009 04:40

Re: > Масло масляное получается.
Я вот сильно не уверен. Свап - дело такое, да вытеснить туда всякие getty ненужные полезно, но откуда в 2009-м году активный свап?

C журналами же еще интереснее - правильный журнал пишется линейно, по идее ему скорость позиционирования в штатных условиях не важна. Хотя да, рекомендуют.

poige (not verified) - 21/Окт/2009 04:42

> по идее ему скорость позиционирования в штатных
Дело в том, что помимо журнала пишутся и сами данные, причём даже не столько мета- , сколько данные per se , изначальные так сказать. Поэтому журнал на отдельном ус-все штука несомненно полезная для уменьшения latency, да и throughput тож.

poige (not verified) - 21/Окт/2009 04:48

> да и throughput тож.
[тут, ес-но, его увеличение имелось в виду. :-)]

lexa - 21/Окт/2009 05:07

Re: > по идее ему скорость позиционирования в штатных
Ну и ставить на журнал надо быстрый SAS, никакое единичное устройство быстрее по линейному доступу не будет (на сегодня), естественно всякие SSD с рейдом внутри я не считаю, точно так же можно страйп на Savvio сделать.

poige (not verified) - 21/Окт/2009 04:44

> Я вот сильно не уверен. Свап - дело такое
Типа, такое же тонкое, как Восток? :-) Всё нормально будет, уверен. :-) Даже если речь пойдёт не о getty, а чём-то более серьёзном

lexa - 21/Окт/2009 05:06

Re: > Я вот сильно не уверен. Свап - дело такое
Я очень давно не видел машины с активным свапом. Памяти - памятево, если ее не хватает, то никакой SSD не спасет.
Лишнее выкинуть - да, можно.

poige (not verified) - 21/Окт/2009 05:08

> то никакой SSD не спасет.
Бывают разные ситуации. Например такие, когда система прошвыривает через своп несколько десятков гигов, а потом всё нормально снова; в случае с SSD это произойдёт существенно быстрее

lexa - 21/Окт/2009 05:17

Re: > то никакой SSD не спасет.
Наверное бывают такие ситуации, но я таких очень давно не видел.

Пока эти гигабайты прошвыриваются - машина, очевидно, стоит. Значит ей бы надо дать по рукам, чтобы процессы не пухли (или лишние не плодились).

lexa - 21/Окт/2009 05:18

Re: > то никакой SSD не спасет.
И, кстати, не быстрее.
Линейная запись - не самое сильное место SSD, чтобы нам вендоры не пели в тестах. Оно "не сильно хуже" обычных дисков, ну и все.

aalleexxiivv (not verified) - 04/Ноя/2009 03:58

> Линейная запись - не самое сильное место SSD, чтобы нам вендоры не > пели в тестах. Оно "не сильно хуже" обычных дисков, ну и все.

Поспорю. На своем X-25E я намерял ускорение в два-три раза супротив обычного (одного) SATA-диска - именно в линейной записи (чтении, кстати, тоже). Юниксовый RAID из 4-х дисков дает паритет по скорости записи - для Win 2003 Server, а вот под Win XP - опять же SSD выиграл в два раза. А более современные SSD (даже MLC-шки - блин, пара месяцев разницы) - еще быстрее.

lexa - 04/Ноя/2009 09:44

X25-E - вроде лучший по линейной записи на сегодня?

Ну так и сравнивай его с лучшим по линейной записи Cheetah 15k7, там может случиться интересное открытие....

aalleexxiivv (not verified) - 04/Ноя/2009 18:38

> X25-E - вроде лучший по линейной записи на сегодня?

Я в этом не уверен. По-моему второе поколение X25-M от того же Интела - его переплевывает.

> Ну так и сравнивай его с лучшим по линейной записи Cheetah

Да, сейчас ты прав, сам не мерял, но у Тома и правда для серверных дисков в потоковых операциях разницы с SSD не просматривается.

Но судя по тому, как развиваются события в SSD-отрасли мнится мне, что через пару лет SSD будет раз в восемь быстрее... А хардам - куда расти?

lexa - 04/Ноя/2009 18:48

Через пару лет SSD будут максимум в 2-2.5 раза быстрее (по линейному доступу), ибо 10+гигабитный SATA не успеют испечь быстрее, тогда только-только 6-гигабитный станет массовым.

aalleexxiivv (not verified) - 06/Ноя/2009 00:13

А нафига SATA вообще сдался для SSD? Уже ведь нарисовали указатель счастья: OCZ zDrive, FusionIO - оно пока дороговато, но сама идея втыкивать девайс прямо в PCIe - мне представляется правильной. И я не вижу, почему это решение должно быть всегда дорогим. Думаю - подешевеет.

lexa - 06/Ноя/2009 08:56

Fusion что-то свое лепит, а вот zDrive - это RAID-контроллер и несколько дисков в особом конструктиве, от самосбора ничем не отличается.

А количество слотов PCIe ограничено больше, чем количество дырок под диски.

poige (not verified) - 21/Окт/2009 04:50

> правильный журнал пишется линейно
Да, а если ты про то, что сам журнал можно было бы и на диске каком-нибудь более привычном выполнить, и уже было б неплохо, то я исходил из того, что на SSD можно поместить более одного журнала без падения всё тех же l & t. :-)

lexa - 21/Окт/2009 04:59

Re: > правильный журнал пишется линейно
Ну казалось бы делаем один ZFS pool на все FS, соответственно один журнал.

poige (not verified) - 21/Окт/2009 05:07

> казалось бы делаем один ZFS
uname Linux, какая ZFS? Тут LVM-2 и co.

lexa - 21/Окт/2009 05:10

Re: > казалось бы делаем один ZFS
Будет и на вашей улице праздник (в FreeBSD ситуация с нормальными FS поправилась вот только что, да и то надо тестировать вдумчиво...)

poige (not verified) - 21/Окт/2009 05:17

> Будет и на вашей улице праздник
Я щщщитаю лучше party вчера и сегодня, чем celebration непойми когда. :-) Тем паче, что celebration весьма спорный и пример с FreeBSD это доказывает. Ради ZFS ползти на Solaris? Чёт не хочется. BtrFS, кстати, уже почти работает, но в реальности пока хватает тех же EXT{4,3}, XFS, Reiser

lexa - 21/Окт/2009 05:31

Re: > Будет и на вашей улице праздник
Я вот думаю, что "почти работает" там не лучше, чем ZFS был последние несколько лет. Только gjournal-ом и спасались последние несколько лет

poige (not verified) - 21/Окт/2009 05:37

> думаю, что "почти работает" там не лучше, чем ZFS был
Ну Btrfs я в том смысле упомянул, что вряд-ли в Linux будет ZFS, поскольку там именно Btrfs позиционируется в эту нишу.

lexa - 21/Окт/2009 05:15

Re: > Масло масляное получается.
128 гигабайт памяти стоят примерно 4 килобакса сейчас (в 10 раз дороже SSD), по 250 за 8-гиговый ECC DIMM.

На этом фоне можно и материнку нормальную купить, которая эту память примет, это недорого.

lexa - 21/Окт/2009 10:11

Re: > Масло масляное получается.
Кстати, с ограничениями по циклам очень простая арифметика.

Представим, у нас 100-гиговый диск и туда непрерывно пишется 100Mb/sec (что очень дохрена). Он будет перезаписываться 4 раза в час. 100 тыс циклов - 1000 дней или 3 года.

Сходил на серьезно загруженный сервер. iostat -x сказал мне, что за две недели аптайма средняя скорость записи была 416 kb/sec т.е. в 200 раз меньше, чем в моей прикидке. Тут и 10 тыс циклов не страшны.

Понятно, что write multiplication и все дела, реальная ситуация будет хуже чем в моей прикидке, но не на порядки (на порядок - может быть).

3jia5l_ca6aka (not verified) - 21/Окт/2009 05:36

почему вы так решили?) возьмите любую систему, напихайте ей памяти много-много, а ей все-равно захочется страницы выгружать)

lexa - 21/Окт/2009 05:45

Нормальной (tm) системе захочется выгрузить только неактивное. Можно выгрузить и на медленное устройство.

Выгружать же на очень быстрое - проще свап отключить, без свапа на разумно-большой памяти сейчас все работает.

3jia5l_ca6aka (not verified) - 21/Окт/2009 05:59

Что-то меня переклинило и я взял в голове за систему - маленький объем оперативной памяти и быстрый своп :\

lexa - 21/Окт/2009 06:07

Арвиды, если кто помнит, можно было использовать для хранения AVI-шников (и в этом даже был смысл).

Если памяти мало, а процессор быстрый - может быть смысл сделать своп в RAM, но на компрессированной FS. Хотя это и гусарство.

alll (not verified) - 21/Окт/2009 07:58

Поставьте ей размер файла подкачки страниц метра четыре - и пусть хоть обвыгружается.

3jia5l_ca6aka (not verified) - 21/Окт/2009 08:05

Это тоже не очень хорошо
емнип, на терминальном сервере 50 пользователей запускает 50 одинаковых exe (с dll и пр.) - винда пытается хранить 50 копий этого ужоснаха в памяти (пока память есть), как только память уменьшается до 20-40% от общего объема, винда начинает разумней ее использовать - выгружает весь этот ужОс в виртуальную память, оставляя в оперативной только одну копию. может что путаю, давно было, но с тех пор я ее редко выключаю :\

alll (not verified) - 21/Окт/2009 08:14

exe, dll и прочий immutable код не должен попадать в файл подкачки вообще - он по определению уже есть на диске и ещё раз его на диск записывать нет никакого смыслаж; винда это дело вроде как понимает и умеет

плюс у нас исходная посылка: памяти много настолько, что занять 80% от общего объёма не получится :)

lexa - 21/Окт/2009 08:43

DLL-ки вроде бы разделяемые между приложениями? Да и исполняемые файлы должны быть тоже.

slapsh (not verified) - 21/Окт/2009 10:57

Масло маслом, но своп на SSD в Windows XP это нечто. Я пробовал нагружать ноут с 1Гб RAM тяжелым софтом (было занято 1.6Гб) -- переключение между задачами было мгновенным. Я никогда до этого такого не видел.

alll (not verified) - 21/Окт/2009 11:02

> Я пробовал нагружать ноут с 1Гб RAM тяжелым софтом (было занято 1.6Гб)

Попробуйте нагрузить ноут с 120Гб RAM этим же самым софтом. ;)

_slw (not verified) - 20/Окт/2009 20:51

мда
в 88 году я начинал работать именно на рам-дисках.
полмега
и памяти 56к

sergeax (not verified) - 20/Окт/2009 20:18

Где-почём оторвал?

lexa - 21/Окт/2009 04:19

eBay, примерно $300 (что очень дешево, подозреваю что ворованый из супермаркета, тем более что продавец пропал).

3jia5l_ca6aka (not verified) - 21/Окт/2009 08:05

А не странно, что таможня не заартачилась - оне, кажется, должны проверять стоимость товара?

lexa - 21/Окт/2009 08:42

У меня не было случая, чтобы они не верили customs form, наклеенной на коробку.

dmarck (not verified) - 20/Окт/2009 21:20

для ZFS - amd64, я надеюсь? потому как на i386 всё сильно хуже, хотя и приемлемо (сам дома на ём живу, как раз на зеркале из Caviar Green)

lexa - 21/Окт/2009 04:41

Да вроде с чтением там все приемлемо, "сильно хуже" связано с необходимостью запрета префетча только (т.к. ядерной памяти мало)?

renat (not verified) - 21/Окт/2009 03:07

Да, правильные SSD - штука очень хорошая. Жаль, что часто в серийные ноутбуки (и особенно нетбуки) ставятся такие образчики, что после них работу с обычным хардом за счастье почтешь. Экономия...

Anton Yuzhaninov (not verified) - 21/Окт/2009 11:25

> Да, ZFS (но с одним диском) тоже смотрел, скорость записи сильно больше, скорость линейного чтения - сильно меньше.

Как то раз я читал логи с ZFS и заметил что скорость чтения в несколько раз ниже чем с UFS при этом по gstat с диска читается в несколько раз больше, чем потом уходит в userland.

Написал
vfs.zfs.prefetch_disable=1
в /boot/loader.conf

Скорость чтения сильно возросла, а скорость чтения по gstat стала примерна равна скорости передачи данных в userland.

lexa - 21/Окт/2009 11:31

Я смотрел скорость втч и по iostat, она примерно совпадало с тем, что в userland.

Подозреваю, что размер страницы и все такое надо настраивать, но вдаваться не стал, я ZFS пока готовить не умею, нужно отдельно разбираться.

Anton Yuzhaninov (not verified) - 21/Окт/2009 11:30

дополнение - это было на amd64, 6 Gb RAM и vm.kmem_size=4000M

Dimez (not verified) - 22/Окт/2009 12:16

Купили потестировать Intel X25-E. Аппликуха на одном ssd (против raid на scsi) стала быстрее грузиться и работать от 5 до 28 раз.

lamantyn (not verified) - 28/Окт/2009 02:11

http://ask.slashdot.org/story/09/10/27/1559248/Reliability-of-PC-Flash-SSDs

lexa - 28/Окт/2009 06:08

Ну надо сказать, что у меня было ненулевое количество старых дохлых флэшек, а относительно нестарых (от 8 гигов) - пока ровно ноль. Как и любая технология, должна устояться, вот на ./ ругают JMicron, но не ругают indilinx. Но они могли еще не начать сыпаться.

А статистику набирать конечно надо, но конкретная тестировавшаяся задача выигрывает настолько, что можно просто покупать запасных дисков с экономии на colocation.

lamantyn (not verified) - 29/Окт/2009 01:18

=== /. ===
Intel has pulled a firmware upgrade it released on Monday for its X25-M consumer solid-state drives after users complained that the software caused crashes.
===

Как-то не хочется экспериментировать в боевых условиях. Мы пока по старинке, RAM добавляем. 128GB уже стандартом стало. "Совершенно случайные данные с диска" - редкая задача. А из кеша в памяти всяко быстрей.

lexa - 29/Окт/2009 04:24

Ага, про интел я тоже ржал.

Ежу понятно, что на этом пути будет еще много всяких чудных открытий. Но

1. MLC-флэш в ~10 раз дешевле DRAM.
2. Терабайт-два в сервер - влезает без проблем.

Что же до задачи, то скажем BTree с диска - будет случайный доступ. Апдейт индексов (да, у флеша с записью не так хорошо как с чтением, но тоже неплохо) - тоже (псевдо)случайный доступ.

lamantyn (not verified) - 29/Окт/2009 04:42

MLC-флэш в ~10 раз дешевле DRAM.

И в десять (или двадцать?) раз медленнее.

lexa - 29/Окт/2009 06:00

Ага, поэтому я не предлагаю делать сервера совсем без памяти.

Но пара терабайт флэша - вполне приемлемо стоит и промежуток между быстрой памятью и совсем медленным (в сравнении) диском - вполне заполняет.

Зеня (not verified) - 04/Авг/2013 20:49

Не правда даже на Линукс, если все правильно настроить и добавить пару утилит тот же HDD начинает издавать умопомрачающие очень мелодичные стимпанковские звуки. Например e4rat это делает частично.

Да и надежнее они до сих пор с большим количеством оперативной памяти )))