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

Известно кто в теме
Safari (вроде виндовая - тоже)
Firefox3

Больше и нету (Opera не проверял, но откуда там алмазы...)

Re: > А юниксовый - собирать с lcms
В чудеса мы не верим - вот у меня в системе нету lcms никакого - и чем оно будет делать оный management?

Firefox 2 не в теме

Это не вполне то, потому что паттерн немножко другой, но смысл тот же.
В рамках нашей дискуссии можно смотреть на Database

http://techreport.com/articles.x/15931/9

Если получится по пожалуйста прогони на нем iometer с размерами 1, 2, 4, 8, 16, 64, 128, & 1024kb, seq/random при queue depth от 2-х до 32-х.

Очень интересно было бы посмотреть на результаты.

Гугл может тройное дублирование себе позволить, но это не значит что многие могут позволить для себя то-же самое.

Что происходит у гугла в датацентрах я знаю не понаслышке, у меня двое друзей в их storage division работают. У них датацентры в среднем раз в 9 месяцев сгорают. В букавальном смысле. Для FEC и восстановления данных у них альгоритмы (адаптированные для них turbo codecs) встроены на уровне application, и data redundancy на уровне storage controllers не используется. Т.е. у них дисковая подсисема построена на уновне JBOD (в основном используется HP DL180/185/320s) чтобы запаковать как можно больше ТБ (они используют 7.2К 1TB SATA) в 1U.

тогда 2q на желтые штаны :)

Следите за руками.
15k-rpm диск вращается со скоростью 4 миллисекунды на оборот. Т.е. даже без seek средняя дисковая транзакция будет 2 ms просто запись и 6ms с read-after-write. C random - хуже, нужно еще seek time добавить (еще 3-4ms для лучших дисков).
Итого, в лучшем из лучших случаев мы будем иметь 500 Write IOPS, а скорее чуть меньше (в тестах намеривают под 400).

Для разумного SSD из текущей линейки - Intel X25-E (быстрый, относительно дорогой но без наворотов вроде DRAM с батарейкой) - интел врет про 3300 4-килобайтных random write в секунду, причем random и stream отличаются, понятно, очень мало (для stream - 4k с хвостом получается).

У предыдушего поколения (MTRON-ов всяких) несколько хуже, но все еще много лучше чем у дисков.

Понятно, что на SLC flash не так много дисков делается, ибо дорого, но в ряде узких мест они окупаются.

А с RAM - те же микросхемы, может только ножек побольше :)
С дисками мы прошли GMR, перпендикулярную запись и прочие страшные слова - и это только за последние лет 10, раньше я не следил или уже забыл

А эффект близкий - рост bandwidth (мне за 20 лет сложно оценить, могу за 15 - у дисков примерно на 2 порядка, у памяти - тоже), падение latency (у памяти раз в 6 за те же 15 лет, у дисков - раза в 4 минимум).
Я же помню эти серверные диски 93-го года - 700 мегабайт, 5 дюймов, полная высота, мегабайт 6-10 в секунду на чтение в хорошую погоду, десятки миллисекунд avg seek, когда много seek-s - корпус big tower трясется как уазик на ухабах.

Ну и с ценой - пик цены 92-93 года на память - 30 доларов за мегабайт, помню как я 16Mb за $600 покупал. SCSI-диск в 92-м - доллар за мегабайт.

Интересно было бы послушать обоснование про падение стоимости хранилища если класть transaction log на SSD. Если ничего в мире баз данных и storage за последный месяц не случилось, то transaction log - это всегда sequential writes of data. Т.е. хренилище для TL должно быть оптимизировано для _записи_, а не для чтения.

Все учебники советуют класть TL на RAID10 или по крайней мере на RAID1. Не забываем что write time у SSD диска _ниже_ чем у SATA 7.2k диска. Поэтому при условиях держания TL на SSD производительность дисковой подсистемы (и в результате - баз данных) должно падать.

Полностью согласен с тем, что хорошо оптимизированная база должна строится под storage performance and type а не наобарот. Это я время от времени пытаютсь довести до клиентов. Не все понимают с первого раза. Подай им 10000 транзакции (IOPS) в секуду и когда они слышат во столько это обойдется....

Многие (например, Петя Зайцев) говорят, что если transaction log класть на SSD, то общая стоимость дискового хранилища при тех же транзакциях в секунду - падает.

И это при сохранении старой парадигмы, а вообще под SSD нужно иначе программировать.

18М записей - это в тесте. В жизни будет на порядок больше.
А 32 бита - требование, причем в него можно вписаться.

Там на закрытии fsync() делается - т.е. все будет на диске.

А время я считаю вместе с close()

Алекс, а где в Spectraview II выставляется (и выставляется ли вообще) под какую точку черного мы калибруем - Native Black или цветокорректированную?

А то привыкнув к Spectraview Profiler, где без ответа на этот вопрос процедуру калибровки просто не пройдешь, я получил какой-то не сильно хороший уровень черного 0.45 в Spectraview II вместо привычного 0.2-0.3 в Profiler :-)