Диск изначально весь SLC. По мере записи SLC меняется на TLC.
Поэтому SLC-кеш изначально объемом в весь диск, по мере записи SLC-кеш уменьшается до некоего уровня.
Поэтому пока первый раз такой диск полностью не запишешь, он будет более высокие скоростные характеристики показывать и выше надёжность.
Примечательно в результатах там то, что при многопоточной записи производительность сильно падает, что видимо объясняется частым переключением контекстов (т.е. большое количество виртуалок на хосте — плохо), а производительность чтения совершенно неадекватна т.к. в реальности чтение происходит из ОЗУ хостовой ОС, а не с дисков.
Ну и да, бенчмаркать дисковую систему очень нетривиально т.к. много что может сильно влиять на производительность и может случиться, что измеряешь не производительность nvme, а производительность своей программно-аппаратной конфигурации, которая в руках другого человека с другой конфигурацией железа, но теми же дисками не воспроизведется.
CrystalDiskMark вроде никогда адекватных результатов для SSD и не показывал, его вообще не надо было использовать. Посмотрите обзоры IXBT и что они используют. Попробуйте IOmeter, там можно детально нагрузкой управлять как по чтению, так и по записи.
RAID сейчас многие собирают софтово. В винде же тоже можно, вот бы и собрали, раз так нужно. С софтовым RAID может быть печально если ОС умрет, но при обновлении ОС все равно все виртуалки смигрируются, так что не так опасно, а вот если аппаратный контроллер помрет, то веселья будет заметно больше. Количество багов к аппаратным контроллерам тоже не внушает уверенности в сохранности данных.
Здесь выше писали, что при записи в одну очередь разницу между nvme/sas/sata увидеть сложно т.к. тормозом является непосредственно запись в SSD, а не интерфейс. Гигабайты в секунду получаются при записи большой очередью т.к. SSD будут писать в разные ячейки одновременно и на этом можно прокачать IOPS и полосу пропускания. При последовательной записи и быстрые и медленные SSD выдадут на блоках по 4K около 50 тыс. IOPS.
При этом многие практически приложения были сильно оптимизированы во времена HDD чтобы писать последовательно в один поток (например СУБД) и у меня сайты на Drupal сохраняют материалы на SSD всего-лишь в два раза быстрее HDD (а никак не в сотни раз быстрее формальной разницы в IOPS). Поэтому синтетика может сильно завышать скорость по сравнению с реальными приложениями. На тех же СУБД, если вся база в ОЗУ влазит, не надо удивляться, что при чтении IOPS к дискам нет и использование nvme не дает прироста производительности.
Латентность на скриншотах в посте в десятки миллисекунд типична для HDD, а не SSD. Латентность SSD обычно в 50 раз меньше латентности HDD. C этим определенно надо разбираться, как и с провалом на 45ГБ.
Не написано, выключался ли WriteCache в хостовой Windows и в SATA RAID. Думаю не надо объяснять как кеш на запись может на результаты повлиять.
Сейчас SLC-кеши могут быть динамические. Пока диск первый раз не перезаписан, всё свободное пространство может быть SLC. Затем постепенно SLC может уменьшаться до некоторого порога, который в корпоративных дисках сильно больше домашних.
Так выдать теорию в цифре, а кто хочет пусть пишет опорный конспект для запоминания.
В реальности же так: «теории в цифре такой как у меня в мозгу нигде нет, свой суперценный контент я вам не выдам чтоб только я владел им <дьявольский смех>, так что сидите и записывайте, на экзамене проверю».
Ну и запомнить — не значит понять теорию. А надо чтобы поняли.
Для понимания надо добавить задачи и тесты прямо в теорию. Только тестировать с мелом на доске как-то сложно, поэтому нужно все сделать в цифре.
Чтение сериализованного объекта из СУБД скорее всего будет работать быстрее чтения с файловой системы.
Ну и кроме ACID в СУБД есть индексы.
На файлах хранилище тоже раз делал в электронной библиотеке для киосков. Но там задача стояла сделать что-то, что можно поставить в один клик и при этом архитектурно:
1) nodejs при запуске приложения сканирует все файлы и составляет поисковый индекс в памяти процесса (долгий старт даже на 4 тыс. файлах).
2) скрипт поиска не умел в перестроение индекса, поэтому при импорте новых ресурсов надо перезагрузить всю программу (но это баг конкретного поисковика на JS)
3) есть ограничения на длину имени файла на файловой системе
4) столкнулся с проблемой, что некоторые файлы, созданные nodejs, нельзя потом удалить через проводник Windows или через консоль (в чём проблема так и не разобрался)
Ну и бенчмарки показывают, что ОС очень не любят сильноконкурентный случайный доступ к файловой системе — нелинейно падает производительность ввода-вывода. Что в общем и понятно, файл может в файловом кеше ОС находиться, но чтобы прочитать оттуда, надо системный вызов дёрнуть.
В случае использования какого-нибудь stateless языка типа PHP, использование множества файлов в качестве БД совсем плохой идеей кажется: ни поиска ни индексов на файлах как-то не хочется делать, а если для поиска и индекса БД использовать, то и данные логично там же хранить.
Если документы существуют только на сервере, можно серверный рендеринг использовать как здесь: elibsystem.ru/node/186, но от него текстовые pdf распухают и есть проблема при ресайзе (пользователь решил увеличить).
Если в pdf много изображений, рендеринг может подтормаживать, так что рендерить лениво — правильное решение.
А так если нужно с удобной корпоративной лицензией, то здесь стоит смотреть pdfium или apache pdfbox. Ну или покупать. Купить можно mupdf (или более старый ghostscript), но есть также коммерческие библиотеки на java.
Есть групповая работа (2 ученика на одном устройстве задание выполняют). Школа может планшеты выдавать на время занятий (есть станции зарядки и т.п., так что решить можно).
Просто HTML5 сделал всё это не нужным.
Ценность Flash в том, что он улучшал веб тогда, когда в этом была острая необходимость. Но развитие веба ценность свело на нет и Adobe приняли вполне разумное решение сосредоточиться на развитие веба в рамках HTML5 и перестроить свои продукты на HTML5, а не продавливать пользователей на Flash, который к тому же не работал без Adobe AIR на смартфонах.
З.Ы. Adobe AIR они продали Samsung-у (Harman точнее), а Flash в Китае, судя по всему, вполне развивается, так что дело не в деньгах, а в выборе стратегического пути: можно развивать прогресс, а можно тормозить. Adobe поступила так, как и должен был поступить один из лидеров в создании ПО.
А она у них и была:
1) Продажи Flash Builder;
2) Продажа систем DRM с шифрованием контента для видео и PDF, работающих во FlashPlayer с оплатой за дешифровку каждого ресурса;
3) Продажа установок антивирусов вместе с Flash;
4) Продажа корпоративных подписок;
5) Продажа некоторых фичей движка разработчикам игр.
Когда весь мир пользуется Adobe Flash — видимо хватало на содержание команды и кэш конторе.
Вот я тоже про «родительский контроль» в общественном обсуждении стандарта «цифровой школы» написал.
Но здесь надо понимать «политический момент». Ростелеком в фильтры продвигает Минцифры (хотя слова Ростелеком с стандарте не звучит, но все догадываются кто будет единственным исполнителем подключений школ к интернету). Фильтры — это деньги.
Можно приложение для родительского контроля написать и предложить его взволнованным родителям поставить на смартфоны учащихся, а можно «выделенные защищенные ГОСТовским шифрованием каналы с функцией фильтрации трафика» вписать в многомиллиардную программу подключения школ к интернету.
Не сложно догадаться какой вариант будет выбран.
З.Ы. Ни ответа ни привета на мои предложения от Минпросвета не последовало.
1. SLC работает на запись быстрее MLC/TLC/QLC;
2. У SLC меньше износ.
Поэтому SLC-кеш изначально объемом в весь диск, по мере записи SLC-кеш уменьшается до некоего уровня.
Поэтому пока первый раз такой диск полностью не запишешь, он будет более высокие скоростные характеристики показывать и выше надёжность.
Примечательно в результатах там то, что при многопоточной записи производительность сильно падает, что видимо объясняется частым переключением контекстов (т.е. большое количество виртуалок на хосте — плохо), а производительность чтения совершенно неадекватна т.к. в реальности чтение происходит из ОЗУ хостовой ОС, а не с дисков.
Ну и да, бенчмаркать дисковую систему очень нетривиально т.к. много что может сильно влиять на производительность и может случиться, что измеряешь не производительность nvme, а производительность своей программно-аппаратной конфигурации, которая в руках другого человека с другой конфигурацией железа, но теми же дисками не воспроизведется.
RAID сейчас многие собирают софтово. В винде же тоже можно, вот бы и собрали, раз так нужно. С софтовым RAID может быть печально если ОС умрет, но при обновлении ОС все равно все виртуалки смигрируются, так что не так опасно, а вот если аппаратный контроллер помрет, то веселья будет заметно больше. Количество багов к аппаратным контроллерам тоже не внушает уверенности в сохранности данных.
Здесь выше писали, что при записи в одну очередь разницу между nvme/sas/sata увидеть сложно т.к. тормозом является непосредственно запись в SSD, а не интерфейс. Гигабайты в секунду получаются при записи большой очередью т.к. SSD будут писать в разные ячейки одновременно и на этом можно прокачать IOPS и полосу пропускания. При последовательной записи и быстрые и медленные SSD выдадут на блоках по 4K около 50 тыс. IOPS.
При этом многие практически приложения были сильно оптимизированы во времена HDD чтобы писать последовательно в один поток (например СУБД) и у меня сайты на Drupal сохраняют материалы на SSD всего-лишь в два раза быстрее HDD (а никак не в сотни раз быстрее формальной разницы в IOPS). Поэтому синтетика может сильно завышать скорость по сравнению с реальными приложениями. На тех же СУБД, если вся база в ОЗУ влазит, не надо удивляться, что при чтении IOPS к дискам нет и использование nvme не дает прироста производительности.
Латентность на скриншотах в посте в десятки миллисекунд типична для HDD, а не SSD. Латентность SSD обычно в 50 раз меньше латентности HDD. C этим определенно надо разбираться, как и с провалом на 45ГБ.
Не написано, выключался ли WriteCache в хостовой Windows и в SATA RAID. Думаю не надо объяснять как кеш на запись может на результаты повлиять.
Тестирование Ceph можно, например, здесь посмотреть: www.proxmox.com/en/downloads/item/proxmox-ve-ceph-benchmark-2020-09
Если нужно совсем без SLC, то это Intel Optane.
SMB (Samba): 5-7%;
NFS: 30%;
GlusterFS: 70%.
Это цифры в каком-то смысле «сферический конь в вакууме», естественно.
В реальности же так: «теории в цифре такой как у меня в мозгу нигде нет, свой суперценный контент я вам не выдам чтоб только я владел им <дьявольский смех>, так что сидите и записывайте, на экзамене проверю».
Ну и запомнить — не значит понять теорию. А надо чтобы поняли.
Для понимания надо добавить задачи и тесты прямо в теорию. Только тестировать с мелом на доске как-то сложно, поэтому нужно все сделать в цифре.
Ну и кроме ACID в СУБД есть индексы.
На файлах хранилище тоже раз делал в электронной библиотеке для киосков. Но там задача стояла сделать что-то, что можно поставить в один клик и при этом архитектурно:
1) nodejs при запуске приложения сканирует все файлы и составляет поисковый индекс в памяти процесса (долгий старт даже на 4 тыс. файлах).
2) скрипт поиска не умел в перестроение индекса, поэтому при импорте новых ресурсов надо перезагрузить всю программу (но это баг конкретного поисковика на JS)
3) есть ограничения на длину имени файла на файловой системе
4) столкнулся с проблемой, что некоторые файлы, созданные nodejs, нельзя потом удалить через проводник Windows или через консоль (в чём проблема так и не разобрался)
Ну и бенчмарки показывают, что ОС очень не любят сильноконкурентный случайный доступ к файловой системе — нелинейно падает производительность ввода-вывода. Что в общем и понятно, файл может в файловом кеше ОС находиться, но чтобы прочитать оттуда, надо системный вызов дёрнуть.
В случае использования какого-нибудь stateless языка типа PHP, использование множества файлов в качестве БД совсем плохой идеей кажется: ни поиска ни индексов на файлах как-то не хочется делать, а если для поиска и индекса БД использовать, то и данные логично там же хранить.
Хотя да, вот пруф: www.chromestatus.com/feature/6206321818861568
Если в pdf много изображений, рендеринг может подтормаживать, так что рендерить лениво — правильное решение.
А так если нужно с удобной корпоративной лицензией, то здесь стоит смотреть pdfium или apache pdfbox. Ну или покупать. Купить можно mupdf (или более старый ghostscript), но есть также коммерческие библиотеки на java.
Что бы тягаться с Flash, надо рендерер SVG в Canvas делать. Ну собственно оно и сделано: github.com/canvg/canvg.
Есть групповая работа (2 ученика на одном устройстве задание выполняют). Школа может планшеты выдавать на время занятий (есть станции зарядки и т.п., так что решить можно).
Если же исходить из тезиса, что у учащихся свой тырнет на смартфонах, то вообще никакие блокировки не нужны.
Ценность Flash в том, что он улучшал веб тогда, когда в этом была острая необходимость. Но развитие веба ценность свело на нет и Adobe приняли вполне разумное решение сосредоточиться на развитие веба в рамках HTML5 и перестроить свои продукты на HTML5, а не продавливать пользователей на Flash, который к тому же не работал без Adobe AIR на смартфонах.
З.Ы. Adobe AIR они продали Samsung-у (Harman точнее), а Flash в Китае, судя по всему, вполне развивается, так что дело не в деньгах, а в выборе стратегического пути: можно развивать прогресс, а можно тормозить. Adobe поступила так, как и должен был поступить один из лидеров в создании ПО.
1) Продажи Flash Builder;
2) Продажа систем DRM с шифрованием контента для видео и PDF, работающих во FlashPlayer с оплатой за дешифровку каждого ресурса;
3) Продажа установок антивирусов вместе с Flash;
4) Продажа корпоративных подписок;
5) Продажа некоторых фичей движка разработчикам игр.
Когда весь мир пользуется Adobe Flash — видимо хватало на содержание команды и кэш конторе.
Но здесь надо понимать «политический момент». Ростелеком в фильтры продвигает Минцифры (хотя слова Ростелеком с стандарте не звучит, но все догадываются кто будет единственным исполнителем подключений школ к интернету). Фильтры — это деньги.
Можно приложение для родительского контроля написать и предложить его взволнованным родителям поставить на смартфоны учащихся, а можно «выделенные защищенные ГОСТовским шифрованием каналы с функцией фильтрации трафика» вписать в многомиллиардную программу подключения школ к интернету.
Не сложно догадаться какой вариант будет выбран.
З.Ы. Ни ответа ни привета на мои предложения от Минпросвета не последовало.