Запуск программ в оперативной памяти

Программы и так запускаются в оперативной памяти.

Платиновые треды!

tmpfs

чтение/запись то с дисков идет.

А энергонезависимую оперативку пока не изобрели. Так что купи SSD и не мучай попу.

а как ты узнаешь что ты смог организовать то что хотел?

вот запустил ты программу — как собираешься узнавать — в оперативке она или нет? :-)

man mlock

по скорости работы

Результаты подобной операции в винде:

Из приведенного результата видно, что средняя скорость чтения с HDD составляет 70 Мб/с, а скорость чтения с виртуального составляет 1527 Мб/с, что почти в 22 раза больше чем с HDD. Я думаю, комментарии лишние.

А энергонезависимую оперативку пока не изобрели. Так что купи SSD и не мучай попу.

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

Я вот, например, не могу придумать, как. Думал о shm_open + exec, только execve закрывает shared memory ещё до загрузки нового образа.

твоя «работа» состоит в запуске-закрывании программ?

Программы разные бывают

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

> вот запустил ты программу — как собираешься узнавать — в оперативке она или нет? :-)

man mlock

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

а не чтобы «Запускать программы в оперативной памяти» :)

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

Просто примонтируй tmpfs и перенеси туда все нужные данные. Естественно, при перезагрузке или внезапном отключении питания всё пропадёт.

Просто примонтируй tmpfs

Тогда уж ramfs.
Жалко, только, что не пришёл какой-нибудь хакер и не ответил на оригинальный вопрос.

Понимаешь вопрос? Зачем? Почитай про prelink, preload, read-ahead демоны.
Кстати, как по-твоему происходит загрузка исполняемых файлов в память? Ты ведь знаешь, что после загрузки бинарника его можно удалить?

Просто примонтируй tmpfs и перенеси туда все нужные данные. Естественно, при перезагрузке или внезапном отключении питания всё пропадёт.

тыг в реальной системе — уже ведь полно существует уже примонтированных tmpfs

например /run/

или /tmp/ (но не у всех).

##################################################

но нам тут гораздо важнее узнать — что именно хочет топикстартер .. зачем ему всё это нужно.. :)

а-то вдруг он решает проблему «xy»!

чтение/запись то с дисков идет.

И что? Чтение/запись кэшируются в памяти. После того как система прочихается - всё будет в памяти.

Понимаешь вопрос? Зачем?

Чтобы танки не тормозили, это каждый знает

Из приведенного результата видно, что средняя скорость чтения с HDD составляет 70 Мб/с, а скорость чтения с виртуального составляет 1527 Мб/с, что почти в 22 раза больше чем с HDD. Я думаю, комментарии лишние.

неее.. комментарии как раз НЕ излишни. :)

HDD медленный — но зато *имеет* данные.

оперативка быстрая — но зато *не_имеет* нужных данных.

как ты сделаешь так чтобы в оперативке появились данные? будешь копировать данные из HDD в оперативку? но ведь HDD медленный.. выигрыша нет..

Тогда уж ramfs

чем оно лучше tmpfs?

Ее давно закапали, работы по откапыванию ведутся

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

А как насчет повторных обращений к этим данным?

В качестве примера можно загрузить базу данных, тоже бессмысленно?

А как насчет повторных обращений к этим данным?

а повторные обращения — они всё равно физически не будут задействовать HDD (ну там по минимум будут, совсем)

В качестве примера можно загрузить базу данных, тоже бессмысленно?

думаю кой какой выигрыш будет. я бы так рисковать не стал бы.

не стоит оно того

а если базу дрючат 10к хомячков, чьи действия навечно остаются в этой базе и действий этих под пол сотни в секунду? (:

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

думаю узкое горлышко будет в момент этого синка :)

насчет повторных обращений к этим данным?

Смотри, какой фокус:

$ dd if=test of=/dev/null
712757+1 записей получено
712757+1 записей отправлено
 скопировано 364931808 байт (365 MB), 4.40023 c, 82.9 MB/c
$ dd if=test of=/dev/null
712757+1 записей получено
712757+1 записей отправлено
 скопировано 364931808 байт (365 MB), 0.404766 c, 902 MB/c

не, узкое место, это вайп на несколько минут при факапе, но такое бывает редко

а если базу дрючат 10к хомячков, чьи действия навечно остаются в этой базе и действий этих под пол сотни в секунду? (:

сложный вопрос. нужно все нюансы учитывать.

быть может как-то оттюнинговать базу данных — поособому

хы, «гео» кластер и базы в озу, быстрее решений не видел

Это: http://home.arcor.de/David-Peters/Gigabyte-iRAM-SATA.jpg

Ну будет 1902 MB/c, чем это плохо то?

хы, «гео» кластер и базы в озу, быстрее решений не видел

понятие ОЗУ — не совсем конкретное...

например файл «test» — тоже лежит в ОЗУ у товарища no-such-file .. вот здесь — Запуск программ в оперативной памяти (комментарий) :-)

А мемристоры по-твоему что? И оперативку с батарейкой куда отнести? Они успешно существуют уже лет 10 по меньшей мере.

Ну будет 1902 MB/c, чем это плохо то?

Не будет.

$ cp test /dev/shm
$ dd if=/dev/shm/test of=/dev/null
712757+1 записей получено
712757+1 записей отправлено
 скопировано 364931808 байт (365 MB), 0.455423 c, 801 MB/c
$ dd if=/dev/shm/test of=/dev/null
712757+1 записей получено
712757+1 записей отправлено
 скопировано 364931808 байт (365 MB), 0.443302 c, 823 MB/c

Как видишь, результат получается хуже. Можно конечно тут попробовать что-нибудь настроить. Но существенно лучше чем кэш всё равно не будет.

Кстати, а почему ты сравниваешь свою скорость с моей? У меня как бы очень не быстрая память и процессор в этом отношении.

а повторные обращения — они всё равно физически не будут задействовать HDD (ну там по минимум будут, совсем)

Это только когда система ничем другим не занята. Меня, вот, удручает, что я не могу в Linux для каких-то данных указать «кешировать насмерть». А то, например, такая распространённая ситуация. На Web-сервере лежит файловый архив за 10 лет. Сотни гигабайт картинок. Поисковики и случайные пользователи их постоянно обшаривают. Отдельные конкретные данные нужны очень редко, иная картинка и раз в месяц запросится. Но их очень много. ОС, постоянно, десятки раз в секунду читая эти единожды запрашиваемые данные так же постоянно забивает ими кеш. В результате, когда идёт обращение к свежим данным, которые активно читают текущие пользователи, их уже не оказывается в кеше. Хотя вот их-то (скажем, все картинки за последний месяц) читают постоянно. Получается, что реальная эффективность кеширования ОС в такой ситуации оказывается околонулевой. Постоянно с этим сталкиваюсь. Свежие данные из кеша постоянно выбиваются регулярным чтение старых данных. Прямо, хоть в tmpfs с периодической записью данных на диск делай свежие файловые архивы...

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

расскажи это орацле.

читая эти единожды запрашиваемые данные так же постоянно забивает ими кеш

А куда она должна их прочитать? ЕМНИП там файлы ммапятся на страницы памяти, которые потом расшариваются и в кэш и в читающую программу. Т.е. дополнительно под кэш ничего не расходуется.

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

а не бывает такой кэшевой плитики, которая автоматически могла бы разделять кэш на «частый» и «случайный» ?

например когда идёт частое обращение к одним и тем же данным — то кэш помечается как «частый» , и затем такой НЕ выгружается случайным кешем (а выгружается только другим «частым»)..

не работает так ядро Linux ?

у zfs примерно так и работает кэш.

А куда она должна их прочитать?

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

а что по поводу новых данных, генерируемых ежесекундно 1кк хомячками?

Они тоже кэшируются, причём параметры настраиваются. Тут есть такая проблема, что если много держать в пямяти, то во время очередного sync этот самый синк будет долгим и подтормозит другие операции с диском. Так что идея держать всё в ОЗУ (хоть на диске, хоть в кэше) не всегда хороша. Поэтому и есть настройки.

не работает так ядро Linux ?

По-моему, нет.

...

Нагуглил тут такую штуку, как проект RapidDisk и его приложение RapidCache. Кажется, оно умеет делать именно то, что нужно. Буду экспериментировать. А не поможет — подумаю на счёт tmpfs, загрузки при старте, выгрузки при выключении и синхронизации через lsyncd :) Велосипед, конечно, и не так эффективно, как при кешировании, но задача решаемая.

Тут есть такая проблема, что если много держать в пямяти, то во время очередного sync этот самый синк будет долгим и подтормозит другие операции с диском

Само по себе это не проблема. Есть же всякие lsyncd, которые синхронизируются при изменениях в файлах.

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

например, в системе нет никаких накопителей кроме RAM вообще

Изобрели уже много лет назад. Только вот с массовым производством никак.