SSD-накопители

  • Автор темы Автор темы Cheater
  • Дата начала Дата начала
@Vosk, а зачем на него устанавливать винду? У нас же он под библохранилище используется, ему там самое место. Для винды и простого сата ссд хватит.
 
кстати, на x99 на единственный ставится винда на nvme raid
 
  • Like
Реакции: Scarlatino
@Dmitry Stepin, ну по твоему обзору выходит, что он такой не идеал-не идеал)) особенно в сравнении с Про. Но Плекстор и по температуре хуже и по скорости. Вот ведь задача...
 
http://www.tomshardware.com/reviews/intel-optane-ssd-900p-3d-xpoint,5292.html - новый, быстрый ссд. На мелкоблочных операциях уверенно рвёт все пользовательские ссд, существующие на сегодня. Вполне возможно, что именно такой будет лучшим выбором для ответственного библохранилища. Минус только один - цена..
 
@Dmitry Stepin, насчет уверенно рвет - это пока без реальных тестов.
по табличкам уже можно сравнить с самсом:
S 960PRO - 440 kiops - 300$ incl НДС
I 900P - 550 kiops - 600$ w/o НДС

Итог: сомнительная хрень.
 
@basЫl, да ты посмотри тест по ссылке. Всё там понятно)) Цена не зря такая.

Интересно, что о нагреве нет ни слова в обоих тестах.

Хотя, опять же, не понятно, могут ли хотя бы на пятьдесят процентов использовать возможности подобных ссд контакты и плеи.
 
Последнее редактирование:
в народе говорят на него устанавливается только W10 ), 7-ка не устанавливается..
Подсунешь дистрибутиву NVMe-драйвер для семерки (а он есть) - и установится, как миленькая. Спрашивает же скази и прочие извращения при установке.
 
Спустя сутки после релиза Intel опубликовала новые цены на свои Optane 900p, старые цены, указанные выше, теперь недействительны: отныне версия на 280 Гбайт будет стоить $569, а на 480 Гбайт - $979

Да уж, Интел скромности не занимать... Ухи поели они конкретно.
 
Изначально Оптаны позиционировались как кэш-решения. И прежде всего для тяжелой нагрузки. Отсюда погоня за адскими скоростями в 4Кбайт-чанках, а главное - за адскими скоростями в смешанной нагрузке.

Ну так это... дружно выдыхаем, бобры! НАМ ЭТО НЕ НАДО. Нам нужно хорошую скорость в чтении средними-крупными блоками, от 128Кбайт примерно. А на запись вообще плевать. И в этих режимах новые Оптаны ничем не круче тех уже старых Плексторов 8-й серии.
Так что пусть хоть мешок золота просят, у нас есть выбор.

не понятно, могут ли хотя бы на пятьдесят процентов использовать возможности подобных ссд контакты и плеи.
при загрузке патчей - точно НЕТ, это здесь уже кто-то тестил. Там скорости не подымались выше 400МБ/с никак.
при воспроизведении - по идее да, если только уже проц не скажет "кря" от работы тяжелых скриптов при огромной полифонии.
 
ам нужно хорошую скорость в чтении средними-крупными блоками, от 128Кбайт примерно.

Так вот в этих режимах оптан также быстрее. В сравнении с плекстором, кстати, аж на 1 гб/с. Оптан максимальные скорости показывает начиная с минимальной глубины очереди запросов, в то время, как любые другие ссд выходят на такие скорости только с большей глубиной запросов. Вопрос в том, что чтение семплов контактами в проекте - это глубина запросов какая - маленькая или большая?

aHR0cDovL21lZGlhLmJlc3RvZm1pY3JvLmNvbS9QL1QvNzIyODAxL29yaWdpbmFsL2ltYWdlMDAxLnBuZw==

aHR0cDovL21lZGlhLmJlc3RvZm1pY3JvLmNvbS9QL1IvNzIyNzk5L29yaWdpbmFsL2ltYWdlMDAyLnBuZw==



Надежда на новые самсунги 970-980 серий, они наверняка будут дешевле оптанов.
 
Последнее редактирование:
@Dmitry Stepin, в это режиме оптан быстрее чем самс процентов на 5. При емкости 280Г vs 2ТБ.
 
@basЫl, в этом да. Самсунг вообще молодец. Но всё же нужно тестировать в реальной работе, так как при меньших блоках оптан уходит в отрыв даже от Самсунга.

о, блин, один диск в компе и се ту.. ))

А может за те же деньги лучше два двухтерабайтника Самсунг 960 про. Будет ли быстрее в итоге?)
 
Последнее редактирование:
... а теперь посчитаем в уме.
Стереопоток несжатого аудиоCD - 176КБайт/сек. Это 16/44.1
Стереопоток 16/48 - 192КБ/с. Библы для Контакта, как правило, бОльшей частоты дискретизации не имеют, не верите - посмотрите выходные данные.
При этом они все пожатые, то есть поток данных меньше... Но пусть непожатые, и даже 32/48... тогда 384КБ/с, то есть три восьмых мегабайта. В секунду.

Помнится, дядька Воск хвастал, что у него в плотной аранжировке голосовая вертикаль (то есть полифония) аж до двух с половиной тыщ голосов доходит.
Ну, у меня меньше, где-то 1500-1700... Но, допустим, среднее по больнице - две тысячи. Процессор класса i7 загружен при этом уже по самое не балуйся...
Умножаем три восьмых на два и вместо мега пишем гига. Получаем... 3/4 ГБ/сек. 750 мегабайт в секунду. Большего потока ваш сисидюк обеспечивать никогда и не будет.

Ну вот и давайте посмотрим, от каких блоков начиная драйв выходит на эту скорость. ЭТО - и есть важная характеристика. Контакт 4КБ-чанки не читает.

Вывод: Оптан офигенный молодец, но свою медальку может засунуть себе... под радиатор. За такие бабки лучше пару терабайтных плексторов, на которые все библиотеки лягут.
Вывод2: на красивом цветном графике видно, что ВСЕ NVMe-участники даже при единичной глубине запроса вполне отвечают нашим требованиям. Даже старенький Интел-600 выдает 500 мег... при том запасе, с которым считали, - понятно, что их хватит.
Вывод3: почти никогда не надо гоняться за красивыми циферками. Нам же ехать, а не шашечки. Вот объем... его много никогда не бывает, а значит, за ту же сумму дайте два! И еще вон тот... И памяти побольше, побольше... Мне вот 64 гиг на сервере как-то впритык, думаю, где немножко денежек взять до 96 проапгрейдить.

Я в диспетчере задач при очень нагруженных контактами сессиях выше 700 мб/с скоростей почти не видел, в основном крутится всё время вокруг 300-400 мб/с..
Как же я просмотрел эту реплику?! Можно было и не считать. Вот они, те же цифры.

Оффтопный вывод4: погоня за скоростной оперативкой - примерно такое же зло, и по тем же причинам... Проц крякнет раньше.
 
Последнее редактирование:
  • Like
Реакции: RockMeister и dmitryga
Да даже бюджетные диски подойдут если грамотно распределить тяжелые библы между ними.
Кстати, возможно, если уменьшить кэш контакта по максимуму(чтоб в озу все влезло), то мб оптан ещё пригодиться. И мб обойдётся дешевле чем наращивать озу, а мне вообще для этого придётся всю систему менять)
 
  • Like
Реакции: Herr Morkovka
@dmitryga, эмм... в моей практике, если кэш Контакта утоптать до минимума (6кб вместо 60), то многие библиотеки начинают дурить, причем независимо от загрузки. То ли скрипты заплетаются, то ли уж не знаю, что. Меньше 18 не ставил. Сейчас на оркестровом венском сервере стоит кэш 24кб. При этом спитфайровский оркестр с рюшечками (рюшечек еще четверть объема, но хочется их держать тут же) где-то до 58 гиг оперы жрёт. Чо-та как-то без запаса :(. Не, воткнуть 4 по 16 вместо 4 по 8 должно дешевле обойтись :D

А может за те же деньги лучше два двухтерабайтника Самсунг 960 про. Будет ли быстрее в итоге?)
А это уже смотря, хватит ли свободных линий PCIe... А то у людей вон всё забито... Хотя, на мой взгляд, Вена решает. Один двухтерабайтник на каждый сервак - и кайф. При том, что стоимость остального сервака сравнима, заметим...
 
Последнее редактирование:
@Sandello1973, всё-таки, при нашей полифонии в 2000 голосов, нагрузка на ссд идёт параллельная? То есть, нам нужны такие диски, которые дают минимальные задержки доступа и максимальную скорость чтения при большой очереди запросов, так? То есть другими словами, нужно просто побольше отдельных ссд (можно даже простых сата-3), вместо одного скоростного?

Ну и да, оперативку тоже нужно максимально наращивать в объеме..

Можно было и не считать. Вот они, те же цифры.

Причем, большие скорости только при первом воспроизведении после открытия проекта, пока контакты подгружают семплы на лету. Когда они это сделали, скорости падают до совсем уж неприличных 10-20 мб\с. Но я помню, что когда я только настраивал свой рейд массив из ссд, то вначале я сделал кое-что не правильно и он у меня работал на уровне одиночного ссд, и патчи в контакт грузились заметно дольше, чем на нормальной скорости для рейда. То есть большая скорость диска всё-таки влияет на быстроту загрузки контакта..
 
Последнее редактирование:
@Dmitry Stepin, да откуда там большая очередь запросов возьмется, если они выполняются быстрее, чем поступают? Это для хардов актуально, с их менее чем 300 iops.
Скорость падает, если вообще всё в память перегружено.В принципе... если оперы много, при втором проигрывании так и должно быть, те же сэмплы, их из RAM никто не тёр. Но это смотря сколько всего употреблено... Если в тутти фигачит весь состав библ размером в терабайт... то даже при том, что играется лишь малая часть диапазонов, всё равно может понадобиться под соточку гигов оперативки... А в ней же еще полным-полно всего, кроме сэмплов.

нужно просто побольше отдельных ссд (можно даже простых сата-3)
угу... можно даже сата2, что характерно. Я пробовал даже софт-рейд виндовый собирать, причем из разных ссдшек, ничо так :cool:
 
  • Like
Реакции: smack и Dmitry Stepin
@Scarlatino, оптимально - не морочиться. Система предложит размер "по умолчанию" - соглашайся. Выбирать имело смысл раньше, при создании рейд-массива жестких дисков под хранение (тогда да, нужен кластер побольше, чтоб режим работы был ближе к последовательному чтению).
 
  • Like
Реакции: Scarlatino

Сейчас просматривают