зогчем вам столько свопа?

А чем он мешает?

отъедает 8ГБ НЖМД. вот у меня например тоже amd64 (правда генту), свопа нет, всё работает ))

«Этот процент по умолчанию равен, но можно его несколько увеличить.»

Равен...?

...равен 50

Годно

Насчёт overcommit и свопа — поддерживаю. Насчёт дисковых буферов — потестирую.

Своп нужен еще и затем, чтобы при использовании стратегии overcommit_memory = 2, не заканчивалась преждевременно доступная для выделения память. Поскольку многие программы отхватывают себе большие куски, из которых реально используют лишь малую часть, при принудительном распределении памяти может запросто сложиться ситуация, когда свободной ОЗУ еще завались, но выделить ни одной страницы уже не возможно. Наличие большого свопа решает эту проблему.

отъедает 8ГБ НЖМД

Большая потеря на терабайтовых винтах, ага.

> Своп нужен еще и затем, чтобы при использовании стратегии overcommit_memory = 2, не заканчивалась преждевременно доступная для выделения память.

У меня спервоначалу не было свопа. Как только я сделал overcommit_memory = 2, моментально отвалилась возможность запустить любой процесс. Пришлось убить файрфокс, а то даже автокомплит в баше не работал ;)

Особенно файрфокс. Он, сволочь, сколько памяти видит, столько гребет.

Спасибо. Познавательно. Теперь понял, почему без свопа при исчерпании памяти всё встаёт колом...

Собственно, речь идет о том, как подкрутить параметры ядра, чтобы оно работало сходно, например, с Darwin. На Mac OS X стратегия выделения памяти, например, сходна, и можно ее в принципе тоже поставить на колени (в рассылке darwin-dev за 2004 год есть примеры, как).

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

Полевые впечатления во время установки нового ядра и сборки DKMS-штук под него: иногда залипает переключение на другие программы на две-три секунды (ожидаемо — если их надо зачитать в память), в то же время докаппы WindowMaker'овские перерисовываются вовремя, курсор не тормозит.

Возможно, xcompmgr в чем-то виноват. Был виноват, конечно, я его убил.

Неплохо. :)

Собственно, речь идет о том, как подкрутить параметры ядра, чтобы оно работало сходно, например, с Darwin.

А почему тогда эта бага не везде, не всегда и не у всех? Ведь, если проблема именно в этом, по идее должно у всех воспроизводиться...

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

И не каждый ввод-вывод приводит систему к постановке раком. Например, когда mlocate базу обновляет, система влегкую впадает в кататонию, а когда md-raid перестраивается, то почему-то нет.

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

Ясно. А то «неуловимый баг» и всё такое...

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

Способ с созданием tmpfs, равного по размеру физическому ОЗУ, и заполнение его файлами в отсутствие свопа является гарантированным способом посмотреть, как это все происходит. Другим хватает, что tracker начинает все индексировать как угорелый.

В других случаях все происходит чуть по-иному:
1) процесс А говорит: ядро, дай мне два гига ОЗУ!
2) ядро говорит: на, дорогой, два гига ОЗУ!
3) процесс Б говорит: ядро, дай мне два гига ОЗУ!
4) ядро говорит: на, дорогой, два гига ОЗУ!
5) процесс В говорит: ядро, дай мне два гига ОЗУ!
6) ядро говорит: на, дорогой, два гига ОЗУ!
7) процесс Г говорит: ядро, дай мне два гига ОЗУ!
8) ядро говорит: на, дорогой, два гига ОЗУ!

Это при том, что их, допустим, только три всего и есть. С этим нет никаких проблем, так как ОЗУ выдавать можно только на бумажке. Проблемы начинаются, как только все эти процессы _одновременно_ начинают выделенной памятью пользоваться. Но и это не проблема, так как можно потеснить спящие процессы. Проблема, нет, ПРОБЛЕМА — это когда спящие процессы надо все же разбудить. А там еще кто-то файлы пишет-читает, пишет-читает, пишет-читает, и тоже ему ОЗУ надо...

Короче, man кризис мировой экономики. Тут то же самое все, вкупе с разгильдяйством и деланием всего в последний момент.

Решить проблему просто — нефиг обещать столько ОЗУ всем и сразу.

Так как получается, что всякие файрфоксы пишутся с оглядкой на то, что памяти можно брать больше, чем ее вообще есть, а потом люди кричат — у нас БРАУЗЕР ТЕКЁТ 10 вкладок и кранты системе!

А еще бы ей не кранты.

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

У тебя есть способ воспроизвести тормоза? Так, чтобы раз и второй и третий.

Ну и интересует:
1) у тебя в носителях часом DMA не отрубился?
2) если это SATA, то есть ли NCQ?
3) какой расклад по busy/free/buffers/cache перед процессом?
4) если есть возможность снять показания в процессе, как это выглядит?

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

Как будет время и свободный компьютер, всё сделаю.

На FreeBSD 8.2 становится почти так же: если начать копирование относительно большого файла (>1ГБ) между файловыми системами (даже одного пула) десктопные приложения начинают реагировать на действия пользователя с заметным опозданием и появляются заметные артефакты отрисовки, как то: убрал заслоняющее окно одного приложения, на заслонённом месте другого окна перерисовка происходит с запозданием; набираешь текст в редакторе фактически в слепую и ждёшь, когда «попустит», и набранная строка появится буква-за-буквой.

Можно ли такие случаи считать «встаёт колом» — я не знаю, но работать в такие моменты в X'ах дико бесит. И, да, курсор мыши не тормозит, бегает как обычно.

Ну, у меня так же.

Памяти 7.5ГБ, свободно 60%. SWAP 3ГБ, не занят вообще.

Чипсет какой?

FreeBSD небось? Кыш из моей песочницы. :) Мы тут линакс починить пытаемся!

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

Погугли бсдевые списки рассылки, может, там memory overcommit реализовали, пока все спали. Если да, погугли, как его отключать.

И да, у вас же как-то тоже VFS буферизуется? Возможно, есть способ замерить объем буферизации и подтюнить его?

Р67.

Хм, в бсдях разве overcommit по дефолту не впилен?

Даже и если, то вопрос — как он себя ведет. В линуксе он страдает излишним оптимизмом.

Нашёл: http://people.freebsd.org/~kib/overcommit/
Сравнил исходники и изменения патча — только частично наложено на исходники 8.2-STABLE.

А физический интерфейс подключения SATA-дисков что реализует? У меня JMicron. (Чипсет AMD 785G/SB710)

Ну видишь. Попробуй откатить и пересобрать.

Если всё просто, то почему баг так давно открыт в багзилле (и до сих пор не решен)?

Потому что стратегию вытеснения все равно надо пересматривать, плюс пара спецфайлов в /proc/sys/vm вообще не работает (и это связано с багом). То бишь, когда на этой стороне все это починится, тогда вместе с какими-то дефолтными значениями можно будет рекомендовать дистрибутивам и т. п.

То есть воркараунд для каждого будет в нюансах отличаться, и я даже не берусь утверждать, что он всегда будет работать.

У меня всё Intel, кроме USB 3.0 и FireWire.

Здравые мысли, но у меня, например, самые ощутимые тормоза начинаются когда кто-то что-то пишет в своп — это вообще ппц. Поэтому пока загнал vm.swappiness в 4%.

Не во всех ситуациях спасает, т.к. в своп страницы сбрасываются не только при нехватке памяти.

Это не борьба, это прогибание под баг. Борьба - это когда ты нашел фрагмент кода в ядре, из-за которого баг, выяснил, что там не так и поправил.

Там мнооооооого таких фрагментов. Я не программирую на C.

Я тоже, но я понимаю суть вещей ^ᴗ^

Если всё так просто, ткните кто-нибудь пальцем во внятное описание причин бага.

Последовательный протокол SATA.

Ага, сата виноват, что система встаёт колом. А в Win95, по этой логике, дисковод был виноват, что система стояла колом при форматировании дискетки?

Не знаю, что вы там делали со своей Win95, у меня форматирование дискетки происходило прозрачно для запущенных приложений: как-будто ничего и не происходило. И чисто DOS-программы под Win95-98 выполнялись ПАРАЛЛЕЛЬНО, в отличие от WinNT4, где приходилось переключать окна, чтобы хоть как-то активизировать выполнение DOS-сессии.

Причина всегда одна и та же - криворукость ッ

Ну и как тебе помогло знание этого факта? ;) Все заработало вдруг?

У всех системы разные — у кого Intel, у кого AMD, а баг проявляется. Может дело в типе памяти и/или в интегрированном контроллёре? DDR1 — проблем вроде как нет; DDR2 (Athlon X2 5600+ с интегрированным контроллёром) — есть проблема; DDR3 (чипсеты AMD 785G, Intel P67) — есть проблема.

> отъедает 8ГБ НЖМД

ОЗУ - 4ГБ, раздел подкачки - 10ГБ.

открывать PDFки с овер300 страниц в GIMPе и скриптами в PNG переводить, сохраняя все картинки с 300 DPI.

>Способ с созданием tmpfs, равного по размеру физическому ОЗУ, и заполнение его файлами в отсутствие свопа

А это точно 12309? Визуально в такой сиутации систему убивает kswapd, тем более что записи на диск не происходит

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

echo 32 >/sys/block/sda/queue/nr_requests

echo 2 >/proc/sys/vm/overcommit_memory
echo 100 >/proc/sys/vm/overcommit_ratio

##echo 0 >/proc/sys/vm/dirty_ratio
##echo 0 >/proc/sys/vm/dirty_background_ratio
##echo 999999999 >/proc/sys/vm/vfs_cache_pressure