Собираем проект на RAM-диск при помощи Maven

[Torvald3d]

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

[vostapenko]

Думаю, чаще всего результаты билда не так важны, чтобы о них заботиться. Можно включить компьютер и пересобрать все заново. Безусловно, бывают исключения.

[Torvald3d]

Разумеется, если под средой средой сборки подразумеваются только объектники с бинарем, то проблем нет. Но я имел ввиду громоздкий проект, который содержит постоянно изменяемую графику или звуки, какие то кастомные бинари, да вообще любые отличные от исходников файлы. При чем такая организация рабочего процесса может быть обусловлена особенностью ide. Яркий пример тому — unity3d, хотя это возможно не совсем корректный пример в виду того что юнити нет под линуксом, но под виндой тоже можно часть ram пространства представить в виде виртуального диска. Возможно это и правильно, когда сорцы отдельно, сборка отдельно, но тем не менее обратные ситуации слишком часто встречаются что бы быть исключением из правила.

[holyorb2]

Я использую RAM диск для Web разработки. Делал разные эксперементы, помещая БД в оперативку или даже целую виртуалку. Самый оптимальный оказался вариант только БД запустить в оперативной памяти.

Все делается легко и даже в обход fstab: запускаем такой скрипт:
#/bin/sh
service mysql stop
mount -t tmpfs -o size=2G tmpfs /home/user/sys/ram
cp -r /home/user/sys/ram_backup/mysql /home/user/sys/ram/
rm /var/lib/mysql
ln -s /home/user/sys/ram/mysql /var/lib/mysql
chown -R mysql:mysql /home/user/sys/ram/mysql
service mysql start

Т.к. по адресу /var/lib/mysql дазы находятся на другом диске, то команда удаления удаляет только симлинк.
Есть еще второй скрипт, который делает все то же но в обратную сторону, т.е. копирует из РАМ на диск.

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

[0x3f00]

Тема сборки на RAM-диске уже не раз поднимается на хабрахабре, habrahabr.ru/post/188360/ например. И опять без бенчмарков.

А провели бы бенчмарки, то выяснили бы, что весь прирост оказывается в рамках статистической погрешности.

[Sicness]

Для своего проекта я получал прирост около 20%

[jaspeen]

>>бенчмарки
Apache Camel — 259 модулей и 10714 только java файлов.
Исходники тут.
Система: i5-2400 4x3.10Ghz, 24GiB, SSD, jdk1.6.0_26, maven 3.0.4.
Файловый кэш прогрет и скачаны все зависимости. Локальный репозиторий во всех случаях лежит на SSD.

Исходники и таргеты на SSD:

mvn -Pfastinstall clean install

Total time: 6:41.404s

mvn -Pfastinstall clean package

Total time: 6:21.148s

Исходники и таргеты на RAM диске:

mvn -Pfastinstall clean install

Total time: 6:36.178s

mvn -Pfastinstall clean package

Total time: 6:19.597s

Понятно что все проекты разные, но по-хорошему нужно еще и unit тесты запускать, а они занимают 60-70% времени билда и дискового I/O там не должно быть никакого.

[jaspeen]

На всякий случай проверил на HDD — та же история:

mvn -Pfastinstall clean install

Total time: 6:42.424s

[vostapenko]

Я думаю, что проект проекту — рознь, также как и оборудование у всех разное.

Лично у меня, например:
SSD
[INFO] Total time: 122.29s

HDD 7200
[INFO] Total time: 139.36s

RAM
[INFO] Total time: 116.41s

Оценить разницу в секундах на своем старом Thinkpad T500 с HDD 5400 в данный момент не могу, но когда я его использовал для разработки, RAM-диск был просто панацеей.

Думаю, при выборе каждого решения нужно руководствоваться здравым смыслом. Вам подобная оптимизация не нужна. Лично мне нужна. Возможно и еще кому-то пригодится.

[kuber]

>> Значительное увеличение скорости сборки за счет отсутствия операций ввода-вывода на жесткий диск

А конкретные цифры можете привести?

[vostapenko]

К сожалению, не могу привести цифры по бенчмаркам, но в рамках моего проекта скорость сборки увеличилась на 15-20%. Спасибо за идею, возможно стоит об этом отдельно написать или дополнить статью как появится время.

[kuber]

>> но в рамках моего проекта скорость сборки увеличилась на 15-20%

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

[vostapenko]

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

Я, видимо, не совсем понятно выразился в посте. Я нигде не говорил, что выгода по времени будет космической именно по сравнению с SSD. Это касается скорее классических HDD, особенно с 5400 оборотов. Я дополнил формулировку, чтобы это не вызывало вопросов.

[Torvald3d]

На счет износа SSD согласен, сам пользуюсь уже два года — у меня на нем и свап и билд и система и все на свете кроме мультимедиа, работает все прекрасно. А вот на счет кеширования можно поспорить. На сколько я знаю, кеширование на запись происходит ровно до того момента, пока не вызовится из ядра функция sync, после этого данные сбрасываются на жесткий диск. А функция эта вызывается довольно часто, и уж точно при окончательной записи файла.
Боевой пример: попробуйте сбилдить что нибудь на HDD и SSD — разницу почувствуете сразу.

[Googolplex]

gksudo -k gedit /usr/share/maven/conf/settings.xml

Так нельзя делать. Вы редактируете файл, не предназначенный для изменения сразу по нескольким причинам:

1. это глобальные дефолтные настройки мавена, которые не должны меняться;
2. этот файл под управлением менеджера пакетов — при следующем апдейте мавена файл либо перезапишется, либо будет какой-нибудь конфликт, либо ещё что.

Правильный способ — использовать локальный для юзера settings.xml, обычно — ~/.m2/settings.xml:

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
                        http://maven.apache.org/xsd/settings-1.0.0.xsd">
...
    <profiles>
        <profile>
            <id>RAMBuild</id>
            <activation>
                <activeByDefault>true</activeByDefault>
            </activation>
            <properties>
                <target.directory>/tmp/maven/${project.groupId}.${project.artifactId}/target</target.directory>
            </properties>
        </profile>
    </profiles>
...
</settings>

[vostapenko]

Спасибо за точное замечание, обновлю информацию в статье.

[gkraser]

«Занавесками не вытираться!»
О! А это мысль!