Рекомендации по ускорению работы Linux Mint на слабых ПК
Как правильно задавать вопросы Правильно сформулированный вопрос и его грамотное оформление способствует высокой вероятности получения достаточно содержательного и по существу ответа. Общая рекомендация по составлению тем: 1. Для начала воспользуйтесь поиском форума. 2. Укажите версию ОС вместе с разрядностью. Пример: LM 19.3 x64, LM Sarah x32 3. DE. Если вопрос касается двух, то через запятую. (xfce, KDE, cinnamon, mate) 4. Какое железо. (достаточно вывод
inxi -Fxz
в спойлере (как пользоваться спойлером смотрим здесь)) или же дать ссылку на hw-probe 5. Суть. Желательно с выводом консоли, логами. 6. Скрин. Просьба указывать 2, 3 и 4 независимо от того, имеет ли это отношение к вопросу или нет. Так же не забываем об общих правилах Как пример вот
-
- Сообщения: 4469
- Зарегистрирован: 21 июн 2017, 18:09
- Решено: 95
- Благодарил (а): 51 раз
- Поблагодарили: 1965 раз
- Контактная информация:
Рекоммендации по ускорению работы Linux Mint на слабых ПК
Зато ни скайпа ни вайбера на x32 уже нету. И фиг знает, что будет следующим. Отказываются от нее потихоньку. А так - можно и ее конечно поставить и x32.
Но кроме того, если система x64 - это само по себе дает некоторый прирост к быстродействию при выполнении x64 кода. А в отличии от винды, под линуксом в x64 дистрибутивах код программ реально так откомпилирован весь. А не исполнятся львиной долей legacy 32-битный код через эмуляцию x86. Я тестил специально на 17-ом минте х86 и х64 - архиваторы, скажем, могут до 30% разницы выдавать, в определенных условиях. Под линуксом 64 бита имеет смысл использовать всегда, когда это возможно. Расход памяти немного выше, но совсем не в два раза, как часто пишут. На этом смысл экономить только если памяти меньше гигабайта.
Но кроме того, если система x64 - это само по себе дает некоторый прирост к быстродействию при выполнении x64 кода. А в отличии от винды, под линуксом в x64 дистрибутивах код программ реально так откомпилирован весь. А не исполнятся львиной долей legacy 32-битный код через эмуляцию x86. Я тестил специально на 17-ом минте х86 и х64 - архиваторы, скажем, могут до 30% разницы выдавать, в определенных условиях. Под линуксом 64 бита имеет смысл использовать всегда, когда это возможно. Расход памяти немного выше, но совсем не в два раза, как часто пишут. На этом смысл экономить только если памяти меньше гигабайта.
-
- Сообщения: 245
- Зарегистрирован: 17 окт 2016, 15:36
- Решено: 4
- Откуда: Кинешма
- Благодарил (а): 40 раз
- Поблагодарили: 51 раз
- Контактная информация:
Рекомендации по ускорению работы Linux Mint на слабых ПК
Не по теме
wanoska писал(а): ↑22 ноя 2016, 11:54Dja, с таким железомМне кажется не логично из за одной программы менять 32 на 64ilopatin@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
LM18.2 Xfce 4.12.3 Kernel: 4.10.0-40-generic
-
- Сообщения: 340
- Зарегистрирован: 17 фев 2017, 12:01
- Решено: 2
- Откуда: Москва
- Благодарил (а): 43 раза
- Поблагодарили: 46 раз
- Контактная информация:
Рекомендации по ускорению работы Linux Mint на слабых ПК
Недавно прочитал статью на хабре по этому поводу и там высказано диаметрально противоположное мнение:Chocobo писал(а): ↑28 сен 2016, 13:211.1 Оптимизировать порог использования swap-раздела
По умолчанию параметр swappiness имеет значение 60 - что указывает ядру ОС начинать обращаться к своп-разделу уже при утилизации в 40% от общего объема оперативной памяти.
Практической пользы для рядового десктопа в этом никакой, и может напротив повысить интенсивность обращения к дискам и замедлить работу системы в целом.
проверить текущее значение этого параметра можно командой:
sudo sysctl vm.swappiness
Для того, чтобы исправить это поведение - параметр swappiness нужно уменьшить следующей командой
sudo sysctl -w vm.swappiness=5
Чтоб новые параметры сразу вступили в силу - можно перезагрузить компьютер, или очистить текущий набор памяти в разделе подкачки:
КОД: ВЫДЕЛИТЬ ВСЁ
sudo swapoff -a
sudo swapon -a
Что еще интереснее, в комментах к статье было высказано мнение, что параметр vm.swappiness вообще работает иначе:Часто в интернете советуют изменить параметр ядра 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 минут не происходит.
Так в итоге, как оно работает и стоит ли менять этот параметр (как в шапке) или стоит смотреть в сторону приоритетов своп и zram (как на хабре)?Очень распространенное заблуждение. На самом деле 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:То есть опция указывает приоритет дискового кэша перед данными приложений. Поэтому уменьшение этой опции увеличивает приоритет данных приложений, взамен ухудшается кэширование I/O.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.
-
Автор темы - Сообщения: 10015
- Зарегистрирован: 27 авг 2016, 22:57
- Решено: 215
- Откуда: НН
- Благодарил (а): 815 раз
- Поблагодарили: 3008 раз
- Контактная информация:
Рекомендации по ускорению работы Linux Mint на слабых ПК
SemenSinchenko, в этой же ветке обсуждения идет следом
А нас в данном случае, в сценарии десктопного использования как правило инетересует чтоб в своп не попдали именно RSS-наборы наиболее активных процессов, тех же браузеров. Запись одного Гб на жесткий диск - как тут представлен пример, не отправит в частном случае систему в пятиминутный stuck. Но если своппить все подряд дефолтным методом - то тупняки и отзывчивость интерфейса потеряешь еще раньше в купе с выросшими иовейтам еще до возникновения дефицита памяти. И тут да, на фоне общих непрекращающихся фризов - вполне возможно все пройдет визуально несколько более гладко при выделении неких нескольких гигабайт разом. А сам оверкоммит кстати у нас выключен по дефолту.Более того совсем не понятно что такое "% свободной памяти", поскольку само понятие свободная память (особенно при разрешенном оверкоммите) это тема для еще нескольких статей.
Угу, прям золотая пуля . Только вот 60 по умолчанию выставлено мейнтейнерами моего дистрибутива специально для десктопных задач? А если нет - то наверное это идеальная цифра для задач серверных... мой ELK-стек как-то раз этого совсем не оценил, когда кусок хипа elasticsearch попал в своп...SemenSinchenko писал(а): ↑18 дек 2017, 10:50вы не умнее разработчиков ядра Linux, которые не просто так поставили 60 по умолчанию
-
- Сообщения: 340
- Зарегистрирован: 17 фев 2017, 12:01
- Решено: 2
- Откуда: Москва
- Благодарил (а): 43 раза
- Поблагодарили: 46 раз
- Контактная информация:
Рекомендации по ускорению работы Linux Mint на слабых ПК
Так ведь ядро свопит именно редко используемые страницы памяти - ну висит у меня с позавчера вкладка в файрфокс - так пусть и свопится. Открыт у меня пять часов уже либр офис с курсовой, которую я делать не хочу пока - пусть свопится. А в chrome/firefoxe и прочих вкладки это процессы. А активные вкладки по логике и не будут свопится.
Ну и потом - в шапке работа swapinness описана через % свободной памяти (условимся для простоты, что это цифра, которую выдает
top
), а на хабре пишут (и в документации вроде написано), что это именно активность. Ну и тогда зачем ставить именно 10? Поставить 40 и пусть в фоне свопит неиспользуемое - мне же удобней - либр офис, игрушки и прочее будет даже быстрее открываться по факту, так как своп уже выполнен.Может быть в теории могут быть проблемы с garbage collector-ами которым может внезапно приспичить собрать мусор в свопе и подвесить систему, если своп загружен, но мы все же исходим из предположения, что наши программы не индусы писали и GC настроены нормально.
Там же в комментах пишут
То есть 60 это оптимальное значение для десктопа, а администратор сервера может в документацию ядра и сам настроит как надо (что кстати логично).Будьте внимательны: речь идёт про десктопные машины а не про сервера в данной статье.
Для серверов БД (например для Оракла) редхат в руководстве по настройке рекомендует swapiness выставлять в 1 для RHEL 7
-
Автор темы - Сообщения: 10015
- Зарегистрирован: 27 авг 2016, 22:57
- Решено: 215
- Откуда: НН
- Благодарил (а): 815 раз
- Поблагодарили: 3008 раз
- Контактная информация:
Рекомендации по ускорению работы Linux Mint на слабых ПК
Т.е. ядра подготавливаемые в Centos, RHEL, Debian - все как один настроили сей параметр специально для десктопа, независимо от роли своего дистрибутива?
Мы тут даже обсуждаем чуть другое - а именно как комфортно вылезти за рамки имеющегося объема ОЗУ, и при этом сделать все бесшовно:SemenSinchenko писал(а): ↑18 дек 2017, 12:03мы все же исходим из предположения, что наши программы не индусы писали и GC настроены нормально.
Так вот находится ли не интересующий процесс (тем более процесс над иксами, вися в панели задач) все свое время в состоянии сна в тот момент, и не дергает ли аллокаторы (или же не дергается со стороны ядра) - система слишком комплексна, чтоб сходу сказать, надо б провести ряд экспериментов да потыкать палочкойSemenSinchenko писал(а): ↑18 дек 2017, 12:03висит у меня с позавчера вкладка в файрфокс - так пусть и свопится. Открыт у меня пять часов уже либр офис с курсовой, которую я делать не хочу пока - пусть свопится.
Ну и в любом случае, по некоторому опыту взаимодействия сподобными системами, где озу в дефиците - у меня совсем не получается сказать что при дефолтном значении swapiness все работает тем идеальным методом распределения памяти описанным тобой, иначе не было десятков подобных тем, пусть даже и с противоположными мнениями)
-
- Сообщения: 1920
- Зарегистрирован: 03 сен 2016, 13:36
- Решено: 24
- Благодарил (а): 5 раз
- Поблагодарили: 264 раза
- Контактная информация:
Рекомендации по ускорению работы Linux Mint на слабых ПК
Поменьше читай таких статей. Особенно всякой школоты - говноблогеров. Всё актуально было (vm.swappiness=60), когда ОЗУ 4Мб было нормой, а не 4Гб, и своп делали специально первым разделом. И планировщики были тех времён. Он ещё на горшке сидел. Как вообще без свопа люди живут по многу вкладок держат открытыми в браузере. Браузеры свой дисковый кеш используют с возможность размещать его в ОЗУ. Лиса так при сворачивании все странички на диск бросает по умолчанию. Если ОЗУ позволяет, то можно всё в нём и оставлять. Аффтор по видимому и не знает, что память делится для работы программ и данных, обрабатываемыми этими прогами.SemenSinchenko писал(а): ↑18 дек 2017, 10:50Недавно прочитал статью на хабре по этому поводу и там высказано диаметрально противоположное мнение:
Да, ещё, советовать применять сжатие свопа в ОЗУ, при дефиците последнего может только идиот. Копипастят годами старый пример своп -разделом. Это именно пример, а не руководство к действию.
И параметры по умолчанию в дистрибутивах ОС, софте такие, какие есть, потому что разработчик не знает на какое железо будет установлена ОС.
Поэтому в Минт по умолчанию древний ondemand для ЦП Пентиум4 Е6хх до сих пор.
-
Автор темы - Сообщения: 10015
- Зарегистрирован: 27 авг 2016, 22:57
- Решено: 215
- Откуда: НН
- Благодарил (а): 815 раз
- Поблагодарили: 3008 раз
- Контактная информация:
Рекомендации по ускорению работы Linux Mint на слабых ПК
Unborn, по
И учитывая название темы "ускорения работы Linux Mint на слабых ПК" - эффект в теории может вполне получиться обратным при слабом камне, когда часть процессорного времени будет тужиться в sys над обработкой пожатых страниц памяти для какой-либо её экономии, в то время как мне надо уже в usr отрендерить страничку в браузере вместо этого
zram
я вижу от компрессии некоторый возможный профит именно в плане снижения объема после компрессии. Но обратная строна медали - сжатие/распаковка ляжет на чьи плечи, процессора разумеется. И учитывая название темы "ускорения работы Linux Mint на слабых ПК" - эффект в теории может вполне получиться обратным при слабом камне, когда часть процессорного времени будет тужиться в sys над обработкой пожатых страниц памяти для какой-либо её экономии, в то время как мне надо уже в usr отрендерить страничку в браузере вместо этого
-
- Сообщения: 1920
- Зарегистрирован: 03 сен 2016, 13:36
- Решено: 24
- Благодарил (а): 5 раз
- Поблагодарили: 264 раза
- Контактная информация:
Рекомендации по ускорению работы Linux Mint на слабых ПК
Тут ещё, чтобы обработать, нужно сначала распаковать, а куда, если ОЗУ мало, по чайной ложке будет выделятся. Вот и получается чистейший идиотизм - по кусочкам распаковывать, обрабатывать, запаковывать. Лучше просто чистое физическое ОЗУ без всяких зетов и свопов.
Прошли уже те времена, когда планки имели конские цены. И какой-нибудь природный катаклизм резко их поднимал.
-
Автор темы - Сообщения: 10015
- Зарегистрирован: 27 авг 2016, 22:57
- Решено: 215
- Откуда: НН
- Благодарил (а): 815 раз
- Поблагодарили: 3008 раз
- Контактная информация:
Рекомендации по ускорению работы Linux Mint на слабых ПК
Unborn, Разумеется, также подмечал тут неподалеку
Глянув в текущий выхлоп - посмотрел что и браузеры и вайн, и gnome-online-accounts (и еще много прочего) вполне себе отжирают десятками блоков
Вот тут на RH есть описание по взаимодействию с ними - https://access.redhat.com/solutions/46111
Можно попробовать отключить (
Но еще подумалось тут в кач-ве твика по некоторой экономии ОЗУ - может есть смысл погасить HugePages в десктопном сценарии. Дабы предотвратить эллокейт блоками по 2Мб в AnonHugePages.Chocobo писал(а): ↑16 апр 2017, 21:41При любой аппаратной конфигурации - обращение к своппированным данным это явная просадка по производительности.
...
своппинг в процессе работы - всегда плохо, если он случается постоянно - все же лучше увеличить объем оперативной памяти, благо сегодня это не такой уж и дефицит.
Глянув в текущий выхлоп - посмотрел что и браузеры и вайн, и gnome-online-accounts (и еще много прочего) вполне себе отжирают десятками блоков
Код: Выделить всё
grep -e AnonHugePages /proc/*/smaps | awk '{ if($2>4) print $0} ' | awk -F "/" '{print $0; system("ps -fp " $3)} '
Можно попробовать отключить (
transparent_hugepage=never
) и понаблюдать, как изменится утилизация и не будет ли ядру сложней скакать по маленьким 4к-чанкам.-
- Сообщения: 4469
- Зарегистрирован: 21 июн 2017, 18:09
- Решено: 95
- Благодарил (а): 51 раз
- Поблагодарили: 1965 раз
- Контактная информация:
Рекомендации по ускорению работы Linux Mint на слабых ПК
Смысл zram не в том, чтобы больше влезло. А в том, что сжатые данные скидывающиеся в своп быстрее запишутся и прочитаются - т.к. диск в десятки раз медленнее памяти. И самое узкое место. А тут ему в абсолютном значении писать/читать меньше придется. Алгоритм там используется максимально быстрый, чтобы процессор излишне не грузить - но в "чистой памяти" огромное число данных как раз в хорошо подающемся сжатию виде. Те же картинки - это они только на диске в сжатом формате - а в памяти, подготовленные для отображения на экране - уже нет.
zram - это скорее в случае медленной дисковой подсистемы полезно. Если уж своп таки приходится терпеть. Т.е. размениваем мощность процессора на скорость записи/чтения. Нужно это или нет - от конкретных условий зависит. То же самое с обычными FS, которые умеют компрессию на лету - вроде NTFS или BTRFS. Там конечно есть выигрыш и в общем объеме хранения, но, скажем, системный диск на btrfs c компрессией lzo иногда быстрее чем без компрессии вообще получается - если скоростью загрузки системы мерятся.
zram - это скорее в случае медленной дисковой подсистемы полезно. Если уж своп таки приходится терпеть. Т.е. размениваем мощность процессора на скорость записи/чтения. Нужно это или нет - от конкретных условий зависит. То же самое с обычными FS, которые умеют компрессию на лету - вроде NTFS или BTRFS. Там конечно есть выигрыш и в общем объеме хранения, но, скажем, системный диск на btrfs c компрессией lzo иногда быстрее чем без компрессии вообще получается - если скоростью загрузки системы мерятся.
-
- Сообщения: 2866
- Зарегистрирован: 11 окт 2016, 12:58
- Решено: 11
- Откуда: Новосибирск
- Благодарил (а): 1083 раза
- Поблагодарили: 468 раз
- Контактная информация:
Как сэкономить ресурсы при нехватке оперативной памяти
Понравился материал на хабре на тему: "Нехватка оперативной памяти в Linux на рабочем ПК: оптимизация и действия при зависании" Публикую здесь ссылку (для тех кто не читал). По-моему статья интересная и полезная.
https://habrahabr.ru/post/344836/?utm_c ... =link2post
https://habrahabr.ru/post/344836/?utm_c ... =link2post
-
- Сообщения: 96
- Зарегистрирован: 27 сен 2016, 15:55
- Решено: 2
- Благодарил (а): 38 раз
- Поблагодарили: 3 раза
- Контактная информация:
Рекомендации по ускорению работы Linux Mint на слабых ПК
Только теперь заметил - оптимизация работает до перезагрузки (выключения/включения) ПК?! По крайней мере у меня на LM 18.2 x32.
-
Автор темы - Сообщения: 10015
- Зарегистрирован: 27 авг 2016, 22:57
- Решено: 215
- Откуда: НН
- Благодарил (а): 815 раз
- Поблагодарили: 3008 раз
- Контактная информация:
Рекомендации по ускорению работы Linux Mint на слабых ПК
AllVit, ага,
чтоб сделать перманентно - добавь строчки со своими значениями
в
Добавлю в шапку, а то реально не прояснили чёт этот момент
sysctl -w
пишет в рамках текущей сессии, чтоб сделать перманентно - добавь строчки со своими значениями
vm.swappiness = XX
vm.vfs_cache_pressure = YY
в
/etc/sysctl.conf
, чтоб они вычитывались при каждой загрузкеДобавлю в шапку, а то реально не прояснили чёт этот момент
-
- Сообщения: 96
- Зарегистрирован: 27 сен 2016, 15:55
- Решено: 2
- Благодарил (а): 38 раз
- Поблагодарили: 3 раза
- Контактная информация:
Рекомендации по ускорению работы Linux Mint на слабых ПК
Так все таки значение по умолчанию 100 заменить на 1000 или на 50 для 2ГБ оперативно памяти. В теме есть два противоречивых мнения.
Unborn писал(а): ↑13 янв 2017, 21:55Это кеш метаданных файловых систем. Чем выше значение, тем чаще кеш будет сбрасываться на диск. Там и 100 много. В современных реалиях при достаточности ОЗУ кеш можно подольше держать в ней. Так что наоборот - не 1000, а 50. А если ОЗУ мало, то да - почаще сбрасывать.
-
- Сообщения: 129
- Зарегистрирован: 27 ноя 2017, 20:50
- Благодарил (а): 22 раза
- Контактная информация:
Рекомендации по ускорению работы Linux Mint на слабых ПК
Ссылку не нашёл, а было написано, что можно увеличить ОЗУ подключением пустой флешки в USB -порт. Но писали про Винду Висту и старше. А на линуксе нет такого?
-
- Сообщения: 5469
- Зарегистрирован: 27 авг 2016, 19:06
- Решено: 32
- Откуда: Арзамас
- Благодарил (а): 1593 раза
- Поблагодарили: 1276 раз
- Контактная информация:
Рекомендации по ускорению работы Linux Mint на слабых ПК
Ты наверное про ReadyBoost ? Это виндовая фишка. Только это скорее не увеличение RAM, а свап
Настоящая водка — это не пьянство, а ключ к своей совести, с нее-то и начинается настоящая мудрость. (c)
-
- Сообщения: 129
- Зарегистрирован: 27 ноя 2017, 20:50
- Благодарил (а): 22 раза
- Контактная информация:
Рекомендации по ускорению работы Linux Mint на слабых ПК
https://opartnerke.ru/kak-uvelichit-ope ... -fleshkoj/ вот она ссылка. Ныне юзаю линукс минт 18.2 xfce 32 бита. Друг уверял,что с 2 гигами оперативки 64 битный циннамон будет летать. А он не полетел, завис сразу. И несколькот раз подряд. Ну тогда ухожу на xfce 64 бита, легче он. Друг уверяет: только не ленись, настрой. А как настроить, если тоже самое? Тык-мык и ушёл на 32. Зависал было, настроил - не зависает. На своём опыте понял как важно иметь оперативки поболее, у меня ноутбук, сложнее добавить.
-
- Сообщения: 10015
- Зарегистрирован: 27 июн 2017, 13:36
- Решено: 128
- Откуда: Нижний Тагил
- Благодарил (а): 776 раз
- Поблагодарили: 1950 раз
- Контактная информация:
Рекомендации по ускорению работы Linux Mint на слабых ПК
Ничего сложного. Открыть заднюю крышку и добавить/поменять планку и будет минимум 4 Гига памяти
-
- Сообщения: 4469
- Зарегистрирован: 21 июн 2017, 18:09
- Решено: 95
- Благодарил (а): 51 раз
- Поблагодарили: 1965 раз
- Контактная информация:
Рекомендации по ускорению работы Linux Mint на слабых ПК
Ну, как бы сам cinnamon на 2GB. летать будет. А вот сторонние программы запущенные в нем (броузер, офис)- уже не очень. Но вот виснуть он совсем не должен, в любом случае. Где-то что-то у вас серьезно не так пошло, и недостаток памяти сам по себе тут вряд-ли при чем.
Кто сейчас на конференции
Сейчас этот форум просматривают: Google [Bot] и 5 гостей