Есть ли такая вещь, как постоянный таран?

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

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

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

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

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

Вы могли бы рассмотреть возможность покупки SSD или RAM-дисков с интерфейсом HDD.

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

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

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

M

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

Если ваше приложение достаточно маленькое, вы можете получить 30-гигабайтный твердотельный накопитель для вашей машины. Тесты показывают, что они читают в 3 или 4 раза быстрее, чем традиционные диски (и примерно в 2,4 раза быстрее, чем диски со скоростью 10 000 об / мин). Большие диски стоят в комплекте, но 30-гигабайтные стоят чуть меньше 200 долларов.

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

Что вы можете сделать, это запустить два сервера MySQL, один из которых является основным, который существует на виртуальном диске, а другой - ведомым, который сохраняет все данные на жесткий диск.

Таким образом, если вам нужно запустить сервер mysql на основе ramdisk после того, как он был выключен или что-то еще, вы можете просто ..

cat mysqldump -uroot -hslaveServer dbName | mysql -uroot -hramdiskServer dbName

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

Управление тем, выполняет ли MySQL операцию синхронизации, выполняется на уровне базовой БД. Я посмотрел на InnoDB, и он не позволяет отключить fsync.

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

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

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

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

Для каждого из вышеперечисленного вам нужно было бы запланировать что-то, чтобы периодически копировать образы в памяти на диск. Преимущество состоит в том, что вы будете время от времени записывать только на этот медленный диск - что-то вроде медленной «синхронизации» - вместо того, чтобы записывать каждое изменение в таблицу MySQL и каждое изменение в файл в DOCROOT. Таким образом, в обоих случаях вы можете использовать CRON для планирования «резервного копирования»:

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

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

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

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

При создании этих таблиц в базе данных памяти.
Предполагая, что у вас есть таблицы, управляемые механизмом на диске, вы можете использовать 'show create table tablename', чтобы MySQL дал вам именно тот SQL, который вам понадобится для повторного создания этой таблицы. ... затем измените часть двигателя, чтобы указать, что нужно использовать механизм MEMORY, и выполните это.

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

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

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

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

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

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

  cat the_test_database.db > /dev/null

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