Свежие комментарии

Title	Comment
дома с 7-10 перешел просто, и	дома с 7-10 перешел просто, и в остальных местах довольно ровненько переходится.
Нет, спасибо!	Нет, спасибо! Переход 7-8.1 уже был сексуальным, боюсь что 8-10 будет не лучше. Ключей для 10-ки у меня полный MSDN, виртуалки есть, физическая есть, а с переходом я подожду еще полгодика.
почему 8.1-то? вроде же еще	почему 8.1-то? вроде же еще пару дней как можно обновить до 10-ки?
Там и с радиатором есть	Там и с радиатором есть варианты. Но у меня на слоты дует отдельный карлсон - потому что без него греется 10G Intel. И на самсунг хватит.
О, я тоже на эту их 3Тб серию	О, я тоже на эту их 3Тб серию попал, из 6 до конца гарантии дожило 2, хорошо хоть деньги вернулись даже без потерь, потом выжившие я куда-то спихнул, нафиг-нафиг.))
Эх, я тот пост пропустил, для	Эх, я тот пост пропустил, для самса лучше взять вот такой: http://www.ebay.com/itm/222168424398 У меня, кстати, есть лишний, если в Москве. Так ему комфортней будет, особенно если под видюхой поставить. Кстати последи за температурами, во время теста и при большом копировании, после 70 он может начать замедляться, а греется он очень охотно.
Ну если работа - на работе,	Ну если работа - на работе, то да. У меня то - ночью встал пописать, заодно заглянул и на работу, почту глянуть.
Я перестал хотеть, когда	Я перестал хотеть, когда понял, что собрав себе новую WS (скайлейк старший, 32 гига, 850 Evo), я сажусь за неё на 2-3 часа в субботу и 2-3 часа в воскресенье. Что-то последний год сил что-то делать дома кроме как жрать и спать нет вообще.
Ну да.	Ну да. Но я думал что 3 гигабита - это 3 гигабита. А там 260Mb/sec. Чуть больше двух гигабит.
Ну вот я резко захотел ТАКОГО	Ну вот я резко захотел ТАКОГО, когда у меня не только макбук стал (некоторые форматы) RAW показывать быстрее, чем WS, но и ПЛАНШЕТ.
Ну как бы намекалось, что	Ну как бы намекалось, что разнородные диски (как ещё оказалось на разноскоростных портах) в страйпе всегда будут работать со скоростью самого медленного :-).
Экспериментально выяснено,	Экспериментально выяснено, что два SSD в страйпе (на SATA-600 портах) работают быстрее трех (600+600+300). Поэтому два SSD в страйпе. Ща мы еще тут поиграем в "15" и на 60-ки разложим скомпилированный Qt (это фактически RO, а место на быстрых дисках под него жалко)
Картинка заслоняет! :)	Картинка заслоняет! :) У меня теперь на матери даже дырка под него есть без переходников. Эх!
никто ничего не читает :(	никто ничего не читает :( первая строчка поста.
Это 950 Pro?	Это 950 Pro?
Если не жалко ssd :-), то	Если не жалко ssd :-), то нижнюю оценку по скорости записи можно легко произвести. На блочном уровне заполнить весь объём с помощью dd if=/dev/random (random действительно медленный, у меня dd if=/dev/random of=/dev/zero около 70Mb/s, придётся довольно долго ждать :-)). Затем с помощью fio запустить случайную запись блоками 64kB (или наверно даже правильнее 128kB) наверное в два потока (я думаю этого будет достаточно) на весь выделенный объём объёмом записи на пару гигабайт (пример запуска: fio --name=random128k --rw=randwrite --filename=/dev/stripe/L2ARC --bs=128k --group_reporting --thread --numjobs=2 --size=2g --direct=1 --gtod_reduce=1). Получится практически точная эмуляция записи в L2ARC на заполненном ssd. Также можно заодно проверить с помощью dd скорость чтения. Но я думаю скорость чтения из пула (8 дисков в raidz2) будет для этой конфигурации кэша (три ssd в страйпе) довольно высока. Поэтому наверно надо смириться, что при последовательном чтении кэш просто не будет успевать записывать и часть считанных данных будет пролетать мимо кэша :-).
Lr по идее кэш равок не	Lr по идее кэш равок не держит. В любом же случае, при нынешнем размере файлов - ни в какой RAM кэш большая сессия съемочная не влезет. И от чего хочется уйти - это от копирования всего на SSD, работы, потом копирования результатов обратно,хочется чтобы оно само, в фоне, пусть не 100% оптимально, а только 75.
Скорость линейной записи	Скорость линейной записи нулей на этот страйп - ~900mb/sec. Жмется, понятно. Скорость чтения "не нулей" что я видел по iostat- 750mb/s Скорость записи не нулей - неизвестна, /dev/random сильно медленнее
Для Lightroom по идее то же	Для Lightroom по идее то же самое? Хоть там превьюшки локально хранятся, но при переключении в 1:1 оно вроде основной файл подтягивает.
Это типичная нагрузка если	Это типичная нагрузка если "работать с фоточками". Особенно если работать не "только сегодня", а постепенно обрабатывать большую съемку. Ну там неделю сидеть и обрабатывать. FRV, потом raw-конвертор. FRV - держит кэш прочитанных, но не очень большой, максимум можно выставить - 40 файлов. Но это в одной сессии работы же.
Согласен :-).	Согласен :-). Пункт два - это несогласованность скорости чтения с пула (hdd) и скорости чтения/записи c кэша (ssd). По моему опыту скорость кэша (ssd) по возможности должна грубо превосходить в три раза скорость пула (hdd). Если со скоростью чтения всё вроде нормально, то со скоростью записи есть вопросы. Кстати, пункт два может быть довольно часто встречаемым в реальной жизни. Можно нарваться на ситуацию, что пункт 4 будет постоянно куда-то убегать :-). "Дальше прыгает". Я тоже это наблюдал и меня это немного смущает :-).
А это типичная нагрузка -	А это типичная нагрузка - чтение каталога по несколько раз? FRV раз за разом картинку снова читает, если по файлам туда-сюда бегать? По идее, NVMe диск в качестве L2ARC должен рулить. А если на нём ещё и overprovisioning сделать (под L2ARC отдать только половину диска), так совсем хорошо должно стать?
Профит есть, он огромен. Вот	Профит есть, он огромен. Вот последовательные чтения одного и того же каталога (ранее в тестировании не принимал участия). Каталог 70Gb, 1866 файлов, ARC - 14Gb, L2Arc - 120. 1-й раз, 3:31 (т.е. 330MB/sec). В L2ARC попала примерно половина 4:02 (289 MB/s), наибольшая нагрузка была на L2ARC, туда что-то активно вытесняло 2:31 (463) 1:50 (636) 1:30 (777) дальше прыгает 1:50-1:55/1:30-1:40 Начиная с 4-го прохода в L2ARC ничего не писало практически. То есть 4-е и далее "чтение каталога" - выигрыш 2x где-то. Надо еще поиграться с мелкими файлами (вполне возможно, что будет выигрыш по latency еще больше, чем "в линейной скорости) размером страйпа у gstripe.
zfs читает с L2ARC на	zfs читает с L2ARC на удивление хорошо. При чтении одного большого файла стабильно видна очередь в три запроса чтения по 128kB к ssd. Если верны мои предположения и блок L2ARC равен 64kB, то это как бы намекает на оптимизацию (присутствие планировщика) чтения. С другой стороны видно, что если закэшировалась только часть файла, то профита как бы и не видно. Как обеспечить кэширование файла при чтении в полном объёме пока не ясно. Да и в комментариях к исходному коду разработчики настаивают "The main role of this cache is to boost the performance of random read workloads.". Хотя файл впервые публиковался в 2005 и возможно многое поменялось :-).
Да, TRIM используется, похоже	Да, TRIM используется, похоже, только при полной чистке, но не при замещении.
Мой друг передает, что если	Мой друг передает, что если толк от SSD-L2ARC есть (а по "жизненным тестам" - он есть, причем дело именно в latency - у один раз (давно) прочитанного набора файлов - превьюшки в FRV показываются мгновенно "как с локального SSD"), то купить пару мелких (60-100Gb) серверных SSD - совершенно не заломает. Пока же - ну сточу эти старые диски, ну так и хрен с ними, им срок жизни по любому подходит к.
Я уже писал о	Я уже писал о "непредсказуемости" :-). Если посмотреть на "классический" подход по кэшированию читаемых данных, то увидим "понятные/предсказуемые" алгоритмы/политики. У flashcache и bcache кэшировать всегда по первому чтению. У dm-cache эта величина настраивается (по умолчанию, если мне не изменяет память, кэшировать после четвёртого (или восьмого) чтения). У L2ARC, как я понимаю, во время чтения текущие данные попадают (если они ещё не там) в ARC, а выталкиваться в L2ARC должны данные, которые находятся в конце LRU(MRU). Что это за данные - это ещё вопрос :-). Также нужно учитывать, что MFU живёт "своей жизнью" и тоже периодически забирает/отдаёт данные в LRU(MRU). Также существуют ghost списки недавно вытесненных данных из кэша. Причём у LRU(MRU) и MFU они свои :-). Если к этому добавить настраиваемые sysctl по ограничению/разрешению записи в L2ARC (.l2arc_noprefetch, .l2arc_write_max, .l2arc_norw, ...) и влияние соотношения размера файла и размера ARC (пока ещё не совсем понятного), то предсказать, когда читаемые данные попадут в L2ARC и в каком объёме становиться довольно сложно (если вообще возможно) :-). При замещении данных в L2ARC данные пишутся поверх старых. Вывод при полном заполнении L2ARC будет снижаться скорость записи на ssd. Никакие техники поддержания скорости записи заполненного ssd (TRIM, Over-Provisioning) на уровне L2ARC не применяются :-(. Хотя для применённой политики замещения LRU в L2ARC этого наверно и стоило ожидать. "Твоему другу", исходя из марок его ssd, стоит это учитывать. Хотя для некоторых ssd построенных на SandForce и TRIM бы мало помог :-). Также есть подозрение об использовании части одних и тех же ssd под ZIL и L2ARC. Как бы это вступает в противоречие с попыткой получить высокую производительность :-). Если ещё учесть gstripe, то ... :-))).
Вот что-то я в полном	Вот что-то я в полном недоумении. Есть folder, 21Gb, примерно вдвое больше ARC делают tar cf /dev/null folder много раз подряд. И смотрю на zpool iostat -v 5 Через раз. После каждого прогона выжидаю, пока все по нулям по IO устаканится - ~100% чтений из L2ARC, общее время на исполнение 24 cек - ~20% чтений с HDD. 35 секунд Система только в том, что оно так мигает, строго через раз. Пойду опять напьюсь
Пока не дошёл - не знаю, но	Пока не дошёл - не знаю, но перед началом тестирования у себя включил. Посмотрим :-).
trim_enabled=0 не отлючит ли	trim_enabled=0 не отлючит ли TRIM на l2arc тож?

Свежие комментарии

Pages