Buy OCZ-p88 MLC or SLC and solve all your IO issues

http://www.amazon.com/OCZ-Technology-Drive-Express-OCZSSDPX-ZD2P88512G/dp/B00...

Ну и чем тебе слака мешает в данном случае? Детские обиды? :)

Ну расскажи, что нужно патчить в дистрибутивном ядре?

>Buy OCZ-p88 MLC or SLC and solve all your IO issues

Всенепременно. Вы понимаете, что советуете?))

слака мешает тем что отвлекает внимание на себя от полезных проектов (я считаю и федору вредным проектом. лучше серьёзные, но независимые проекты развивать).

в дебиан и rhel часто бекпортируется код. дистр остаётся стабильным а проблемы с оборудованием решаются (или даже появляется поддержка нового). как минимум слака собирается с поддержкой 2Gb максимум. это неприемлемо. про pae мне надоело уже писать, равно как и про поддержку сборок ядра с патчами (контейнеры, preempt и тд). если это всё не надо разработчику - значит левые сборки (если кто-то их выложит отдельно) этих кернелов не тестируются совершенно, в реальной жизни. и дистр без PAM - не нужен. многие программы просто настроены и рассчитывают на его использование. консольные программы в слаке так и не рассчитаны на использование UTF-8. не надо недоделок. фаны слаки будут её защищать и по каждому пункту яростно давать отпор, говоря «это не нужно!», «собери сам!». хватит. слаку не используют потому что в ней вечно что-то не хватает. это единственное обьяснение.

>>> С корпоративных, на которые приходится почти половина серверов

О-ло-ло! Это же что же весь парк «корпораций» это серверы для обслуживания инраструктуры AD? Интересные такие корпорации...

Ну тогда приводи статистику использования виндоус серверов

привожу. при том что корпоративная инфраструктура у нас полностью на виндах, со всеми возможными МСовскими серверами (ad, exchange, scom, sharepoint, uc/ocs, sql, isa(как он там теперь называется?) и тд), да еще и телефония на винде, виндовые серваки - это не больше 5% от всего серверного парка, т.е. около четырехсот серверов.

> как минимум слака собирается с поддержкой 2Gb максимум

добро пожаловать из анабиоза про слаку64 мы не слышали? а до неё о slamd and bluewhite64?

слака64 - это фактически левый проект. патрик к нему отношения не имеет. просто пересобранная (кажется всего одним человеком) слака. патрику ни более 2Gb, ни PAE, ни 64 бит не нужно. значит считает что и вам не нужно.

>Ибо планировщику XEN'а можно для любого домена задать вес и лимит использования процессора

man cgroups

> офигеть - почитать комит лог и взять чужой патч уже считается гигантской работой. По сути их работа - взять у клиента описание баги, посмотреть пофиксена она в mainstream, если пофиксена - взять фикс и предложить клиенту сборку. _И_ВСЕ_. офигеть какая тяжелая работа.

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

ну да, только скачать без этого не дают. Говорят или 30 дней триала (как у всяких там пропринетаршиков) или плати бабло что бы получить бинарники - поведение 1 в 1 с пропринетарщиками. Для них нет смысла делать код открытых проектов стабильным - иначе у них никто сборку пакетов и фикс багов не купят, вот и суют по всюду глючный бетакод. который потом сами же и фиксят за ваши деньги.

анонимус, ты просто необразован. ты понимаешь, что никто не стал бы покупать подписку на патчи если бы все было так просто и все было бы шоколадно в апстриме? ты понимаешь, что никто бы не стал покупать суппорт, если бы он не работал быстро и качественно? как например никто в здравом уме не покупает HP. ну и вообще, все исходники можно скачать с оффсайта, только их компилировать прийдеться ручками.

> патрик к нему отношения не имеет. просто пересобранная (кажется всего > одним человеком) слака

слаку, в том числе и 64, собирает команда разработчиков, Патрик там не один. довольно давно он передал значительную часть полномочий (кажется во время болезни), так что слак64 - это не форк, а официальный порт на 64 бита.

слаку, в том числе и 64, собирает команда разработчиков, Патрик там не один

так он её и не собирает! слаку64 бит

>> Buy OCZ-p88 MLC or SLC and solve all your IO issues

Всенепременно. Вы понимаете, что советуете?))

We use them (500gb and several 1tb) and they working great (check out ssd tuning under linux) We use openvz.

Also we have fusionio dual drive (better performance but way more expensive)

Going to buy new OCZ IBIS Also will buy new intel x25M G3 (and new x25e g3) once they are available.

(sorry no russian keyboards there)

Я в начале этого года покупал два OCZ Agility 60G для тестов. Посмотреть, чего от них можно добиться в разных режимах. Вещи, конечно, замечательные. И в своих проектах я далее везде, где это технически обосновано, буду использовать SSD. В том числе fusionio и аналоги.

Однако, там есть технические проблемы, связанные количеством записи. Производительность SSD-шки легко убивается мелкоблочной записью и это — особенность флэш-технологии, а не контроллера. Это означает, что приложения, работающие с SSD, надо дорабатывать. Просто поместить СУБД на SSD в общем случае нельзя, если она не знает, что это такое. Иначе можно словить совершенно непредвиденные тормоза на ровном месте.

> OCZ Agility 60G

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

Пробовать надо OCZ Vertex 2 (который на контроллере SandForce) - там проблема быстродействия на маленьких блоках решена. К тому же сейчас появились небольшие (40, 60 ГБ) но доступные Vertex 2.

> слака мешает тем что отвлекает внимание на себя от полезных проектов (я считаю и федору вредным проектом. лучше серьёзные, но независимые проекты развивать).

Хохо, мистер истина-в-последней-инстанции :)

как минимум слака собирается с поддержкой 2Gb максимум

Ты какую версию смотрел последний раз? Довольно давно уже с CONFIG_HIGHMEM4G=y собирается.

Про левые сборки комментировать не буду. PAM не нужен в 99% случаев, единственную программу, которую мне не удалось завести в слаквари - был vmware gsx server, т.к. он бинарный и слинкован с pam. Во всех остальных случаях я обходился без него. Юникод можно очень быстро прикрутить.

В общем мысль понятна, попробовал использовать, не осилил, теперь объявил крестовый поход против. Вендузятники тоже самое против линукса устраивают.

Вот X25-E G3 - это да. OCZ мы покупать не стали, нет доверия, сидим на X25-E G1.

OCZ Agility 60G

неудачный винт, котороый славится как раз низким быстродействием на маленьких блоках

Не-не-не... Agility, действительно, тормоз на фоне SandForce. Но те же самые проблемы будут и на других девайсах, только в меньшей степени. Это всё не так-то просто отловить. Я около месяца просидел, тестируя свои железяки и в хвост, и в гриву под разными нагрузками. Немного графиков есть здесь В первую очередь надо смотреть, чтобы на диске было достаточное количество свободного (через TRIM) места. Для Indilinx это примерно 50%. Иначе скорость записи будет падать хоть и медленно, но почти линейно. SandForce именно этой бедой, вожможно, не страдает. Но падение там тоже будет.

Причина тут фундаментальная. Контроллер SSD должен транслировать паттерны доступа приложений, оптимизированных для HDD в оптимальные для SSD. Indilinx уже довольно успешен в этом деле, SandForce/Intel вообще молодцы. Но это всё только для десктопных MLC. Проблема в общем случае не решается силами любого встроенного контроллера. И на серверной задаче, под длительной переменной нагрузкой эти контроллеры может переклинить. Не всем выпадет удача словить такой клин. Но кому повезет, того, скорее всего, уволят.

На мой взгляд, SSD идеальны в качестве недостающего звена в иерахии памяти между очень быстрой RAM и очень медленными HDD, в качестве прозрачного персистентного кэша. Особенно вкусно для этой цели смотрятся устройства на PCI-E x4.

По идее, если использовать раид с чанком побольше, то мелкоблочной записи вообще не будет. Мелкие данные будут сидеть в кеше контроллера данных дожидаясь добавки или таймаута.

То же самое происходит во внутреннем кэше SSD.

Что касается linux swraid, то увеличение размера чанка более 128 кб у меня приводило к понижению производительности. В том числе и чтения. Не помню уже точно, почему.

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

Через несколько лет технологический стек устаканится и наступит нам всем счастье - больше не будет безумных iowait на дисках :)

прикрутить.

и чуть что - прикрутить. ради чего? ради фанатства слакой? у других просто работает сразу. а что-бы прикручивать надо знать как должно выглядеть в конечном виде. значит: поставь rhel, fedora, debian, ubuntu, посмотри как собирается и работает там - какие компоненты и какие патчи. и пересобери всё сам. вобщем слака - для тех кому в общем от линукса ничего не надо. истинный justforfun.

плюсую, слака не нужна

Не вытаскивай отдельные слова из фразы, это некрасиво.

Мне это интересно тем, что, после того, как я это сделаю, я ПОНИМАЮ, как оно устроено, а не как обезьянка потыкал по инструкциям по кнопкам. В этом и прелесть слаквари, в том, что KISS и в том, что после неё понимаешь, как работает линукс и становится очень легко освоить любой другой дистрибутив.

А твоя злость - ущербна и не созидательна.

Для понимания нужно просто один раз собрать LFS, а потом с чистой совестью пользоваться готовыми решениями. Это вроде как получить образование: ты же не поступаешь каждые 5 лет на один и тот же факультет университета, подавляющему большинству людей достаточно одного раза.

Время слаки как production решения прошло. Только если как учебное — тренировать начинающих. Но с обязательным переползанием потом на «настоящие» дистрибутивы

Я где-то говорил, что Slackware - 100% production решение? :)

И сравнение образованием не совсем корректно. Ну не 5, но 10 лет назад не было dbus, рипнувшегося hal, avahi, policykit и вообще со шрифтами было всё по-другому.

Почитал про cgroups. Да это решение. RH-based only. Без патчей от RH, ИМХО, лучше с этим не связываться (как раз мой случай) :)

Разве не в ванильном? http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt

>То же самое происходит во внутреннем кэше SSD.

не надо забывать, что в раид-контроллере есть батареечка. И кеш больше.

Оптимизацию записи нужно выполнять на уровне приложений,

ни разу. этак можно дойти до драйверов фс в приложениях. Нет, raw партиции в СУБД пожалста, но это далеко не все приложения.

Что касается linux swraid, то увеличение размера чанка более 128 кб у меня приводило к понижению производительности.

логично, но имхо чанк 64к, это уже очень много для оптимизации блочной записи. При размере блока в ssd в 512 байт, чанк в 64к даст в 128 раз меньше обращений на мелких записях. Куда больше?

вроде бы по умолчанию (см параметр -a в hdparm) Linux использует упреждающее чтение по 256 блоков за раз, что как раз и дает 128 кб...

Мне это интересно тем, что, после того, как я это сделаю, я ПОНИМАЮ, как оно устроено

вот ты разобрался и остался доволен. но зачем надо каждый раз патчить и пересобирать? и так при установке нового компьютера/сервера есть чем заняться - настройка, тестирование и тд. стадию допила и патченься можно пропустить. профессионалы это сделали для/за тебя для конкретного дистра и ты не заменяешь мэинтейнеров пакетов которые гарантированно знают больше.

. В этом и прелесть слаквари, в том, что KISS

это не KISS. KISS это убунта и сусе, например. слака это - недоделанность и красноглазие во все поля.

про то что со слакой можно понять как всё работает в linux. я сам советую другим начать серьёзное знакомство с linux с изучения и ковыряния в дженте. сам я с джентой наигрался. просто у меня есть расхождения с линией партии и мне многие вещи там не нравятся (не нравились). не идеология дитра а политика в отношении некоторых пакетов.

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

> вот ты разобрался и остался доволен

Хочешь сказать, я разобрался - можно Slackware закрывать? А как же тогда ты? :-)

это не KISS

Нет, именно это KISS и называется. Простейшая система загрузки, нет разбивки на основные и dev-пакеты, нет зависимостей, ванильное ядро, софт без патчей, нет PAM'а - идеальный инструмент для глубокого изучения.

я сам советую другим начать серьёзное знакомство с linux с изучения и ковыряния в дженте

Как раз джента - не особо полезна для изучения архитектуры и процедуры загрузки линукса. Пользователь сидит и надрючивает emerge до посинения, откуда знаниям то взяться?

я считаю неправильным

Да мало ли что ты считаешь. Пользователи есть, причём далеко не полтора. Не нравится - не пользуйся, зачем крестовые походы то устраивать? Что за детский сад?

Авель, толку от этой батареечки 0, если такой же нет в SSD. Известная беда. При пропадании питания, данные из кэша SSD тоже пропадают. А если в нем отключить кэширование записи, то с производительностью станет всё более чем печально.

Не драйверов ФС в приложениях, а рефлексивные ФС: использование информации о физическом размещении данных, предоставляемой ФС, на уровне приложений - для оптимизации паттернов доступа.

Блок у SSD 4kb, но не в этом дело. Чтобы такой кэш работал эффективно, необходима «пространственная локальность» - чтобы как можно больше блоков данных попадало в 1 чанк. Иначе хост будет гонять немодифицированные данные и итоговая производительность всё равно будет низкой. Несмотря на то, что запись формально крупноблочная. Именно по этой причине у SSD низкая скорость 4k-записи.

Чтобы достичь высокой локальности, ФС должна накапливать статистику по доступу и, подобно HotSpot, оптимизировать размещение данных. Если она это будет делать не консультируясь с приложением, время накопления будет очень большим.

>> OCZ Agility 60G

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

начинать рассматривать надо с х25м 160 (размер имеет значение) если много пишете то х25е

enterprise ssd (even mlc ones) обычно хорошо работают с маленькими записями

never do raid5/6 of ssd for database (usually make performance worse) raid1 or 10 (not really reccomended) 2*raid1 is better

new generation of ssd (intel g3, ocz revo x2, ocz ibis) is way better than old ones.

new generation of ssd (intel g3, ocz revo x2, ocz ibis) is way better than old ones.

Если не трудно, попробуйте рандомно писать на эти девайсы 4k-блоками по всему объему в течение нескольких часов (или суток). И посмотрите на график латентности операции записи. У меня на Agility латентность росла почти линейно (графики здесь) и в установившийся режим даже не думала входить. Ситуацию выправляет периодический TRIM на пол девайса или на весь объем.

Если вышеозначенные девайсы такой бедой (сублинейная деградация) не страдают, значит всё более-менее. Если же страдают, то периодически придется делать полный TRIM.

>вроде бы по умолчанию (см параметр -a в hdparm) Linux использует упреждающее чтение по 256 блоков за раз, что как раз и дает 128 кб...

я гоыорил о записи. Запись на ssd идет только полными блоками. хоть один бит пишешь - весь блок надо очистить и записать и количество циклов записи ограничено. Так что записывая данные с задержкой, можно неплохо увпличить не только скорость, но и ресурс привода.

Хех, ну кто ж таким образом управляет виртулками? RH специально свою тулзу запихнули. И уверен с набором патчей.

>Авель, толку от этой батареечки 0, если такой же нет в SSD. Известная беда. При пропадании питания, данные из кэша SSD тоже пропадают. А если в нем отключить кэширование записи, то с производительностью станет всё более чем печально.

Вот это плохо. Надо обеспечивать запись данных.

Чтобы достичь высокой локальности, ФС должна накапливать статистику по доступу и, подобно HotSpot, оптимизировать размещение данных. Если она это будет делать не консультируясь с приложением, время накопления будет очень большим.

Да ладно. Приложение, которое может перемешивать данные для их уплотнения, это что-то из ряда космологии.

ССДшная ФС должна больше писать в журнал изменений. Если ускорить сборку данных при чтении большим кешем и своим dsp, то должно рботать эффективно и быстро.

Scientific Linux 6.0 давно в обкатке

Scientific Linux 6.0 лежит в обкатке с 15-Oct-2010: http://ftp.scientificlinux.org/linux/scientific/6rolling/iso/ Буду ставить.

>Вот это плохо. Надо обеспечивать запись данных.

Надо выбирать соответствующий накопитель. Например, известный всем Intel x25e такой батарейки не имеет (не имел). А вот Vertex 2 Pro - имеет.

Да ладно. Приложение, которое может перемешивать данные для их уплотнения, это что-то из ряда космологии.

Ничего подобного. Рано или поздно (а точнее, скоро) мы к этому придем.

ССДшная ФС должна больше писать в журнал изменений. Если ускорить сборку данных при чтении большим кешем и своим dsp, то должно работать эффективно и быстро.

Кэши... Вот уж эта вера в кэширование. Как только размер рабочего множества переваливает за размер кеша, мы получаем высокую ступеньку на графике производительности :) Ибо толку от него становится ноль.

Чтобы приложение могло получить выигрыш от кэша, оно должно уметь разделять свои данные на рабочие множества, размером меньше, чем размер кэша.

It is hard to do such tests on production servers,

But i found similar tests on the internet.

http://www.mysqlperformanceblog.com/2010/05/25/flashcache-tpcc-workload/

PS: You can buy separate BBU (battery backup unit) for ssd (in order not to lose info in case of power fail)

Btw google have BBU in every server

PPS: also it is a good idea to use raid1 and/or master/slave configs

ssd can (and will eventually) fail

PPPS: you should tune your scheduler, some system params to get most of ssd. (do noatime and nodiratime at least)

other ideas: ext4 / nojournal, | XFS nobarrier

echo deadline > /sys/block/sda/queue/scheduler

echo 1 > /sys/block/sda/queue/iosched/fifo_batch

always keep 50%+ of free space on device.

check: http://www.slideshare.net/matsunobu/ssd-deployment-strategies-for-mysql

На мой взгляд, SSD идеальны в качестве недостающего звена в иерахии памяти между очень быстрой RAM и очень медленными HDD, в качестве прозрачного персистентного кэша. Особенно вкусно для этой цели смотрятся устройства на PCI-E x4.

Идея интересная, и в чем-то созвучна Seagate... они предлагают тоже самое. Вот только реализация у них пока не очень. И я думаю еще долго будет не очень.

Тут скорее нужен подход реализованный в Documentum: есть два типа хранилища - быстрое и дорогое и маленькое, и медленное и дешевое и большое, а приложение перемещает между ними информацию по мере надобности (в засимости от действий пользователя).

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

Та ви што?!?! Упал со стула. Суся у провов?! не в Ынтерпрайзе?! O Fuck! You made my day!

Насчет BBU thanks за идею))

PPPS: you should tune your scheduler, some system params to get most of ssd. (do noatime and nodiratime at least)

Ага. Для SSD объем записываемых данных - ограниченный ресурс (да еще и с трудом поддающийся учету). Ни приложения, ни ФС оказались не готовы к такому сценарию.

always keep 50%+ of free space on device.

Вот. Ключ к успеху :) Технически могу немного ошибаться... ОС предоставляет API для TRIM на уровне приложений, но пользоваться та же СУБД им сразу не сможет. Поэтому, например, свободное место в файлах БД не всегда отдается назад системе. И с точки зрения SSD оно является занятым, не TRIM-нутым.

Я бы рекомнедовал разбить накопитель на два раздела по 50%, один оставить чистым и периодически стирать его TRIMом весь. Это здорово упростит жизнь любому контроллеру SSD.

Тут скорее нужен подход реализованный в Documentum: есть два типа хранилища - быстрое и дорогое и маленькое, и медленное и дешевое и большое, а приложение перемещает между ними информацию по мере надобности

Ну это просто деталь реализации - «непрозрачный» кэш. Он просто по определению будет куда более интеллектуальным (и сложным), чем «прозрачный», основанный на обобщенных допущениях.

И проблема 4К блоков у них решена.

Всё же, если есть возможность, попробуйте посмотреть динамику роста латентности при случайной записи 4к-блоками по всему носителю... Такие тесты на публичных сайтах не проводились.

А без регистрации на оффсайте исошки нигде скачать нельзя?

> А как с 5 обновиться на 6? Кто-нибудь так пробовал?

Еще не пробовали. Но в теории, поставить DVD и сказать Linux Upgrade? :)

А у меня не хотит апгрейдить. Только новую инсталляцию предлагает (

Всё же, если есть возможность, попробуйте посмотреть динамику роста латентности при случайной записи 4к-блоками по всему носителю... Такие тесты на публичных сайтах не проводились.

Если подскажете утилиту, то я попробую запустить такой тест.

У Вас Linux?

нет PAM'а

Не вижу в этом преимущества. PAM устроен достаточно понятно, и может делать довольно полезные штуки (pam-mount, к примеру).

Простейшая система загрузки

Можно подумать, System-V очень сложная... Опять же, можно заменить sysv-rc на file-rc, и, сохраняя всю гибкость System-V, избежать ковыряния в джунглях симлинков, редактируя все ранлевелы в одном файле.

aist1

нет... на этой машине Win7.

>Ничего подобного. Рано или поздно (а точнее, скоро) мы к этому придем.

Да никогда. Полторы тысячи приложений в стандартной установке федоры должны узнать о существовании ssd?

Кэши... Вот уж эта вера в кэширование.

это не вера, а обычный инструмент на порядок уменьшающий количество обращений к ssd.

Как только размер рабочего множества переваливает за размер кеша, мы получаем высокую ступеньку на графике производительности :) Ибо толку от него становится ноль.

Опять не верно. Ибо размер рабочего множества в кеше фиксирован. Сколько бы там не держала в себе программа, запись и чтение идет блоками по 4к. И вся задача кеша, сделать так, чтобы запись шла не байтами, а килобайтами. Он это делает с гарантией.

Я сейчас не говорю вообще о кешах. И не о скорости чтения/записи равной скорости кеша. Я говорю о скорости работы всего ssd, которая неравномерна, но не падает ниже определенного гарантированного минимума. И этот минимум гораздо выше, чем у обычного нжмд.

По статистике в мире каждый второй сервер это винда, и корпорации единственное место, где виндовые сервера используются.