Согласен. Но размер страницы памяти скорее всего не будет указан в даташите накопителя, да и у разных накопителей размер страницы может быть разным и при превышении размера можно столкнуться с распараллеливанием. Поэтому не так очевидно что измерять в качестве показателя, да и опять же к реальной нагрузке этот показатель будет спорное отношение иметь, больше теоретический интерес.
Ну в данном случае соглашусь, что запись первые 13% - это не ОЗУ, а видимо SLC-кеш, так как вряд ли на SSD ОЗУ 128 ГБ под кеш записи выделено.
Но: 1) нет никаких гарантий, что AIDA64 делает fsync в процессе бенча и если делает, то после скольки блоков она его делает? 2) SSD с конденсаторами при fsync сразу врут, что записали на энергонезависимую память, так как могут гарантировать запись за счет конденсаторов и тут рядом есть бенч на эту тему: https://habr.com/ru/post/708768/comments/#comment_25073958
По факту если взять скорость записи в ячейку, то видимо она сильно не выросла за эти годы, а прирост линейной скорости записи происходит за счет возможности параллельной записи (ваши данные, которые вы пишите мегабайтами в один поток по факту разбиваются на несколько очередей и пишутся параллельно в разные микросхемы SSD (не знаю как их правильно называть). Чтобы запись внутри параллелилась, надо или чтобы была большая очередь на запись или блоки на запись сами были большими (сотни кбайт или мегабайты).
Но тут, конечно, что увидеть хочешь в бенче. Если хочешь примерно увидеть скорость записи в микросхему памяти, надо долбить записью мелким блоком (скажем в 4к) и после каждого блока fsync вызывать. Ну и диск при этом без кондера должен быть и не врать о записи сразу же по получению fsync.
Но этот бенч будет оценкой снизу, реальная нагрузка будет более оптимальна для распараллеливания.
По тем данным, что я встречал, стоимость переключения контекста оценивается в 1 мксек. При 35к IOPS, если каждая операция IO приводит к переключению контекста, получаем 35k * 1 мксек = 0.035 сек - оверхед на переключение контекста в секунду на операции IO. Таким образом можно предположить, что сисколы имеют вклад в IOPS на уровне процентов и в разы влиять на IOPS не должны.
4k 1Q 1T: 106 Мб чтение и 365 Мб запись. И это на файле в 1ГБ, то есть не пробивая SLC-кеш на запись, а как пробьете, скорость на запись упадет в разы.
Если же говорить про 1M Q8 T1, то это фактически пишут пачками по 8 Мб и в SSD действует внутренний распараллеливающий механизм, то есть это для ОС запись последовательная, а по факту она параллельная и на файле в 1ГБ это вообще тест ОЗУ SSD. А надо писать так, чтобы если уж такие объемы записи, чтобы пробить SLC кеш диска и тогда у вас скорость тоже драматическим образом упадет.
Поэтому дайте нормальный бенчмарк на файле с 200 Гб или такого размера, чтобы пробить SLC-кеш конкретного SSD (и уж тем более его ОЗУ). Лучше всего fio.
Ну я пока сталкивался только с невозможностью автоматической генерации обложки (не может изображение из PDF извлечь, не может отресайзить, кончилось таки место в кеше и т.д.) ну и просто в логи попадает ошибка и команда с помощью которой обложку пытались сгенерировать.
А на фронте особо нечему ломаться, главное оттестировать непосредственно сам алгоритм ленивой загрузки с fallback при ошибке.
Ну отслеживать не сложно. Координаты изображения можно узнать от верха экрана. Высота и ширина экрана известны. Математика уровня 5 класса.
Тут надо пояснить проблему и почему именно такое решение. Вот пользователь схватил скролл и проскролил одним рывком 100 обложек. При классическом подходе или с loading="lazy" попав в вьюпорт они начнут все отображаться. Но встанут в очередь и будет единовременно в процессе загрузки не более 6 (так как столько потоков по умолчанию в браузерах). И все, пока все эти 100 не загрузятся по 6 штук, 101 обложка, до которой домотал пользователь, грузиться не будет. А сколько это времени займет? Ну если одна обложка по 50к, то 5 Мб пока не скачается...
То есть если пользователь резко крутанул скролл, он и должен увидеть заглушку (если она предполагается на время загрузки) и лишь когда перестанет быстро мотать заглушки постепенно (по 6 шт) сменятся обложками.
Вспомнил еще один хинт с обложками: если быстро крутится полоса прокрутки, то обложки грузятся не сразу, а после задержки на тот случай, если их уже прокрутили через экран, то не начинать загрузку.
Ну собственно, это одна из причин реализации собственного loading="lazy".
А какую-то часть кода из SSR исключить нельзя, чтоб она так и передалась как <script>..?
Вообще с бесплатностью CPU история более сложная: если на сервере рендеринг утилизирует все ядра, значит отвечать сервер на другие (конкурентные) запросы будет медленнее и начнут падать показатели по скорости загрузки страниц.
У меня при очистке кеша это прямо проблемой становится. И проблема эта частая, например в NextCloud для генерации обложек можно выделенный сервер запустить, чтобы нагрузка на него не замедляла слишком сильно остальное.
У меня в электронной библиотеке тоже есть задача динамического сжатия PDF-страниц и обложек ресурсов. Обложки выводятся React, вначале подставляется URL на кешированное значение обложки, если его нет, срабатывает fallback на динамическую генерацию нужной ширины. Сгенерированные обложки кладутся в кеш и в следующий раз обращение попадет в кеш и отдастся напрямую nginx.
Из форматов если исходный SVG, то отдается SVG. Если исходник не в SVG, то если браузер поддерживает, отдается webp, а если не поддерживает, то PNG или JPG в зависимости от того, в каком формате исходник (PNG на случай если в исходном PNG есть прозрачность). Про AVIF думал, но пока долго динамически генерировать, не хочется, чтобы на сервер слишком большая нагрузка пришлась.
По поводу сжатия, у меня WebP дает те самые 20-25% что гугл и обещал по сравнению с JPEG при, как правило, лучшем качестве.
Про devicePixelRatio не понял в чем проблема прочитать его из JS и выставить правильный URL. srcset я не использую именно из-за fallback при промахе мимо кеша: при промахе надо динамически подставить другой URL и в это время и devicePixelRatio известен.
Также есть забавный момент, что реализован собственный аналог loading="lazy" так как он лениво загружает когда изображение выходит за пределы экрана по вертикали, а когда по горизонтали (горизонтальный скролл), то все равно грузит. Ну и не очень устраивало в какой момент браузер решает подгрузить изображение.
AVIF пока не использую так как слишком большая нагрузка и у меня обложки в кеш не на все время попадают, а чистятся если место под кеш закончится (первым удаляются обложки к ресурсам, которые давно не открывались). Думаю как-нибудь стоит потыкать в видюхи Intel ARC, может они смогут аппаратно генерить AVIF через аппаратный кодировщик?
То есть мой вывод такой, что изображения надо целиком на js отрисовывать, тогда это управляемо.
А 7 ГБ/c с SSD в типичных нагрузках вы и сейчас не увидите. Увидите 70-100Мб/c в однопоток. Ну а ваши базы данных в однопоток и пишут и писать в 50 потоков, чтобы нагрузить SSD параллельной записью, просто не способны.
ZFS отлично и без ECC работает. ЕСС - это не требование, а настоятельная рекомендация.
ECC лучше иметь на любом сервере, если, конечно, вам не все равно на скрытую порчу обрабатываемых данных.
Представьте, что у вас испортилась ячейка памяти и вы из нее читаете не то, что записали. Как это скажется на работе ПО на сервере? Скажется непредсказуемым образом. И тут не важно будет этим ПО ZFS, РСУБД или что-то еще.
Да, SAS HDD обычно на 10 и 15 тыс. оборотов, в то время как SATA на 7200 или 5400. Хотя был WD VelociRaptor на 10 тыс. и с SATA-интерфейсом.
То есть скорость вращения не характеризует как таковая интерфейс, а в сегодняшних условиях покупать HDD на 15 тыс. оборотов "для скорости" дороже SSD той же емкости выглядит совсем уж странным.
Ну это надо именно бенчить, есть же еще ФС над HDD. Так по памяти где-то читал, что PostgreSQL пишет по 8к, а InnoDB по 16к.
Там не написано, что fsync игнорируется. Написано, что не гарантируется очередность записи.
Согласен. Но размер страницы памяти скорее всего не будет указан в даташите накопителя, да и у разных накопителей размер страницы может быть разным и при превышении размера можно столкнуться с распараллеливанием. Поэтому не так очевидно что измерять в качестве показателя, да и опять же к реальной нагрузке этот показатель будет спорное отношение иметь, больше теоретический интерес.
Ну в данном случае соглашусь, что запись первые 13% - это не ОЗУ, а видимо SLC-кеш, так как вряд ли на SSD ОЗУ 128 ГБ под кеш записи выделено.
Но:
1) нет никаких гарантий, что AIDA64 делает fsync в процессе бенча и если делает, то после скольки блоков она его делает?
2) SSD с конденсаторами при fsync сразу врут, что записали на энергонезависимую память, так как могут гарантировать запись за счет конденсаторов и тут рядом есть бенч на эту тему: https://habr.com/ru/post/708768/comments/#comment_25073958
По факту если взять скорость записи в ячейку, то видимо она сильно не выросла за эти годы, а прирост линейной скорости записи происходит за счет возможности параллельной записи (ваши данные, которые вы пишите мегабайтами в один поток по факту разбиваются на несколько очередей и пишутся параллельно в разные микросхемы SSD (не знаю как их правильно называть). Чтобы запись внутри параллелилась, надо или чтобы была большая очередь на запись или блоки на запись сами были большими (сотни кбайт или мегабайты).
Но тут, конечно, что увидеть хочешь в бенче. Если хочешь примерно увидеть скорость записи в микросхему памяти, надо долбить записью мелким блоком (скажем в 4к) и после каждого блока fsync вызывать. Ну и диск при этом без кондера должен быть и не врать о записи сразу же по получению fsync.
Но этот бенч будет оценкой снизу, реальная нагрузка будет более оптимальна для распараллеливания.
По тем данным, что я встречал, стоимость переключения контекста оценивается в 1 мксек. При 35к IOPS, если каждая операция IO приводит к переключению контекста, получаем 35k * 1 мксек = 0.035 сек - оверхед на переключение контекста в секунду на операции IO. Таким образом можно предположить, что сисколы имеют вклад в IOPS на уровне процентов и в разы влиять на IOPS не должны.
Сейчас нет данных под рукой, но по памяти штраф не нулевой даже у Optane. А есть бенч где нулевой?
4k 1Q 1T: 106 Мб чтение и 365 Мб запись. И это на файле в 1ГБ, то есть не пробивая SLC-кеш на запись, а как пробьете, скорость на запись упадет в разы.
Если же говорить про 1M Q8 T1, то это фактически пишут пачками по 8 Мб и в SSD действует внутренний распараллеливающий механизм, то есть это для ОС запись последовательная, а по факту она параллельная и на файле в 1ГБ это вообще тест ОЗУ SSD. А надо писать так, чтобы если уж такие объемы записи, чтобы пробить SLC кеш диска и тогда у вас скорость тоже драматическим образом упадет.
Поэтому дайте нормальный бенчмарк на файле с 200 Гб или такого размера, чтобы пробить SLC-кеш конкретного SSD (и уж тем более его ОЗУ). Лучше всего fio.
Ну я пока сталкивался только с невозможностью автоматической генерации обложки (не может изображение из PDF извлечь, не может отресайзить, кончилось таки место в кеше и т.д.) ну и просто в логи попадает ошибка и команда с помощью которой обложку пытались сгенерировать.
А на фронте особо нечему ломаться, главное оттестировать непосредственно сам алгоритм ленивой загрузки с fallback при ошибке.
Раз пошла речь за avif, то у кого CentOS8, вот репозитарий с libavif-tools (avifenc), чтоб руками не собирать: https://elibsystem.ru/node/641
Ну отслеживать не сложно. Координаты изображения можно узнать от верха экрана. Высота и ширина экрана известны. Математика уровня 5 класса.
Тут надо пояснить проблему и почему именно такое решение. Вот пользователь схватил скролл и проскролил одним рывком 100 обложек. При классическом подходе или с loading="lazy" попав в вьюпорт они начнут все отображаться. Но встанут в очередь и будет единовременно в процессе загрузки не более 6 (так как столько потоков по умолчанию в браузерах). И все, пока все эти 100 не загрузятся по 6 штук, 101 обложка, до которой домотал пользователь, грузиться не будет. А сколько это времени займет? Ну если одна обложка по 50к, то 5 Мб пока не скачается...
То есть если пользователь резко крутанул скролл, он и должен увидеть заглушку (если она предполагается на время загрузки) и лишь когда перестанет быстро мотать заглушки постепенно (по 6 шт) сменятся обложками.
Вспомнил еще один хинт с обложками: если быстро крутится полоса прокрутки, то обложки грузятся не сразу, а после задержки на тот случай, если их уже прокрутили через экран, то не начинать загрузку.
Ну собственно, это одна из причин реализации собственного loading="lazy".
А какую-то часть кода из SSR исключить нельзя, чтоб она так и передалась как <script>..?
Вообще с бесплатностью CPU история более сложная: если на сервере рендеринг утилизирует все ядра, значит отвечать сервер на другие (конкурентные) запросы будет медленнее и начнут падать показатели по скорости загрузки страниц.
У меня при очистке кеша это прямо проблемой становится. И проблема эта частая, например в NextCloud для генерации обложек можно выделенный сервер запустить, чтобы нагрузка на него не замедляла слишком сильно остальное.
У меня в электронной библиотеке тоже есть задача динамического сжатия PDF-страниц и обложек ресурсов.
Обложки выводятся React, вначале подставляется URL на кешированное значение обложки, если его нет, срабатывает fallback на динамическую генерацию нужной ширины. Сгенерированные обложки кладутся в кеш и в следующий раз обращение попадет в кеш и отдастся напрямую nginx.
Из форматов если исходный SVG, то отдается SVG. Если исходник не в SVG, то если браузер поддерживает, отдается webp, а если не поддерживает, то PNG или JPG в зависимости от того, в каком формате исходник (PNG на случай если в исходном PNG есть прозрачность). Про AVIF думал, но пока долго динамически генерировать, не хочется, чтобы на сервер слишком большая нагрузка пришлась.
По поводу сжатия, у меня WebP дает те самые 20-25% что гугл и обещал по сравнению с JPEG при, как правило, лучшем качестве.
Про devicePixelRatio не понял в чем проблема прочитать его из JS и выставить правильный URL. srcset я не использую именно из-за fallback при промахе мимо кеша: при промахе надо динамически подставить другой URL и в это время и devicePixelRatio известен.
Также есть забавный момент, что реализован собственный аналог loading="lazy" так как он лениво загружает когда изображение выходит за пределы экрана по вертикали, а когда по горизонтали (горизонтальный скролл), то все равно грузит. Ну и не очень устраивало в какой момент браузер решает подгрузить изображение.
AVIF пока не использую так как слишком большая нагрузка и у меня обложки в кеш не на все время попадают, а чистятся если место под кеш закончится (первым удаляются обложки к ресурсам, которые давно не открывались). Думаю как-нибудь стоит потыкать в видюхи Intel ARC, может они смогут аппаратно генерить AVIF через аппаратный кодировщик?
То есть мой вывод такой, что изображения надо целиком на js отрисовывать, тогда это управляемо.
Но все равно раз запись двойная, быстрее чем в один поток в wal не будет.
Да еще и частые fsync-и.
История про "собирать" вместо того, чтобы "разбирать" - действительно интересная, спасибо за перевод.
Ссылку на бенчмарк можно c 7ГБ в один поток последовательной записи?
А 7 ГБ/c с SSD в типичных нагрузках вы и сейчас не увидите. Увидите 70-100Мб/c в однопоток. Ну а ваши базы данных в однопоток и пишут и писать в 50 потоков, чтобы нагрузить SSD параллельной записью, просто не способны.
https://sata-io.org/system/files/specifications/SerialATA_Revision_3_1_Gold.pdf
Ctrl+F
hot plug
Если говорить про десктопы, то горячее извлечение надо в UEFI включить.
ZFS отлично и без ECC работает. ЕСС - это не требование, а настоятельная рекомендация.
ECC лучше иметь на любом сервере, если, конечно, вам не все равно на скрытую порчу обрабатываемых данных.
Представьте, что у вас испортилась ячейка памяти и вы из нее читаете не то, что записали. Как это скажется на работе ПО на сервере? Скажется непредсказуемым образом. И тут не важно будет этим ПО ZFS, РСУБД или что-то еще.
Да, SAS HDD обычно на 10 и 15 тыс. оборотов, в то время как SATA на 7200 или 5400.
Хотя был WD VelociRaptor на 10 тыс. и с SATA-интерфейсом.
То есть скорость вращения не характеризует как таковая интерфейс, а в сегодняшних условиях покупать HDD на 15 тыс. оборотов "для скорости" дороже SSD той же емкости выглядит совсем уж странным.