LINUX.ORG.RU

Небольшие оптимизации доступа к диску

 , , , ,


3

2

В общем хочу поделится тем, что нарыл и помогло. Проблема такова. Сборка проекта, который я ваяю идет очень медленно, минуту :), но при небольшом изменении и «посмотреть, что вышло» это долго. Потому, было решено как то ускорить все, что можно. Узким местом была объявлена дискова подсистема :) Несмотря на то, что ssd на борту и i7. Плюс по дороге тормоза тормозилы решил попробовать убрать, на которую я вновь переехал когда понял, что хром намного менее удобный хоть и намного менее тормозной.

Решения таковы:

  • https://github.com/graysky2/profile-sync-daemon Помогает меньше ssd диск протирать, ну и доступ естественно ускоряет. Тормоза стали ощутимо меньше в тормозиле, я даже смирился с теми, что есть. Работает в убунте в том числе.
  • https://www.linux.org.ru/forum/admin/12794471 Небольшая самоделка на предмет tmp в памяти, с расширением оной на диск когда места мало и сжатием. Места мало бывает когда IDE начинает качать образ обновления очередного.
  • bcache. Так как я не рискую хранить проекты на ssd диске. Бекапы делаются редко и по настроению, когда что то закончил большое. bcache характерен тем, что при разрушении кэша на ssd диске (10Гб раздел, выделенный под это дело) основные данные на hdd будут доступны и живы. Это судя по документации. Кстати, очень легко его включить и пользоваться. Буквально пара команд.
  • UPD. Позже добавил. https://github.com/vaeth/zram-init использую var_tmp и swap юниты оттуда.
  • Ну и gradle накрутил, тоже помогло. Если кому интересно, опишу.

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

★★

Последнее исправление: i3draven (всего исправлений: 2)

Наверное лучше всего как-нибудь объеденить реальную фс и tmpfs чтобы запись шла только в озу, а потом чтобы записанное очень медленно и неблокирующе сбрасывалось на реальный диск. Вроде background writeback патч и большое значение dirty_bytes должно так работать, плюс несколько других настроек.

anonymous
()
Ответ на: комментарий от anonymous

Насколько я понимаю bcache это умеет. Можно взять zram диск как кэш и беком к нему прицепить обычный диск. Выбрать параметры его работы и будет то, что вы описали. Но я так не пробовал. Хотя мысль мне нравится :) Может попробую. Тут проблема в том как кэш будет заполнятся и работать. Перед перезагрузкой его придется «отцеплять», а после загрузки он некоторое время не будет действовать, так как будет заполняться.

i3draven ★★
() автор топика
Последнее исправление: i3draven (всего исправлений: 1)

Небольшая самоделка на предмет tmp в памяти, с расширением оной на диск когда места мало и сжатием

По-моему, куда более нормальный вариант это tmpfs + zram (как swap) + swap на диске (если нужно, можно в виде файла).

sudopacman ★★★★★
()
Ответ на: комментарий от i3draven

Лол. Какую-то наркоманию ты, по-моему, сказал. Уже есть дисковый кеш. А то, что ты описал вряд ли вообще работать будет.

sudopacman ★★★★★
()
Ответ на: комментарий от sudopacman

Сейчас tmpfs может переезжать в своп на диск, а btrfs сжимает данные и поддерживает целостность. Если просто tmpfs то сжатия там не будет, а оно (как проверено) в два раза ускоряет запись в /tmp. Но тесты делались так себе. В результате имеем, когда памяти мало /tmp едет в своп, а скорость записи 1.5Гб/с в нее пока памяти хватает. zram я тоже использую как часть свопа, но уже просто потому, что отрубать ее лень :)

i3draven ★★
() автор топика
Ответ на: комментарий от sudopacman

Дисковый кэш не жмется в памяти, как это будет с zram. Вот и разница. А работать думаю будет, вопрос в скоростях. При этом сжатие существенно ускоряет запись/чтение на нормальном проце.

i3draven ★★
() автор топика
Последнее исправление: i3draven (всего исправлений: 1)
Ответ на: комментарий от sudopacman

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

i3draven ★★
() автор топика
Ответ на: комментарий от i3draven

Что у тебя там за сборка такая, что ёё производительность уприается в скорость I/O, даже если оно идёт в оперативку, но при этом не зависит от нагруженности процессора?

sudopacman ★★★★★
()
Ответ на: комментарий от sudopacman

У меня четырехядерный i7 который после всех колупаний теперь грузится при сборке на 90%. Раньше грузился на 30% в максимуме. В общем помогло :)

i3draven ★★
() автор топика
Ответ на: комментарий от sudopacman

Но было и просто интересно повозится. Мелкие тормоза в UI тоже все пропали, а они меня раздражали.

i3draven ★★
() автор топика
Ответ на: комментарий от i3draven

Хватит хотеть пихать сжатие куда ни попадя. С bcache работать не будет нормально, потому что каждый раз при загрузке будет создаваться новое устройство кеширования, и надо будет заново собирать данные о самых используемых файлах. И это при условии, что оно вообще заведётся с каждый раз с новым устройством для кешей.

sudopacman ★★★★★
()

И да, в треде не хватает dk-, fornlr и Фрактала, которые тебе обяснят, что не нужно трястись над ресурсом SSD.

sudopacman ★★★★★
()
Ответ на: комментарий от sudopacman

В своем комменте выше я уже писал, о заполнении, но судя по всему очень надо со мной спорить :) Но могу предположить (пока не проверял), что уже вторая сборка проекта будет ускорена кешем, так как все данные уже будут собраны. Что до «завестись с каждый раз новым кэшем», так это дело прачильно написанного юнита, отцепить и подцепить кэш можно легко и без перезагрузок прямо на горячем диске, так что уже при перезагрузке оно точно сработает.

А эксперименты запрещать не стоит, это же линукс :) Плюс ко всему прошлые привели к желаемому.

i3draven ★★
() автор топика
Ответ на: комментарий от sudopacman

Интересно как поменялась бы эффективность дискового кэша в памяти, если к нему добавить сжатие. Как минимум можно было бы хранить больше данных.

i3draven ★★
() автор топика
Ответ на: комментарий от i3draven

Если сжатие реально так помогает, напиши патч для ядра, добавляющий его в tmpfs и куда там тебе ещё надо. Будет куда нативнее.

sudopacman ★★★★★
()
Ответ на: комментарий от i3draven

Блин, вроде бы в той сборке ядра, что я пользую (liquorix) оно по умолчанию и так включено. Так что тут ловить нечего и того, что я уже сделал достаточно. Но надо поизучать сей интересный момент :) Пока я следов не нашел.

i3draven ★★
() автор топика
Последнее исправление: i3draven (всего исправлений: 1)
Ответ на: комментарий от i3draven

Так оно уже протухло. Или его в основное ядро включили? Что-то у меня ничего не находится в конфиге ядра по grep ZCACHE.

sudopacman ★★★★★
()
Последнее исправление: sudopacman (всего исправлений: 1)
Ответ на: комментарий от sudopacman

Думаю вы правы, протухло видать. Что то я уже пару упоминаний нашел, что начиная с ядра 3.11 его выкинули. Для tmpfs сжатия я не нашел совсем. Но там помимо zram есть еще zswap какой то. Почему выкинули zcache неясно, судя по статье зачинателя он в тестах получил хорошие результаты.

https://www.kernel.org/doc/Documentation/vm/

i3draven ★★
() автор топика
Ответ на: комментарий от i3draven

Как выясняется из вот этого:

https://oss.oracle.com/projects/tmem/dist/files/RAMster/ramster-howto.txt https://www.kernel.org/doc/Documentation/kernel-parameters.txt http://www.gossamer-threads.com/lists/gentoo/user/262895

Что то эта фича где то на задворках лежит и даже параметр ядра zcache отсутствует в документации.

i3draven ★★
() автор топика
Ответ на: комментарий от i3draven

Когда bcache заполнился, наступило полное счастье. Теперь проекты собираются за 3-5 секунд.

i3draven ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.