Трёх уровневое кэширование для HDD.

>логичное решения для ускорения работы с SATA дискам

гугли «raid 10»

Raid10 из 4-ёх SATA дисков уже есть, при чём тут SSD?

«трехуровневый» пишется слитно :3

SSD тут не причем.
лучше, опиши задачу - почему не хватает скорости рейда?

>лучше, опиши задачу - почему не хватает скорости рейда?
С каких пор raid* на HDD уменьшал seek time?

поэтому я и прошу описать где именно затык

на сколько знаю такого нету. Мы городили свои костыли для этого.

изобрели zfs? O_o

ZFS имеет две замечательные функции, которые резко увеличивают производительность операций чтения. Это ARC и L2ARC. ARC предназначена для замены кэша. ARC - это очень быстрый кэш, располагающийся в ОЗУ - памяти сервера.Объем доступной ARC памяти это обычна вся память сервера минус 1ГБ.

Например, Ваш ZFS сервер имеет с 12 ГБ ОЗу имеет 11ГБ выделенной под AR, что значит что ZFS сервер сможет закешировать до 11ГБ часто-используемых данных. То есть любые запросы к частоиспользуемым данных будут идти не на медленный жесткий диск, а прямо к в память. Это значительно повышает скорость доступа к часто-используемым данным.

Чем больше памяти в сервере тем больше Вы можете выделить ARC, в конце концов это вопрос стоимости. Вот тут нам помогу L2ARC - это адаптивный кэш второго уровня. В ZFS система L2ARC обычно называются кэширующими дисками (cache drivers).

Быстро-быстро, вприпрыжку бежать и читать про L2ARC >>>

Из свободных рещений, афаик, нет. Но есть отдельные части типа XFS + DMAPI + HSM

http://oss.sgi.com/projects/xfs/training/xfs_lab_10_dmapi.pdf

Потому что столько обращений к S-ATA дискам на чтение, что они перестали справляться по количеству выдаваемых IOPS. Пока решил проблему увеличением памяти с 8 гигов до 32 на сервере. Теперь многое в кэше, который в памяти. Но время от времени бывает нет-нет да и начнутся лаги, когда из кэша вытеснятся «горячие» данные кем-нибудь. Вот и пришла идея использовать в качестве второго уровня кэша SSD диски, это ещё + 256GB кэша (два SSD в RAID0). Данное решение будет дешевле чем организовывать хранилище из SAS дисков хотя бы объёмом в половину меньшего, чем текущий объём.

2iZEN. ARC - это тот же файловые кэш в Linux, а вот L2ARC как бы получить на Linux-е без FUSE.

>true_admin. Примерно не расскажешь из чего костыли делали?

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

Это не то же самое что ты предложил, но тоже задачу решает. Вместо отдельного сервера можно использовать отдельный ssd. Ну а с памятью ничего не сделаешь, тут ещё очень многое можно улучшить.

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

>>Потому что столько обращений к S-ATA дискам на чтение

если записи немного, может стоит попробовать собрать raid1 из этих 4 дисков? 4-way, естественно Ж)
в некоторых случаях помогает.

Что-то мне кажется что один ssd уделает «скока-хошь-raid» на обычных винтах ибо обычные винты у меня бОльшую часть временем занимаются позиционированием головок.

Блин, вот энергию бы лора да в нормальное русло. Давно бы уже сделали :)

Давно уже сделали. Линаксоеды тормозят только.

>Что-то мне кажется что один ssd уделает «скока-хошь-raid» на обычных винтах

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

Блин, вот энергию бы лора да в нормальное русло. Давно бы уже сделали :)

4 звезды жеж, давно пора понять, что тут эта масса не управляется, разве что на уровне коллективно-бессознательного попробовать, хотя и так большинство :D

Давно бы уже сделали :)

дак давно сделали, аж 4 порта, только в каком они все состоянии без понятия и проверять тоже особо не тянет ))

да и не только seek'ом едины

я поэтому и уточнил что в моих условиях.

давно пора понять

просто мечтаю в слух

аж 4 порта

не интересно, жду когда в btrfs запилят. Вообще, возникла сумасшедшая идея на fuse написать обёртку которая это всё сделает. Но пока лень.

>жду когда в btrfs запилят А btrfs обещают функционал кэширования не только в памяти, но и на более быстрых устройствах чем HDD? ИМХО, в моих условиях, 4TB дискового массив на SATA, плюс 256GB для кэша на SSD и 16GB кэша в RAM, было бы по производительности не сильно хуже, чем дисковый массив на дисках SAS, а зато на сколько дешевле.

>Можно ли на СentOS5 реализовать кэш таким образом, что бы данные с диска кэшировались в памяти, при вытеснении из памяти кэшировались на SSD и при нехватке SSD старые данные удалялись с SSD

Поместить своп на SSD.

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

btrfs обещают функционал кэширования не только в памяти, но и на более быстрых устройствах чем HDD?

да.

в моих условиях

тут ключевой момент у кого какие условия :). У нас стояли sas 15k rpm, их как-то в притык хватало. Всё в seek упиралось.

По формулировке своп. Но ты явно хочешь не этого, а кеша для дисков попробуй dm-cache, но оно старье.

Есть вот такой проект, разработанный в Facebook: http://github.com/facebook/flashcache