LINUX.ORG.RU

Зависание (swap, нагрузка на HDD) при ОЗУ 80%+

 , , ,


1

2

Как только ОЗУ заполняется на 80% - сразу начинается swap, всё виснет. Иногда, если повезет, то мышь еле-еле перемещается. Происходит нагрузка на HDD. Подобная проблема поднималась много раз, но решения я не смог найти.

> $ cat /proc/sys/vm/swappiness
> 0

Это не помогло, всё равно начинает напрягать HDD с 80% ОЗУ

Отключение swap не помогает

> $ sudo swapoff -a

Удалось выяснить, что какой-то процесс find начинает насиловать диск и очень долго и беспощадно.

http://joxi.ru/-djRU4wyTJBUNkHVARo

Остальные процессы, типа Firefox или даже Skype тоже начинают активно юзать HDD, но не так грубо.

OS XUbuntu HDD старенький 5200 об.м. Озу 4 гига

Вопросы:

1) Как заставить юзать 100% ОЗУ? До 90 почти ни когда не доходило. Если набирается 87 (во время «набора» - всё весит), то всё, алес, только hardreset, жалко диск так насиловать.

2) Что за процесс FIND и зачем он объявляется?

3) Может можно как-то запретить swap вообще? Раньше и 512 МБ хватало. А теперь - чем больше даём, тем больше просит.


хм... вчера наблюдал подобную проблему, как только начинается лютая нагрузка на HDD - всё начинает тормозить, а при нехватке ОЗУ - вплоть до полного отказа работоспособности системы.
Меня одно интересует: как ты определил, что запускается «некий find»?

Озу 4 гига

аналогично, 4гб ОЗУ. 21 век, слюнтяи-программисты совсем зажрались, ресурсы разучились экономить

Может можно как-то запретить swap вообще?

Можно: закомментируй swap в fstab. Но толку от этого нет.

Чувствую, это наследие бага 12309, который в 2014 не могут никак починить.

reprimand ★★★★★
()
Ответ на: комментарий от BaN

Timing buffered disk reads: 30 MB in 3.06 seconds = 9.82 MB/sec

Как-то некрасиво. Может быть разделы не выровнены на диске с секторами размером 4 KБ?

greenman ★★★★★
()

Если нет желания влезать в работу vm в ядре, то остается только пробовать разные версии. У меня когда-то тоже было подобное при записи на медленный usb hdd большого файла. Сейчас в 3.14.14 не замечаю ничего такого. Параметры в /proc/sys/vm не менял.

Даже если в других ядрах нет нужных патчей или сторнних модулей, можно хотя бы провести тест, забить ram и запустить тот find.

amaora ★★
()
Ответ на: комментарий от erzent

мин 4 терминала

не показатель

и репликация mysql с багтрэкинга
у меня сейчас среднее потребление оперативы 8,7 гб

я надеюсь, что ты не делаешь репликации беспрерывно?

reprimand ★★★★★
()
Ответ на: комментарий от amaora

Если нет желания влезать в работу vm в ядре, то остается только пробовать разные версии.

либо дружно собраться и отписаться в багтрекере под 12309,
ибо задолбало уже. Linux, сколько можно?

reprimand ★★★★★
()
Ответ на: комментарий от reprimand

Меня одно интересует: как ты определил, что запускается «некий find»?

я успел запустить iotop Но это всё же разовая выходка была вроде.

Можно: закомментируй swap в fstab. Но толку от этого нет.

Да, не помогало

Даже zram не помог

BaN
() автор топика
Ответ на: комментарий от greenman

ХЗ. Вот это я точно не знаю. Разбивал даааавно, ещё на винде. Винду снес и форматнул системный раздел под линукс (swap, корень и home). Ещё два раздела в NTFS.

BaN
() автор топика
Ответ на: комментарий от amaora

и запустить тот find.

Он всё же мне кажется не при чем. Я обычно запускаю мозилу - 30-40%, система 10%, ну так по мелочи ещё - 10%. Это обычно от 40 до 60 %. Полет отличный. Но стоит запустить VB, там отдано 1 гиг...если запуститься тормозами - повезло ненадолго. чуть браузер нагрузишь и «пишите письма». Даже урезал до 768, чуть дольше дает поработать, не забивая озу до 80-90%.

Пробовал сегодня утром ставить патченные ядра. Два штуки разных, на обоих не работает VB. Пробовал нагрузить GIMP'ом, закинув с сотню огромных фоток. Подлагивания были и сразу всё сбрасывалось в КЭШ. ОЗУ постоянно до 70-90 доходила и сразу кешилось. Забил папку HOME на 100%, тогда гимп ругнулся, но продолжал тужиться. Пока сам окончательно не завис, а потом и XFCE не утянул.

На старом ядре такой эксперимент с гимпом не проводил. Завтра во второй половине дня попробую.

VB мне нужен для Корела. Это моя третья нога :D

BaN
() автор топика

Решено!

Как я выше писал: пробовал ставить готовые ядра pf, но виртуалка на них не запускалась. А попытки загрузить ОЗУ на ядре с pf через GIMP показали необычные для меня результаты.

Я так же попробовал на обычном ядре загрузить ОЗУ через GIMP. Это получилось очень быстро. Сначала лаги и висячий GIMP (интерфейс его вообще не отзывался), а через считанные секунды и саму ОСЬ.

Сегодня я поставил только лишь BFQ и BFS. При сборке использовал localmodconfig и дефалтные настройки патча (т.е. эал ентер). Система запустилась прекрасно. VB запустился тоже хорошо. ОЗУ взлетело до 93 % вообще без лагов. Запись на диск пошла не мешая.

Это действительно работает!

Материал который я использовал:

Про патчи: материал 1 (пункт 4) и материал 2

Основной материал HOW-TO: Сборка ядра Linux

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

Всем спасибо за участие, помощь и холивары!

BaN
() автор топика
Ответ на: Решено! от BaN

Увидел один баг, точнее наверное отсутствие патча из убунтувского ядра.

Раньше моск в простое выдавал 0.8 ггц, а теперь всегда держется на 3.5 ггц? а то и гонится почему-то в 3.7 и это уже почти разгон :)

BaN
() автор топика
Ответ на: комментарий от BaN

Это интеловский драйвер так работает. Все ок.

roman77 ★★★★★
()
17 ноября 2014 г.

Решил потестить, что же работает быстрее в JS - insertAdjacentHTML или documentFragment. Зашел для тестов на сервим jsperf.com и убил свою ОЗУ при первом тесте.

Для тех, кто уверн, что его ОЗУ в 640 кб 32 гига хватит на всё или смеётся в лицо багу 12309, то welcome под FireFox'ом http://jsperf.com/kill-you-ram-in-firefox (не забудте нажать RUN TEST)

Патченное ядро не помогло - система заскулила и повисла.

BaN
() автор топика

память проверил memtest'ом?

HDD старенький 5200 об.м.

и его тоже проверь.

Ну и, как не странно, блок питания.

emulek
()
Ответ на: комментарий от BaN

По твоей логике пока получается купить SSD и убить его за месяц.

вернёшь по гарантии.

И только на винты и работать.

ты слишком богатый, раз покупаешь дешёвые HDD на барахолке. И не слишком умный.

emulek
()
Ответ на: комментарий от erzent

нельзя, 4 гб озу сейчас это только на браузер

$ free -m
             total       used       free     shared    buffers     cached
Mem:           986        956         29          0        102        538
-/+ buffers/cache:        315        670
Swap:          121          0        121

пишу тебе сейчас ответ из FireFox, открыты и другие вкладки. Брат жив.

emulek
()
Ответ на: комментарий от MiniRoboDancer

Пожалуй, надо ограничить максимальный занимаемый объём оперативы. Как — самому интересно.

Hint: иногда закрывай вкладки в браузере, когда их больше 200.

emulek
()
Ответ на: комментарий от BaN

У меня же, честно при честно, начинается своп при 80-90%

это нормально. Если тебе _действительно_ необходимо столько памяти, то иди в магазин за новой. При 80..90% всю жизнь плохо работало, ещё Кнут про это писал. Я вот только не пойму, как ты засрал 4Гб? Мне хватает вполне, и ещё под буфера и кеш остаётся.

emulek
()
Ответ на: комментарий от BaN

Timing buffered disk reads: 30 MB in 3.06 seconds = 9.82 MB/sec

выкинь на помойку этот кусок говна

смотри, сколько у меня:

# hdparm -Tt /dev/sda

/dev/sda:
 Timing cached reads:   1164 MB in  2.00 seconds = 581.89 MB/sec
 Timing buffered disk reads:  48 MB in  3.07 seconds =  15.62 MB/sec

ВНЕЗАПНО: это microSD флешка.

emulek
()
Ответ на: комментарий от emulek

Во-первых, лиса не грузит на старте все вкладки. Во-вторых, он даже не запущена постоянно (а уж тем более в случае нехватки памяти), ибо для «открыть страницу полноценным движком» тундерптицы вполне хватает. Как это решит проблему с отжиранием рамы чем угодно?

MiniRoboDancer ★☆
()
Ответ на: комментарий от emulek

Мне действително необходимо 4 гига памяти. У меня и стоит 4 гига памяти. А ещё свап на экстренный случай.

Завтра линукс начнет работать плохо с 10-20%, опять бежать в магазин? Я понимаю, что данная проблема не зависит от нас, а зависит от разработчиков. Но посылать в магазин за новой рамой, тоже самое что посылать тебя фиксить. Ни то, ни другое проблемы не решит.

Что касается «как засрал» - я ссылку выше привел. Зайди на неё и ты узнаешь.

BaN
() автор топика
Ответ на: комментарий от anonymous

Что занчит «прибивается»? - ты прибиваешь? - вылетает?

Если второе, то могу предположить, что она 32 битная и ОЗУ у тебя больше, чем разрешено выделять на приложение (как там точно не помню формулировка), но отжирание ОЗУ - это то что и требовалось «доказать» )

BaN
() автор топика
Ответ на: комментарий от emulek

Ты зашел пиписьками помериться?

Мне HDD особо не нужен скоростной, ибо комп перезагружаю только когда он виснет - 1-2 раза в неделю. Скорость запуска остальных приложений, которые запускаются также при старте - вполне хватает. Именно для этого я и покупал скорострое ОЗУ, чтобы всё крутилось в памяти и поэтому свап при 70-90% меня не устраивает.

BaN
() автор топика

Порекламирую zswap. Специально для тестирования поставил хромиум и открыл овердофига вкладок. При съеденных 6 гигах памяти ноутбук ведёт себя вполне отзывчиво, и это при 4х гигах реальной оперативы. На некоторых железках ещё zram помогал, но на данном ноуте никакой разницы в отзывчивости не заметил.

anonymous
()
Ответ на: комментарий от BaN

Что занчит «прибивается»? - ты прибиваешь? - вылетает?

Ну "(firefox), uid 1001, was killed: out of swap space" в dmesg как бы намекает, что не я сам и не «оно само» ;).

Прогнал тест еще пару раз - система (8ГБ ОЗУ, своп отключен) не подвисает, никаких лагов и зависаний, т.е mpsyt играет, пара дюжин вкладок в мидори висят, оффтопик в VirtualBoxe крутится (про qtcreator с кухонным комбайном емаксом вообще молчу). Если не смотреть в топ, то и не заметишь сходу, что лис, зараза, все доступное ОЗУ сожрал (т.е кэши тоже, хотя на SSD это и не критично) и «пропал».

но отжирание ОЗУ - это то что и требовалось «доказать»

Отжирать ОЗУ, чуть менее чем полностю, может все что угодно - иначе зачем оно (ОЗУ) вообще нужно? ;) А вот

система заскулила и повисла.

это да, это не норма.

anonymous
()

вот так же мучаюсь с kubuntu+google chrome, в ноуте ssd и 4гб ram, право встроенный видак забирает 1гб. Но после того как сжирается 2.5гб оперативки все встаёт /

Думаю доставить 8гб или хотя бы 4.

ggrn ★★★★★
()
Ответ на: комментарий от MiniRoboDancer

Во-первых, лиса не грузит на старте все вкладки. Во-вторых, он даже не запущена постоянно (а уж тем более в случае нехватки памяти), ибо для «открыть страницу полноценным движком» тундерптицы вполне хватает. Как это решит проблему с отжиранием рамы чем угодно?

тут два решения:

1. идти в магазин за памятью

2. экономить память, закрывая не нужные вкладки и т.п.

Третьего не дано.

С чем ты не согласен?

emulek
()
Ответ на: комментарий от BaN

Мне действително необходимо 4 гига памяти. У меня и стоит 4 гига памяти. А ещё свап на экстренный случай.

мне тоже. Хотя и не всегда. Я вполне комфортно работаю даже на своём стареньком нетбуке с 1015Мб.

Завтра линукс начнет работать плохо

дело не в линуксе. Дело в говносайтах с говножабоскриптами. Ну и ещё в говножабоприложениях. А сам по себе Linux до сих пор отлично работает и на 512Мб, я проверял недавно. Т.е. последние кеды с последним ядром работают без проблем и тормозов, но стоит запустить огнелис(а тем паче хромой), и зайти на какой-нить говносайт, и всё, ППЦ, система вязнет в свопе, а если его нет, то просто падает нахер.

Я понимаю, что данная проблема не зависит от нас, а зависит от разработчиков.

а что «разработчики»? Говносайты тестируются с 4..8ю гигами, вот и получаем, то говно, что есть. Сам по себе браузер есть крохи, и даже с ЛОРом тоже немного (1024Мб хватает за глаза).

emulek
()
Ответ на: комментарий от BaN

Ты зашел пиписьками помериться?

нет. Просто у меня для тебя плохие новости: что-то у тебя с системой не так. Твой HDD работает _очень_ _плохо_, хуже, чем даже MicroSD флеш-карта. Я не знаю, с чем это связано. Может и не в диске дело.

emulek
()
Ответ на: комментарий от emulek

Сам по себе браузер есть крохи, и даже с ЛОРом тоже немного

Ну, не совсем - в вебките/хромом (за лиса не скажу, не интересовался) есть свои велосипеды с тем же кешем (причем не просто хттп, а именно сам рендеринг страницы, что соответсвенно жрет память десятками и сотнями МБ):

https://www.webkit.org/blog/427/webkit-page-cache-i-the-basics/ http://comments.gmane.org/gmane.os.opendarwin.webkit.user/3809

There is no global memory limit for WebKit. Most caches have their own limits, usually defined experimentally.

The general strategy regarding memory is to use the RAM as needed to maximize the runtime performance.

When memory is exhausted, a memory pressure handler try to free as much memory as possible (look for memoryPressure/lowMemory in the source).

The way the memory pressure handler is invoked depends on the system. On OS X/iOS, it is a system notification sent to the app by the system.

Unfortunately, most of the memory used by Web Browser is indirectly created by the content. As a result, it is not bounded, and it cannot be reclaimed on memory pressure.

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

И вообще - движки в первую очередь заточены под «нормального» (возможно только в представлении разработчиков или маркетологов) пользователя т.е - запущен только браузер (ну может еще скайп) и в нем открыты 2-4 вкладки, все.

anonymous
()
Ответ на: комментарий от anonymous

с этим я вынужден согласится. Однако, последняя лиса с ~20 вкладками (в т.ч. гугл, а он сейчас довольно тяжёлый) вполне влезает в гигабайт, и своп не юзает.

emulek
()
Ответ на: комментарий от MiniRoboDancer

С чем ты не согласен?

С тем, что причиной рамопроблем всегда является браузер.

конечно кривые руки пользователя никто не отменял.

Кроме того, многие OS(и Linux тоже) делают в расчёте на «типичный компьютер». А это на сегодня 4Гб или больше.

Т.ч. любителям дефолта имеет смысл покупать хотя-бы 8Гб, в расчёте на ближайшее будущее.

emulek
()
Ответ на: комментарий от BaN

Для тех, кто уверн, что его ОЗУ в 640 кб 32 гига хватит на всё или смеётся в лицо багу 12309, то welcome под FireFox'ом http://jsperf.com/kill-you-ram-in-firefox (не забудте нажать RUN TEST)

Мне и 1015Мб хватает. ФФ пожрал 700+ памяти, конец немного предсказуем: его убили.

Отчёт прилагается:

Nov 19 01:50:56 amilo kernel: [22941.330271] firefox invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
Nov 19 01:50:59 amilo kernel: [22941.330297] CPU: 1 PID: 7816 Comm: firefox Not tainted 3.14.17-smp #2
Nov 19 01:50:59 amilo kernel: [22941.330302] Hardware name: FUJITSU SIEMENS AMILO Ui 3520/CW0A0___, BIOS 1.0D-1585-0018 10/08/2008
Nov 19 01:50:59 amilo kernel: [22941.330308]  00000000 00000000 e9b91c5c c1b040c1 f5721f20 e9b91cb4 c1aff5f7 c1cc17e4
Nov 19 01:50:59 amilo kernel: [22941.330326]  f57221e0 000201da 00000000 00000000 00200046 00000000 0000003b 00000000
Nov 19 01:50:59 amilo kernel: [22941.330340]  e9b91c90 c1049025 00200206 e9b91cb4 c1571d9e 000201da 00000000 00000000
Nov 19 01:50:59 amilo kernel: [22941.330355] Call Trace:
Nov 19 01:50:59 amilo kernel: [22941.330375]  [<c1b040c1>] dump_stack+0x41/0x52
Nov 19 01:50:59 amilo kernel: [22941.330388]  [<c1aff5f7>] dump_header+0x73/0x1bf
Nov 19 01:50:59 amilo kernel: [22941.330401]  [<c1049025>] ? irq_exit+0x45/0xa0
Nov 19 01:50:59 amilo kernel: [22941.330412]  [<c1571d9e>] ? ___ratelimit+0x6e/0xd0
Nov 19 01:50:59 amilo kernel: [22941.330423]  [<c10f627c>] oom_kill_process+0x19c/0x2e0
Nov 19 01:50:59 amilo kernel: [22941.330436]  [<c150d34c>] ? security_capable_noaudit+0x1c/0x30
Nov 19 01:50:59 amilo kernel: [22941.330446]  [<c10f6988>] out_of_memory+0x428/0x470
Nov 19 01:50:59 amilo kernel: [22941.330458]  [<c10fb7be>] __alloc_pages_nodemask+0x89e/0x960
Nov 19 01:50:59 amilo kernel: [22941.330472]  [<c112c17f>] alloc_pages_current+0x8f/0x130
Nov 19 01:50:59 amilo kernel: [22941.330481]  [<c10f30df>] __page_cache_alloc+0x7f/0xa0
Nov 19 01:50:59 amilo kernel: [22941.330489]  [<c10f4ab0>] filemap_fault+0x170/0x3c0
Nov 19 01:50:59 amilo kernel: [22941.330499]  [<c1115c3a>] __do_fault+0x6a/0x4c0
Nov 19 01:50:59 amilo kernel: [22941.330509]  [<c1119074>] handle_mm_fault+0x284/0xc90
Nov 19 01:50:59 amilo kernel: [22941.330518]  [<c1573f80>] ? timerqueue_add+0x50/0xb0
Nov 19 01:50:59 amilo kernel: [22941.330530]  [<c10a03a5>] ? clockevents_program_event+0x95/0x130
Nov 19 01:50:59 amilo kernel: [22941.330539]  [<c10360c2>] __do_page_fault+0x142/0x420
Nov 19 01:50:59 amilo kernel: [22941.330551]  [<c10363b0>] ? vmalloc_sync_all+0x10/0x10
Nov 19 01:50:59 amilo kernel: [22941.330561]  [<c10363bb>] do_page_fault+0xb/0x10
Nov 19 01:50:59 amilo kernel: [22941.330596]  [<c1b0cfc3>] error_code+0x67/0x6c
Nov 19 01:50:59 amilo kernel: [22941.330603] Mem-Info:
Nov 19 01:50:59 amilo kernel: [22941.330609] Node 0 DMA per-cpu:
Nov 19 01:50:59 amilo kernel: [22941.330617] CPU    0: hi:    0, btch:   1 usd:   0
Nov 19 01:50:59 amilo kernel: [22941.330624] CPU    1: hi:    0, btch:   1 usd:   0
Nov 19 01:50:59 amilo kernel: [22941.330629] Node 0 Normal per-cpu:
Nov 19 01:50:59 amilo kernel: [22941.330637] CPU    0: hi:  186, btch:  31 usd:  26
Nov 19 01:50:59 amilo kernel: [22941.330643] CPU    1: hi:  186, btch:  31 usd:   0
Nov 19 01:50:59 amilo kernel: [22941.330648] Node 0 HighMem per-cpu:
Nov 19 01:50:59 amilo kernel: [22941.330656] CPU    0: hi:   42, btch:   7 usd:   6
Nov 19 01:50:59 amilo kernel: [22941.330662] CPU    1: hi:   42, btch:   7 usd:   0
Nov 19 01:50:59 amilo kernel: [22941.330678] active_anon:118547 inactive_anon:118597 isolated_anon:0
Nov 19 01:50:59 amilo kernel: [22941.330678]  active_file:71 inactive_file:83 isolated_file:0
Nov 19 01:50:59 amilo kernel: [22941.330678]  unevictable:0 dirty:1 writeback:29 unstable:0
Nov 19 01:50:59 amilo kernel: [22941.330678]  free:2979 slab_reclaimable:2620 slab_unreclaimable:2703
Nov 19 01:50:59 amilo kernel: [22941.330678]  mapped:1933 shmem:38053 pagetables:1083 bounce:0
Nov 19 01:50:59 amilo kernel: [22941.330678]  free_cma:0
Nov 19 01:50:59 amilo kernel: [22941.330696] Node 0 DMA free:3936kB min:64kB low:80kB high:96kB active_anon:5324kB inactive_anon:5336kB active_file:4kB inactive_file:12kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15992kB managed:15916kB mlocked:0kB dirty:0kB writeback:8kB mapped:44kB shmem:3396kB slab_reclaimable:100kB slab_unreclaimable:220kB kernel_stack:48kB pagetables:64kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:29 all_unreclaimable? yes
Nov 19 01:50:59 amilo kernel: [22941.330716] lowmem_reserve[]: 0 845 969 969
Nov 19 01:50:59 amilo kernel: [22941.330726] Node 0 Normal free:7860kB min:3684kB low:4604kB high:5524kB active_anon:406120kB inactive_anon:406128kB active_file:248kB inactive_file:264kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:894968kB managed:866268kB mlocked:0kB dirty:4kB writeback:100kB mapped:6524kB shmem:131328kB slab_reclaimable:10380kB slab_unreclaimable:10592kB kernel_stack:2688kB pagetables:3640kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
Nov 19 01:50:59 amilo kernel: [22941.330747] lowmem_reserve[]: 0 0 998 998
Nov 19 01:50:59 amilo kernel: [22941.330758] Node 0 HighMem free:120kB min:128kB low:264kB high:400kB active_anon:62744kB inactive_anon:62924kB active_file:32kB inactive_file:56kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:127816kB managed:127816kB mlocked:0kB dirty:0kB writeback:8kB mapped:1164kB shmem:17488kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:628kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
Nov 19 01:50:59 amilo kernel: [22941.330776] lowmem_reserve[]: 0 0 0 0
Nov 19 01:50:59 amilo kernel: [22941.330786] Node 0 DMA: 0*4kB 0*8kB 4*16kB (R) 3*32kB (R) 1*64kB (R) 1*128kB (R) 0*256kB 1*512kB (R) 1*1024kB (R) 1*2048kB (R) 0*4096kB = 3936kB
Nov 19 01:50:59 amilo kernel: [22941.330826] Node 0 Normal: 971*4kB (UEM) 4*8kB (M) 3*16kB (MR) 1*32kB (R) 0*64kB 0*128kB 1*256kB (R) 1*512kB (R) 1*1024kB (R) 1*2048kB (R) 0*4096kB = 7836kB
Nov 19 01:50:59 amilo kernel: [22941.330864] Node 0 HighMem: 1*4kB (E) 9*8kB (E) 3*16kB (M) 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 124kB
Nov 19 01:50:59 amilo kernel: [22941.330894] 38667 total pagecache pages
Nov 19 01:50:59 amilo kernel: [22941.330900] 402 pages in swap cache
Nov 19 01:50:59 amilo kernel: [22941.330906] Swap cache stats: add 32101, delete 31699, find 387/684
Nov 19 01:50:59 amilo kernel: [22941.330910] Free swap  = 0kB
Nov 19 01:50:59 amilo kernel: [22941.330915] Total swap = 124736kB
Nov 19 01:50:59 amilo kernel: [22941.330920] 259694 pages RAM
Nov 19 01:50:59 amilo kernel: [22941.330925] 31954 pages HighMem/MovableOnly
Nov 19 01:50:59 amilo kernel: [22941.330930] 0 pages reserved
Nov 19 01:50:59 amilo kernel: [22941.331708] Out of memory: Kill process 7816 (firefox) score 675 or sacrifice child
Nov 19 01:50:59 amilo kernel: [22941.331727] Killed process 7816 (firefox) total-vm:1246416kB, anon-rss:765108kB, file-rss:0kB

Да, секунд на 30 оно «зависло» немного, в самом конце. Потом проблевалось, и работает дальше, как не в чём не бывало.

emulek
()
Ответ на: комментарий от emulek

дефолта

Это ты про жирноDE? и опять мимо.

Кстати, кривизна рук таки явно >>0, ибо с кастомным ядром система стала потреблять мегабайт на 200 меньше при идентичном юзерспейсе — с чего бы это вдруг?

MiniRoboDancer ★☆
()
Ответ на: комментарий от BaN

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

dk-
()
Ответ на: комментарий от reprimand

А у меня так :) Теперь только обычный своппинг

# Contains, as a percentage of total system memory, the number of pages at which
# a process which is generating disk writes will start writing out dirty data.
vm.dirty_ratio = 3

# Contains, as a percentage of total system memory, the number of pages at which
# the background kernel flusher threads will start writing out dirty data.
vm.dirty_background_ratio = 2
Deleted
()
Ответ на: комментарий от MiniRoboDancer

Это ты про жирноDE? и опять мимо.

ты про что?

Кстати, кривизна рук таки явно >>0, ибо с кастомным ядром система стала потреблять мегабайт на 200 меньше при идентичном юзерспейсе — с чего бы это вдруг?

на самом деле, если «на 200Мб меньше», то это совсем _не_ _хорошо_. Возможно — даже плохо. Зачем тебе эти мегабайты? Солить будешь?

Кстати, у меня система всего 200Мб потребляет, и это вместе с ФФ. А вам, слабо?

Да, ядро ванильное(правда тут 32 бита, ибо говноатом 64 не умеет).

emulek
()
Ответ на: комментарий от emulek

Ну, размеры кэшей в лисе тоже от объема ОЗУ зависят ;)

Вообще, в виртуалках, что лисе, что хрому, 512-768МБ почему-то хватает с запасом. Наверное из-за особой, виртуальной магии.

Кстати, в хроме (как впрочем и в остальном зоопарке браузеров на вебките), несмотря на все ухищрения (и обильный жор памяти, да), переход вперед/назад все равно ощутимо тормозит - в отличии от лисы.

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

anonymous
()
Ответ на: комментарий от anonymous

переход вперед/назад все равно ощутимо тормозит - в отличии от лисы.

Нет, тут уж анонимус врет. Хромиум вообще не тормозит, поэтому частенько ставлю его на нетбуки

Deleted
()
Ответ на: комментарий от emulek

Кстати, у меня система всего 200Мб потребляет, и это вместе с ФФ. А вам, слабо?

Вместе с браузером будет 400, если конечно у тебя не опенбокс вместо кед.

Deleted
()
Ответ на: комментарий от emulek

ты про что?

А что ты ещё подразумеваешь под дефолтом?

Зачем тебе эти мегабайты? Солить будешь?

Ну лишняя сотня мегабайт на дороге не валяется. А две — так вообще песня. Можно одной-двумя софтинами больше запускать, например.

Кстати, у меня система всего 200Мб потребляет, и это вместе с ФФ

Голое ядро, иксы, коробка и браузер? Возможно. Но зачем так жить?

32 бита

Ну тады тем более. Я возможностями процессора ради потребления памяти жертвовать не собираюсь, ибо он ещё слабее — бразос. И вроде ж для планшетов разрабатывался, а чудес энергосбережения особых не даёт — ватт-два потребляет.

MiniRoboDancer ★☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.