| |
| 2.76, dvfv (?), 09:58, 07/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
Я бы не сказал. Сначала система загружается с диска в ОЗУ, потом загружается это с диска в ОЗУ, потом это с диска в ОЗУ загружает данные. Костыль. Это как если бы в Windows файл подкачки расположить на RAM-диске.
| | |
| |
| 3.77, Andrey (??), 10:29, 07/04/2012 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Костыль. Это как если бы в Windows файл подкачки расположить на RAM-диске.
для windows 2003 std это нормальное решение если хотите заюзать более 4гб
| | |
| |
| |
| |
| 6.90, Forth (??), 16:33, 08/04/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> 2003 Std плевать хотел на PAE
Вы правы, я ошибся. Действительно PAE есть только в Enterprise и Datacenter.
| | |
|
|
|
|
|
| 1.5, Нанобот (?), 19:57, 05/04/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
интересно, а можно такого же добиться, сделав raid1 из ram-диска и обычного?
| | |
| 1.9, Tav (ok), 20:13, 05/04/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +11 +/– |
 Так ведь и для "обычных" дисковых ФС данные кэшируются в оперативной памяти. И барьеры также используются. А если оперативной памяти достаточно, обращения к диску для чтения могут быть достаточно редкими (я это ясно ощутил, когда проапгрейдился с 2 до 6 GB).
Так в чем все-таки соль этого EPRD?
| | |
| |
| |
| 3.19, Tav (ok), 21:51, 05/04/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Некоторые туда профиль фокса пихают.
Помогает? Вроде, и так нормально: горячий запуск меньше секунды (как раз за счет кэшей), холодный дольше, но это один раз.
| | |
| |
| 4.35, Lain_13 (?), 01:50, 06/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
 Ну у некоторых он до сих пор секунд по 20-40 запускается, а уж если с сотней табов, да ещё и всех сразу, а не в выгруженном состоянии (там теперь есть опция — не загружать табы сразу при запуске, а лишь по мере надобности). То да, помогает.
Вот только дисковый кэш нужно свести к минимуму — всё равно толку от него при таком раскладе ноль целых и ноль десятых. А вроде можно и вовсе выключить.
| | |
|
|
| 2.13, Аноним (-), 21:11, 05/04/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Так в чем все-таки соль этого EPRD?
Наверно, в дополнительной гибкости. Можно кэшировать отдельные файлы, а не весь диск; можно принудительно держать файл в памяти.
| | |
| |
| 3.18, Tav (ok), 21:48, 05/04/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
Тогда следовало именно об этом и писать в новости.
| | |
|
| 2.14, grondek (?), 21:32, 05/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
Это вы про домашиний компьютер говорите. Там увеличение оперативки решает проблемы свопа. А если идет интенсинвая запись/чтение, то увеличением оперативки не решить проблему.
| | |
| |
| 3.17, Tav (ok), 21:47, 05/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
Про домашний. Но речь не о свопе, а именно о кэше ФС.
| | |
|
| 2.20, антоним (?), 22:13, 05/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
Соль, судя по всему, в том что под кэш фс отводится память по остаточному принципу, а тут выделена конкретная область памяти. Которая в своп не вытеснится, например, или бесполезным (но только что прочитанным\записанным) левым файлом не забьется. Правильно сказали - для домашнего десктопа малополезно, только для случаев интенсивной работы с дисками и некоторой общей нехватке памяти.
| | |
| 2.38, тоже Аноним (ok), 08:51, 06/04/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Так в чем все-таки соль этого EPRD?
Я, например, живо представил, как использовать такой диск при компиляции: на него могут валиться объектные файлы - объемные, но после компиляции ненужные в принципе. А если идет правка и перекомпиляция каждые пару минут, то и результат, в принципе, не критично потерять...
Впрочем, тут подходит любой RAM-диск без лишних сложностей.
| | |
| 2.91, Michael Shigorin (ok), 16:50, 08/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
 > Так в чем все-таки соль этого EPRD?
Из подуманного: попробовать впихнуть место для сборочных чрутов вместо tmpfs, если надоест изредка восстанавливать забытые конфигурации временных сборочных репозиториев под конкретную задачу, аккурат попавшие под ребут. Но и то вряд ли.
Насколько понимаю, соль в обеспечении гораздо большей степени "батчевости" синхронизации на постоянный носитель. Обычная ФС и с кэшированием тормозит на том, что всё-таки беспокоится о долетании записанных в файлы данных до блинов, в отличие от того же tmpfs...
| | |
| |
| 3.97, Алексей Поляков (?), 13:51, 09/04/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Даже не столько ФС тормозит, сколько в юзерспейсе исторически много вызовов sync/fsync/fdatasync etc. Если с ними бороться "грязными" методами (например глушить через LD_PRELOAD) - то, как показала практика, рано или поздно это кончается проблемами.
Плюс дисковые ФС рассчитаны на медленные устройства, и для хранения таблиц обычно используют разного рода Б-деревья - а хеши для данных, находящихся в памяти, быстрее.
| | |
|
|
| 1.21, антиантоним (?), 22:32, 05/04/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Но тогда решение ещё проще: добавить в ядро параметр "размер фиксированного кэша" - и вопрос решён без EPRD.
| | |
| |
| 2.92, Michael Shigorin (ok), 16:51, 08/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Но тогда решение ещё проще: добавить в ядро параметр "размер фиксированного кэша"
> - и вопрос решён без EPRD.
...и получен древний опёнок, где размер кэша при сборке задавался. :)
| | |
|
| 1.22, Rico (??), 22:52, 05/04/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Очень полезный функционал, базу данных полностью в оперативу и сброс на SSD винт раз в час + UPS - можно неплохо разогнать работу с базой.
| | |
| |
| 2.26, Anonymouse (?), 23:55, 05/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
Ну разве MS-SQL какой .... Нормальные базы тюнятся на много-рамы-в-кэш и без этого ...
| | |
| |
| 3.47, an. (?), 12:15, 06/04/2012 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> EPRD оформлен в виде модуля для ядра Linux
и:
> Ну разве MS-SQL какой
Я что-то упустил? :)
| | |
| |
| 4.73, Аноним (-), 23:48, 06/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
Да. Будут разрабатывать порт MS-SQL для линукс чтобы было для чего применять EPRD.
| | |
| |
| 5.85, Аноним (-), 00:39, 08/04/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Да. Будут разрабатывать порт MS-SQL для линукс чтобы было для чего применять EPRD.
Скорее, допил wine под запуск mssql.
| | |
|
|
|
| 2.81, Forth (??), 22:48, 07/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
 > Очень полезный функционал, базу данных полностью в оперативу и сброс на SSD
> винт раз в час + UPS - можно неплохо разогнать работу
> с базой.
На PostgreSQL с fsync = off можно получить тот же эффект не плодя лишних сущностей.
| | |
| |
| 3.86, Аноним (-), 00:39, 08/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
> На PostgreSQL с fsync = off можно получить тот же эффект не
> плодя лишних сущностей.
А раз в час оно синкаться будет?
| | |
| |
| 4.89, Forth (??), 16:31, 08/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> На PostgreSQL с fsync = off можно получить тот же эффект не
>> плодя лишних сущностей.
> А раз в час оно синкаться будет?
А зачем? У вас же по условию задачи UPS.
| | |
|
|
|
| 1.23, добрый дядя (?), 23:20, 05/04/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– | |
но ведь обычные файловые операции щедро кэшируются в Linux-е - это заметили все у кого много рамы и так... и без этой EPRD будем жить, в оффтопике с этим дела гораздо хуже кстати
но буду рад если кому-то EPRD принесет пользу!
| | |
| |
| 2.30, Аноним (-), 00:26, 06/04/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
Linux с кэшированием - это весч (если только софт не тупорылый как, к примеру, vmware workstation)! У меня на машинке памяти под потолок, так у меня бывает что я фильм запускаю сразу после скачивания - так обращении к винту вообще нет.
| | |
| |
| 3.32, Аноним (-), 00:29, 06/04/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
Оу, забыл добавить: "EPRD" - тоже весч! Я давно что-то подобное хотел, а тут все уже есть. Будет время - поразбираюсь с ним как следует и покажу (статьей) "мастер-класс" с EPRD (несколько идей давно поселились в голове - ну не зря же я так сильно хотел подобное).
| | |
|
|
| 1.27, yohel (?), 00:03, 06/04/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 интересно, насколько в перспективе возможна установка дистрибутива линукса да еще и с частью хоума на подобный ram-drive-fs раздел?
| | |
| |
| 2.36, Lain_13 (?), 01:59, 06/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
> интересно, насколько в перспективе возможна установка дистрибутива линукса да еще и с
> частью хоума на подобный ram-drive-fs раздел?
Купи себе SSD, например. Тогда в рам-драйв можно будет только /home слить и держать его на обычном винте. Сэкономишь кучу памяти и возможно даже денег
| | |
| |
| 3.71, yohel (?), 22:23, 06/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
ssd в мой ноут стоит дорого. А вот 8 гиг оперативы, из которых 4 можно отвести под рут раздел арча - стоит вполне доступно. Да и интересно было бы поэкспериментировать с таким конфигом.
| | |
| 3.93, Michael Shigorin (ok), 16:54, 08/04/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Купи себе SSD, например. Тогда в рам-драйв можно будет только /home слить
Да нормальные SSD и так не вызывают желания что-то ещё разгонять, чаще начинает в процессор упираться...
2 yohel: хм, а почему дорого -- явно ж не 2.5" или IDE, если обсуждается 8G RAM?
| | |
|
|
| 1.29, Аноним (-), 00:23, 06/04/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
Хочу плату расширения чтобы можно было туда 256 планок памяти DDR3 можно было напихать и аппаратную поддержку EPRD на нем. Годный будет девайс: очень дешево и очень сердито.
// виндузятники - минусуем меня
| | |
| |
| 2.31, кевин (?), 00:26, 06/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
данафейхоа? вон под заказ тебе ссдху на 40 ТБ вкорячат за бешенобабло.
| | |
| 2.33, Stax (ok), 00:50, 06/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
 Вы в своем уме? Вы представляете, какой (и сколько) контроллер памяти нужен для поддержки 256 планок?
Такие девайсы для серверов уже есть, с "аппаратной поддержкой" (память + флеш + конденсаторы для хранения заряда, позволяющего при отключении перелить на флеш), и по множеству причин совершенно не дешево. Но кому нужно, покупает.
| | |
| 2.39, ryoken (?), 09:03, 06/04/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Хочу плату расширения чтобы можно было туда 256 планок памяти DDR3 можно
> было напихать и аппаратную поддержку EPRD на нем.
Благородный дон представляет себе, СКОЛЬКО физически\геометрически места сия куча займёт? Мне навскидку не удалось.
| | |
| |
| 3.75, Аноним (-), 07:13, 07/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
Ну, в здоровый четырехъюнитовый сервак с восемью процами серии Xeon E7 можно впихнуть 128 16-гиговых серверных планок DDR3, итого 2 Тб памяти под кэш и 80 ядер проца. Стоит, правда, эта зараза как самолет и шумит не меньше.
| | |
|
|
| 1.40, Аноним (-), 09:21, 06/04/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Интересная идея...
Кажется, я такую хочу...
Это ж нехило можно "подпереть" любую FS... Или я что-то недопонял?
| | |
| 1.41, alex.h (??), 10:18, 06/04/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Наверно для систем на флеш-дисках полезная вещь была бы, если монтировать через эту прослойку, то и флеш дольше проживёт и данные более-менее в сохранности. Вот только можно ли её использовать для /, /boot, /etc?
| | |
| |
| 2.44, Ваня (??), 11:02, 06/04/2012 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Глупость!
Запись:
- на диск
- в ОП
Чтение:
- из ОП
С учётом того что скорость чтения флэш очень высокая, а скорость записи низкая, пользы от использования RAM-диска с зеркалированием на SSD немного. Для НЖМД возможны лишь локальные применения для узко-профилированных задач.
У меня работает RAM-диск на 40 Мб без зеркалирования для временных файлов, результатов компиляции и сохранения скачиваемых из интернета файлов (по умолчанию всё на него валится) + этот диск единственный расшарен в локальную сеть для обмена файлами.
| | |
| |
| 3.49, тоже Аноним (ok), 12:42, 06/04/2012 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Глупость!
Ваня, можно вас попросить: вешайте, пожалуйста, такое предупреждение перед каждым своим постом. Не все еще в курсе вашего амплуа.
По теме: человек говорил о времени жизни SSD, а не о скорости. Вполне логично, что, чем реже и кучнее случается запись на SSD, тем меньше расходуется его резерв.
| | |
| |
| 4.50, Ваня (??), 12:46, 06/04/2012 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Запись на SSD случается также часто, как и запись на RAM-диск, чтение с диска не производится вообще.
Т.е. мы оставляем слабые места SSD (ресурс жизни и его зависимость к записи, медленную запись) и не используем не одного сильного (скорость чтения).
А теперь ещё раз про глупость.
| | |
| |
| 5.52, Аноним (-), 12:49, 06/04/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Запись на SSD случается также часто, как и запись на RAM-диск, чтение
> с диска не производится вообще.
Запись на накопитель в EPRD делается порциями, в зависимости от настроек (по дефолту раз в 3 секунды). Читайте MAN про то, как работают barriers.
> А теперь ещё раз про глупость.
Вот-вот.
| | |
| 5.95, Michael Shigorin (ok), 18:40, 08/04/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Запись на SSD случается также часто, как и запись на RAM-диск
У нас на линуксе это широко тюнится: /proc/sys/vm/dirty_writeback_centisecs, /proc/sys/vm/dirty_ratio, /proc/sys/vm/dirty_background_ratio вообще и discard,commit=15,nobarrier,delalloc,min_batch_time=1000 (например) для той же ext4.
> А теперь ещё раз про глупость.
Глупость и глупость, весна уже, зачем бы морозить. :)
| | |
| |
| 6.99, Алексей Поляков (?), 14:03, 09/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> Запись на SSD случается также часто, как и запись на RAM-диск
> У нас на линуксе это широко тюнится: /proc/sys/vm/dirty_writeback_centisecs, /proc/sys/vm/dirty_ratio,
> /proc/sys/vm/dirty_background_ratio вообще и discard,commit=15,nobarrier,delalloc,min_batch_time=1000
> (например) для той же ext4.
commit=81600 тогда уж
а вообще для скорости - это tune2fs -o journal_data_writeback (для безбашенных - tune2fs -O ^has_journal)
а для бережного использования ssd по-моему ext4 решили не развивать в пользу btrfs (который еще сырой)
| | |
| |
| 7.100, Michael Shigorin (ok), 00:12, 10/04/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> commit=81600 тогда уж
Не-не, привёл для /home -- для /var/ftp с локальным зеркалом сизифа совсем другие цифры. :)
| | |
|
|
|
|
|
| 2.78, Pilat (ok), 13:07, 07/04/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
 >Наверно для систем на флеш-дисках полезная вещь была бы, если монтировать через эту
>прослойку, то и флеш дольше проживёт и данные более-менее в сохранности. Вот только можно
>ли её использовать для /, /boot, /etc?
скорее пользу можно ждать, используя прослойку между HDD и кэшем на SSD вместо оперативной памяти. А boot и etc особенно ускорять не нужно.
| | |
|
| 1.68, SuseUser (?), 18:38, 06/04/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Жаль раньше не знал про эту приблуду. Совсем недавно решал задачу с клиентскими компьютерами с флешками вместо ЖД: / на squashfs /etc и /home на nfs, ну а /tmp на tmpfs. Вот и ломал голову с /var, куда бы его деть
| | |
| 1.69, дядя (?), 19:21, 06/04/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Тут основной вопрос - как оно восстанавливается после загрузки. Если полностью надо ждать чтения с диска, то фигня.
| | |
| 1.70, Аноним (-), 19:32, 06/04/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> В итоге будет представлено работающее на уровне ядра Linux (в LessFS используется FUSE) высокопроизводительное блочное устройство, поддерживающее автоматическое объединение дубликатов данных.
Единственная более-менее понятная и обнадеживающая новость.
А смысл EPRD непонятен совершенно - чем оно отличается от обычной ФС с большим кешем?
| | |
| |
| 2.74, Aleks Revo (ok), 02:16, 07/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
 Вопрос: зачем???
Не проще ли ядро читать с обычного раздела, если чтение при загрузке всё равно идёт с диска?
А запись в /boot так и вообще происходит раз в пятилетку...
| | |
| 2.84, Аноним (-), 00:37, 08/04/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Давно ждал. Вот если grub еще научится ядро грузить из такого диска.
А в чем профит? Лучше уж /boot на ssd вынести.
| | |
|
| 1.79, Аноним (79), 21:00, 07/04/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 вопрос почти не втему: существует ли, в Линуксе для десктопа "ускорение" подобно как у виндувсе с использованием флеш.? Сорри за оффтоп но статтья навеяла.
| | |
| |
| |
| 3.87, тоже Аноним (ok), 14:17, 08/04/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
Вопрос был про другой флеш - про флешку, которую Винды научились использовать как быстрый своп, чтобы ускорить загрузку системы.
В Линуксе же есть возможность и вынести систему на сколь угодно быстрый носитель, и оптимизировать загрузку непосредственно, оставив в ней только необходимое. Это куда эффективнее, чем подпирание наследственных болезней "передовыми технологиями". Но, конечно, это не выглядит как привлекательный товар. Хотя бы потому, что это не товар.
| | |
| |
| 4.96, Michael Shigorin (ok), 18:44, 08/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Вопрос был про другой флеш - про флешку, которую Винды научились использовать
> как быстрый своп, чтобы ускорить загрузку системы.
Intel TurboMemory[1] в линуксе до сих пор не поддерживается (у меня под руками гиг такого флэша в X61t воткнутым приехал, всё не доходят выкинуть его, чтоб свои милли/микроамперы не жрал) -- поскольку интел сам потом понял бессмысленность всей затеи в корне.
[1] http://www.thinkwiki.org/wiki/Intel®_Turbo_Memory_hard_drive_cache
| | |
|
|
| 2.98, Алексей Поляков (?), 13:55, 09/04/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
> вопрос почти не втему: существует ли, в Линуксе для десктопа "ускорение" подобно
> как у виндувсе с использованием флеш.? Сорри за оффтоп но статтья
> навеяла.
Это по-моему и в винде новой уже выпилили в связи с неудачностью изначальной идеи.
На десктопе (что в винде, что в линуксе) для сколько-нибудь приличной производительности своп должен быть отключен.
| | |
|
|
