The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Релиз ядра Linux 3.18, opennews (??), 08-Дек-14, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


93. "Релиз ядра Linux 3.18"  –4 +/
Сообщение от Аноним (-), 08-Дек-14, 20:36 
Вот как можно не включать(выключить) swap? Вы чем думаете вообще? Вы бы прежде освоили принципы страничной организации памяти в OS. Еще удивляется чего virtualbox у него "глохнет". Отключение swap нечего хорошего не принесет.
Ответить | Правка | Наверх | Cообщить модератору

96. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Crazy Alex (ok), 08-Дек-14, 20:53 
Вообще-то польза от отключения свопа есть. Потому что некоторые программы - браузеры в особенности - судя по всему, своп от физической памяти отличать не хотят, зато отжирают себе в зависимости от общего объема. И потом не отдают. И система начинает свопиться даже тогда, когда полностью умещается в RAM. Отключаешь своп - и внезапно какой-нибудь файрфокс начинает тупить гораздо меньше.
Ответить | Правка | Наверх | Cообщить модератору

97. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Аноним (-), 08-Дек-14, 20:59 
Программы и не должны отличать физическую память от свопа - ядро их тычет в виртуальное её представление. А уж как лучше всем этим добром распорядиться и что куда кидать, ему (ядру) и подавно виднее.
Ответить | Правка | Наверх | Cообщить модератору

122. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Crazy Alex (ok), 09-Дек-14, 02:52 
Ну вот в данном случае не прокатывает - без свопа тупит меньше. Похоже, оно что-то пытается "в памяти" держать, что дешевле пересоздать, чем сохранять на диск и потом тянуть обратно. Или, может, GC как-то по-другому начинает себя вести, уж не знаю.
Ответить | Правка | Наверх | Cообщить модератору

144. "Релиз ядра Linux 3.18"  +/
Сообщение от none7 (ok), 09-Дек-14, 07:40 
Единственное чем может помочь отключение swap, так это фактическим отключением кеша фс при дефиците памяти. Видимо в некоторых случаях ядро предпочитает данные программ сбросить на диск, а не кеш. Если бы системе стало реально не хватать памяти, то первыми бы слетел X-сервер, потому, что не умеют программы адекватно обрабатывать ситуацию malloc() == NULL.
Ответить | Правка | Наверх | Cообщить модератору

149. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 09-Дек-14, 08:17 
Читал тред и вдруг пришла гениальная мысль: вместо firefox запустить firefox:i386 :)
Пойду и проверю насколько мысль гениальная..
Ответить | Правка | Наверх | Cообщить модератору

178. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Crazy Alex (ok), 09-Дек-14, 12:21 
У меня давало 30% разницы в потреблении памяти - но это было гда полтора назад. Буду благодарен, если отпишетесь о результате.
Ответить | Правка | Наверх | Cообщить модератору

179. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 12:22 
> Единственное чем может помочь отключение swap, так это фактическим отключением кеша фс
> при дефиците памяти.

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

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

> умеют программы адекватно обрабатывать ситуацию malloc() == NULL.

Для начала все это весьма иррелевантно управлению памятью в линуксе, где по дефолту оверкоммит врублен и oom killer возбухает. Так, FYI.

Ответить | Правка | К родителю #144 | Наверх | Cообщить модератору

180. "Релиз ядра Linux 3.18"  –2 +/
Сообщение от Crazy Alex (ok), 09-Дек-14, 12:24 
Во-первых, первым слетел бы тот, кого убил бы OOM. Во-вторых - со свапом траблы есть когда памяти достаточно. Не то, чтобы система колом вставала - но тормозит прилично, если запущено что-то развесистое вроде браузера с кучей страниц или IDE  с большим проектом. Моё предположение - что система не угадывает, что можно вытеснить в своп (а она его использует даже если памяти хвтает - освобождает её для файловых буферов, причем в основном - которые на чтение).
Ответить | Правка | К родителю #144 | Наверх | Cообщить модератору

190. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 13:15 
> Во-первых, первым слетел бы тот, кого убил бы OOM.

Так весь пойнт в том чтобы поставить столько памяти, что OOM случается только при runaway и не случается при нормальной эксплуатации вообще совсем. Грубо говоря если у тебя 4 гига памяти и 4 гига свопа - с точки зрения приятности эксплуатации системы намного лучше будет поставить 8 гигз памяти и никакогош свопа. При этом будут доступны те же 8 гигз, только последние 4 гига не будут добиваться с истошным тормозиловом и клином всего что угораздило выпасть в своп. Мало 8? Ок, поставим 16. Все-равно ты с практической точки зрения опупеешь от времени (пере)записи и чтения свопа крупнее 1-2 гигов. Я как-то совсем не готов десятками минут ждать пока система протормозится.

> с кучей страниц или IDE  с большим проектом. Моё предположение
> - что система не угадывает, что можно вытеснить в своп

Искусственный интеллект, который заранее знает что приспичит пользователю - еще не изобрели. Поэтому естественно в своп будет улетать как dead code и такие же данные, так и то что потом через полдня юзеру понадобится (но система про это ессно не знала).

> файловых буферов, причем в основном - которые на чтение).

Как по мне - так идея выиграть дисковый буфер для ускорения I/O за счет тормозов от свопления - очень спорная идея, мягко говоря.

Ответить | Правка | Наверх | Cообщить модератору

197. "Релиз ядра Linux 3.18"  –2 +/
Сообщение от Crazy Alex (ok), 09-Дек-14, 14:26 
Лично мой пойнт в том, чтобы не покупать то, что даёт копеечные приросты. Если у тебя четыре гига, а ещё четыре используются раз в месяц для пересборки, которую можно вообще на ночь зашедулить - глупо их покупать. При этом при наличии постоянно включенного свопа - да, в него (за отсутстсвием искусственного интеллекта и libastral) улетает то, что иногда нужно пользователю. И ни разу не через пол-дня, речь о минутах в случае браузера.

Логичный вывод - обычно живём без свопа, когда он нужен - временно его включаем.

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

Ответить | Правка | Наверх | Cообщить модератору

212. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Аноним (-), 09-Дек-14, 17:47 
> Лично мой пойнт в том, чтобы не покупать то, что даёт копеечные приросты.

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

Я говорю как сделать чтобы не тормозило. А вы говорите что "и так сойдет!". Хотя изначальная постановка вопроса подразумевает что вопрошавшему так не нравится и видимо все-таки не сойдет.

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

А как по мне так нормально. Ждать машину час в месяц - хуже не придумаешь. Тем более что я за час зарабатываю поболее чем на планку оперативки при современных ценах на память - вроде вполне себе окупается даже с формальной точки зрения. Не говоря о элементарном повышении комфорта взаимодействия с такой системой.

По вашей логике кровати покупают только глупцы. Ведь можно же поспать и на полу. Тем более что вы это делаете только 8 часов из 24, не так уж и много вроде.

> о минутах в случае браузера.

Ну а мне вот не хочется смотреть минутами на тормозящую систему. Судя по постановке вопроса - не только мне.

> Логичный вывод - обычно живём без свопа, когда он нужен - временно
> его включаем.

Тоже вариант, но мне своп элементарно не требовался на основной машине уже лет пять. Все задачи влезают в тамошний объем RAM и если там OOM случился - это значит что нечто пошло вразнос.

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

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

Ответить | Правка | Наверх | Cообщить модератору

157. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Аноним (-), 09-Дек-14, 09:31 
> тупить гораздо меньше.

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

p.s. и да, линух умеет оверкоммит - сколько там виртуальной памяти попросят программы не принципиально. Пока они ее не поюзали по факту - она вообще ядром не выделяется. Чисто циферка в top.

Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

100. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 08-Дек-14, 21:32 
А что еще делать, если использование этого самого свопа вешает систему наглухо? Смысл тогда его вообще включать, так глядишь oom прибъет что и пропердится, а со свопом чаще только ребут.
Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

113. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Mihail Zenkov (ok), 09-Дек-14, 00:21 
Сам давно отказался от свопа. Но есть и правда в том, что ядро может вести себя неадекватно при его отключении:
https://bbs.archlinux.org/viewtopic.php?id=144702

Сам иногда наблюдаю такую же картину. Ядро собрано без поддержки свопа, но процесс kswapd0 есть. Это конечно баг, а не "так и было задумано".

Ответить | Правка | Наверх | Cообщить модератору

158. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 09:33 
> Сам иногда наблюдаю такую же картину. Ядро собрано без поддержки свопа, но
> процесс kswapd0 есть. Это конечно баг, а не "так и было задумано".

А у меня ядро хоть и с поддержкой свопа, но ни 1 свопа не подцеплено. И никаких проблем, соотвественно.

Ответить | Правка | Наверх | Cообщить модератору

131. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 03:51 
> Вот как можно не включать(выключить) swap? Вы чем думаете вообще? Вы бы
> прежде освоили принципы страничной организации памяти в OS. Еще удивляется чего
> virtualbox у него "глохнет". Отключение swap нечего хорошего не принесет.

Я думаю, что уж лучше программа через минуту тупняка (без доступной под pagecache памяти дисковые операции залипать будут) по oom сдохнет, чем полчаса об своп спотыкаться будет с еще большими тормозами.

Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

160. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 09:40 
> прежде освоили принципы страничной организации памяти в OS.

Мы освоили. И поняли что при текущих ценах на память довольно глупо заниматься вытаскиванием страниц из свопа если можно их в физической памяти разложить. Нафиг надо тормозную эмуляцию памяти из слоупочного харда, когда можно настоящую быструю память поставить? Оперативка работает со скоростью порядка пары десятков гиг в секунду и временем доступа которым можно принебречь в большинстве случаев. Хард читает ну самый край 200 мегов в секунду, а seek time может быть десятки миллисекунд. Так что эмуляция памяти получается крайне тормозной.

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

Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

181. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Crazy Alex (ok), 09-Дек-14, 12:29 
Чепуха, очередное обобщение. Допустим, я иногда собираю хром или файрфокс. Они в пике выжирают несколько гиг памяти. Вот для этого врубить временно своп гига на три-четыре - хорошо, позволяет параллельно серфить (да, с некоторыми тормозами) или читать или видео сомтреть (а вот здесь тормоза не прибавляются) или что там еще делаешь.

Нет универсальных решений, ну включайте вы голову, черт возьми.

Ответить | Правка | Наверх | Cообщить модератору

185. "Релиз ядра Linux 3.18"  –2 +/
Сообщение от Аноним (-), 09-Дек-14, 12:38 
> Нет универсальных решений, ну включайте вы голову, черт возьми.

Добивать быструю оперативу мелденным винчом - это по современному состоянию дел просто эталонный идиoтизм. Универсальное решение - воткнуть 8 гиг или более. А выюзать 16 нетривиально даже открыв в хромиуме кучу дряни и запустив пару виртуалок, попутно компиля что-то жирное. Проверено. Еще и дисковому кешу остается. А в современные мамки можно и 32 набить. Мне просто как-то 16 хватает выше крыши, поэтому заняты только 2 слота из 4...

А своп - источник тормозов. Если на HDD. Или помощь в быстром залете на бабки. Если на SSD. Совет вкатить максимум оперативки который некто может позволить себе и вырубить своп - вполне универсальный, как минимум для серверов, десктопов и ноутов. Ну да, в каком-нибудь домашнем роутере память добавить сложно. Но там и свопиться чаще всего некуда. Тем паче что отвал свопфайла может уронить всю систему.

Ответить | Правка | Наверх | Cообщить модератору

196. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Crazy Alex (ok), 09-Дек-14, 14:14 
Универсальное решение - это собирать систему под имеющиеся задачи, а не под то, что делается раз в три жизни. Это во-первых. А во-вторых - сборка - это фоновый процесс, и плевать (в разумных пределах) сколько она займёт, лишь бы остальной деятельности, происходящей в это время (а не любой, какая приснится) не мешала.

И, что характерно, в отличие от покупки SSD или оперативки, включение мозга - оно бесплатное.

Ответить | Правка | Наверх | Cообщить модератору

214. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 09-Дек-14, 18:00 
> Универсальное решение - это собирать систему под имеющиеся задачи, а не под
> то, что делается раз в три жизни.

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

Понимаешь, если ты купил дрель которая никак не может сверлить дыры более 5 миллиметров, а тут приспичило просверлить дыру в 10 миллиметров - будет глупо хвататься за голову и бежать за новым инструментом или хардкорно долбаться с маломощным, явно не тянущим задачу. Разумнее брать инструмент с некоторым запасом на worst case. Чтобы в этот случай "раз в месяц" не чесать репу "блин, и что мне теперь делать?".

> Это во-первых. А во-вторых - сборка - это фоновый процесс, и плевать
> (в разумных пределах) сколько она займёт, лишь бы остальной деятельности,
> происходящей в это время (а не любой, какая приснится) не мешала.

При наличии свопа будет мешать - просто потому что в своп попадут не только сборочные процессы но и остальные, что вызовет деградацию времен отклика и проседание производительности системы в целом. Потому что гонять 50 миллисекунд головы чтобы получить плевок в 4 кило, который будет выполнен условно-мгновенно и понадобится еще плевок в 4 кило - это крайне контрпродуктивная активность системы. У буржуев это называется термином "computer is thrashing".

> И, что характерно, в отличие от покупки SSD или оперативки, включение мозга
> - оно бесплатное.

А ожидание системы - оплачивается своим временем и неприятными ощущениями.

Ответить | Правка | Наверх | Cообщить модератору

194. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 09-Дек-14, 13:50 
И нафуа мне эта хрень из прошлого века, при 64Гб памяти? Вообще, эмулировать оперативку разделом на жестком диске - нездоровая идея, оправданная в те времена, когда память была маленькая и дорогая, а сейчас в этом и вовсе никакого смысла нет.
Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру