Comments 62
Вечный цикл за пару секунд… Можно узнать хотя бы примерную стоимость для примеров, приведенных выше?
Цена высокая (ниже в комментариях, кажется, ошиблись на порядок), но при этом получается значительно дешевле в сравнении с mid-range и hi-end массивы с таким же уровнем IOPs построенными на базе большого количества дисков SAS 15000 обр/мин, и даже дешевле конфигураций, где аналогичная производительность получается путем различных «хитростей» в виде кеширования наиболее «горячей» информации на SSD. По состоянию месяц назад система обеспечивала самый дешевый IOPs в галактике. По конкретике — надо писать на почту, потому что вендор имеет гибкую политику скидок под конкретные проекты.
Раньше все хотели коробку сникерсов, а щас мечтают о такой штуке домой для торрентов )
Для торрентов вполне хватает HDD десятилетней давности.
Десятилетние хрустеть громко будут, думаю.
неа. у меня часто при количестве активных раздач больше 50 появляются проблемы со скачкой, торрент пишет, что диск загружен на 100%.
Недавно вообще появились проблемы: невозможно одновременно качать насколько раздач и смотреть фильм с того же диска. Думаю что нужно собирать рейд 10.
Недавно вообще появились проблемы: невозможно одновременно качать насколько раздач и смотреть фильм с того же диска. Думаю что нужно собирать рейд 10.
Что у вас за канал? Что за диск? Может, фрагментирован очень сильно? Попробуйте qBittorrent, в нем есть кеш записи на диск, иногда очень полезен бывает.
Да нет, я думаю, диск просто медленный. У меня в машине остался с давних времён террабайтник IDEшный, какой-то из гриновых вестернов 5400-х — с ним примерно та же история (я на нём, собственно, только торренты и фильмы держу).
Ну не бывает настолько медленных дисков, если у вас канал не гигабит. Он у вас, наверное, очень сильно фрагментирован, и на поиск уходит больше времени, чем на чтение.
Битрейт у фильмов большой — процентов у 60-70 свыше 15 Мбит. Ну и фрагментация, понятное дело.
Ну, предположим, у фильма пиковый битрейт 30 мегабит, это, грубо говоря, 4 мегабайта. Линейная скорость чтения плохого и старого винчестера в вакууме, скажем, 30 мегабайт в секунду. Винчестер должен быть крайне фрагментирован, чтобы не позволять смотреть фильм и качать / раздавать торренты одновременно. На деле, мне удавалось достичь скорости винчестера через сеть только на гигабитном канале. Линейная скорость чтения на моих винчестерах, в среднем, 80 мегабайт в секунду.
А, я допёр в чём дело. Он на одном шлейфе с крайне редко, но все же использующейся оптикой висит — если я еще не до конца забыл все, он в таком случае должен работать на UDMA-4, а это пик в 66.7 Мбит.
UDMA4 это 66 мегабайт в секунду, а не мегабит. Поэтому это не должно влиять.
Мне тоже кажется что дело в сильной фрагментации. Или какие-то беды есть на диске, на обработку которых тратится время.
Мне тоже кажется что дело в сильной фрагментации. Или какие-то беды есть на диске, на обработку которых тратится время.
Хм, таки-мегабайт? Значит, уже ничего не помню :)
А касательно диска — на замену, и вся недолга. В новой машине ему места с гарантией уже не будет — это такая переходная конфигурация получилась в сей раз.
А касательно диска — на замену, и вся недолга. В новой машине ему места с гарантией уже не будет — это такая переходная конфигурация получилась в сей раз.
Тут просто запомнить: IDE/PATA — параллельный интерфейс, поэтому скорости обычно в байтах.
На последовательных интерфейсам скорости, соотвественно, будут в битах (SATA/SAS, Network и т.п.).
На последовательных интерфейсам скорости, соотвественно, будут в битах (SATA/SAS, Network и т.п.).
Просто диск не может одновременно читать и писать из нескольких мест на пластине. скорость начинает катастрофически падать, когда головы мечутся по диску — вот это время когда головки находятся в движении между дорожками диска ооооочень сильно влияет на скорость чтения/записи, которая падает в разы. Этот же эффект я наблюдал на террабайтном винте при раздаче 50+ торрентов при 50+ пиров на каждом. тут или уменьшить количество раздач или терпеть падение скорости.
Совершенно верно. Головы при сильно фрагментации бегают намного больше.
Бороться с этим злом призван NCQ :)
Канал — 90 Мбит
Хард — WD Green 1.5 Tb.
Да надо бы посмотреть что там с фрагментацией.
Хард — WD Green 1.5 Tb.
Да надо бы посмотреть что там с фрагментацией.
Я тут намедни тестировал…
Это CristalMark, тест конечно не лучший, но показательный.
Это LSI Megaraid SAS 6Gb/s, но винты висят SATA и это RAID0 из 4х винтов
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]
Sequential Read: 599.443 MB/s
Sequential Write: 555.758 MB/s
Random Read 512KB: 54.962 MB/s
Random Write 512KB: 170.105 MB/s
Random Read 4KB (QD=1): 0.746 MB/s [ 182.2 IOPS]
Random Write 4KB (QD=1): 7.986 MB/s [ 1949.6 IOPS]
Random Read 4KB (QD=32): 5.261 MB/s [ 1284.5 IOPS]
Random Write 4KB (QD=32): 7.961 MB/s [ 1943.6 IOPS]
Test: 1000 MB [C: 0.4% (14.8/3721.3 GB)] (x5)
Date: 2013/05/14 16:57:57
OS: Windows Server 2008 R2 Server Standard Edition (full installation) SP1 [6.1 Build 7601] (x64)
LSI RAID0 (4HDD+System)
Самое занимательное это Random Read 4KB и Random Write 4KB а ведь торрент пишет мелкими рандомными блоками.
Тут наверное может помочь только предварительное кеширование в пямять.
А у вас железо то слабое, у самого подобное в качестве дом. сервера, и теже проблемы, особенно если в торренте много файлов.
Но обычно потом разгоняется и забивает на всю 100мбит. Кстати а если по SMB качать файл с сервера то выдает 33Мб/сек.
Это CristalMark, тест конечно не лучший, но показательный.
Это LSI Megaraid SAS 6Gb/s, но винты висят SATA и это RAID0 из 4х винтов
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]
Sequential Read: 599.443 MB/s
Sequential Write: 555.758 MB/s
Random Read 512KB: 54.962 MB/s
Random Write 512KB: 170.105 MB/s
Random Read 4KB (QD=1): 0.746 MB/s [ 182.2 IOPS]
Random Write 4KB (QD=1): 7.986 MB/s [ 1949.6 IOPS]
Random Read 4KB (QD=32): 5.261 MB/s [ 1284.5 IOPS]
Random Write 4KB (QD=32): 7.961 MB/s [ 1943.6 IOPS]
Test: 1000 MB [C: 0.4% (14.8/3721.3 GB)] (x5)
Date: 2013/05/14 16:57:57
OS: Windows Server 2008 R2 Server Standard Edition (full installation) SP1 [6.1 Build 7601] (x64)
LSI RAID0 (4HDD+System)
Самое занимательное это Random Read 4KB и Random Write 4KB а ведь торрент пишет мелкими рандомными блоками.
Тут наверное может помочь только предварительное кеширование в пямять.
А у вас железо то слабое, у самого подобное в качестве дом. сервера, и теже проблемы, особенно если в торренте много файлов.
Но обычно потом разгоняется и забивает на всю 100мбит. Кстати а если по SMB качать файл с сервера то выдает 33Мб/сек.
Как правило, ширина интернет канала на порядки ниже пропускной способности диска, а значит диск не может являться фундаментальным ограничением.
Просто увеличьте размер кэша (и на чтение и на запись) в вашем торрент-клиенте (uTorrent, например, позволяет это сделать)
Просто увеличьте размер кэша (и на чтение и на запись) в вашем торрент-клиенте (uTorrent, например, позволяет это сделать)
Очень интересная железка! В одной Health Care Insurance Company, на такой железке крутили виртуальные машины для сотрудников, а их машины были лишь тонкими клиентами.
Но такая штука и стоит не очень дешево: в один момент были разговоры прикупить такого монстра в компанию, фигурировала цифра в $40K за 6232, но так и не прикупили ;(
Но такая штука и стоит не очень дешево: в один момент были разговоры прикупить такого монстра в компанию, фигурировала цифра в $40K за 6232, но так и не прикупили ;(
UFO just landed and posted this here
При создании контейнера в системе резервируется место от 15 до 50% общей свободной ёмкости именно по этой причине. При этом процент выбирается исходя из профиля нагрузки, например 15% резерва для чтение/запись 80/20 и 50% для 0/100. Это, конечно, уменьшает доступное пространство, но главная задача таких систем – производительность, пусть и в угоду ёмкости.
Violin работает немного по другому, FPGA на каждом чипе отслеживает актуальность информации каждой ячейки и, если данные уже не нужны, специальный фоновый процесс под названием garbage collector очищает её. Таким образом, каждая запись всегда идет в пустую ячейку, что позволяет избежать просадки производительности и использовать чипы FLASH-памяти максимально эффективно не только на чтение, но и на запись.
Разве не все современные SSD работают по такому же принципу? Встроенные сборщики мусора везде есть, ну и TRIM со стороны ОС.
Да, различные технологии ускорения записи есть и конкурентов, однако если посмотреть на аналитический график в посте, то вы увидите, что почти все решения страдают значительным «обрывом» производительности. Почему так происходит? Точного ответа я не знаю, но есть некоторые соображения. Во-первых, до недавнего времени дисковые СХД hi-end и mid-range класса garbage collecting-ом вообще не занимались, за редким исключением. Во-вторых, вероятно не все алгоритмы «одинаково полезны» — может конкуренты пожадничали с резервируемым пространством. В любом случае “write cliff” в SSD системах — это проблема, которая в большинстве систем не решена.
UFO just landed and posted this here
Очень интересно! До этого вживую сталкивался только с hp eva 4400 на fc -дисках и ibm storewize v7000 на дешевых sas дисках с кэшем ssd! По сравнению с ними — данная штука — взлетает! Впечатлен!
Вопрос разбирающимся, обычная бытовая SSD в домашнем компьютере тоже работает не оптимально из-за груза старых дисковых протоколов?
Да, да, и ещё как да!
Но не совсем из-за груза, скажем так проблема в том что пользовательские файловые системы по большей части разрабатывались именно для ДИСКОВ, и контроллеры современных SSD делают из массива памяти диск, что само по себе не есть хорошо, тк там свои фишки…
Но не совсем из-за груза, скажем так проблема в том что пользовательские файловые системы по большей части разрабатывались именно для ДИСКОВ, и контроллеры современных SSD делают из массива памяти диск, что само по себе не есть хорошо, тк там свои фишки…
ОС общается с контроллером, в существенной мере точно так же, как если бы это был обычный жесткий диск, а контроллер уже обращается к чипу. Это решает большую часть проблем совместимости, добавляя естественно некоторый оверхед, но сам SSD при этом работает вполне себе нормально т.к. контроллер к нему обращается уже не используя никаких старых протоколов.
Определенная проблема есть разве что в файловых системах, но её решать в ближайшие годы никто не будет т.к. незначительный выигрышь в производительности никак не стоит сломанной обратной совместимости.
Определенная проблема есть разве что в файловых системах, но её решать в ближайшие годы никто не будет т.к. незначительный выигрышь в производительности никак не стоит сломанной обратной совместимости.
Блин, интересное решение, надо будет заняться…
UFO just landed and posted this here
> скорость записи была очень далека от заявленной в презентации 1 мс и составляла в среднем всего 0,4 мс
Величины указаны в «мс» — это время одной операции, или все же, как у Вас указано, скорость записи?
Получается, что операции в 2.5-4 раза быстрее обещанного вендором?
Величины указаны в «мс» — это время одной операции, или все же, как у Вас указано, скорость записи?
Получается, что операции в 2.5-4 раза быстрее обещанного вендором?
Раз количество циклов записи всё равно ограничено — то всё равно ерунда. Ждём мемристоры или что-то подобное.
Статистика по ДЦ показывает что современные шпинделя умирают от износа раньше чем на SSD энтерпрайз уровня заканчивается резерв по циклам записи.
Мемристоры конечно дешевле и их не запускают на рынок ибо на ССД напилить можно больше, что является лишним доказательством заговора мирового капитализма.
Мемристоры конечно дешевле и их не запускают на рынок ибо на ССД напилить можно больше, что является лишним доказательством заговора мирового капитализма.
Давным-давно как таковых отдельных систем хранения данных не было: просто у сервера был жесткий диск, на который записывалась вся информация. Потом информации понадобилось писать всё больше и больше, и в результате выделились отдельные хранилища, создаваемые на магнитной ленте, массивах дисков и массивах флеш-дисков.
Неприятно это писать, но исторически в 60-х годах все выглядело так же как и сейчас: Терминалы, вычислительные процессоры, хранилища данных превратились соответственно в тонкие клиенты, сервера и СХД. Ребрендинг. Есть замечательные документы по storage tiering от компании IBM описывающие характер хранения данных в смешанной системе хранения data cells + mag drums + mag tape (писать на диски придумали позже). Было ведь время когда к оперативной памяти (data cells: тогда были распространены ферриты) относились как к полноценному хранилищу, а не как к JAVA-помойке :( (Для олдфагов: bitsavers.trailing-edge.com/pdf/ibm/370/princOps/GA22-7000-4_370_Principles_Of_Operation_Sep75.pdf )
А продукт супер: в сожалению дороже аналогов от oracle но будем надеяться что хотябы по иопсам Виолончель догонит старших братьев, а вот архитектурка хороша :) (Пятитысячник выжимает полтора мегайопса: www.oracle.com/us/043970.pdf, при том что он уже старенький старенький стал уже, но зато всего один юнит толщиной)
Неприятно это писать, но исторически в 60-х годах все выглядело так же как и сейчас: Терминалы, вычислительные процессоры, хранилища данных превратились соответственно в тонкие клиенты, сервера и СХД. Ребрендинг. Есть замечательные документы по storage tiering от компании IBM описывающие характер хранения данных в смешанной системе хранения data cells + mag drums + mag tape (писать на диски придумали позже). Было ведь время когда к оперативной памяти (data cells: тогда были распространены ферриты) относились как к полноценному хранилищу, а не как к JAVA-помойке :( (Для олдфагов: bitsavers.trailing-edge.com/pdf/ibm/370/princOps/GA22-7000-4_370_Principles_Of_Operation_Sep75.pdf )
А продукт супер: в сожалению дороже аналогов от oracle но будем надеяться что хотябы по иопсам Виолончель догонит старших братьев, а вот архитектурка хороша :) (Пятитысячник выжимает полтора мегайопса: www.oracle.com/us/043970.pdf, при том что он уже старенький старенький стал уже, но зато всего один юнит толщиной)
Пятитысячник при этом ёмкость имеет, мягко говоря, немного меньше.
Он (пятитысячник) пардон четыре года уже бегает по ДЦ и радует многих биржевиков бешенными иопсами. Назначение этих систем кэширование горячих данных. Тому кто сейчас соберет петабайтное ссд хранилище я искренне сочувствую, хотя дай ему бог здоровья.
Я в общем не говорю что виолончель отстой, но могли бы и поднапрячься и обогнать одноюнитового ветерана сделанного но современным меркам уже из г-на и палок.
Да и личный опыт показывает — сколько волка не корми — у слона всеравно толще. Как ни разгоняй внешнюю хранилку, а на PCI шине всеравно быстрей бегает.
Я в общем не говорю что виолончель отстой, но могли бы и поднапрячься и обогнать одноюнитового ветерана сделанного но современным меркам уже из г-на и палок.
Да и личный опыт показывает — сколько волка не корми — у слона всеравно толще. Как ни разгоняй внешнюю хранилку, а на PCI шине всеравно быстрей бегает.
Я о том, почему он дороже пятитысячника.
Этот факт тяжело не признать :)
На самом деле пятитысячник давненько устарел, ибо с появлением сверхтяжелых сервачков с оперативой на 1-2 ТБ — задачи кэширования дурной инфы делаются на рамдисках или непосредственно в оперативе.
пример сервачка прилагается, а то вдруг кто не в курсах: www.itcreations.com/show-server.asp?server_id=6516 или h10010.www1.hp.com/wwpc/us/en/sm/WF05a/15351-15351-3328412-241644-4222584-4231377.html?dnr=1
На самом деле пятитысячник давненько устарел, ибо с появлением сверхтяжелых сервачков с оперативой на 1-2 ТБ — задачи кэширования дурной инфы делаются на рамдисках или непосредственно в оперативе.
пример сервачка прилагается, а то вдруг кто не в курсах: www.itcreations.com/show-server.asp?server_id=6516 или h10010.www1.hp.com/wwpc/us/en/sm/WF05a/15351-15351-3328412-241644-4222584-4231377.html?dnr=1
Интересно, как принимается решение, к примеру, о внедрении VDI — что использует ынтырпрайз вместо классических десктопов и на каких объемах это становится выгодно? Может есть где-то в сети хороший пример расчетов? (Интересно будет сравнить выгоду по сравнению «переписать под web», хотя понятно, что не всегда применимо.)
Хочу домой двухтерабайтник такой.
скорость записи… 1 мс
Я чего-то не понимаю, или массу теперь в джоулях взвешивать?
А есть результаты тестов при заполнении хранилища от 50 до 80-90%?
Sign up to leave a comment.
Обзор новой Violin — флеш-СХД, работающей со скоростью, близкой к DRAM