У меня есть ноутбук с настройкой LAMP. Жесткий диск медленный, что заставляет мои модульные тесты работать медленно.
Мне было интересно, смогу ли я смонтировать веб-корень базы данных mysql на какой-нибудь виртуальный диск.
Из того, что я читал о виртуальных дисках, они непостоянны.
Есть ли способ создать виртуальный диск, который записывает изменения в область жесткого диска при завершении работы и перемонтирует виртуальный диск при загрузке?
То, что вы ищете, это то, что хранит данные fs в памяти, сохраняет их, если может, но не слишком беспокоится о потере ваших данных (как, например, если кто-то выключит питание).
Вы можете посмотреть в cachefs и посмотреть, можете ли вы настроить его так, чтобы он действительно ленился при записи.
Я также подозреваю, что вы решаете правильную проблему. При достаточном объеме памяти вы не должны блокировать записи на диск.
Вы также можете установить опцию монтирования с обратной записью для вашей файловой системы. Смотрите, например, это.
Работа с виртуальными дисками в Linux довольно тривиальна. Вы можете создавать и использовать их несколькими различными способами в зависимости от ваших потребностей, а затем просто скопируйте их содержимое (с помощью cp или dd) на жесткий диск, прежде чем выключить ваш ящик или через запланированный интервал, чтобы избежать потери данных при неожиданном завершении работы. Взгляните на эти инструкции, я думаю, они достаточно просты:
http://www.vanemery.com/Linux/Ramdisk/ramdisk.html
http://wiki.archlinux.org/index.php/Ramdisk
M
Вы могли бы написать простой сценарий rc который делает это. Я помню, как делал это в дни DOS (с autoexec.bat) для быстрого доступа к некоторым файлам.
Вы могли бы рассмотреть возможность покупки SSD или RAM-дисков с интерфейсом HDD.
«ОС уже делает это для обычного доступа к файловой системе (буферизует записи в ОЗУ, а затем сбрасывает их позже). Но чтобы быть более надежным, многие базы данных затем выполняют функцию fsync ()... "- R Samuel Klatchko
Итак, чтобы ускорить ваши модульные тесты, чтобы они не сидели без дела, ожидая, что каждая запись будет полностью fsync'ed, есть несколько вещей, которые вы можете попробовать:
Если вы можете урезать тестовую базу данных, используемую вашими модульными тестами, чтобы она полностью помещалась в ОЗУ, возможно, заставив ОС предварительно кэшировать всю базу данных за один раз (вместо того, чтобы читать и кэшировать немного за раз, как необходимо в тесте ) может сделать тесты быстрее; с чем-то вроде
cat the_test_database.db > /dev/null
То, чего вы хотите достичь, действительно очень возможно, но я не знаю ни одного готового решения. Вы должны будете написать соответствующие сценарии более или менее самостоятельно. У меня есть чувство, что этот факт сам по себе является нарушителем договоренностей, но если вы хотите взять на себя задачу, я уверен, что вы получите всю необходимую помощь.
Вы говорите, что запускаете это на ноутбуке. Работает ли "гибернация" и возобновление работы последовательно на нем? Если это так ... вы можете ПОСТОЯННО использовать это, а также сделать одну или обе из этих двух ПОЛНОСТЬЮ РАЗДЕЛЯЮЩИХ вещей, чтобы помочь улучшить время доступа как для веб-страниц, так и для запросов 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
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 для процесса, который должен дать вам поведение, которое вы ищете.
