Оптимальное использование 16Гб памяти на десктопе (РЕШЕНО)
Danhuu 13 января, 2014 - 17:20
Здравствуйте, все!
Разжился 16 гигами памяти.
Суммируя разное из Инета, в частности, свежую тутошнюю ветку размер swap при 16+гб ram, пришёл к такому:
- Убрать своп. При моих нынешних 4 гигах RAM он начинает использоваться только при компиляции Огнелиса и офиса, максимум на 50 Мб, но резко снижая быстродействие. Для этого:
- Убрать строку про своп в /etc/fstab
- Пересобрать ядро без поддержки свопа, но с TuxOnIce, чтобы засыпал в файл. Помощь по TuxOnIce: самое свежее, старая гентушная вики и арчевая вики.
- Убрать своп с винта. Как бы расширить на него ближайший раздел, не испохабив содержимое? sys-block/partitionmanager?
- /tmp и /var/tmp/portage - в оперативку? Вот тут я совсем запутался... Смотрел здесь и здесь, народ противоречит друг другу, и ХЗ кто прав... Статья в Генту-вики крайне лаконична. Что в итоге делать? Прошу работающие примеры и/или HOWTO.
»
- Для комментирования войдите или зарегистрируйтесь
Цитата: Убрать своп с винта.
Если swap раздел непосредственно после раздела, который желаете расширить, то просто загрузитесь с LiveCD, удалите раздела со swap, увеличьте размер раздела, который хотите увеличить, т.е. удалите его и создайте новый с начальным сектором, что бы и у старого, но увеличьте вторую границу до номера сектора, где оканчивался раздел со swap. Утилитами по работе с файловой системой на этом разделе увеличьте размер файловой системы до всего пространства раздела.
Если раздел со swap находится непосредственно перед разделом, который вы хотите увеличить за счёт раздела со swap, то вам придётся передвинуть увеличиваемый раздел, что бы первая его граница начиналась с первого сектора удалённого раздела со swap. Сделать это можно dd, но действовать нужно осторожно, либо воспользоваться средствами вроде parted.
Если перемещать будете dd, то опять же удаляете раздел и создаёте его заново с новыми границами и увеличиваете затем размер файловой системы.
Если используете что-то вроде parted, то после перемещения раздела растягиваете раздел на доступное свободное пространство, файловая система будет так же увеличена.
Перед изменением размера файловой системы выполните её проверку.
kostik87
Т.е., данные всё-таки придётся куда-то бэкапить?
Да почему ж этого все так
Да почему ж этого все так избегают? :) Ну не бэкапьте – ошибетесь и потом будете грустить. Что выбрать – лень или минимум риска? Это не технический вопрос, а личный.
Потому что переклин мозга ;-)
Потому что переклин мозга ;-) Почему-то решил, что у меня своп граничит с забитым 250-гиговым хомяком, который бэкапить физически некуда. На самом деле это не так, и всё пучком, вопрос снимается, проверенный cfdisk меня устраивает.
все зависит, что того для
все зависит, что того для чего используется комп, для браузера 16Гб много, для игрушек или обработки видео может быть мало )
вместо выключения свопа можно его настроить
ps а если сборка либреофиса, да еще для ускорения в оперативке?
зависит от юзкейса.если это
зависит от юзкейса.
если это обычный десктоп, то /tmp и /var/tmp/portage однозначно в раму.
туда же профиль браузера - таки разница в скорости большая.
можно сборку ядра запихнуть в раму.
если нет ssd и рама действительно пустует, то можно сойти с ума и запихать в раму корень :3
Danhuu
а где противоречие?
нигде не нашел, что от этого кому то хуже стало )) во всяком случае при памяти от 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 выглядит как-то так:
В local.d/
/var/tmp -> /tmp/var_tmp
Кроме того, я держу еще tmpfs для кеша google-chrome, но это скорее пижонство :-)
Danhuu написал(а):Пока что,
первое поле в fstab в этом случае это, скажем так, просто имя - потому можешь написать хоть "shtob_vas_vseh" и потом монтировать можно так
:3
Спасибо! Успокоил. А есть
Спасибо! Успокоил. А есть мнения о плюсах и минусах скрипта от Megabaks для временного подключения/отключения /var/tmp/portage?
Есть. Я не понимаю зачем он
Есть. Я не понимаю зачем он нужен вообще. tmpfs берет столько памяти, сколько нужно для хранения данных, но не больше size. Зачем постоянно маунтить/анмаунтить?
Пример (часть не имеющего значения текста обрезана):
Спрашивать о плюсах и минусах
Спрашивать о плюсах и минусах решения от Мегабакса у самого Мегабакса непродуктивно...
это не моё решение - откуда
это не моё решение - откуда брал не помню - давно это было.
сейчас я постоянно держу /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 там минимальное.
Так вот, практика - это единственный критерий истины.
я процессорных ядер в системе
я процессорных ядер в системе сколько?
А что, если
?
Для теста я считал, что 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 ;)
Цитата: П.С магабакс, тебя
так меня и забанили-то из-за того, что ты вместо рассмотрения готового рабочего решения доказывал что это плохо, что надо писать багрепорты, слать патчи....а человеку надо решить проблему здесь и сейчас, а не ждать полгода пока кто-то там осилит поправить ебилд.
естессно я был не согласен с этим идиотизмом.
не надо злоупотреблять положением и прятаться за банхаммером
странные тесты. сборка
странные тесты.
сборка нескольких пакетов одновременно использует по максимуму возможности машины.
т.е. при сборке большого кол-ва пакетов, тот же проц нагружен всегда полностью, а не скачет с 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
Вот это точно ставит точку в вашем странном диалоге. Столько споров о ускорении сборки, выигрывании пары процентов во времени сборки и прочих гомеопатических вещах, а потом раз - и приоритет сборки ниже уровня плинтуса с игрой на фоне :)
P.S. Я просто запускаю emerge и иду спать, до утра точно соберётся.
а я просто собираю фоном. и
а я просто собираю фоном.
и то, что все свободные мощности проца используются максимально, никак не противоречит приоритету портажа.
я не вижу смысла делать из компа тумбочку на время сборки, т.к. сборка это всё-таки фоновый процесс, не его ради комп завел.
так что у меня всё ладно и складно - фоном и с оптимальным использованием ресурсов.
Представить могу, абстрактно
Представить могу, абстрактно ;-)
Но не мой случай. Хром не пользую, gcc - 1 штука, а если
Дунай потечёт вспять и небо упадёт на землюстолкнутся, скажем, gcc + firefox + libreoffice, ну ругнётся на нехватку памяти - соберу их по очереди. Вот если подобная хрень произойдёт хотя бы 2-3 раза, тады ой, в смысле перенесу компиляцию "толстячков" на винт.Усё, всем большое спасибо,
Усё, всем большое спасибо, мечу как решёёное.
Danhuu написал(а):
И видеть Fixing recoursive fault, but reboot is needed каждую вторую попытку засыпания.
Локальный оверлей растёт