Оптимальное использование 16Гб памяти на десктопе (РЕШЕНО)

Здравствуйте, все!
Разжился 16 гигами памяти.
Суммируя разное из Инета, в частности, свежую тутошнюю ветку размер swap при 16+гб ram, пришёл к такому:

  • Убрать своп. При моих нынешних 4 гигах RAM он начинает использоваться только при компиляции Огнелиса и офиса, максимум на 50 Мб, но резко снижая быстродействие. Для этого:
    1. Убрать строку про своп в /etc/fstab
    2. Пересобрать ядро без поддержки свопа, но с TuxOnIce, чтобы засыпал в файл. Помощь по TuxOnIce: самое свежее, старая гентушная вики и арчевая вики.
    3. Убрать своп с винта. Как бы расширить на него ближайший раздел, не испохабив содержимое? sys-block/partitionmanager?
  • /tmp и /var/tmp/portage - в оперативку? Вот тут я совсем запутался... Смотрел здесь и здесь, народ противоречит друг другу, и ХЗ кто прав... Статья в Генту-вики крайне лаконична. Что в итоге делать? Прошу работающие примеры и/или HOWTO.

Цитата: Убрать своп с винта.

Цитата:
Убрать своп с винта. Как бы расширить на него ближайший раздел, не испохабив содержимое?

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

Если раздел со swap находится непосредственно перед разделом, который вы хотите увеличить за счёт раздела со swap, то вам придётся передвинуть увеличиваемый раздел, что бы первая его граница начиналась с первого сектора удалённого раздела со swap. Сделать это можно dd, но действовать нужно осторожно, либо воспользоваться средствами вроде parted.

Если перемещать будете dd, то опять же удаляете раздел и создаёте его заново с новыми границами и увеличиваете затем размер файловой системы.

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

Перед изменением размера файловой системы выполните её проверку.

kostik87

kostik87 написал(а):
...увеличьте размер раздела, который хотите увеличить, т.е. удалите его и создайте новый...

Т.е., данные всё-таки придётся куда-то бэкапить?

Да почему ж этого все так

Да почему ж этого все так избегают? :) Ну не бэкапьте – ошибетесь и потом будете грустить. Что выбрать – лень или минимум риска? Это не технический вопрос, а личный.

Потому что переклин мозга ;-)

Потому что переклин мозга ;-) Почему-то решил, что у меня своп граничит с забитым 250-гиговым хомяком, который бэкапить физически некуда. На самом деле это не так, и всё пучком, вопрос снимается, проверенный cfdisk меня устраивает.

все зависит, что того для

все зависит, что того для чего используется комп, для браузера 16Гб много, для игрушек или обработки видео может быть мало )
вместо выключения свопа можно его настроить
ps а если сборка либреофиса, да еще для ускорения в оперативке?

зависит от юзкейса.если это

зависит от юзкейса.
если это обычный десктоп, то /tmp и /var/tmp/portage однозначно в раму.
туда же профиль браузера - таки разница в скорости большая.
можно сборку ядра запихнуть в раму.
если нет ssd и рама действительно пустует, то можно сойти с ума и запихать в раму корень :3

Danhuu

Danhuu написал(а):
Здравствуйте, все!
Разжился 16 гигами памяти.
/tmp и /var/tmp/portage - в оперативку? Вот тут я совсем запутался... Смотрел здесь и здесь, народ противоречит друг другу, и ХЗ кто прав...

а где противоречие?
нигде не нашел, что от этого кому то хуже стало )) во всяком случае при памяти от 8 Гб и выше

Пока что, наиболее внятная

Пока что, наиболее внятная HOWTO - вот это. Кто в курсе - не устарело ли? И ещё вопрос: в примерах в fstab пишут

shm /tmp tmpfs ...

или

tmpfs /tmp tmpfs ...

и вроде как и то и это допустимо, но здесь даётся вариант

none /tmp tmpfs ...

Что лучше? Или всё равно?

Например, /var/lock /var/run

Например, /var/lock /var/run являются у меня симлинками на /run/lock и /run, а /run изначально:
tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,size=3291292k,mode=755)

fstab выглядит как-то так:

tmpfs                   /tmp            tmpfs           rw,size=4G,nodev,nosuid         0 0

В local.d/

# cat make-tmpfs-dirs.start 
#!/bin/sh

mkdir /tmp/var_tmp
chmod 1777 /tmp/var_tmp
touch /tmp/var_tmp/.keep

/var/tmp -> /tmp/var_tmp

Кроме того, я держу еще tmpfs для кеша google-chrome, но это скорее пижонство :-)

Danhuu написал(а):Пока что,

Danhuu написал(а):
Пока что, наиболее внятная HOWTO - вот это. Кто в курсе - не устарело ли? И ещё вопрос: в примерах в fstab пишут

shm /tmp tmpfs ...

или

tmpfs /tmp tmpfs ...

и вроде как и то и это допустимо, но здесь даётся вариант

none /tmp tmpfs ...

Что лучше? Или всё равно?

первое поле в fstab в этом случае это, скажем так, просто имя - потому можешь написать хоть "shtob_vas_vseh" и потом монтировать можно так

mount shtob_vas_vseh

:3

Спасибо! Успокоил. А есть

Спасибо! Успокоил. А есть мнения о плюсах и минусах скрипта от Megabaks для временного подключения/отключения /var/tmp/portage?

#!/bin/bash
MEMSIZE=1700M
mounted=false
. /etc/init.d/functions.sh
mounttmpfs() {
mount -t tmpfs tmpfs -o size=$MEMSIZE /var/tmp/portage
mounted="true"
}
compile() {
einfo "emerging ${*}"
emerge ${*}
}
unmount() {
ebegin "unmounting tmpfs"
umount -f /var/tmp/portage
eend $?
}
ebegin "Mounting $MEMSIZE of memory to /var/tmp/portage"
if [ -z "$(mount | grep /var/tmp/portage)" ]
then
mounttmpfs
else
eerror "tmpfs already mounted!"
exit 0
fi
eend $?
compile ${*}
if [ -n "$mounted" ]
then
unmount
fi

Есть. Я не понимаю зачем он

Есть. Я не понимаю зачем он нужен вообще. tmpfs берет столько памяти, сколько нужно для хранения данных, но не больше size. Зачем постоянно маунтить/анмаунтить?
Пример (часть не имеющего значения текста обрезана):

[17:13] root@crits /tmp # free
             total       used       free     shared    buffers     cached
Mem:      32912884    3645032   29267852          0     161548    1007732

[17:13] root@crits /tmp # perl -e 'print 0 x 1_000_000_000' > 1

[17:13] root@crits /tmp # ls -la 1
-rw-r--r--  1 root root   1000000000 Jan 14 17:13 1

[17:13] root@crits /tmp # free
             total       used       free     shared    buffers     cached
Mem:      32912884    4889776   28023108          0     161572    1986956

[17:13] root@crits /tmp # rm 1
[17:14] root@crits /tmp # free
             total       used       free     shared    buffers     cached
Mem:      32912884    3677588   29235296          0     161640    1016156

Спрашивать о плюсах и минусах

Спрашивать о плюсах и минусах решения от Мегабакса у самого Мегабакса непродуктивно...

это не моё решение - откуда

это не моё решение - откуда брал не помню - давно это было.
сейчас я постоянно держу /var/tmp/portage в раме, а самые толстые пакеты собираю на винте, благо это легко автоматизируется.

Спасибо! Значит, скрипт этот

Спасибо! Значит, скрипт этот нафиг. А что ужасного в сборке толстых пакетов в раме? Поставлю я максимум 6Гб на /var/tmp/portage, чтоб на офис хватало, так ещё 10 останется. Зато быстрее(?) соберётся. Это я так, теоретизирую.

эм...у меня собирается по 3

эм...у меня собирается по 3 пакета одновременно.
а теперь представь одновременную сборку 2/3-х gcc
или firefox+chromium+libreoffice...

Зачем собирать три пакета,

Зачем собирать три пакета, если есть MAKEOPTS="-jX"?
Т.е. на фазе конфигурации и инсталляции эта опция не играет роли, но эти фазы минимальны по сравнению с фазой компиляции, не?

ты чего-то путаешь - что

ты чего-то путаешь - что общего между 3-мя пакетами и 3-мя потоками make!?
в системе очень много пакетов, которые настолько малы, что ставятся мгновенно.
ситуация вполне обычная:1 большой пакет компиляется, а параллельно десяток-другой мелких успевает поставиться.
а если это всякие перло/питоно/баш скрипты, то их установка даже проц у компилируемого пакета не жрёт.
таки дела

Ух ты, а что же тогда жрет их

Ух ты, а что же тогда жрет их установка? Только не говори, что IO - библиотеки Перла весят копейки.

ты неадекватен. разговор

ты неадекватен.
разговор окончен.

Мне совершенно плевать на

Мне совершенно плевать на твои баттхертные обиды - в интернете полно истеричных хикки, так что я к ним привык.

Лучше расскажи, как ты распараллеливаешь сборку с учетом зависимостей. Особенно в рамках обновлений.

батхёрд у тебя от непонимания

батхёрд у тебя от непонимания вопроса.
а распараллеливает портаж.
кури доки лучше, а то офтопит тут

Т.е. ответить на вопрос ты не

Т.е. ответить на вопрос ты не можешь. О реальной нагрузке от скриптов emerge понятия не имеешь. Но зачем-то регулярно пересобираешь "2-3 gcc одновременно" (!) и после этого называешь неадекватом меня. Ок. Как скажешь.

не тебе меня чему-то

не тебе меня чему-то учить.
придумал какие-то регулярные сборки...всё возводишь в абсолют...
ты просто неадекватен.
за тебя курить доки я не собираюсь - ты того не стоишь

Конечно не мне, я же не

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

На случай, если кому интересно: имелся в виду ключ --jobs, который дает весьма сомнительное преимущество в скорости перед -jN, но зато резко ухудшает ситуацию с tmpfs.

эх...

1. --jobs это аналог -j
2. и у make и у portage есть этот ключ - только для разных вещей
3. если ты не осилил понять что и для чего используется, то это твои проблемы.
4. к tmpfs эти ключи не имеют никакого отношения и уж тем более ничего не ухудшают.
5. кури матчасть, потом спорь, а пока ты просто порешь чушь - за что ты её так, не понятно.

Милое дитя, тут же все

Милое дитя, тут же все очевидно. Если ты собираешь пакеты в несколько потоков, добавив опцию -j (--jobs) к emerge, то это требует распаковки исходников всех обрабатываемых в один момент времени пакетов в /var/tmp/portage, к которой и привязана tmpfs. А эти исходники и промежуточные продукты сборки занимают довольно много места (1.1 гигабайта для FF, например). Если же ты используешь -j в MAKEOPTS, тогда собирается лишь один пакет за раз, при том, что процессорные мощности используется практически максимально. Основная разница между этими двумя методами в том, что во втором случае процессорные мощности мало используются в процессе конфигурации и инсталляции, но проще контролировать реальную нагрузку, например, выделив только 11 ядер из 12 в системе.

Теперь скажи, почему осознание этих простых, в общем-то, вещей, заняло у тебя столько времени и вызвало такую бурную истерику?

повторяю ещё раз - ты

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

Это хорошо, что ты в таком

Это хорошо, что ты в таком тоне разговаривать не собираешься. Тебе вообще нужно следить за своим тоном, потому как однажды ты можешь забыться и обратиться к кому-то так же IRL. А это может привести к болезненным ощущениям.

Что же до сути проблемы, то мы ходим по кругу. Это нелепое утверждение про время сборки пакета я уже слышал. И твой лютый баттхерт начался как раз с моего вопроса - почему же мелкие пакеты вообще ставятся хоть сколько-то, если I/O там минимальное.

Так вот, практика - это единственный критерий истины.

time MAKEOPTS='-j4' emerge -1qv --jobs 1 --load-average 20 @world
...
real    25m0.315s
user    41m36.670s
sys     2m18.410s
time MAKEOPTS='-j1' emerge -1qv --jobs 4 --load-average 20 @world
...
real    45m30.784s
user    40m39.090s
sys     2m16.780s
time MAKEOPTS='-j2' emerge -1qv --jobs 2 --load-average 20 @world
...
real    27m55.493s
user    41m6.480s
sys     2m15.700s

я процессорных ядер в системе

я процессорных ядер в системе сколько?
А что, если

time MAKEOPTS='-j1' emerge -1qv --jobs 20 --load-average <количество ядер> @world

?

Для теста я считал, что 4. Но

Для теста я считал, что 4. Но это не принципиально, потому как при MAKEOPTS='j1' оно спотыкается на "толстых" пакетах, являющихся при этом необходимыми для дальнейшего продвижения. Тут можно очень аккуратно играться с комбинациями j у emerge и makeopts и даже получить некоторую выгоду на условно-средних раскладах. Или же можно поставить максимальный j в MAKEOPTS и кучу --jobs, тогда выгода точно будет, но периодами в процессе обновления машина будет превращаться в вещь в себе из-за дикого load average - ключ --load-average лишь ограничивает emerge от порождения новых процессов, но не ограничивает makeopts, таким образом легко может возникнуть ситуация при которой общее количество активных процессов многократно превысит число ядер. Ну и, разумеется, это многократный перерасход памяти для tmpfs на /var/tmp/portage.

В общем, я и так, и сяк крутил этот --jobs, но не придумал как его продуктивно использовать. Вот если бы можно было каким-то образом заставить его обрабатывать лишь заведомо мелкие пакеты и с дополнительными настройками MAKEOPTS, типа, чтобы основа собиралась как раньше, а еще одно ядро я готов пожертвовать на сборку мелочи, тогда выгода была бы понятна. Собственно, я потому и начал задавать вопросы, что упоминались мелкие пакеты. Мало ли, вдруг gentoo_hacker как-то придумал способ заставить emerge параллельно собирать лишь мелочь. Но, похоже, такого решения на данный момент не существует.

Ребята, прекращайте словесную

Ребята, прекращайте словесную истерику. Глядя на ваши посты, у меня возникает желеание отполировать банхаммер об ваши аккаунты.

П.С магабакс, тебя это особенно касается - тебе мало 1 бана ?
П.П.С В интернатах всегда кто то не прав ....

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

Цитата: П.С магабакс, тебя

Цитата:
П.С магабакс, тебя это особенно касается - тебе мало 1 бана ?

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

странные тесты. сборка

странные тесты.
сборка нескольких пакетов одновременно использует по максимуму возможности машины.
т.е. при сборке большого кол-ва пакетов, тот же проц нагружен всегда полностью, а не скачет с 0 на стадии configure до 100 на стадии compile.
то что ты написал - глупость.
у меня 4 ядра, -j5 для make, -j3 для emerge.
чего ради ты при 4-х пакетах поставил сборку каждого в 1 поток вообще не понятно.

Я ведь уже объяснял выше -

Я ведь уже объяснял выше - ради контроля использования CPU. Твой вариант дает load average до 15, что не рекомендуется при четырех ядрах. Возможно этим ты немного сокращаешь общее время сборки, но ценой превращения машины в кусок мебели на это время. У меня же сборка идет в фоне не мешая остальной работе. Туда же и расходы памяти. Если используется j3 для emerge, то на /var/tmp/portage должно быть не менее 6 гигабайт. Не то, что бы по нынешним временам 6 гигабайт оперативки было чем-то значимым, но все равно - явный перерасход при очень сомнительном профите.

эм...у меня тоже сборка идёт

эм...у меня тоже сборка идёт фоном - даже играть не мешает
hint: PORTAGE_NICENESS="10"
enjoy

gentoo_hacker

gentoo_hacker написал(а):
hint: PORTAGE_NICENESS="10"

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

P.S. Я просто запускаю emerge и иду спать, до утра точно соберётся.

а я просто собираю фоном. и

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

Представить могу, абстрактно

Представить могу, абстрактно ;-)
Но не мой случай. Хром не пользую, gcc - 1 штука, а если Дунай потечёт вспять и небо упадёт на землю столкнутся, скажем, gcc + firefox + libreoffice, ну ругнётся на нехватку памяти - соберу их по очереди. Вот если подобная хрень произойдёт хотя бы 2-3 раза, тады ой, в смысле перенесу компиляцию "толстячков" на винт.

Усё, всем большое спасибо,

Усё, всем большое спасибо, мечу как решёёное.

Danhuu написал(а):

Danhuu написал(а):
[*]Пересобрать ядро без поддержки свопа, но с TuxOnIce, чтобы засыпал в файл.

И видеть Fixing recoursive fault, but reboot is needed каждую вторую попытку засыпания.

Локальный оверлей растёт

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".