Re[18]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.07.09 11:25
Оценка:
Здравствуйте, mrTwister, Вы писали:

T>>>Опыт профилирования.

VD>>Твой? Это уже является показателем?
T>Разумеется. "Практика — критерий истины" (с)

У каждого практика своя. И истина тоже. Так что не надо свой личный опыт воспринимать как критерий истины в последней инстанции.

T>>>Именно поэтому многие высоконагруженные веб-приложения написаны на тормозных скриптовых языках.

VD>>Я таких не знаю. Ну за исключением тех что написаны на Эрланг. Только это как раз совершенно другой случай.
T>Ну вот, например, эти были написаны на PHP: Facebook, Wikipedia (MediaWiki), Yahoo!, WordPress, YouTube, MyYearbook, Digg, Joomla, Tagged.

Это мягко говоря не правда. Выскогонагруженными в том же Wikipedia является поиск. Который раньше был написан на Моно, а потом из соображений быстродействия был переписан на Яве. Текстовая часть вики живет на кэше. Так что действительно хватит и скриптов. В Yahoo тоже движок поиска написан на С++. В Яндексе и гугле, как я понимаю та же картина. В YouTube основная нагрузка — это потокове видио. Стримы тоже не скриптами отдаются. Так что не надо.

В прочем проблема масштабируемости решается и при низком быстродействии. Можно поставить 100 серверов вместо 10 и проблема будет решена. Для многих проще вложиться в железо, чем заниматься разработкой софта. Программист, ведь, стоит столько же в месяц как несколько серверов. Присчем серверы будут работать и работать потребляя только электричества, а программисту нужно платить каждый месяц.

T>>>Да. Тут имеют место массовые обращения через порты ввода-вывода к БД, распределенному кешу, файловой системе и т.д.

VD>>А СУБД, по-твоему, только к дискам обращается? Данные она не обрабатывает? План построения запросов, соеденения, фильтрацию, кэширование не она делает? На это время не тратится?

T>Клиенту СУБД (то есть Web-серверу в нашем случае) совершенно плевать, что там делается внутри СУБД.


Клиент СБДУ плевать. Он же программа, а вот клиенту обращающемуся с запросом не плевать, так как он человек. И ему важно, чтобы отклик был как можно быстрее.

T>Клиент общается с базой через порты ввода-вывода (сеть, трубы).


А пользователю было бы выгодно, чтобы общение шло через память. А то и через регистры процессора. И чтобы все в одном потоке, разумеется.

T>В этом смысле, для него любое обращение к базе — это стандартная IO операция, которая отлично ложится на IOCP.


Это все проблемы вызванные современной архитектурой компьютеров, а не достижение человечества. Была бы многозадачность дешевле, а процессы легче про такую глупость как порты ввода вывода никто даже не вспоминал бы.

Кстати, когда СУБД стоит на той же машине, что и клиент (скажем веб-сервер) выгоднее использовать не пайпы или сокеты, а прямой доступ к памяти (если СУБД позволяет).

Собственно наш опыт показывает, что вынос СУБД на отдельный компьютер резко ускоряет работу системы. Это говорит, о том, что вычислительные затраты — это главное.

VD>>>>Мне кажется, что IO — это тоже вычисления в массе своей.

T>>>Это неважно,

VD>>Это очень важно! Только это и важно. Если бы все упиралось в медленные устройства ввода-вывода вроде дисков, то твоя позиция имела бы смысл. А так, 99% времени, при обработке веб-запроса, тратится на вычисления. Если бы они работали параллельно и с минимальными затратами, то пользователи были бы удовлетворены. А так пользователь ждет, железо занимается непроизводительными вычислениями, а горе программисты оправдывают эту ситуацию разными глупостями.

T>Вычислениями занимается не Web-сервер (о котором идет речь в этой ветке) а СУБД.

Клиенту это монопенисуально. Ему важен отклик. Никакие порты завершения и т.п. не в силах ускорить работу системы если все упирается в вычислительные ресурсы. Нужно ставить больше процессоров или делать многозадачность дешевле. Майкросовф на сегодня идет экстенсивным путем. В прочем Сингулярити — это движение в правильном направлении. И есть некоторый шанс, что ее идеи таки воплотят в коммерческом продукте.

T>Чтобы Web-сервер по сети обращался к СУБД, которая находится на другой машине и при этом выполнение запроса бы происходило в одном процессе и потоке с Web-сервером — это круто!!!


Если машины разные, то вопросов нет. Но если это не та, то какой смысл заниматься хернеЙ?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: диалог с любителями потоков
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.07.09 11:35
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:
BZ>нет, просто делается маппинг адресов
Без трима ничего интересного из маппинга адресов ты не получишь. Очень быстро чистые страницы кончатся; придется перезаписывать уже перезаписанные. Иначе зачем ты думаешь вендоры "скрывают" часть ёмкости SSD дисков?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[27]: диалог с любителями потоков
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.07.09 11:35
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:
BZ>синхронно — нет, есть кеш на RAM
Тем не менее именно из-за этого происходит деградация скорости записи. Сначала свободных страниц хватает; затем рано или поздно они кончаются, и запись каждой страницы ведёт к предварительному стиранию блока.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[23]: диалог с любителями потоков
От: BulatZiganshin  
Дата: 16.07.09 12:50
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>>>Сик у SSD конечно неплохой, а вот скорость записи никакая.


BZ>>да, ты видимо просто не читал про intel ssd. они в разы опережают то, про что ты читал


VD>Я то как раз читал. Скорость записи у указанной модели ниже чем у 7-тысячников.


1. скорость чистой записи тебе не нужна, смотри iops
2. у серверной модели она больше 200 мб/с, отя цимес всё равно не в этом

VD>Сам лучше почитай. У intel x-25m скорость записи где-то 70 мег в секунду. У нас сейчас где-тр более 300.

VD>Учитывая, что основная часть БД лежит в паяти тольку от SSD не будте никакого. Только выброс денег.
VD>Плюсь это игрушки для новаторов. Никто не гарантирует, что SSD заработают с контрллером что встроен в мать.

память не компенсирует большого числа операций записи
Люди, я люблю вас! Будьте бдительны!!!
Re[28]: диалог с любителями потоков
От: BulatZiganshin  
Дата: 16.07.09 12:52
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, BulatZiganshin, Вы писали:

BZ>>нет, просто делается маппинг адресов
S>Без трима ничего интересного из маппинга адресов ты не получишь. Очень быстро чистые страницы кончатся; придется перезаписывать уже перезаписанные. Иначе зачем ты думаешь вендоры "скрывают" часть ёмкости SSD дисков?

ещё раз. ресурс устройства — 10^17 байт, к примеру. при операции записи данные заносятся в наименее изношенный блок памяти, а из него переносятся в другой
Люди, я люблю вас! Будьте бдительны!!!
Re[28]: диалог с любителями потоков
От: BulatZiganshin  
Дата: 16.07.09 12:54
Оценка:
Здравствуйте, Sinclair, Вы писали:

BZ>>синхронно — нет, есть кеш на RAM

S>Тем не менее именно из-за этого происходит деградация скорости записи. Сначала свободных страниц хватает; затем рано или поздно они кончаются, и запись каждой страницы ведёт к предварительному стиранию блока.

это не *обязательно* делать синхронно
Люди, я люблю вас! Будьте бдительны!!!
Re[23]: диалог с любителями потоков
От: Слоноежик  
Дата: 16.07.09 13:06
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Плюсь это игрушки для новаторов. Никто не гарантирует, что SSD заработают с контрллером что встроен в мать.


А почему бы им не заработать. Так себе обыкновенное блоковое устройтво.
для забивания гвоздя надо выбирать правильный микроскоп.
Re[24]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.07.09 13:21
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>1. скорость чистой записи тебе не нужна, смотри iops


Мне в основном она и важна. У нас логи БД на диск пишутся... постранично.

BZ>2. у серверной модели она больше 200 мб/с, отя цимес всё равно не в этом


Я уже сказал что у нас на не самом быстром варианте под 300?
Указан был десктопный. Причем вы вообще разговариваете про игрушки. Их в москве днем с огнем не съищешь

VD>>Сам лучше почитай. У intel x-25m скорость записи где-то 70 мег в секунду. У нас сейчас где-тр более 300.

VD>>Учитывая, что основная часть БД лежит в паяти тольку от SSD не будте никакого. Только выброс денег.
VD>>Плюсь это игрушки для новаторов. Никто не гарантирует, что SSD заработают с контрллером что встроен в мать.

BZ>память не компенсирует большого числа операций записи


"Большого" — это хороший термин. Ну, считай у нас не большое количество. У нас много посетителей не все из которых пишут.
Так как пишутся в основном логи SQL-сервера, то важна скорость записи, а не сик. Она у SSD в расчете на доллар весьма посредственная.

В общем, мне надоело спорить с читателями теоретиками. Заведете себе сервер с большим количеством посетителей, поэкспериментируйте... Потом расскажете нам результат. А мы пока что как-нибудь по старинке.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.07.09 13:34
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>Неужто все только и делают, что смотрят ответы тебе? Объём БД какой? Очень сомнительно, что такие редкоиспользуемые данные будут в кеше, разве, что памяти совсем немерянно. Но ты ближе к телу сайта — тебе виднее, спорить не стану.


Ага. Виднее. И давайте как вы поверите мне на слово, что лишние 8 гиг оперативки и 4 проца с большей частотой дали выигрыш в производительности намного больший чем замена страйпа на двух 10-тысячниках (которые к слову сейчас снова трудятся) на страйп на 4-ех 15-тысячинках.

EC>Превратить строковый запрос в набор данных — это отравить текст запроса базе и перелить построчно данные из датаридера в хттп ответ?


Нет.

EC>С точки зрения кода твоего приложения IO здесь и вправду немного и он относительно дёшев, настоящий IO в БД происходит и сдаётся мне, что он существенно дороже.


Нет никакой точки зрения приложения. Есть реалии жизни. Есть сервер, софтн на нем и клиент с его запросами.
Клиенту по барабану как запрос обрабатывается. Ему важно за сколько времени ему приходит ответ.

EC>А из БД в память данные как попадают? через астрал?


Они туда редко попадают. Намного реже чем SQL-сервер их отдает.

EC>Вы одномоментно их ставили или сначало одно, потом другое?


Мы серверы апгрэйдили и сбирали. Сначала был Celeron 1.3 Ггц, гиг памяти и идешный винт. Потом 2 P4 и 4 гига, потом 4 Амд и 8 гиг (+ 64-битная ОС). Сейчас 8 Core 2 и 16 гиг.

Пока оперативки было мало апгрэйд винтов давал толк. Но когда ее стало много, то эффект уже не так заметен. Сервер что сейчас под нагрузкой имеет заметно более слабую винтовую подсистему по сравнению с предыдущим, но вычислительная мощь у него намного выше. В результате сервер работает значительно быстрее.

Лучший результат был только когда распределяли нагрузку между двумя серверами. Но это решение получается менее надежным и более сложным в поддержке. К тому же второй сервер сломался и не хватает времени и денег чтобы его восстановить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.07.09 14:01
Оценка:
Здравствуйте, Слоноежик, Вы писали:

VD>>Плюсь это игрушки для новаторов. Никто не гарантирует, что SSD заработают с контрллером что встроен в мать.


С>А почему бы им не заработать. Так себе обыкновенное блоковое устройтво.


Ты на своем веку сколько новых технологий опробовал? Я достаточно. Очень редко было так, чтобы новая технология сразу же замечательно стыковалась с оборудовонием которое было разработано до него.

Вот тебе первый обзор по куазанному винту:
http://www.ixbt.com/storage/ssd-intel-x25m.shtml
Читай внимательно там как раз сказано, что есть проблемы совместимости с контроллерами.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: диалог с любителями потоков
От: EvilChild Ниоткуда  
Дата: 16.07.09 15:36
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ага. Виднее. И давайте как вы поверите мне на слово, что лишние 8 гиг оперативки и 4 проца с большей частотой дали выигрыш в производительности намного больший чем замена страйпа на двух 10-тысячниках (которые к слову сейчас снова трудятся) на страйп на 4-ех 15-тысячинках.

Это согласие или возражение? Я именно это и говорил, что кэширование помогает снизить стоимость IO.

EC>>С точки зрения кода твоего приложения IO здесь и вправду немного и он относительно дёшев, настоящий IO в БД происходит и сдаётся мне, что он существенно дороже.


VD>Клиенту по барабану как запрос обрабатывается. Ему важно за сколько времени ему приходит ответ.

Замечательно. Начали с потоков и IO, а скатились к клиентам. Ты бы ещё разрешение экрана у пользователя сюда привёл.

VD>Пока оперативки было мало апгрэйд винтов давал толк. Но когда ее стало много, то эффект уже не так заметен. Сервер что сейчас под нагрузкой имеет заметно более слабую винтовую подсистему по сравнению с предыдущим, но вычислительная мощь у него намного выше. В результате сервер работает значительно быстрее.

Думаю корректнее будет сказать пропускная способность выше.

VD>Лучший результат был только когда распределяли нагрузку между двумя серверами. Но это решение получается менее надежным и более сложным в поддержке. К тому же второй сервер сломался и не хватает времени и денег чтобы его восстановить.

2 сервера это один с БД, второй — с веб?
now playing: Extrawelt — Trummerfeld (Oliver Huntemann Remix)
Re[25]: диалог с любителями потоков
От: Слоноежик  
Дата: 16.07.09 15:51
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ты на своем веку сколько новых технологий опробовал? Я достаточно. Очень редко было так, чтобы новая технология сразу же замечательно стыковалась с оборудовонием которое было разработано до него.

Глупо сравнивать технологию которую обкатывали минимум 20 лет с технологией которая появилась вышла пару лет назад. Да и то даже сейчас с прошивкой винчестеров косяки случаются.

VD>Вот тебе первый обзор по куазанному винту:

VD>http://www.ixbt.com/storage/ssd-intel-x25m.shtml
VD>Читай внимательно там как раз сказано, что есть проблемы совместимости с контроллерами.

Никаких проблем — глупо требовать от дешёвой SSD-шки для нетбука полной поддержки переупорядочения комманд.
А в нормальных SSD-шках есть кэш память правда она используется не только для переупорядочения (тут вообще аппаратная часть гораздо более продвинутая).
для забивания гвоздя надо выбирать правильный микроскоп.
Re[20]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.07.09 16:57
Оценка:
Здравствуйте, EvilChild, Вы писали:

Ты прочити всю тему целиком и по ходу ее формирования. А то у меня ощущение, что ты влез с этого мест.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: диалог с любителями потоков
От: yuriylsh  
Дата: 18.07.09 02:33
Оценка: 1 (1) +1
Здравствуйте, BulatZiganshin, Вы писали:

BZ>Здравствуйте, Sinclair, Вы писали:


BZ>>>синхронно — нет, есть кеш на RAM

S>>Тем не менее именно из-за этого происходит деградация скорости записи. Сначала свободных страниц хватает; затем рано или поздно они кончаются, и запись каждой страницы ведёт к предварительному стиранию блока.

BZ>это не *обязательно* делать синхронно


В том-то и дело, что обязательно. Проблема в том, что диск понятия не имеет что какая-то страница была удалена. Операционка не посылает команды удаления (TRIM) диску ибо ее чего? — правильно, нету. Диск узнает что у него проблемы в тот момент, когда ему приходит команда на перезапись, и соответсвенно, решает ее (вот где тормоза) только в этот момент – тобишь, синхронно. Попробую обяснить.
В SSD диске нет доступа к отдельной ячейке (байту). Ячейки организованы в страницу (4Кб). Страницы, в свою очередь, организованы в блок из 128 страниц – 512Кб. Давай представим, что мы записали файл размером в 32 страницы (128Кб) в блок. Затем еще один файл размером 64 страницы. Дальше мы удалили первый файл – так как команды удаления для диска нету, то ОС помечает у себя что первые 32 страницы блока свободны и на этом все с удалением (диск вообще в радостном неведении об этом событии, поэтому, все что происходит дальше, ему приходиться делать синхронно). Итого у нас 32 страницы в начале блока свободны, причем об этом знает только ОС (пометим эти страницы как С) – но не чисты (Ч), 64 заняты (З) и 64 страницы в конце чисты: блок выглядит так — СЗЗЧЧ. Теперь мы хотим записать в этот блок файл размером 96 страниц (как раз для наших С + ЧЧ). Вот тут у SSD диска проблема – писать в свободные страницы он не умеет, только в чистые, тобишь, ему С + ЧЧ надо превратить в Ч+ЧЧ, тобишь, стиреть первые 32 страницы. Дальше – лучше, стирать (на самом деле – перезаписывать) отдельные страницы он тоже не умеет, только весь блок. Вот тут ему нужно выкручиваться и вот тут и начинаются обсуждаемые тормоза (причем – синхронно) Что он делает – читает весь блок в кэш, в кэше удаляет первые 32 страницы, производить запись нового 96-страничного файл и с кэша весь блок пишет обратно на диск. Т.е. СЗЗЧЧ –> копируем в кэш –> ЧЗЗЧЧ –> ЗЗЗЗЗ –> копируем обратно с кэша на диск. Итого, запись 96 страниц превращается в копирование 128 страниц в кэш, манипуляции в кэше и запись 128 страниц обратно на диск. Оверхэд очевиден.
Что делает TRIM – он позволяет при удалении нашего первого 32-страничного файла (та операция, про которую я писал, что диск в радостном неведении относительно этого удаления) операционке сказать диску (посылкой команды TRIM) что странци, отведенные под файл нужно очистить (тут диск все так-же пляшет ЗЗЗЧЧ–>кэш–>ЧЗЗЧЧ–>диск). Но он это делат, когда файл удаляется, а не во время записи следующего файла, что уже дает существенное ускорение при повторной записи. Правда, с замедлением операции удаления — но тут уже можно изврящаться с асинхронностью и другими оптимизациями.
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Re[30]: диалог с любителями потоков
От: yuriylsh  
Дата: 18.07.09 02:52
Оценка:
Y>В SSD диске нет доступа к отдельной ячейке (байту). Ячейки организованы в страницу (4Кб). Страницы, в свою очередь, организованы в блок из 128 страниц – 512Кб. Давай представим, что мы записали файл размером в 32 страницы (128Кб) в блок. Затем еще один файл размером 64 страницы. Дальше мы удалили первый файл – так как команды удаления для диска нету, то ОС помечает у себя что первые 32 страницы блока свободны и на этом все с удалением (диск вообще в радостном неведении об этом событии, поэтому, все что происходит дальше, ему приходиться делать синхронно). Итого у нас 32 страницы в начале блока свободны, причем об этом знает только ОС (пометим эти страницы как С) – но не чисты (Ч), 64 заняты (З) и 64 страницы в конце чисты: блок выглядит так — СЗЗЧЧ.

Что-то я зарапортовался Представим, что блок — 160 страниц
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Re[30]: диалог с любителями потоков
От: zlonovich  
Дата: 20.07.09 20:57
Оценка:
Здравствуйте, yuriylsh, Вы писали:

Y>Здравствуйте, BulatZiganshin, Вы писали:


BZ>>Здравствуйте, Sinclair, Вы писали:


BZ>>>>синхронно — нет, есть кеш на RAM

S>>>Тем не менее именно из-за этого происходит деградация скорости записи. Сначала свободных страниц хватает; затем рано или поздно они кончаются, и запись каждой страницы ведёт к предварительному стиранию блока.

BZ>>это не *обязательно* делать синхронно


Y>В том-то и дело, что обязательно. Проблема в том, что диск понятия не имеет что какая-то страница была удалена. Операционка не посылает команды удаления (TRIM) диску ибо ее чего? — правильно, нету. Диск узнает что у него проблемы в тот момент, когда ему приходит команда на перезапись, и соответсвенно, решает ее (вот где тормоза) только в этот момент – тобишь, синхронно. Попробую обяснить.

Y>В SSD диске нет доступа к отдельной ячейке (байту). Ячейки организованы в страницу (4Кб). Страницы, в свою очередь, организованы в блок из 128 страниц – 512Кб. Давай представим, что мы записали файл размером в 32 страницы (128Кб) в блок. Затем еще один файл размером 64 страницы.
Диск — блоковое устройтво, и адресация у него идет ессно секторами по 512 байт. И пишем мы соответственно по некаторому LBA (да да именно он) некаторое количество секторов. Да и если посмотреть то запись одного файла это как минимум 2 записи по 2-м разным LBA разного кол-ва секторов, файловые системы никто не отменял.
Y> Дальше мы удалили первый файл – так как команды удаления для диска нету, то ОС помечает у себя что первые 32 страницы блока свободны
Собственно это удаление с точки зрения накопителя это тоже есть просто запись.
Y> Вот тут у SSD диска проблема – писать в свободные страницы он не умеет, только в чистые, тобишь, ему С + ЧЧ надо превратить в Ч+ЧЧ, тобишь, стиреть первые 32 страницы.
Значит нам нужно целых пол-мегабайта только для для того чтобы обновить кусок данных. Подобное можно предположить про SSD так как там есть буфер для того чтобы считать эти данные (если конечно забыть про прозводительность вообще) так как например некаторые флэш микрухи имеют время записи одного блока порядка полутора секунд. Собственно при таком подходе простые флэшки вообще не могут работать. Трудно прочитать в память содержимое блока если памяти под буфера всего 48К.

[остальное поскипнуто]

Думаю тут стоит избавится от парочки мифов которые возникали в этом типике:

1) Контроллеры для флэшек да и SSD имеют достаточно сложные прошивки которые умеют делать много чего: следить за равномерным износом блоков и перемещать данные из более изношенных блоков в менее изношенные, cледить за состоянием уровня заряда в яйчейках флэш-памяти так как он теряется во время чтения и переносить данные когда он становится низким (естественно это все смотрится по косвенным признакам), обрабатывать ошибки и восстанавливать данные в случае если произошел сбой питания(флӕш память не любит если изчезает питание во время записи) или ошибка записи.
2) Учитывая что есть возможность только записать(а точнее только переключать 1-ки в 0-ки) данные каждый раз пишутся в новое место (включая и контрольные структуры) 2 записи по одному и тому же LBA в общем случае физически после записи будут находится в разных местах на флэш памяти.
3) Давно не слышал про просто SLC и просто MLC память. Дорого это иметь отдельную микруху для каждого типа памяти. А про память которая может работать в SLC режиме и MLC режиме причэм для каждого блока можно выбирать в каком режиме он будет работать слышал.
4) Учитывая что данные перезаписать невозможно без стирания всего блока то последовательные длинные записи гораздо проще реализуются чем короткие рандомные. Cобственно в SSD буферная память и используется для того чтобы уменьшить влияние случайных записей и собственно попытаться уменьшить само кол-во записей. Возьмем предидущий пример: после прихода первого файла контроллер может решить вообще оставить его в памяти и ничего не писать, а когда придет второй кусок записать сразу весь второй файл в 96 страниц.
5) В принципе основные команды это чтение нескольких сектров и запись нескольких секторов. Про стирание слышал только в контексте SD карточек.

З.Ы. Пора заканчивать этот флуд про флэшки или выделять эту ветку в отдельную тему

З.З.Ы. На флэшки и на SSD-шкам(но в гораздо меньшей мере) смотреть со стороны фирмваря приходилось.
Re[31]: диалог с любителями потоков
От: yuriylsh  
Дата: 20.07.09 22:37
Оценка:
Здравствуйте, zlonovich, Вы писали:
Y>> Дальше мы удалили первый файл – так как команды удаления для диска нету, то ОС помечает у себя что первые 32 страницы блока свободны
Z>Собственно это удаление с точки зрения накопителя это тоже есть просто запись.

Угу, так вот проблема в том, что этой команды записи (TRIM — логически это удаление, физически — запись) пока и нету, о чем и речь ведеться.

Y>> Вот тут у SSD диска проблема – писать в свободные страницы он не умеет, только в чистые, тобишь, ему С + ЧЧ надо превратить в Ч+ЧЧ, тобишь, стиреть первые 32 страницы.

Z>Значит нам нужно целых пол-мегабайта только для для того чтобы обновить кусок данных. Подобное можно предположить про SSD так как там есть буфер для того чтобы считать эти данные (если конечно забыть про прозводительность вообще) так как например некаторые флэш микрухи имеют время записи одного блока порядка полутора секунд. Собственно при таком подходе простые флэшки вообще не могут работать. Трудно прочитать в память содержимое блока если памяти под буфера всего 48К.

Согласен, вот только SSD это не простая флэшка, ты же сам дальше об этом говоришь.

Z>[остальное поскипнуто]


Z>Думаю тут стоит избавится от парочки мифов которые возникали в этом типике:


Z>1) Контроллеры для флэшек да и SSD имеют достаточно сложные прошивки которые умеют делать много чего: следить за равномерным износом блоков и перемещать данные из более изношенных блоков в менее изношенные, cледить за состоянием уровня заряда в яйчейках флэш-памяти так как он теряется во время чтения и переносить данные когда он становится низким (естественно это все смотрится по косвенным признакам), обрабатывать ошибки и восстанавливать данные в случае если произошел сбой питания(флӕш память не любит если изчезает питание во время записи) или ошибка записи.

Z>2) Учитывая что есть возможность только записать(а точнее только переключать 1-ки в 0-ки) данные каждый раз пишутся в новое место (включая и контрольные структуры) 2 записи по одному и тому же LBA в общем случае физически после записи будут находится в разных местах на флэш памяти.
Z>3) Давно не слышал про просто SLC и просто MLC память. Дорого это иметь отдельную микруху для каждого типа памяти. А про память которая может работать в SLC режиме и MLC режиме причэм для каждого блока можно выбирать в каком режиме он будет работать слышал.
Z>4) Учитывая что данные перезаписать невозможно без стирания всего блока то последовательные длинные записи гораздо проще реализуются чем короткие рандомные. Cобственно в SSD буферная память и используется для того чтобы уменьшить влияние случайных записей и собственно попытаться уменьшить само кол-во записей. Возьмем предидущий пример: после прихода первого файла контроллер может решить вообще оставить его в памяти и ничего не писать, а когда придет второй кусок записать сразу весь второй файл в 96 страниц.
Z>5) В принципе основные команды это чтение нескольких сектров и запись нескольких секторов. Про стирание слышал только в контексте SD карточек.

Да это все оптимизации для продления жизни (с этим уже сейчас у SSD все не так уж плохо) и попытки избавиться от проблем с записью на несвежий диск — вот тут без TRIM тяжко, проблема не решается, а откладывается. В зависимости от паттерна использования диска (ну и объема, конечно же) ты очень долго можешь не видеть деградации, но рано или поздно ты к ней придешь.
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Re[32]: диалог с любителями потоков
От: zlonovich  
Дата: 20.07.09 23:18
Оценка:
Здравствуйте, yuriylsh, Вы писали:

Y>Да это все оптимизации для продления жизни (с этим уже сейчас у SSD все не так уж плохо) и попытки избавиться от проблем с записью на несвежий диск — вот тут без TRIM тяжко, проблема не решается, а откладывается. В зависимости от паттерна использования диска (ну и объема, конечно же) ты очень долго можешь не видеть деградации, но рано или поздно ты к ней придешь.

Запись на несвежий диск — это собственно и есть стандартный вид записи и стандартный режим работы флэш накопителя, и трим конечно мог бы помочь тут а может и помешать ведь эту информацию надо где-то хранить и дополнительно обрабатывать. А с деградацией все равно ничего не сделать Трим ее может только ненадолго отсрочить. А вот платить за трим полной потерей совместимости при этом придется.
е
Re[33]: диалог с любителями потоков
От: yuriylsh  
Дата: 21.07.09 02:04
Оценка:
Здравствуйте, zlonovich, Вы писали:

Z>Запись на несвежий диск — это собственно и есть стандартный вид записи и стандартный режим работы флэш накопителя, и трим конечно мог бы помочь тут а может и помешать ведь эту информацию надо где-то хранить и дополнительно обрабатывать.


Не понял, каку информацию? TRIM — это всего лишь возомжность произвести перезапись блока при удалении (или отложенно, после удаления, например, как дефрагментацию ты можешь делать отложенно, или по расписанию), а не во время записи данных в непочищенный блок. Какую информацию ты имеешь в виду?

Z>А с деградацией все равно ничего не сделать Трим ее может только ненадолго отсрочить.


Не, это без TRIM така ситуация. Это комманда призвана ее разрешить.

Z>А вот платить за трим полной потерей совместимости при этом придется.


С чего ты взял? Если диск не поддерживает TRIM, то он просто будет функционировать как текущие диски.
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Re[31]: диалог с любителями потоков
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 21.07.09 08:25
Оценка:
Здравствуйте, zlonovich, Вы писали:

Y>>В SSD диске нет доступа к отдельной ячейке (байту). Ячейки организованы в страницу (4Кб). Страницы, в свою очередь, организованы в блок из 128 страниц – 512Кб. Давай представим, что мы записали файл размером в 32 страницы (128Кб) в блок. Затем еще один файл размером 64 страницы.

Z>Диск — блоковое устройтво, и адресация у него идет ессно секторами по 512 байт. И пишем мы соответственно по некаторому LBA (да да именно он)

Тогда уж расшифровали бы — "linear block address". А то "он", "он" — скорее можно подумать, что речь про C2H5OH.

Далее, диск-то блоковый, но над ним FS, у которой свои соображения о том, что есть блок и почему.

Z> некаторое количество секторов. Да и если посмотреть то запись одного файла это как минимум 2 записи по 2-м разным LBA разного кол-ва секторов, файловые системы никто не отменял.

Y>> Дальше мы удалили первый файл – так как команды удаления для диска нету, то ОС помечает у себя что первые 32 страницы блока свободны
Z>Собственно это удаление с точки зрения накопителя это тоже есть просто запись.

Вы с прямым углом путаете. Запись _метаданных_ на диск о том, что какие-то страницы свободны, никак не подсказывает диску, какие области данных (в Ваших терминах — блоки с каким конкретно LBA) стали свободны: он ничего не знает про используемую FS. Чтобы диск начал оптимизировать, ему надо _явно_ сказать "вот то что тут — уже неважно".

Z>Думаю тут стоит избавится от парочки мифов которые возникали в этом типике:


Z>1) Контроллеры для флэшек да и SSD имеют достаточно сложные прошивки которые умеют делать много чего: следить за равномерным износом блоков и перемещать данные из более изношенных блоков в менее изношенные, cледить за состоянием уровня заряда в яйчейках флэш-памяти так как он теряется во время чтения и переносить данные когда он становится низким (естественно это все смотрится по косвенным признакам), обрабатывать ошибки и восстанавливать данные в случае если произошел сбой питания(флӕш память не любит если изчезает питание во время записи) или ошибка записи.


А что, не умеют ничего из перечисленного? Или умеют только часть? Если Вы уж решили "избавить от мифов", надо говорить конкретнее: что именно миф, для какого типа/поколения.
Или это Вы, наоборот, утверждаете, а не отрицаете? Тогда хорошо было бы, чтобы Вы выражались яснее, а то телепать каждый раз очень тяжело...

Z>5) В принципе основные команды это чтение нескольких сектров и запись нескольких секторов. Про стирание слышал только в контексте SD карточек.


Ну вот, как видите, времена изменились.

Z>З.Ы. Пора заканчивать этот флуд про флэшки или выделять эту ветку в отдельную тему


Z>З.З.Ы. На флэшки и на SSD-шкам(но в гораздо меньшей мере) смотреть со стороны фирмваря приходилось.


Ну тогда расскажите подробнее. Лучше со слайдами:))
The God is real, unless declared integer.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.