Рекомендации по ускорению работы Linux Mint на слабых ПК

Руководства, вопросы, обсуждения
Правила форума
Как правильно задавать вопросы Правильно сформулированный вопрос и его грамотное оформление способствует высокой вероятности получения достаточно содержательного и по существу ответа. Общая рекомендация по составлению тем: 1. Версия ОС вместе с разрядностью. Пример: LM 18.1 x64, LM Sarah x32 2. DE. Если вопрос касается двух, то через запятую. (xfce, KDE, cinnamon, mate) 3. Какое железо. (достаточно вывод inxi -Fxz в спойлере (как пользоваться спойлером смотрим здесь)) или же дать ссылку на hw-probe 4. Суть. Желательно с выводом консоли, логами. 5. Скрин. Просьба указывать 1, 2 и 3 независимо от того, имеет ли это отношение к вопросу или нет. Так же не забываем об общих правилах Как пример вот
Аватара пользователя

slant
Сообщения: 1039
Зарегистрирован: 21 июн 2017, 15:09
Решено: 14
Благодарил (а): 7 раз
Поблагодарили: 381 раз

Рекоммендации по ускорению работы Linux Mint на слабых ПК

Сообщение slant » 16 дек 2017, 17:56

Зато ни скайпа ни вайбера на x32 уже нету. И фиг знает, что будет следующим. Отказываются от нее потихоньку. А так - можно и ее конечно поставить и x32.

Но кроме того, если система x64 - это само по себе дает некоторый прирост к быстродействию при выполнении x64 кода. А в отличии от винды, под линуксом в x64 дистрибутивах код программ реально так откомпилирован весь. А не исполнятся львиной долей legacy 32-битный код через эмуляцию x86. Я тестил специально на 17-ом минте х86 и х64 - архиваторы, скажем, могут до 30% разницы выдавать, в определенных условиях. Под линуксом 64 бита имеет смысл использовать всегда, когда это возможно. Расход памяти немного выше, но совсем не в два раза, как часто пишут. На этом смысл экономить только если памяти меньше гигабайта.

Аватара пользователя

wanoska
Сообщения: 209
Зарегистрирован: 17 окт 2016, 12:36
Решено: 4
Откуда: Кинешма
Благодарил (а): 39 раз
Поблагодарили: 46 раз

Рекомендации по ускорению работы Linux Mint на слабых ПК

Сообщение wanoska » 17 дек 2017, 20:25

Не по теме
Dja писал(а):
22 ноя 2016, 08:46
wanoska, счас вроде не проблема 64-х установить ) Даже если 2 гига оперативы.
wanoska писал(а):
22 ноя 2016, 08:54
Dja, с таким железом :smile:
ilopatin@WlopatinI ~ $ inxi
CPU~Dual core Intel Celeron E1500 (-MCP-) speed~1600 MHz (max) Kernel~4.5.0-040500rc1-generic i686 Up~4:00 Mem~879.4/2003.6MB HDD~330.1GB(7.3% used) Procs~189 Client~Shell inxi~2.2.35
Мне кажется не логично из за одной программы менять 32 на 64
___A1___ писал(а):
22 ноя 2016, 09:17
wanoska, :thumbs:
И вообще не факт что на старом железе 64bit версия вообще стартует.
Dja писал(а):
22 ноя 2016, 10:02
у меня на одном старичке х32 только потому что там мне вайбер ни к чему ) Если бы нужен был - не задумываясь бы накатил х64.
все новое...
LM18.2 Xfce 4.12.3 Kernel: 4.10.0-40-generic

Аватара пользователя

SemenSinchenko
Сообщения: 340
Зарегистрирован: 17 фев 2017, 09:01
Решено: 2
Откуда: Москва
Благодарил (а): 43 раза
Поблагодарили: 46 раз

Рекомендации по ускорению работы Linux Mint на слабых ПК

Сообщение SemenSinchenko » 18 дек 2017, 07:50

Chocobo писал(а):
28 сен 2016, 10:21
1.1 Оптимизировать порог использования swap-раздела
По умолчанию параметр swappiness имеет значение 60 - что указывает ядру ОС начинать обращаться к своп-разделу уже при утилизации в 40% от общего объема оперативной памяти.
Практической пользы для рядового десктопа в этом никакой, и может напротив повысить интенсивность обращения к дискам и замедлить работу системы в целом.
проверить текущее значение этого параметра можно командой:

sudo sysctl vm.swappiness

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

sudo sysctl -w vm.swappiness=5

Чтоб новые параметры сразу вступили в силу - можно перезагрузить компьютер, или очистить текущий набор памяти в разделе подкачки:
КОД: ВЫДЕЛИТЬ ВСЁ

sudo swapoff -a
sudo swapon -a
Недавно прочитал статью на хабре по этому поводу и там высказано диаметрально противоположное мнение:
Часто в интернете советуют изменить параметр ядра Linux vm.swappiness. Узнать его текущее значение на вашей системе можно так:

sysctl vm.swappiness

Ответ будет 60 почти наверняка. Это значит, что ядро Linux начинает свопить редко используемые страницы оперативной памяти, когда использование свободной оперативной памяти достигает 100%-60%=40%. Часто встречаются рекомендации поставить, например, vm.swappiness=10, чтобы своп не начинал использоваться, пока загрузка ОЗу не достигнет 90%. На самом деле не нужно трогать vm.swappiness, вы не умнее разработчиков ядра Linux, которые не просто так поставили 60 по умолчанию. Почему?

Представьте, что у вас всего 4 ГБ оперативной памяти, из них прямо сейчас занято 3 ГБ, vm.swappiness=10, своп на жестком диске (HDD) занят на 0%, и вы открываете тяжелый сайт в браузере, для чего требуется больше, чем имеющийся свободный 1 ГБ, например, 2 ГБ. Операционная система начинает в экстренном порядке отправлять в своп как минимум 0.5 ГБ (а по факту больше), чтобы можно было выделить браузеру необходимое количество оперативной памяти. Эта процедура становится самой приоритетной задачей, и придется пожертвовать даже движениями курсора мыши, чтобы ее выполнить как можно быстрее. Вы ждете. Проходит 5 минут, и система развисает, потому что окончила процедуру 100% загрузки очереди доступа к медленному жесткому диску, на котором размещена оперативная память (своп). При дефолтном vm.swappiness=60 редко используемые страницы памяти сбрасываются в своп заблаговременно, и резкого зависания на 5-10 минут не происходит.
Что еще интереснее, в комментах к статье было высказано мнение, что параметр vm.swappiness вообще работает иначе:
Очень распространенное заблуждение. На самом деле vm.swappines делает следующее:
This control is used to define how aggressive the kernel will swap
memory pages. Higher values will increase aggressiveness, lower values
decrease the amount of swap. A value of 0 instructs the kernel not to
initiate swap until the amount of free and file-backed pages is less
than the high water mark in a zone.
(Из документации к ядру). Уже отсюда ясно, что никакого отношения к % свободной памяти эта настройка не имеет.
Чуть подробнее о работе этой опции рассказано на портале Red Hat:
A value from 0 to 100 which controls the degree to which the system favors anonymous memory or the page cache. A high value improves file-system performance, while aggressively swapping less active processes out of physical memory. A low value avoids swapping processes out of memory, which usually decreases latency, at the cost of I/O performance. The default value is 60.
То есть опция указывает приоритет дискового кэша перед данными приложений. Поэтому уменьшение этой опции увеличивает приоритет данных приложений, взамен ухудшается кэширование I/O.
Так в итоге, как оно работает и стоит ли менять этот параметр (как в шапке) или стоит смотреть в сторону приоритетов своп и zram (как на хабре)?

Аватара пользователя

Автор темы
Chocobo
Сообщения: 8259
Зарегистрирован: 27 авг 2016, 19:57
Решено: 178
Откуда: НН
Благодарил (а): 550 раз
Поблагодарили: 2210 раз

Рекомендации по ускорению работы Linux Mint на слабых ПК

Сообщение Chocobo » 18 дек 2017, 08:51

SemenSinchenko, в этой же ветке обсуждения идет следом
Более того совсем не понятно что такое "% свободной памяти", поскольку само понятие свободная память (особенно при разрешенном оверкоммите) это тема для еще нескольких статей.
А нас в данном случае, в сценарии десктопного использования как правило инетересует чтоб в своп не попдали именно RSS-наборы наиболее активных процессов, тех же браузеров. Запись одного Гб на жесткий диск - как тут представлен пример, не отправит в частном случае систему в пятиминутный stuck. Но если своппить все подряд дефолтным методом - то тупняки и отзывчивость интерфейса потеряешь еще раньше в купе с выросшими иовейтам еще до возникновения дефицита памяти. И тут да, на фоне общих непрекращающихся фризов - вполне возможно все пройдет визуально несколько более гладко при выделении неких нескольких гигабайт разом. А сам оверкоммит кстати у нас выключен по дефолту.
SemenSinchenko писал(а):
18 дек 2017, 07:50
вы не умнее разработчиков ядра Linux, которые не просто так поставили 60 по умолчанию
Угу, прям золотая пуля :smile: . Только вот 60 по умолчанию выставлено мейнтейнерами моего дистрибутива специально для десктопных задач? А если нет - то наверное это идеальная цифра для задач серверных... мой ELK-стек как-то раз этого совсем не оценил, когда кусок хипа elasticsearch попал в своп... :harakiri:
Изображение
   
Изображение

Аватара пользователя

SemenSinchenko
Сообщения: 340
Зарегистрирован: 17 фев 2017, 09:01
Решено: 2
Откуда: Москва
Благодарил (а): 43 раза
Поблагодарили: 46 раз

Рекомендации по ускорению работы Linux Mint на слабых ПК

Сообщение SemenSinchenko » 18 дек 2017, 09:03

Chocobo писал(а):
18 дек 2017, 08:51
А нас в данном случае, в сценарии десктопного использования как правило инетересует чтоб в своп не попдали именно RSS-наборы наиболее активных процессов, тех же браузеров.
Так ведь ядро свопит именно редко используемые страницы памяти - ну висит у меня с позавчера вкладка в файрфокс - так пусть и свопится. Открыт у меня пять часов уже либр офис с курсовой, которую я делать не хочу пока - пусть свопится. А в chrome/firefoxe и прочих вкладки это процессы. А активные вкладки по логике и не будут свопится.

Ну и потом - в шапке работа swapinness описана через % свободной памяти (условимся для простоты, что это цифра, которую выдает top), а на хабре пишут (и в документации вроде написано), что это именно активность. Ну и тогда зачем ставить именно 10? Поставить 40 и пусть в фоне свопит неиспользуемое - мне же удобней - либр офис, игрушки и прочее будет даже быстрее открываться по факту, так как своп уже выполнен.

Может быть в теории могут быть проблемы с garbage collector-ами которым может внезапно приспичить собрать мусор в свопе и подвесить систему, если своп загружен, но мы все же исходим из предположения, что наши программы не индусы писали и GC настроены нормально.
Chocobo писал(а):
18 дек 2017, 08:51
А если нет - то наверное это идеальная цифра для задач серверных...
Там же в комментах пишут
Будьте внимательны: речь идёт про десктопные машины а не про сервера в данной статье.
Для серверов БД (например для Оракла) редхат в руководстве по настройке рекомендует swapiness выставлять в 1 для RHEL 7
То есть 60 это оптимальное значение для десктопа, а администратор сервера может в документацию ядра и сам настроит как надо (что кстати логично).

Аватара пользователя

Автор темы
Chocobo
Сообщения: 8259
Зарегистрирован: 27 авг 2016, 19:57
Решено: 178
Откуда: НН
Благодарил (а): 550 раз
Поблагодарили: 2210 раз

Рекомендации по ускорению работы Linux Mint на слабых ПК

Сообщение Chocobo » 18 дек 2017, 09:23

SemenSinchenko писал(а):
18 дек 2017, 09:03
То есть 60 это оптимальное значение для десктопа,
Т.е. ядра подготавливаемые в Centos, RHEL, Debian - все как один настроили сей параметр специально для десктопа, независимо от роли своего дистрибутива? :smile:
SemenSinchenko писал(а):
18 дек 2017, 09:03
мы все же исходим из предположения, что наши программы не индусы писали и GC настроены нормально.
Мы тут даже обсуждаем чуть другое - а именно как комфортно вылезти за рамки имеющегося объема ОЗУ, и при этом сделать все бесшовно:
SemenSinchenko писал(а):
18 дек 2017, 09:03
висит у меня с позавчера вкладка в файрфокс - так пусть и свопится. Открыт у меня пять часов уже либр офис с курсовой, которую я делать не хочу пока - пусть свопится.
Так вот находится ли не интересующий процесс (тем более процесс над иксами, вися в панели задач) все свое время в состоянии сна в тот момент, и не дергает ли аллокаторы (или же не дергается со стороны ядра) - система слишком комплексна, чтоб сходу сказать, надо б провести ряд экспериментов да потыкать палочкой :)

Ну и в любом случае, по некоторому опыту взаимодействия сподобными системами, где озу в дефиците - у меня совсем не получается сказать что при дефолтном значении swapiness все работает тем идеальным методом распределения памяти описанным тобой, иначе не было десятков подобных тем, пусть даже и с противоположными мнениями)
Изображение
   
Изображение

Аватара пользователя

Unborn
Сообщения: 1325
Зарегистрирован: 03 сен 2016, 10:36
Решено: 20
Благодарил (а): 2 раза
Поблагодарили: 191 раз

Рекомендации по ускорению работы Linux Mint на слабых ПК

Сообщение Unborn » 18 дек 2017, 11:32

SemenSinchenko писал(а):
18 дек 2017, 07:50
Недавно прочитал статью на хабре по этому поводу и там высказано диаметрально противоположное мнение:
Поменьше читай таких статей. Особенно всякой школоты - говноблогеров. Всё актуально было (vm.swappiness=60), когда ОЗУ 4Мб было нормой, а не 4Гб, и своп делали специально первым разделом. И планировщики были тех времён. Он ещё на горшке сидел. Как вообще без свопа люди живут по многу вкладок держат открытыми в браузере. Браузеры свой дисковый кеш используют с возможность размещать его в ОЗУ. Лиса так при сворачивании все странички на диск бросает по умолчанию. Если ОЗУ позволяет, то можно всё в нём и оставлять. Аффтор по видимому и не знает, что память делится для работы программ и данных, обрабатываемыми этими прогами.
Да, ещё, советовать применять сжатие свопа в ОЗУ, при дефиците последнего может только идиот. Копипастят годами старый пример своп -разделом. Это именно пример, а не руководство к действию.
И параметры по умолчанию в дистрибутивах ОС, софте такие, какие есть, потому что разработчик не знает на какое железо будет установлена ОС.
Поэтому в Минт по умолчанию древний ondemand для ЦП Пентиум4 Е6хх до сих пор.

Аватара пользователя

Автор темы
Chocobo
Сообщения: 8259
Зарегистрирован: 27 авг 2016, 19:57
Решено: 178
Откуда: НН
Благодарил (а): 550 раз
Поблагодарили: 2210 раз

Рекомендации по ускорению работы Linux Mint на слабых ПК

Сообщение Chocobo » 18 дек 2017, 11:39

Unborn, по zram я вижу от компрессии некоторый возможный профит именно в плане снижения объема после компрессии. Но обратная строна медали - сжатие/распаковка ляжет на чьи плечи, процессора разумеется.
И учитывая название темы "ускорения работы Linux Mint на слабых ПК" - эффект в теории может вполне получиться обратным при слабом камне, когда часть процессорного времени будет тужиться в sys над обработкой пожатых страниц памяти для какой-либо её экономии, в то время как мне надо уже в usr отрендерить страничку в браузере вместо этого :smile:
Изображение
   
Изображение

Аватара пользователя

Unborn
Сообщения: 1325
Зарегистрирован: 03 сен 2016, 10:36
Решено: 20
Благодарил (а): 2 раза
Поблагодарили: 191 раз

Рекомендации по ускорению работы Linux Mint на слабых ПК

Сообщение Unborn » 18 дек 2017, 12:14

Chocobo писал(а):
18 дек 2017, 11:39
Но обратная строна медали - сжатие/распаковка ляжет на чьи плечи, процессора разумеется.
Тут ещё, чтобы обработать, нужно сначала распаковать, а куда, если ОЗУ мало, по чайной ложке будет выделятся. Вот и получается чистейший идиотизм - по кусочкам распаковывать, обрабатывать, запаковывать. Лучше просто чистое физическое ОЗУ без всяких зетов и свопов.
Прошли уже те времена, когда планки имели конские цены. И какой-нибудь природный катаклизм резко их поднимал.

Аватара пользователя

Автор темы
Chocobo
Сообщения: 8259
Зарегистрирован: 27 авг 2016, 19:57
Решено: 178
Откуда: НН
Благодарил (а): 550 раз
Поблагодарили: 2210 раз

Рекомендации по ускорению работы Linux Mint на слабых ПК

Сообщение Chocobo » 18 дек 2017, 12:42

Unborn, Разумеется, также подмечал тут неподалеку :smile:
Chocobo писал(а):
16 апр 2017, 18:41
При любой аппаратной конфигурации - обращение к своппированным данным это явная просадка по производительности.
...
своппинг в процессе работы - всегда плохо, если он случается постоянно - все же лучше увеличить объем оперативной памяти, благо сегодня это не такой уж и дефицит.
Но еще подумалось тут в кач-ве твика по некоторой экономии ОЗУ - может есть смысл погасить HugePages в десктопном сценарии. Дабы предотвратить эллокейт блоками по 2Мб в AnonHugePages.
Глянув в текущий выхлоп - посмотрел что и браузеры и вайн, и gnome-online-accounts (и еще много прочего) вполне себе отжирают десятками блоков

Код: Выделить всё

grep -e AnonHugePages  /proc/*/smaps | awk  '{ if($2>4) print $0} ' |  awk -F "/"  '{print $0; system("ps -fp " $3)} '
Вот тут на RH есть описание по взаимодействию с ними - https://access.redhat.com/solutions/46111
Можно попробовать отключить (transparent_hugepage=never) и понаблюдать, как изменится утилизация и не будет ли ядру сложней скакать по маленьким 4к-чанкам.
Изображение
   
Изображение

Аватара пользователя

slant
Сообщения: 1039
Зарегистрирован: 21 июн 2017, 15:09
Решено: 14
Благодарил (а): 7 раз
Поблагодарили: 381 раз

Рекомендации по ускорению работы Linux Mint на слабых ПК

Сообщение slant » 18 дек 2017, 12:45

Смысл zram не в том, чтобы больше влезло. А в том, что сжатые данные скидывающиеся в своп быстрее запишутся и прочитаются - т.к. диск в десятки раз медленнее памяти. И самое узкое место. А тут ему в абсолютном значении писать/читать меньше придется. Алгоритм там используется максимально быстрый, чтобы процессор излишне не грузить - но в "чистой памяти" огромное число данных как раз в хорошо подающемся сжатию виде. Те же картинки - это они только на диске в сжатом формате - а в памяти, подготовленные для отображения на экране - уже нет.
zram - это скорее в случае медленной дисковой подсистемы полезно. Если уж своп таки приходится терпеть. Т.е. размениваем мощность процессора на скорость записи/чтения. Нужно это или нет - от конкретных условий зависит. То же самое с обычными FS, которые умеют компрессию на лету - вроде NTFS или BTRFS. Там конечно есть выигрыш и в общем объеме хранения, но, скажем, системный диск на btrfs c компрессией lzo иногда быстрее чем без компрессии вообще получается - если скоростью загрузки системы мерятся.

Аватара пользователя

hellonet
Сообщения: 433
Зарегистрирован: 11 окт 2016, 09:58
Решено: 2
Откуда: Новосибирск
Благодарил (а): 132 раза
Поблагодарили: 43 раза

Как сэкономить ресурсы при нехватке оперативной памяти

Сообщение hellonet » 19 дек 2017, 06:57

Понравился материал на хабре на тему: "Нехватка оперативной памяти в Linux на рабочем ПК: оптимизация и действия при зависании" Публикую здесь ссылку (для тех кто не читал). По-моему статья интересная и полезная.
https://habrahabr.ru/post/344836/?utm_c ... =link2post


AllVit
Сообщения: 60
Зарегистрирован: 27 сен 2016, 12:55
Решено: 2
Благодарил (а): 21 раз
Поблагодарили: 1 раз

Рекомендации по ускорению работы Linux Mint на слабых ПК

Сообщение AllVit » 20 дек 2017, 07:31

Chocobo писал(а):
28 сен 2016, 10:21
1.1 Оптимизировать порог использования swap-раздела
По умолчанию параметр swappiness имеет значение 60
Chocobo писал(а):
28 сен 2016, 10:21
1.2 Оптимизация выделяемой памяти для кэшей
По умолчанию значение установлено в 100
Только теперь заметил - оптимизация работает до перезагрузки (выключения/включения) ПК?! По крайней мере у меня на LM 18.2 x32.

Аватара пользователя

Автор темы
Chocobo
Сообщения: 8259
Зарегистрирован: 27 авг 2016, 19:57
Решено: 178
Откуда: НН
Благодарил (а): 550 раз
Поблагодарили: 2210 раз

Рекомендации по ускорению работы Linux Mint на слабых ПК

Сообщение Chocobo » 20 дек 2017, 07:50

AllVit, ага, sysctl -w пишет в рамках текущей сессии,
чтоб сделать перманентно - добавь строчки со своими значениями
vm.swappiness = XX
vm.vfs_cache_pressure = YY
в /etc/sysctl.conf, чтоб они вычитывались при каждой загрузке

Добавлю в шапку, а то реально не прояснили чёт этот момент :)
Изображение
   
Изображение


AllVit
Сообщения: 60
Зарегистрирован: 27 сен 2016, 12:55
Решено: 2
Благодарил (а): 21 раз
Поблагодарили: 1 раз

Рекомендации по ускорению работы Linux Mint на слабых ПК

Сообщение AllVit » 20 дек 2017, 08:04

Chocobo писал(а):
28 сен 2016, 10:21
1.2 Оптимизация выделяемой памяти для кэшей
Так все таки значение по умолчанию 100 заменить на 1000 или на 50 для 2ГБ оперативно памяти. В теме есть два противоречивых мнения.
Unborn писал(а):
13 янв 2017, 18:55
Это кеш метаданных файловых систем. Чем выше значение, тем чаще кеш будет сбрасываться на диск. Там и 100 много. В современных реалиях при достаточности ОЗУ кеш можно подольше держать в ней. Так что наоборот - не 1000, а 50. А если ОЗУ мало, то да - почаще сбрасывать.

Аватара пользователя

Lion
Сообщения: 14
Зарегистрирован: 27 ноя 2017, 17:50
Благодарил (а): 3 раза

Рекомендации по ускорению работы Linux Mint на слабых ПК

Сообщение Lion » 20 янв 2018, 13:27

Ссылку не нашёл, а было написано, что можно увеличить ОЗУ подключением пустой флешки в USB -порт. Но писали про Винду Висту и старше. А на линуксе нет такого?

Аватара пользователя

di_mok
Сообщения: 4205
Зарегистрирован: 27 авг 2016, 16:06
Решено: 27
Откуда: Арзамас
Благодарил (а): 975 раз
Поблагодарили: 759 раз

Рекомендации по ускорению работы Linux Mint на слабых ПК

Сообщение di_mok » 20 янв 2018, 13:35

Ты наверное про ReadyBoost ? Это виндовая фишка. Только это скорее не увеличение RAM, а свап
Настоящая водка — это не пьянство, а ключ к своей совести, с нее-то и начинается настоящая мудрость. (c)

Аватара пользователя

Lion
Сообщения: 14
Зарегистрирован: 27 ноя 2017, 17:50
Благодарил (а): 3 раза

Рекомендации по ускорению работы Linux Mint на слабых ПК

Сообщение Lion » 22 янв 2018, 16:05

https://opartnerke.ru/kak-uvelichit-ope ... -fleshkoj/ вот она ссылка. Ныне юзаю линукс минт 18.2 xfce 32 бита. Друг уверял,что с 2 гигами оперативки 64 битный циннамон будет летать. А он не полетел, завис сразу. И несколькот раз подряд. Ну тогда ухожу на xfce 64 бита, легче он. Друг уверяет: только не ленись, настрой. А как настроить, если тоже самое? Тык-мык и ушёл на 32. Зависал было, настроил - не зависает. На своём опыте понял как важно иметь оперативки поболее, у меня ноутбук, сложнее добавить.

Аватара пользователя

darkfenix
Сообщения: 2952
Зарегистрирован: 27 июн 2017, 10:36
Решено: 32
Откуда: Нижний Тагил
Благодарил (а): 188 раз
Поблагодарили: 499 раз

Рекомендации по ускорению работы Linux Mint на слабых ПК

Сообщение darkfenix » 22 янв 2018, 16:45

Lion писал(а):
22 янв 2018, 16:05
у меня ноутбук, сложнее добавить.
Ничего сложного. Открыть заднюю крышку и добавить/поменять планку и будет минимум 4 Гига памяти
Изображение

Аватара пользователя

slant
Сообщения: 1039
Зарегистрирован: 21 июн 2017, 15:09
Решено: 14
Благодарил (а): 7 раз
Поблагодарили: 381 раз

Рекомендации по ускорению работы Linux Mint на слабых ПК

Сообщение slant » 22 янв 2018, 17:28

Lion писал(а):
22 янв 2018, 16:05
Друг уверял,что с 2 гигами оперативки 64 битный циннамон будет летать.
Ну, как бы сам cinnamon на 2GB. летать будет. А вот сторонние программы запущенные в нем (броузер, офис)- уже не очень. :) Но вот виснуть он совсем не должен, в любом случае. Где-то что-то у вас серьезно не так пошло, и недостаток памяти сам по себе тут вряд-ли при чем.

Вернуться в «Параметры и оптимизация»