Действительно ли там такая вещь как персистентный электронный диск?

Вы могли записать простое rc сценарий, который делает это. Я не забываю делать подобную вещь назад в дни DOS (с autoexec.bat) для быстрого доступа к некоторым файлам.

Вы могли бы рассмотреть покупку Твердотельные или Электронные диски с интерфейсом HDD вместо этого.

То, что Вы ищете, является чем-то, что хранит данные фс в памяти, сохраняет его, если это может, но не волноваться слишком много о потере Ваших данных (как в том, если кто-то выключает питание).

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

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

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

Электронный диск является, вероятно, способом пойти. Однако, если у Вас есть немного денег, чтобы потратить, и хотеть действительно персистентное решение, можно также хотеть посмотреть на Жесткие диски SSD. Технология довольно молода и не так устойчива как классический жесткий диск все же, но это назревает и становится довольно доступным.

Контакт с электронными дисками в Linux довольно тривиален. Можно создать и использовать их несколькими различными способами в зависимости от потребностей, затем просто скопировать их содержание (с CP или dd) к HDD прежде, чем закрыть поле или в запланированном интервале для предотвращения потери данных для неожиданного завершения работы. Смотрите на них практическое руководство, я думаю, что они достаточно просты:

http://www.vanemery.com/Linux/Ramdisk/ramdisk.html

http://wiki.archlinux.org/index.php/Ramdisk

M

Если Ваше приложение является достаточно небольшим, Вы могли бы захватить твердотельный накопитель на 30 ГБ для своей машины. Сравнительные тесты показывают им делающий 3x или 4x более быстрые чтения, чем традиционные диски (и что-то как 2.4x так же быстро как 10k диски об/мин). Более крупные диски стоят пакета, но на 30 ГБ просто находятся под 200$.

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

То, что можно сделать, выполняется два mysql сервера с одним из них являющийся основным устройством, которое существует на электронном диске и другом являющемся ведомым устройством, которое сохраняет все данные к жесткому диску.

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

кошка mysqldump-uroot-hslaveServer dbName | mysql-uroot-hramdiskServer dbName

ОС уже делает это для регулярных доступов к файловой системе (буферизует записи к RAM и затем сбрасывает их позже). Но быть более устойчивыми, много баз данных затем делают fsync (), чтобы вынудить ОС сбросить буферы к диску, который замедляет вещи.

Управление, делает ли MySQL синхронизирующую операцию, сделано на уровне базового DB. Я посмотрел на InnoDB, и он не позволяет Вам отключать fsync.

Но ища вокруг я нашел libeatmydata, который может отключить fsync для процесса, который должен дать Вам поведение, которое Вы ищете.

Вы говорите выполнение этого на портативном компьютере. "Быть в спящем режиме" и последовательно возобновляют работу функциональности над ним? Раз так... Вы могли ПОСЛЕДОВАТЕЛЬНО использовать это и также делать один или обе из этих двух ПОЛНОСТЬЮ ОТДЕЛЬНЫХ вещей помочь улучшить времена доступа для обеих веб-страниц и для запросов MySQL:

• (a) настроенный и использование ramfs для Вашего DOCROOT; Google для "мини-практического руководства Электронного диска Linux" для деталей. Это может или не может окупиться. Вы могли бы быть более обеспеченным сохранением что RAM для использования MySQL (т.е. (b) ниже) особенно, если у Вас есть много данных в тех таблицах MEMORY.

• (b) мигрируйте Ваши таблицы базы данных MySQL, к которым чаще всего получают доступ, к механизму устройства хранения данных ПАМЯТИ Удостоверяются, что Ваша структура таблицы не требует BLOB или Столбцов текста; если это сделает, то это не будет работать. Читайте на этом здесь: http://dev.mysql.com/doc/refman/5.0/en/memory-storage-engine.html

Для каждого из вышеупомянутых необходимо было бы запланировать что-то для периодического копирования изображений в оперативной памяти прочь в диск. Преимущество состоит в том, что Вы будете только писать в тот медленный диск время от времени - своего рода замедленную съемку своего рода "синхронизация" - вместо того, чтобы писать с каждым изменением в таблице MySQL и каждым изменением в файле в DOCROOT. Таким образом для обоих случаев Вы могли использовать КРОН для планирования "резервного копирования":

• В ramfs случае Вы могли создать архив tar всего содержания в файловой системе.

• Для таблиц MySQL Вы могли создать серию операторов, подобных следующему:

  вставьте в выбор someInnoDBdatabase.tablename * от someMemoryDatabase.tablename

  Принятие Вашей таблицы в обеих базах данных имеет ту же самую структуру, это скопирует все с таблицы в someMemoryDatabase в someInnoDBdatabase таблицу того же имени - эффективно резервное копирование дисковой таблицы MEMORY.

При составлении тех таблиц в базе данных памяти:
Принятию Вас управлял таблицами дисковый механизм теперь, Вы могли использовать 'шоу, создают имя таблицы таблицы', чтобы заставить MySQL давать Вам точно SQL, необходимо будет воссоздать ту таблицу..., затем изменяют часть двигателя для определения, чтобы использовать механизм ПАМЯТИ и выполнить это.

Надеюсь, это поможет!
- pbr

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

"ОС уже делает это для регулярных доступов к файловой системе (буферизует записи к RAM и затем сбрасывает их позже). Но быть более устойчивыми, много баз данных затем делают fsync ()..." - R Samuel Klatchko

Таким образом для ускорения модульных тестов, таким образом, они не сидят без дела, ожидая каждой записи, чтобы быть полностью fsync'ed, существует несколько вещей, которые можно попробовать:

• запустите тесты в виртуальной машине, которая позволяет Вам включить "небезопасное" кэширование обратной записи, которое эффективно поворачивает fsync () в чрезвычайно быстрое нет. (Но только сделайте это для поблочного тестирования, не на производственной базе данных).
• запустите тесты в виртуальной машине с - опция снимка, такие как QEMU - это перенаправляет все записи к файлу журнала. Во время теста это перенаправляет некоторые чтения к тому файлу журнала для поддержания иллюзии. Относительно линейные записи к файлу журнала, вероятно, будут быстрее, чем записи, которые рассеиваются на всем протяжении подложки диска.
• так или иначе минимизируйте количество записей в Вашем модульном тесте - это должно действительно писать в тестовую базу данных?

• Если можно обрезать тестовую базу данных, используемую модульными тестами для установки полностью к RAM, возможно, заставив ОС предварительно кэшировать всю базу данных сразу (а не читать и кэш немного за один раз, по мере необходимости в тесте) мог бы сделать тесты быстрее; с чем-то как

  cat the_test_database.db > /dev/null

• запустите тесты на машине с RAID 0 чередований для ускорения чтений и записей. (Я искал ноутбуки, которые поддерживают RAID - увы, ноутбуки, которые поддерживают RAID, очень редки).