Утекает память

["Артём Н."]

Почему-то система использует 15 Гб памяти.

root@dana:~# free
total used free shared buffers cached
Mem: 19G 15G 4,5G 328M 931M 8,8G
-/+ buffers/cache: 5,4G 14G
Swap: 29G 0B 29G

После убийства процессов, требовательных к памяти (firefox, chromium, icedove), остаются использованными 14-10 Гб.
Куда она утекает? Под какой-нибудь кэш?
Как это понять?
Проблема в том, что hibernate, при таком использовании сбоит.

root@dana:~# for i in $(mount|grep tmp|cut -f3 -d' '); do df $i; done
Файловая система Тип Размер Использовано Дост Использовано% Cмонтировано в
udev devtmpfs 10M 0 10M 0% /dev
Файловая система Тип Размер Использовано Дост Использовано% Cмонтировано в
tmpfs tmpfs 4,0G 11M 4,0G 1% /run
Файловая система Тип Размер Использовано Дост Использовано% Cмонтировано в
tmpfs tmpfs 9,8G 2,5M 9,8G 1% /dev/shm
Файловая система Тип Размер Использовано Дост Использовано% Cмонтировано в
tmpfs tmpfs 5,0M 8,0K 5,0M 1% /run/lock
Файловая система Тип Размер Использовано Дост Использовано% Cмонтировано в
tmpfs tmpfs 9,8G 0 9,8G 0% /sys/fs/cgroup
Файловая система Тип Размер Использовано Дост Использовано% Cмонтировано в
tmpfs tmpfs 9,8G 524K 9,8G 1% /tmp
Файловая система Тип Размер Использовано Дост Использовано% Cмонтировано в
tmpfs tmpfs 2,0G 8,0K 2,0G 1% /run/user/1000
...

KiB Mem: 20516700 total, 15767592 used, 4749108 free, 953720 buffers
KiB Swap: 31264596 total, 0 used, 31264596 free. 9188968 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
23207 artiom 20 0 1288736 514472 86708 S 6,5 2,5 1:33.34 firefox
22312 artiom 20 0 875040 325572 78016 S 0,0 1,6 0:08.76 icedove
10634 artiom 20 0 3457612 260240 89112 S 0,0 1,3 2:46.30 kwin
10643 artiom 20 0 3848900 230240 96120 S 0,0 1,1 3:17.86 plasma-desktop
10644 artiom 20 0 1705204 153260 85784 S 0,0 0,7 0:04.85 krunner
12416 artiom 20 0 649636 147952 56164 S 0,0 0,7 0:01.80 okular
12414 artiom 20 0 632840 145124 54504 S 0,0 0,7 0:02.06 okular
12391 artiom 20 0 621124 144152 54452 S 0,0 0,7 0:04.17 okular
2147 root 20 0 538188 143328 93620 S 6,5 0,7 10:20.30 Xorg
12405 artiom 20 0 652940 140332 56860 S 0,0 0,7 0:03.14 okular
12387 artiom 20 0 616188 137692 54480 S 0,0 0,7 0:01.68 okular
12402 artiom 20 0 649284 137128 56416 S 0,0 0,7 0:02.31 okular
12403 artiom 20 0 650740 136324 56416 S 0,0 0,7 0:02.32 okular
12377 artiom 20 0 614464 136136 54508 S 0,0 0,7 0:02.18 okular


--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/55B6750F...@yandex.ru

[Max Dmitrichenko]

в последней колонке cached  8,8G

--

--
With best regards
  Max Dmitrichenko

[dimas]

навскидку - что за куча okular'ов? сколько их там еще?

Archive: https://lists.debian.org/20150727213...@Ulf.tvoe.tv

["Артём Н."]

On 27.07.2015 21:51, Tim Sattarov wrote:

> On 2015-07-27 14:38, Max Dmitrichenko wrote:
>> в последней колонке cached 8,8G
>>

> Это был мой первый ответ.
> но потом я посмотрел на вывод своего free:
>
И..?

> # free -h
> total used free shared buff/cache
> available
> Mem: 15G 899M 2.7G 24M
> 11G 14G
> Swap: 15G 0B 15G
>
> может потому что free поновее ...
>
> # dpkg -S `which free`
> procps: /usr/bin/free
>
> ii procps
> 2:3.3.10-2 amd64

>
>


--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55B68949...@yandex.ru

["Артём Н."]

On 27.07.2015 21:38, Max Dmitrichenko wrote:
> в последней колонке cached 8,8G
>

Ну, так подо что cached?

> 2015-07-27 21:14 GMT+03:00 "Артём Н." <arti...@yandex.ru <mailto:arti...@yandex.ru>>:

>
> Почему-то система использует 15 Гб памяти.
>
> root@dana:~# free
> total used free shared buffers cached
> Mem: 19G 15G 4,5G 328M 931M 8,8G

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55B68974...@yandex.ru

["Артём Н."]

> навскидку - что за куча okular'ов? сколько их там еще?

Книжки недочитанные. Около 15. После убийства освобождается 1.5-2 Гб, которые я посчитал.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55B688C3...@yandex.ru

["Артём Н."]

On 27.07.2015 21:44, Tim Sattarov wrote:
> ps axo %mem,cmd k -%mem | grep -v "0.0"
Ничего криминального. От силы 15% наберётся, а это около 3 Гб. Собственно, прибив всё столько же (ну чуть больше/меньше) и
освобождается, а 10 Гб остаются заняты.

%MEM CMD=
2.6 /usr/lib/firefox/firefox
1.8 /usr/bin/icedove
1.2 /usr/bin/plasma-desktop
0.9 /opt/staruml/StarUML --type=renderer --no-sandbox --lang=en-US --lang=en-US --log-severity=disable
--disable-accelerated-2d-canvas --disable-accelerated-video-decode --channel=15298.0.114383386
0.9 java -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:InitiatingHeapOccupancyPercent=25 -Xmx2048m -Xverify:none
-Dsun.io.useCanonCaches=false -jar /usr/share/smartgit/lib/bootloader.jar
0.7 /usr/bin/X :0 vt7 -br -nolisten tcp -auth /var/run/xauth/A:0-vKvjfb
0.7 /usr/bin/krunner
0.5 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=mysql
--log-error=/var/log/mysql/error.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --port=3306

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55B68A47...@yandex.ru

[Mikhail A Antonov]

27.07.2015 22:41, "Артём Н." пишет:

> On 27.07.2015 21:38, Max Dmitrichenko wrote:
>> в последней колонке cached 8,8G
>>
> Ну, так подо что cached?

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

>
>> 2015-07-27 21:14 GMT+03:00 "Артём Н." <arti...@yandex.ru
>> <mailto:arti...@yandex.ru>>:
>>
>> Почему-то система использует 15 Гб памяти.
>>
>> root@dana:~# free
>> total used free shared buffers cached
>> Mem: 19G 15G 4,5G 328M 931M 8,8G
>
>

--
Best regards,
Mikhail
-
WWW: http://www.antmix.ru/
XMPP: ant...@stopicq.ru

[Ста Деюс]

Здравствуйте, Артём.


В Mon, 27 Jul 2015 21:14:39 +0300 вы писали:

> После убийства процессов, требовательных к памяти (firefox, chromium,
> icedove), остаются использованными 14-10 Гб. Куда она утекает? Под
> какой-нибудь кэш? Как это понять?
> Проблема в том, что hibernate, при таком использовании сбоит.

Из того, что вы привели, не видно, чтобы ОЗУ куда-то «утекало». ОС
использует ОЗУ про запас -- что нормально.

А проблемы со «спячкой» -- вероятно, лежат в ином. -- Посмотрите журналы
в /var/log: кажется, свитки (files) с «pm-» называются. Ну, или syslog
и проч.


Всего доброго, Ста.


Справка к моим сокращениям
--
б/т - будет
к. - кои, коий и т.п.
кол-во - количество
м/о - можно
н/о - нужно
ОЗУ - Оперативное запоминающее ус-во
ОС - Операционная система
т.д. - так далее
т.е. - то есть
ус-во - устройство

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/20150728131319.6ba2db26@STNset

["Артём Н."]

>> Ну, так подо что cached?
> Дисковый кеш, библиотеки, сетевые буферы и прочее.
> Если коротко - не мешай системе работать. Как только эта память потребуется для
> реального приложения - она будет доступна.
>

Да, я увидел это по ссылке. Но don't worry не получается.
Проблема не в выводе free, а в том, что при таком использовании памяти, умирает hibernate.

Если коротко: мне надо выяснить какие кэши и ограничить их использование, например, лимиты через sysctl выставить.
Как понять подо что уходит память?

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55B8618...@yandex.ru

["Артём Н."]

> http://www.linuxatemyram.com/
"You can't disable disk caching. The only reason anyone ever wants to disable disk caching is because they think it takes memory
away from their applications, which it doesn't! You can't disable disk caching. The only reason anyone ever wants to disable disk
caching is because they think it takes memory away from their applications, which it doesn't! "

А подкорректировать лимит по памяти я могу? Надо смотреть в Documentation/vfs?

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55B86565...@yandex.ru

["Артём Н."]

Да, забыл сказать.
Последнее время я использую не pm-hibernate, а пункт меню "Спящий режим" в KDE.
В логи, вероятно, при этом ничего не пишется (но проблема уже давно):
-rw-r--r-- 1 root root 0 июн 25 22:44 /var/log/pm-powersave.log
-rw-r--r-- 1 root root 33K июн 24 21:40 /var/log/pm-powersave.log.1
-rw-r--r-- 1 root root 587 май 7 19:32 /var/log/pm-powersave.log.2.gz
-rw-r--r-- 1 root root 555 апр 28 00:04 /var/log/pm-powersave.log.3.gz
-rw-r--r-- 1 root root 1,6K фев 18 23:08 /var/log/pm-powersave.log.4.gz
-rw-r--r-- 1 root root 0 июн 25 22:44 /var/log/pm-suspend.log
-rw-r--r-- 1 root root 51K июн 24 21:40 /var/log/pm-suspend.log.1
-rw-r--r-- 1 root root 2,1K май 7 19:32 /var/log/pm-suspend.log.2.gz
-rw-r--r-- 1 root root 1,9K апр 28 00:05 /var/log/pm-suspend.log.3.gz
-rw-r--r-- 1 root root 6,8K фев 18 23:08 /var/log/pm-suspend.log.4.gz

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55B8684B...@yandex.ru

[Andrey Melnikoff]

"Артём Н." <arti...@yandex.ru> wrote:
> >> Ну, так подо что cached?
> > Дисковый кеш, библиотеки, сетевые буферы и прочее.
> > Если коротко - не мешай системе работать. Как только эта память потребуется для
> > реального приложения - она будет доступна.
> >
> Да, я увидел это по ссылке. Но don't worry не получается.
> Проблема не в выводе free, а в том, что при таком использовании памяти, умирает hibernate.

Если у тебя умирает гибернейт - то надо смотреть хотя-бы в вывод dmesg, от
чего он умирает.

> Если коротко: мне надо выяснить какие кэши и ограничить их использование, например, лимиты через sysctl выставить.
> Как понять подо что уходит память?

Для нужд системы она уходит.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/0c6n8c-...@woofie.cef.spbstu.ru

[aleksey]

29.07.2015 08:24, "Артём Н." пишет:
> Т.е., вы хотите сказать, что перед этим кэш сбрасывается на диск и всё
> ok?
> В любом случае, запись 10 Гб (да, проблемы с hibernate начинаются
> после долгой работы),
> не быстрая процедура. Собственно, мне такого не надо.
Система периодически сбрасывает незаписанные данные из кэша на диск. И я
сильно сомневаюсь, что у вас данные для записи постоянно накапливаются.
Иначе я бы постоянно терял свои данные на своих дисках, т.к. у меня
регулярно случаются проблемы с электропитанием. Так что длительная
запись данных перед выключением вам не грозит.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55B8EDFE.3090406@localhost

[Alexander Sitnik]

29 июля 2015 г., 18:15 пользователь aleksey <li...@mail.ru> написал:

29.07.2015 08:24, "Артём Н." пишет:
> Т.е., вы хотите сказать, что перед этим кэш сбрасывается на диск и всё
> ok?
> В любом случае, запись 10 Гб (да, проблемы с hibernate начинаются
> после долгой работы),
> не быстрая процедура. Собственно, мне такого не надо.
Система периодически сбрасывает незаписанные данные из кэша на диск. И я
сильно сомневаюсь, что у вас данные для записи постоянно накапливаются.
Иначе я бы постоянно терял свои данные на своих дисках, т.к. у меня
регулярно случаются проблемы с электропитанием. Так что длительная
запись данных перед выключением вам не грозит.

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

Для принудительного сброса кеша вполне стандартный способ:

sudo sh -c 'echo 1 > /proc/sys/vm/drop_caches'.

После этого посмотри вывод free и попробуй запустить гибернацию.

--

Alexander Sitnik

["Артём Н."]

Уже игрался. Сильного изменения в выводе free не заметил. Попробую делать перед каждой гибернацией и понаблюдаю картину.

Кстати, вызов sync, как я понимаю, не сбросит дисковый кэш?

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55B90AE...@yandex.ru

["Артём Н."]

Да, сбрасывает.
Долго пишет.

root@danroot@dana:/home# free ; dd if=/dev/zero of=test.dump bs=1024 count=16353480 ; rm -f test.dump

total used free shared buffers cached

Mem: 19G 7,7G 11G 335M 666M 1,3G
-/+ buffers/cache: 5,8G 13G
Swap: 29G 352M 29G
16353480+0 записей получено
16353480+0 записей отправлено
скопировано 16745963520 байт (17 GB), 181,822 c, 92,1 MB/c
удалён «test.dump»
root@dana:/home# free

total used free shared buffers cached

Mem: 19G 6,2G 13G 335M 4,0M 465M
-/+ buffers/cache: 5,7G 13G
Swap: 29G 350M 29G
a:/home# free ; dd if=/dev/zero of=test.dump bs=1024 count=16353480 ; rm -f test.dump

total used free shared buffers cached

Mem: 19G 7,7G 11G 335M 666M 1,3G
-/+ buffers/cache: 5,8G 13G
Swap: 29G 352M 29G
16353480+0 записей получено
16353480+0 записей отправлено
скопировано 16745963520 байт (17 GB), 181,822 c, 92,1 MB/c
удалён «test.dump»
root@dana:/home# free

total used free shared buffers cached

Mem: 19G 6,2G 13G 335M 4,0M 465M
-/+ buffers/cache: 5,7G 13G
Swap: 29G 350M 29G


On 29.07.2015 17:33, Tim Sattarov wrote:

>
>
> On 2015-07-27 15:41, "Артём Н." wrote:
>> On 27.07.2015 21:38, Max Dmitrichenko wrote:
>>> в последней колонке cached 8,8G
>>>
>> Ну, так подо что cached?
>>
>>

> Попробуй вот так:
>
>
> free ; dd if=/dev/zero of=test.dump bs=1024 count=16353480 ; rm -f
> test.dump; free
>
>
> вот что выдает у меня (я немного модифицировал параметры, для удобства
> отображения и заменил dd на dcfldd)
>
>
> ~# free -h ; dcfldd if=/dev/zero of=test.dump bs=1024 count=16353480 ;
> rm -f test.dump; free -h

> total used free shared buff/cache
> available

> Mem: 15G 1.0G 156M 40M
> 14G 14G
> Swap: 15G 0B 15G
> 16353280 blocks (15970Mb) written.
> 16353480+0 records in
> 16353480+0 records out

> total used free shared buff/cache
> available

> Mem: 15G 1.0G 13G 40M
> 1.5G 14G
> Swap: 15G 4K 15G
>
>
> по сути ты создаешь файл размером с память и удаляешь его, это должно
> сбросить буфер и освободить память.
> Как видно выше у меня кэш сбросился с 14 до 1.5 гигабайта и свободная
> память увеличилась с 156М до 13Г.
>
> проверь сбрасываются ли буферы в твоем случае.

>
>
>


--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55B90A8A...@yandex.ru

["Артём Н."]

> Если у тебя умирает гибернейт - то надо смотреть хотя-бы в вывод dmesg, от
> чего он умирает.
>

dmesg ничего не даёт (плюс ещё, он загажен криво настроенным AppArmor).
И он не то, чтобы "умирает": очень долго пытается уснуть, постоянно обращается к диску.
В итоге, я не жду, и выключаю: потом fsck показывает, что ФС немного порушена.

>> Если коротко: мне надо выяснить какие кэши и ограничить их использование, например, лимиты через sysctl выставить.
>> Как понять подо что уходит память?
>
> Для нужд системы она уходит.

Слишком общий ответ: это вы уже писали. Конкретнее.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55B90937...@yandex.ru

["Артём Н."]

Да, это предсказуемо. И настраивают это через параметры vm.dirty_*.
Например, у меня vm.dirty_writeback_centisecs = 1500 (хотя почему-то стояло дефолтное 500),
т.е. каждые пятнадцать секунд, кэш должен сбрасываться на диск.
Но...
Откуда тогда такой долгий hibernate?
Даже, когда занято 10 Гб RAM, они не могу писаться в своп (который на SSD) пять-семь минут.

Archive: https://lists.debian.org/55B90C0...@yandex.ru

["Артём Н."]

> Самое главное - сумма занятой памяти совпадает ? :)
Сложно сказать: много процессов.

> Я бы задумался если нет, попробовал бы проапгрейдить систему ... те же
> util-linux.
> проверить debsums и прочее.
> Подобные данные ввели бы меня в параноидальное состояние и полную
> проверку системы, пока не найду что происходит.
>
Большое потребление памяти прикладными процессами у меня - это нормально.
Одни браузеры занимают кучу памяти, KDE, периодически виртуалки...
На винде на работе тоже firefox жрёт память.

А чтобы меня кто-то порутал - сомнительно (да, я слышал про эпизод с некой hacked team, но там особый случай). :-)
Кроме того, я использую сторонние репозитории и сторонний софт, так что ничто не мешает внедрить туда что-нибудь,
при этом все суммы будут совпадать.

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

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55B91838...@yandex.ru

[Mikhail A Antonov]

29.07.2015 08:15, "Артём Н." пишет:

>>> Ну, так подо что cached?
>> Дисковый кеш, библиотеки, сетевые буферы и прочее.
>> Если коротко - не мешай системе работать. Как только эта память потребуется для
>> реального приложения - она будет доступна.
>>
> Да, я увидел это по ссылке. Но don't worry не получается.
> Проблема не в выводе free, а в том, что при таком использовании памяти,
> умирает hibernate.

У тебя свопа хватает запихнуть всю память? Начни с этого, а не с возни с кешем.

["Артём Н."]

On 29.07.2015 22:19, Mikhail A Antonov wrote:
> 29.07.2015 08:15, "Артём Н." пишет:
>>>> Ну, так подо что cached?
>>> Дисковый кеш, библиотеки, сетевые буферы и прочее.
>>> Если коротко - не мешай системе работать. Как только эта память потребуется для
>>> реального приложения - она будет доступна.
>>>
>> Да, я увидел это по ссылке. Но don't worry не получается.
>> Проблема не в выводе free, а в том, что при таком использовании памяти,
>> умирает hibernate.
> У тебя свопа хватает запихнуть всю память? Начни с этого, а не с возни с кешем.
>
>

32 Гб при размере RAM 20 Гб.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55B932D1...@yandex.ru

[Anatoly Pugachev]

2015-07-29 20:18 GMT+03:00 "Артём Н." <arti...@yandex.ru>:

    29.07.2015 08:24, "Артём Н." пишет:
    > Т.е., вы хотите сказать, что перед этим кэш сбрасывается на диск и всё
    > ok?
    > В любом случае, запись 10 Гб (да, проблемы с hibernate начинаются
    > после долгой работы),
    > не быстрая процедура. Собственно, мне такого не надо.
    Система периодически сбрасывает незаписанные данные из кэша на диск. И я
    сильно сомневаюсь, что у вас данные для записи постоянно накапливаются.
    Иначе я бы постоянно терял свои данные на своих дисках, т.к. у меня
    регулярно случаются проблемы с электропитанием. Так что длительная
    запись данных перед выключением вам не грозит.


Как правильно отметил Алексей, большая часть данных в этом кеше -- уже сброшены на диск, система это делает постоянно.
Для принудительного сброса кеша вполне стандартный способ:
sudo sh -c 'echo 1 > /proc/sys/vm/drop_caches'.
После этого посмотри вывод free и попробуй запустить гибернацию.

Уже игрался. Сильного изменения в выводе free не заметил. Попробую делать перед каждой гибернацией и понаблюдаю картину.

вместо echo 1 , echo 3 пробовали?

[root@nbu7 ~]# free && sync && echo 3 > /proc/sys/vm/drop_caches && free

             total       used       free     shared    buffers     cached

Mem:       4056468    3454004     602464          0     347592    2210568
-/+ buffers/cache:     895844    3160624
Swap:      6160376          0    6160376

             total       used       free     shared    buffers     cached

Mem:       4056468     762484    3293984          0        484      39840
-/+ buffers/cache:     722160    3334308
Swap:      6160376          0    6160376

[Ста Деюс]

В Wed, 29 Jul 2015 08:44:43 +0300 Артём писал:

> Последнее время я использую не pm-hibernate, а пункт меню "Спящий
> режим" в KDE.

Попробуйте из консоли/окна терминала дать команду -- чисто для
сравнения: и по скорости работы и по записям в журналах.

Всего доброго, Ста.


Справка к моим сокращениям
--
б/т - будет
к. - кои, коий и т.п.
кол-во - количество
м/о - можно
н/о - нужно
ОЗУ - Оперативное запоминающее ус-во
ОС - Операционная система
т.д. - так далее
т.е. - то есть
ус-во - устройство

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/20150730195704.7a0e456e@STNset

[Ста Деюс]

Здравствуйте, Артём.


В Wed, 29 Jul 2015 08:24:35 +0300 вы писали:

> Да, пусть не "утекает", а "используется про запас".

Так работает ОС. Конечно, вы можете сие изменить, поиграв параметрами
процессов сброса запасу «pdflush»: /proc/sys/vm/dirty_* .

> > А проблемы со «спячкой» -- вероятно, лежат в ином.

> Т.е., вы хотите сказать, что перед этим кэш сбрасывается на диск и
> всё ok? В любом случае, запись 10 Гб (да, проблемы с hibernate
> начинаются после долгой работы), не быстрая процедура. Собственно,
> мне такого не надо.

Кол-во процессов (чем больше -- значит: больше ожидается на
запись), м/о посмотреть так:

/bin/cat /proc/sys/vm/nr_pdflush_threads

Если ноль -- значит, «В Багдаде всё спокойно.» /«КарМэн»/ :о) -- Т.е.
нет проблем с записью на диск.

> Ошибки есть, но ничего криминального я не нашёл. Приложил логи, на
> всякий случай.

Я не знаю что значат сообщения журналов, но там есть некоторые ошибки,
по к. я бы почитал -- что они значат и/или устранил бы -- попробовать
-- а не ускорит ли это процесс отключения машины.

Всего доброго, Ста.


Справка к моим сокращениям
--
б/т - будет
к. - кои, коий и т.п.
кол-во - количество
м/о - можно
н/о - нужно
ОЗУ - Оперативное запоминающее ус-во
ОС - Операционная система
т.д. - так далее
т.е. - то есть
ус-во - устройство


--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/20150730195422.268c2608@STNset

[Ста Деюс]

В Wed, 29 Jul 2015 20:11:19 +0300 Артём писал:

> dmesg ничего не даёт (плюс ещё, он загажен криво настроенным
> AppArmor). И он не то, чтобы "умирает": очень долго пытается уснуть,
> постоянно обращается к диску. В итоге, я не жду, и выключаю: потом
> fsck показывает, что ФС немного порушена.

Это плохая идея так обращаться с СС (FS)! -- Лучше б/т решить проблемы
со спячкой, или, выключать иначе машину.

> >> Если коротко: мне надо выяснить какие кэши и ограничить их
> >> использование, например, лимиты через sysctl выставить. Как понять
> >> подо что уходит память?
> >
> > Для нужд системы она уходит.
> Слишком общий ответ: это вы уже писали. Конкретнее.

Запас используется с целью повышения скорости обращения к данным путём
остатка их в свободном ОЗУ. -- Там всегда б/т данные, с к. работали
(читали/писали). -- Это не несохранённые данные. С чего вы взяли, что
запас и спячка -- связаны?

Посмотрите на значение поля «wa» программы «top», когда даёте команду
впасть в спячку. -- Если оно около нуля, то у вас нет затыку по работе
с диском.

Всего доброго, Ста.


Справка к моим сокращениям
--
б/т - будет
к. - кои, коий и т.п.
кол-во - количество
м/о - можно
н/о - нужно
ОЗУ - Оперативное запоминающее ус-во
ОС - Операционная система
т.д. - так далее
т.е. - то есть
ус-во - устройство

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/20150730200813.4f1c7314@STNset

[Andrey Melnikoff]

"Артём Н." <arti...@yandex.ru> wrote:
> > Если у тебя умирает гибернейт - то надо смотреть хотя-бы в вывод dmesg, от
> > чего он умирает.
> >
> dmesg ничего не даёт (плюс ещё, он загажен криво настроенным AppArmor).
> И он не то, чтобы "умирает": очень долго пытается уснуть, постоянно обращается к диску.

А как ты шочешь - 19 гигов памяти надо как-то слить на диск. Хочешь быстро -
ставь под своп SSD. Хочешь еще быстрее - велком собирать своё ядро с
tuxonice, тогда будет еще и компрессия при сбросе на диск.

> В итоге, я не жду, и выключаю: потом fsck показывает, что ФС немного порушена.

А зачем выключать? Само выключится, как закончит сбрасывать.

> >> Если коротко: мне надо выяснить какие кэши и ограничить их использование, например, лимиты через sysctl выставить.
> >> Как понять подо что уходит память?
> >
> > Для нужд системы она уходит.
> Слишком общий ответ: это вы уже писали. Конкретнее.

Читать linux\documentation\vm\* - там уж будет одна сплошная конкретика.
Хотя нет, там еще рядом надо читать про cgroups и еще в паре мест.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/jcpp8c-...@woofie.cef.spbstu.ru

[Илья]

Хотелось бы узнать у знатоков : если предположим, swap практически весь "забит", то при входе в ждущий режим, что с ним происходит?

Вопросы автору "топика":
1 Почему вы решили, что проблема связана памятью, какие критерии ?
2 Судя по логам - все успешно сохраняется и просыпается. Я не увидел или нету логов когда не уходит в режим спячки?
3 Для выявления закономерностей, я бы сделал скрипт, который сначала сохранял некую информацию о состояние системы (mem,proc,io, etc) а потом вызывал pm-hibernate.
4 Не в тему, но люди говорят, что kvm и virtualbox криво работают совместно.



С уважением, Илья.

> On 29.07.2015 22:19, Mikhail A Antonov wrote:
>
>> 29.07.2015 08:15, "Артём Н." пишет:
>>

>>> Проблема не в выводе free, а в том, что при таком использовании памяти,
>>> умирает hibernate.
>>
>> У тебя свопа хватает запихнуть всю память? Начни с этого, а не с возни с кешем.
>
> 32 Гб при размере RAM 20 Гб.
>
> --

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/3528143...@web6j.yandex.ru

["Артём Н."]

On 30.07.2015 16:38, Ста Деюс wrote:
> В Wed, 29 Jul 2015 20:11:19 +0300 Артём писал:
>
>> dmesg ничего не даёт (плюс ещё, он загажен криво настроенным
>> AppArmor). И он не то, чтобы "умирает": очень долго пытается уснуть,
>> постоянно обращается к диску. В итоге, я не жду, и выключаю: потом
>> fsck показывает, что ФС немного порушена.
>
> Это плохая идея так обращаться с СС (FS)! -- Лучше б/т решить проблемы
> со спячкой, или, выключать иначе машину.
>

ext4 терпит. Так как иначе? Я начинаю гибернацию, жду, не дожидаюсь, вырубаю: проблема не всегда проявляется, а только при забитой
оперативке.

>>>> Если коротко: мне надо выяснить какие кэши и ограничить их
>>>> использование, например, лимиты через sysctl выставить. Как понять
>>>> подо что уходит память?
>>>
>>> Для нужд системы она уходит.
>> Слишком общий ответ: это вы уже писали. Конкретнее.
>
> Запас используется с целью повышения скорости обращения к данным путём
> остатка их в свободном ОЗУ. -- Там всегда б/т данные, с к. работали
> (читали/писали). -- Это не несохранённые данные. С чего вы взяли, что
> запас и спячка -- связаны?

Потому что перед спячкой содержимое RAM надо скинуть на диск, что, как минимум, занимает время.

> Посмотрите на значение поля «wa» программы «top», когда даёте команду
> впасть в спячку. -- Если оно около нуля, то у вас нет затыку по работе
> с диском.

Так, наверное проблема проявляется при начале записи?

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55BA5E5C...@yandex.ru

["Артём Н."]

On 30.07.2015 17:36, Andrey Melnikoff wrote:
> "Артём Н." <arti...@yandex.ru> wrote:
>>> Если у тебя умирает гибернейт - то надо смотреть хотя-бы в вывод dmesg, от
>>> чего он умирает.
>>>
>> dmesg ничего не даёт (плюс ещё, он загажен криво настроенным AppArmor).
>> И он не то, чтобы "умирает": очень долго пытается уснуть, постоянно обращается к диску.
> А как ты шочешь - 19 гигов памяти надо как-то слить на диск. Хочешь быстро -
> ставь под своп SSD.

Вот в том и проблема, что своп на SSD.

> Хочешь еще быстрее - велком собирать своё ядро с
> tuxonice, тогда будет еще и компрессия при сбросе на диск.

Так вроде и так сжимается, при записи?

>> В итоге, я не жду, и выключаю: потом fsck показывает, что ФС немного порушена.
> А зачем выключать? Само выключится, как закончит сбрасывать.
>

Долго ждать очень.

>>>> Если коротко: мне надо выяснить какие кэши и ограничить их использование, например, лимиты через sysctl выставить.
>>>> Как понять подо что уходит память?
>>>
>>> Для нужд системы она уходит.
>> Слишком общий ответ: это вы уже писали. Конкретнее.
> Читать linux\documentation\vm\* - там уж будет одна сплошная конкретика.
> Хотя нет, там еще рядом надо читать про cgroups и еще в паре мест.

Ok, я как раз собирался пробежаться по описанию этих параметров.
А причём cgroups?

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55BA5EDC...@yandex.ru

["Артём Н."]

> вместо echo 1 , echo 3 пробовали?

Ну да, там по какой-то из ссылок было же. Я от 4-х до 0 попробовал. 3-1 прокатили, но сильного сброса я не заметил (может плохо
смотрел).

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55BA5F7F...@yandex.ru

["Артём Н."]

On 30.07.2015 16:27, Ста Деюс wrote:
> В Wed, 29 Jul 2015 08:44:43 +0300 Артём писал:
>
>> Последнее время я использую не pm-hibernate, а пункт меню "Спящий
>> режим" в KDE.
>
> Попробуйте из консоли/окна терминала дать команду -- чисто для
> сравнения: и по скорости работы и по записям в журналах.

Раньше делал. Но было медленнее, видимо за счёт подцепления хуков.
Сейчас примерно одинаково по времени.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55BA60CB...@yandex.ru

["Артём Н."]

> Кол-во процессов (чем больше -- значит: больше ожидается на
> запись), м/о посмотреть так:
>
> /bin/cat /proc/sys/vm/nr_pdflush_threads
>
> Если ноль -- значит, «В Багдаде всё спокойно.» /«КарМэн»/ :о) -- Т.е.
> нет проблем с записью на диск.

Сейчас 0. Спасибо за наводку. Посмотрю перед следующей спячкой.

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

В основном, это проблемы с ИБП: никак не влияет.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55BA602C...@yandex.ru

["Артём Н."]

On 30.07.2015 20:31, Tim Sattarov wrote:

>
>
> On 2015-07-30 13:26, "Артём Н." wrote:
>> Так, наверное проблема проявляется при начале записи?
>>
>>

> Это из твоих логов hibernate
>
> Ср июн 24 20:09:45 MSK 2015: performing hibernate
> sh: echo: I/O error
> Ср июн 24 20:10:08 MSK 2015: Awake.
>
Thanx, я сразу не заметил. В следующий раз выловлю - посмотрю лог pm-hibernate. Буду через него засыпать, а не через менюшку.

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

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55BA62D1...@yandex.ru

["Артём Н."]

On 30.07.2015 18:23, Илья wrote:
> Хотелось бы узнать у знатоков : если предположим, swap практически весь "забит", то при входе в ждущий режим, что с ним происходит?

Вот, и мне хотелось бы узнать.

> Вопросы автору "топика":
> 1 Почему вы решили, что проблема связана памятью, какие критерии ?

Ну, проблема с hibernation, так или иначе связана с памятью: память большая, она пишется в своп, на что уходит время.
Однако, есть вероятность, что случается отказ, я это не исключаю.

> 2 Судя по логам - все успешно сохраняется и просыпается. Я не увидел или нету логов когда не уходит в режим спячки?

По большей части я производил спячку из меню KDE: он не ведёт логов.

> 3 Для выявления закономерностей, я бы сделал скрипт, который сначала сохранял некую информацию о состояние системы (mem,proc,io, etc) а потом вызывал pm-hibernate.

free+top+cat /proc/sys/vm/dirty_* /proc/sys/vm/nr_pdflush_threads?

> 4 Не в тему, но люди говорят, что kvm и virtualbox криво работают совместно.

Вы про модули? Думаете, может как-то влиять?
А так, virtualbox вообще кривой, в принципе...

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55BA622D...@yandex.ru

[Илья]

>> Это из твоих логов hibernate
>>
>> Ср июн 24 20:09:45 MSK 2015: performing hibernate
>> sh: echo: I/O error
>> Ср июн 24 20:10:08 MSK 2015: Awake.
>
> Thanx, я сразу не заметил. В следующий раз выловлю - посмотрю лог pm-hibernate. Буду через него засыпать, а не через менюшку.
>
>> проверь лог сразу после проблемы, чтобы захватить события которые отображают проблемную ситуацию.

Это sync ругается в /usr/sbin/pm-hibernate:

# run the sleep hooks
log "$(date): Running hooks for $ACTION."
if run_hooks sleep "$ACTION $METHOD"; then
# Sleep only if we know how and if a hook did not inhibit us.
log "$(date): performing $METHOD"
sync
"do_$METHOD" || r=128
log "$(date): Awake."



--
С уважением, Илья.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/2086914...@web15h.yandex.ru

[Илья]

> Три ошибки:
>
> 1) sync не вызывает sh: и echo: ...

Согласен, не прав, я думаю это ругается /usr/lib/pm-utils/pm-functions:
if [ -z "$HIBERNATE_MODULE" ] && \
[ -f /sys/power/disk ] && \
grep -q disk /sys/power/state; then
HIBERNATE_MODULE="kernel"
do_hibernate()
{
[ -n "${HIBERNATE_MODE}" ] && \
grep -qw "${HIBERNATE_MODE}" /sys/power/disk && \
echo -n "${HIBERNATE_MODE}" > /sys/power/disk
echo -n "disk" > /sys/power/state
}
fi

> 2) ответ с неиспользованием In-Reply-To: заголовка (ломается тред)

Мой почтовый клиент (веб морда яндекса ) не позволяет задать данный параметр, если
вы знаете как, то подскажите, буду благодарен. Я писал пару лет назад в яндекс по этому
поводу - они меня культурно послали. Менять клиента не буду - мне так удобнее,
если модератор (кто кстати, где посмотреть?) или большинство сообщества рассылки считает
ломание треда "преступлением", то сожалению, мне придется покинут рассылку.

> 3) ответ напрямую отсылателю письма и в рассылку

Да, облажался :(

> вот правила по которым работают рассылки debian-lists:
> https://www.debian.org/MailingLists/#codeofconduct
> https://wiki.debian.org/DebianMailingLists#Message_Threading_and_Replying

ps Знает ли кто публичные почтовые сервисы с "веб мордой" которые позволяют "правильно
общаться" в рассылке? Ответы можно писать в личку.

--
С уважением, Илья.


--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/19635414...@web7j.yandex.ru

[ivan demakov]

On Wednesday, July 29, 2015 20:11:19 Артём Н. wrote:
> > Если у тебя умирает гибернейт - то надо смотреть хотя-бы в вывод dmesg, от
> > чего он умирает.
>
> dmesg ничего не даёт (плюс ещё, он загажен криво настроенным AppArmor).
> И он не то, чтобы "умирает": очень долго пытается уснуть, постоянно
> обращается к диску. В итоге, я не жду, и выключаю: потом fsck показывает,
> что ФС немного порушена.

Диск проверте. Похоже на последжнем издыхании.

> > Для нужд системы она уходит.
>
> Слишком общий ответ: это вы уже писали. Конкретнее.

Читайте исходники системы. Никто вам конкретнее не скажет.

--
ivan

["Артём Н."]

On 31.07.2015 12:16, Илья wrote:
>> Три ошибки:
>>
>> 1) sync не вызывает sh: и echo: ...
>
> Согласен, не прав, я думаю это ругается /usr/lib/pm-utils/pm-functions:
> if [ -z "$HIBERNATE_MODULE" ] && \
> [ -f /sys/power/disk ] && \
> grep -q disk /sys/power/state; then
> HIBERNATE_MODULE="kernel"
> do_hibernate()
> {
> [ -n "${HIBERNATE_MODE}" ] && \
> grep -qw "${HIBERNATE_MODE}" /sys/power/disk && \
> echo -n "${HIBERNATE_MODE}" > /sys/power/disk
> echo -n "disk" > /sys/power/state
> }
> fi

При выборе режима сна? С чего бы?

> Мой почтовый клиент (веб морда яндекса ) не позволяет задать данный параметр, если
> вы знаете как, то подскажите, буду благодарен. Я писал пару лет назад в яндекс по этому
> поводу - они меня культурно послали. Менять клиента не буду - мне так удобнее,
> если модератор (кто кстати, где посмотреть?) или большинство сообщества рассылки считает
> ломание треда "преступлением", то сожалению, мне придется покинут рассылку.

> ps Знает ли кто публичные почтовые сервисы с "веб мордой" которые позволяют "правильно
> общаться" в рассылке? Ответы можно писать в личку.
>

gmail?
Но я бы подумал насчёт смены клиента: локальный реально удобнее.
И безопаснее.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55BE2BF...@yandex.ru

["Артём Н."]

On 01.08.2015 06:16, ivan demakov wrote:
> On Wednesday, July 29, 2015 20:11:19 Артём Н. wrote:
>>> Если у тебя умирает гибернейт - то надо смотреть хотя-бы в вывод dmesg, от
>>> чего он умирает.
>>
>> dmesg ничего не даёт (плюс ещё, он загажен криво настроенным AppArmor).
>> И он не то, чтобы "умирает": очень долго пытается уснуть, постоянно
>> обращается к диску. В итоге, я не жду, и выключаю: потом fsck показывает,
>> что ФС немного порушена.
>
> Диск проверте. Похоже на последжнем издыхании.

Да нет, он не старый (то, на котором ФС). Просто не всё успевает записаться. А так с диском всё более ли менее.

>
>
>>> Для нужд системы она уходит.
>>
>> Слишком общий ответ: это вы уже писали. Конкретнее.
>
> Читайте исходники системы. Никто вам конкретнее не скажет.
>

Смешно. Для того, чтобы узнать под какие буфера распределяется память, не обязательно обращаться к исходникам.
На это есть документация (весь вопрос в том, что читать).
Впрочем, не будем разводить флейм. Этот ответ ещё более общий и бесполезный.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55BE2D22...@yandex.ru

[Aleksandr Sytar]

2 августа 2015 г., 17:45 пользователь "Артём Н." <arti...@yandex.ru> написал:

Смешно. Для того, чтобы узнать под какие буфера распределяется память, не обязательно обращаться к исходникам.
На это есть документация (весь вопрос в том, что читать).
Впрочем, не будем разводить флейм. Этот ответ ещё более общий и бесполезный.

Если  ядро собрано с поддержкой slab/slub - то кто конкретно держит память можно посмотреть через cat /proc/slabinfo Теоретически там не должно быть записей относительно процессов которые уже выгружены.

[Илья]

>> я думаю это ругается /usr/lib/pm-utils/pm-functions:

> При выборе режима сна? С чего бы?

К долгому сохранению (кстати, сколько по времени не могли дождаться и прерывали?) это возможно не относится, эта ошибка о том, что не смог "уснуть" .
Я смог вызвать эту ошибку двумя способами (выдает именно это сообщение sh: echo: I/O error):

1) swapoff -a
но тут понятно - система даже "ругается".

2) забивал всю память, добиваясь заполнения свопа . Тут странно. Если полностью
заполнить всю память - в "сон" не уходит и в системных логах нет никаких следов: Если, места чуть есть (но не достаточно)
то выводит прогресс сжатия/записи образа и прервывется с сообщением сколько времени ушло на операцию и какова скорость записи.

Эта ошибка говорит скорее всего о том, что система не может быть сброшена в своп.
В вашем случае (по логе) не понятно: место есть.

Initial commandline parameters:
Ср июн 24 20:09:31 MSK 2015: Running hooks for hibernate.
...

total used free shared buffers cached

Mem: 20516700 15441688 5075012 429416 421652 6526504
-/+ buffers/cache: 8493532 12023168
Swap: 31264596 0 31264596
...

Ср июн 24 20:09:45 MSK 2015: performing hibernate
sh: echo: I/O error
Ср июн 24 20:10:08 MSK 2015: Awake.

У меня пока только два предположения:
1) проблемы с файловой системой или диском
2) система "зависает" на таком объеме, можно оценить сколько ресурсов будет "съедено" при сжатии и записи всей памяти на диск.
3) что то другое :)

Нужно смотреть на момент когда возникает ошибка или зависание /var/log/kern.log. Там все есть.
Читали https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt?

ps моделировал на ноуте с убунтой.

> gmail?
> Но я бы подумал насчёт смены клиента: локальный реально удобнее.
> И безопаснее.

Пока, я думаю.

--
С уважением, Илья.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/16477414...@web18m.yandex.ru

[Anatoly Pugachev]

2015-08-03 9:24 GMT+03:00 Илья <mir...@yandex.ru>:

             total       used       free     shared    buffers     cached

Память:    2063884     826892    1236992       1064      17720      85756
-/+ буферы/кэш:     723416    1340468
Подкачка:    2242556    2240568       1988
...

а не пробовали vm.swappiness (sysctl) менять? по умолчанию вроде 60 , поставьте в диапазоне 1-5

["Артём Н."]

On 03.08.2015 11:45, Anatoly Pugachev wrote:
> 2015-08-03 9:24 GMT+03:00 Илья <mir...@yandex.ru <mailto:mir...@yandex.ru>>:

Я пробовал.
# sysctl vm.swappiness
vm.swappiness = 2

Естественно, что при 20 Гб RAM, 60% - это слишком.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55BFC2AB...@yandex.ru

["Артём Н."]

On 03.08.2015 14:12, Илья wrote:
> Я делал синтетические тесты - в реальности у меня таких проблем не возникает.
> Будет свободное время попробую, но...
> Как я понял этот параметр действует по направлению ram -> swap, а не обратно.
Да.

> Я считаю, что на больших объемах ОЗУ можно вообще отказаться от свопа
Да, я думал над этим, но тогда RAM потребуется ещё больше.
Тем не менее, своп у меня, в основном требуется для hibernate.

> а для hibernate использовать либо свой pm hook (swapon,swapoff)
А вот это идея. Насчёт хуков я не подумал.
Только вот какие побочные эффекты могут быть?

> либо какой то
> специфический параметр виртуальной памяти, что то типа overcommit_ratio.
Почитаю в конце недели эту документацию, в том числе и про overcommit_*: пока времени нет.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55BFC380...@yandex.ru

["Артём Н."]

On 03.08.2015 17:43, Tim Sattarov wrote:
> On 2015-08-03 07:12, Илья wrote:
>> Я считаю, что на больших объемах ОЗУ можно вообще отказаться от свопа ,
>> а для hibernate использовать либо свой pm hook (swapon,swapoff), либо

>> какой то
>> специфический параметр виртуальной памяти, что то типа overcommit_ratio.
>>
>

> В конкретно этой ситуации можно сделать системный своп в файл
> а hibernate/resume направить на свап партицию.
>
Указывать системе, какой своп юзать (помню, была в fstab опция, позволяющая распределить нагрузку), а hibernate указать UID раздела?
Всё же не совсем приятно, что своп будет в файле: там получится три уровня под ним.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55BFC404...@yandex.ru

[Alex Kicelew]

On 08/03/15 22:36, "Артём Н." wrote:
>> а не пробовали vm.swappiness (sysctl) менять? по умолчанию вроде 60 ,
>> поставьте в диапазоне 1-5
> Я пробовал.
> # sysctl vm.swappiness
> vm.swappiness = 2
> Естественно, что при 20 Гб RAM, 60% - это слишком.

Я не помню точную семантику этого числа, но это однозначно не проценты.
В отличие от процентов, которых не может быть больше 100, это число не
ограничено сверху (точнее, ограничено размерностью инта).

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55BFC48F...@gmail.com

["Артём Н."]

On 03.08.2015 00:08, Илья wrote:
>>> я думаю это ругается /usr/lib/pm-utils/pm-functions:
>> При выборе режима сна? С чего бы?
>
> К долгому сохранению (кстати, сколько по времени не могли дождаться и прерывали?) это возможно не относится, эта ошибка о том, что не смог "уснуть" .

В районе 5-10 минут.

> Я смог вызвать эту ошибку двумя способами (выдает именно это сообщение sh: echo: I/O error):
>
> 1) swapoff -a
> но тут понятно - система даже "ругается".

Интересно - почему? Откуда I/O error?
Мне не понятно.

> 2) забивал всю память, добиваясь заполнения свопа . Тут странно. Если полностью
> заполнить всю память - в "сон" не уходит и в системных логах нет никаких следов: Если, места чуть есть (но не достаточно)
> то выводит прогресс сжатия/записи образа и прервывется с сообщением сколько времени ушло на операцию и какова скорость записи.
>
> Эта ошибка говорит скорее всего о том, что система не может быть сброшена в своп.

Да. Такое есть.
Вот, например сейчас (да, запишет наверное, но долго это будет идти, да и заметьте, что забито 5 Гб (!) свопа):
artiom@dana ~ $ free

total used free shared buffers cached

Mem: 19G 19G 254M 188M 711M 3,7G
-/+ buffers/cache: 14G 4,7G
Swap: 29G 5,3G 24G

Сделал, как рекомендовали, немного поменялось (сбросил дисковые буфера):
root@dana:/home# for i in $(seq 1 4); do echo $i > /proc/sys/vm/drop_caches; done
root@dana:/home# free

total used free shared buffers cached

Mem: 19G 14G 5,3G 188M 8,4M 584M
-/+ buffers/cache: 13G 5,9G
Swap: 29G 5,3G 24G

> У меня пока только два предположения:
> 1) проблемы с файловой системой или диском

С диском - возможно, но маловероятно.

> 2) система "зависает" на таком объеме, можно оценить сколько ресурсов будет "съедено" при сжатии и записи всей памяти на диск.

Вот только как это понять.
Опять же, как правило, проблема проявляется со временем, на большом аптайме.

> Нужно смотреть на момент когда возникает ошибка или зависание /var/log/kern.log. Там все есть.

Ошибки пока не было, но проскакивает что-то нездоровое:
Aug 2 23:01:58 dana kernel: [202584.677536] ata3.01: exception Emask 0x10 SAct 0x0 SErr 0x4000000 action 0x0
Aug 2 23:01:58 dana kernel: [202584.677540] ata3.01: SError: { DevExch }
Aug 2 23:01:58 dana kernel: [202584.677546] ata3.00: hard resetting link
Aug 2 23:01:58 dana kernel: [202585.397114] ata3.01: hard resetting link
Aug 2 23:01:59 dana kernel: [202586.281561] ata3.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Aug 2 23:01:59 dana kernel: [202586.281572] ata3.01: SATA link down (SStatus 0 SControl 300)
Aug 2 23:01:59 dana kernel: [202586.295262] ata3.00: configured for UDMA/133
Aug 2 23:01:59 dana kernel: [202586.295579] ata3: EH complete
Aug 3 19:01:10 dana kernel: [202599.188167] PM: Syncing filesystems ... done.
Aug 3 19:01:11 dana kernel: [202599.459154] Freezing user space processes ... (elapsed 0.001 seconds) done.
Aug 3 19:01:11 dana kernel: [202599.461412] PM: Preallocating image memory...
Aug 3 19:01:11 dana kernel: [202660.494175] usb 1-1.1: reset high-speed USB device number 3 using ehci-pci
Aug 3 19:01:11 dana kernel: [202669.471882] kthreadd: page allocation failure: order:2, mode:0x2000d0
Aug 3 19:01:11 dana kernel: [202669.471886] CPU: 0 PID: 2 Comm: kthreadd Tainted: P O 3.16.7-ckt9 #4
Aug 3 19:01:11 dana kernel: [202669.471887] Hardware name: System manufacturer System Product Name/P7P55D, BIOS 2003 12/14/2010
Aug 3 19:01:11 dana kernel: [202669.471888] ffff88052e9abc70 ffffffff81579361 00000000002000d0 ffffffff810d32a9
Aug 3 19:01:11 dana kernel: [202669.471890] 0000000000000002 00000000002000d0 0000000000000002 ffffffff810df991
Aug 3 19:01:11 dana kernel: [202669.471892] 00000000000590b3 0000000000000000 0000000000000020 0000000000000000
Aug 3 19:01:11 dana kernel: [202669.471893] Call Trace:
Aug 3 19:01:11 dana kernel: [202669.471899] [<ffffffff81579361>] ? dump_stack+0x41/0x51
Aug 3 19:01:11 dana kernel: [202669.471903] [<ffffffff810d32a9>] ? warn_alloc_failed+0xd9/0x130
Aug 3 19:01:11 dana kernel: [202669.471906] [<ffffffff810df991>] ? try_to_free_pages+0x91/0xa0
Aug 3 19:01:11 dana kernel: [202669.471908] [<ffffffff810d6f68>] ? __alloc_pages_nodemask+0x588/0xc10
Aug 3 19:01:11 dana kernel: [202669.471911] [<ffffffff81041ebd>] ? copy_process.part.38+0x11d/0x1a10
Aug 3 19:01:11 dana kernel: [202669.471913] [<ffffffff81060e60>] ? kthread_create_on_node+0x170/0x170
Aug 3 19:01:11 dana kernel: [202669.471914] [<ffffffff81043954>] ? do_fork+0xd4/0x380
Aug 3 19:01:11 dana kernel: [202669.471916] [<ffffffff8157aba2>] ? __schedule+0x272/0x7a0
Aug 3 19:01:11 dana kernel: [202669.471918] [<ffffffff81043c1d>] ? kernel_thread+0x1d/0x20
Aug 3 19:01:11 dana kernel: [202669.471919] [<ffffffff810616c0>] ? kthreadd+0x150/0x1a0
Aug 3 19:01:11 dana kernel: [202669.471921] [<ffffffff81061570>] ? kthread_create_on_cpu+0x40/0x40
Aug 3 19:01:11 dana kernel: [202669.471923] [<ffffffff8157ec88>] ? ret_from_fork+0x58/0x90
Aug 3 19:01:11 dana kernel: [202669.471924] [<ffffffff81061570>] ? kthread_create_on_cpu+0x40/0x40
Aug 3 19:01:11 dana kernel: [202669.471925] Mem-Info:
Aug 3 19:01:11 dana kernel: [202669.471927] DMA per-cpu:
Aug 3 19:01:11 dana kernel: [202669.471928] CPU 0: hi: 0, btch: 1 usd: 0
Aug 3 19:01:11 dana kernel: [202669.471929] CPU 1: hi: 0, btch: 1 usd: 0
Aug 3 19:01:11 dana kernel: [202669.471930] CPU 2: hi: 0, btch: 1 usd: 0
Aug 3 19:01:11 dana kernel: [202669.471931] CPU 3: hi: 0, btch: 1 usd: 0
Aug 3 19:01:11 dana kernel: [202669.471931] DMA32 per-cpu:
Aug 3 19:01:11 dana kernel: [202669.471932] CPU 0: hi: 186, btch: 31 usd: 0
Aug 3 19:01:11 dana kernel: [202669.471933] CPU 1: hi: 186, btch: 31 usd: 0
Aug 3 19:01:11 dana kernel: [202669.471934] CPU 2: hi: 186, btch: 31 usd: 0
Aug 3 19:01:11 dana kernel: [202669.471935] CPU 3: hi: 186, btch: 31 usd: 0
Aug 3 19:01:11 dana kernel: [202669.471936] Normal per-cpu:
Aug 3 19:01:11 dana kernel: [202669.471937] CPU 0: hi: 186, btch: 31 usd: 0
Aug 3 19:01:11 dana kernel: [202669.471938] CPU 1: hi: 186, btch: 31 usd: 17
Aug 3 19:01:11 dana kernel: [202669.471939] CPU 2: hi: 186, btch: 31 usd: 0
Aug 3 19:01:11 dana kernel: [202669.471940] CPU 3: hi: 186, btch: 31 usd: 0
Aug 3 19:01:11 dana kernel: [202669.471942] active_anon:1970425 inactive_anon:182303 isolated_anon:64
Aug 3 19:01:11 dana kernel: [202669.471942] active_file:103 inactive_file:53 isolated_file:0
Aug 3 19:01:11 dana kernel: [202669.471942] unevictable:0 dirty:0 writeback:182357 unstable:0
Aug 3 19:01:11 dana kernel: [202669.471942] free:38379 slab_reclaimable:21431 slab_unreclaimable:54960
Aug 3 19:01:11 dana kernel: [202669.471942] mapped:30945 shmem:19951 pagetables:43137 bounce:0
Aug 3 19:01:11 dana kernel: [202669.471942] free_cma:652
Aug 3 19:01:11 dana kernel: [202669.471947] DMA free:15636kB min:52kB low:64kB high:76kB active_anon:0kB inactive_anon:0kB
active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15992kB managed:15908kB mlocked:0kB
dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:16kB kernel_stack:0kB pagetables:0kB
unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
Aug 3 19:01:11 dana kernel: [202669.471948] lowmem_reserve[]: 0 3237 20020 20020
Aug 3 19:01:11 dana kernel: [202669.471952] DMA32 free:78260kB min:10916kB low:13644kB high:16372kB active_anon:617892kB
inactive_anon:123620kB active_file:16kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:3389888kB
managed:3315488kB mlocked:0kB dirty:0kB writeback:123700kB mapped:20988kB shmem:16340kB slab_reclaimable:13916kB
slab_unreclaimable:29736kB kernel_stack:2384kB pagetables:26396kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB
pages_scanned:92502 all_unreclaimable? no
Aug 3 19:01:11 dana kernel: [202669.471953] lowmem_reserve[]: 0 0 16782 16782
Aug 3 19:01:11 dana kernel: [202669.471957] Normal free:59620kB min:56612kB low:70764kB high:84916kB active_anon:7263808kB
inactive_anon:605592kB active_file:396kB inactive_file:212kB unevictable:0kB isolated(anon):256kB isolated(file):0kB
present:17563648kB managed:17185304kB mlocked:0kB dirty:0kB writeback:605728kB mapped:102792kB shmem:63464kB
slab_reclaimable:71808kB slab_unreclaimable:190088kB kernel_stack:14320kB pagetables:146152kB unstable:0kB bounce:0kB
free_cma:2608kB writeback_tmp:0kB pages_scanned:405755 all_unreclaimable? no
Aug 3 19:01:11 dana kernel: [202669.471958] lowmem_reserve[]: 0 0 0 0
Aug 3 19:01:11 dana kernel: [202669.471959] DMA: 1*4kB (U) 0*8kB 1*16kB (U) 2*32kB (U) 1*64kB (U) 1*128kB (U) 0*256kB 0*512kB
1*1024kB (U) 1*2048kB (R) 3*4096kB (M) = 15636kB
Aug 3 19:01:11 dana kernel: [202669.471966] DMA32: 19046*4kB (UM) 27*8kB (UM) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB
0*1024kB 1*2048kB (R) 0*4096kB = 78448kB
Aug 3 19:01:11 dana kernel: [202669.471971] Normal: 14418*4kB (UMC) 65*8kB (MC) 29*16kB (MC) 11*32kB (C) 5*64kB (C) 3*128kB (C)
0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 59712kB
Aug 3 19:01:11 dana kernel: [202669.471977] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
Aug 3 19:01:12 dana kernel: [202669.471978] 218777 total pagecache pages
Aug 3 19:01:12 dana kernel: [202669.471979] 198675 pages in swap cache
Aug 3 19:01:12 dana kernel: [202669.471980] Swap cache stats: add 2204130, delete 2005455, find 16058135/16093634
Aug 3 19:01:12 dana kernel: [202669.471981] Free swap = 24127328kB
Aug 3 19:01:12 dana kernel: [202669.471981] Total swap = 31264596kB
Aug 3 19:01:12 dana kernel: [202669.471982] 5242382 pages RAM
Aug 3 19:01:12 dana kernel: [202669.471982] 0 pages HighMem/MovableOnly
Aug 3 19:01:12 dana kernel: [202669.471983] 94586 pages reserved
Aug 3 19:01:12 dana kernel: [202669.471984] 0 pages hwpoisoned
Aug 3 19:01:12 dana kernel: [202669.523210] done (allocated 2762252 pages)
Aug 3 19:01:12 dana kernel: [202669.523214] PM: Allocated 11049008 kbytes in 69.98 seconds (157.88 MB/s)
Aug 3 19:01:12 dana kernel: [202669.523215] Freezing remaining freezable tasks ... (elapsed 7.432 seconds) done.
Aug 3 19:01:12 dana kernel: [202676.964182] Suspending console(s) (use no_console_suspend to debug)
Aug 3 19:01:12 dana kernel: [202676.964958] serial 00:05: disabled
Aug 3 19:01:12 dana kernel: [202676.964962] serial 00:05: System wakeup disabled by ACPI
Aug 3 19:01:12 dana kernel: [202677.167642] PM: freeze of devices complete after 203.217 msecs
Aug 3 19:01:12 dana kernel: [202677.168029] PM: late freeze of devices complete after 0.385 msecs
Aug 3 19:01:12 dana kernel: [202677.168707] PM: noirq freeze of devices complete after 0.675 msecs
Aug 3 19:01:12 dana kernel: [202677.168962] ACPI: Preparing to enter system sleep state S4
Aug 3 19:01:12 dana kernel: [202677.169186] PM: Saving platform NVS memory
Aug 3 19:01:12 dana kernel: [202677.169409] Disabling non-boot CPUs ...
Aug 3 19:01:12 dana kernel: [202677.169571] Broke affinity for irq 41
Aug 3 19:01:12 dana kernel: [202677.170584] kvm: disabling virtualization on CPU1
Aug 3 19:01:12 dana kernel: [202677.170602] smpboot: CPU 1 is now offline
Aug 3 19:01:12 dana kernel: [202677.171073] Broke affinity for irq 21
Aug 3 19:01:12 dana kernel: [202677.171075] Broke affinity for irq 42
Aug 3 19:01:12 dana kernel: [202677.172088] kvm: disabling virtualization on CPU2
Aug 3 19:01:12 dana kernel: [202677.273469] smpboot: CPU 2 is now offline
Aug 3 19:01:12 dana kernel: [202677.273879] Broke affinity for irq 23
Aug 3 19:01:12 dana kernel: [202677.273881] Broke affinity for irq 43
Aug 3 19:01:12 dana kernel: [202677.274893] kvm: disabling virtualization on CPU3
Aug 3 19:01:12 dana kernel: [202677.376928] smpboot: CPU 3 is now offline
Aug 3 19:01:12 dana kernel: [202677.377340] PM: Creating hibernation image:
Aug 3 19:01:12 dana kernel: [202677.543379] PM: Need to copy 2422607 pages
Aug 3 19:01:12 dana kernel: [202677.378006] PM: Restoring platform NVS memory
Aug 3 19:01:12 dana kernel: [202677.378535] Enabling non-boot CPUs ...
Aug 3 19:01:12 dana kernel: [202677.378565] x86: Booting SMP configuration:
Aug 3 19:01:12 dana kernel: [202677.378566] smpboot: Booting Node 0 Processor 1 APIC 0x2
Aug 3 19:01:12 dana kernel: [202677.381484] /dev/vmmon[13797]: HostIFReadUptimeWork: detected settimeofday: fixed uptimeBase old
18445305546136120844 new 18445305474283604369 attempts 1

В старых логах посмотрел, вроде более ли менее (периодически падает rdiff-backup - ещё одна вероятная причина, когда hibernate
попадает на процесс бэкапа):
Jul 13 08:23:23 dana kernel: [609420.431911] Freezing user space processes ...
Jul 13 08:23:23 dana kernel: [609440.461626] Freezing of tasks failed after 20.006 seconds (1 tasks refusing to freeze, wq_busy=0):
Jul 13 08:23:23 dana kernel: [609440.461756] rdiff-backup D 0000000000000000 0 19234 21026 0x00000004
Jul 13 08:23:23 dana kernel: [609440.461758] ffff8802422abd20 0000000000000086 0000000000009000 ffff8801319b2760
Jul 13 08:23:23 dana kernel: [609440.461760] ffff8802422abfd8 0000000000000000 0000000000000620 ffff88052fc110a0
Jul 13 08:23:23 dana kernel: [609440.461761] ffff88052ffbade8 ffff8802422abd90 0000000000000082 ffffffff810cdf30
Jul 13 08:23:23 dana kernel: [609440.461763] Call Trace:
Jul 13 08:23:23 dana kernel: [609440.461769] [<ffffffff810cdf30>] ? sleep_on_page+0x10/0x10
Jul 13 08:23:23 dana kernel: [609440.461773] [<ffffffff8157b3c6>] ? io_schedule+0xa6/0x140
Jul 13 08:23:23 dana kernel: [609440.461774] [<ffffffff810cdf35>] ? sleep_on_page_killable+0x5/0x40
Jul 13 08:23:23 dana kernel: [609440.461776] [<ffffffff8157b83c>] ? __wait_on_bit_lock+0x3c/0x90
Jul 13 08:23:23 dana kernel: [609440.461777] [<ffffffff810ce085>] ? __lock_page_killable+0x65/0x70
Jul 13 08:23:23 dana kernel: [609440.461781] [<ffffffff8107ab80>] ? autoremove_wake_function+0x30/0x30
Jul 13 08:23:23 dana kernel: [609440.461782] [<ffffffff810cfc08>] ? generic_file_read_iter+0x3b8/0x5b0
Jul 13 08:23:23 dana kernel: [609440.461786] [<ffffffff81120f1c>] ? new_sync_read+0x6c/0xa0
Jul 13 08:23:23 dana kernel: [609440.461787] [<ffffffff8112158a>] ? vfs_read+0x8a/0x170
Jul 13 08:23:23 dana kernel: [609440.461789] [<ffffffff8112218d>] ? SyS_read+0x3d/0xa0
Jul 13 08:23:23 dana kernel: [609440.461791] [<ffffffff8157ed36>] ? system_call_fast_compare_end+0x10/0x15
Jul 13 08:23:23 dana kernel: [609440.461792]
Jul 13 08:23:23 dana kernel: [609440.461793] Restarting tasks ...
Jul 13 08:23:23 dana kernel: [609440.466979] done.

И ещё вот такое:
Jul 17 21:19:04 dana kernel: [ 1296.090329] ------------[ cut here ]------------
Jul 17 21:19:04 dana kernel: [ 1296.090351] WARNING: CPU: 2 PID: 0 at net/sched/sch_generic.c:264 dev_watchdog+0x22f/0x240()
Jul 17 21:19:04 dana kernel: [ 1296.090356] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out
Jul 17 21:19:04 dana kernel: [ 1296.090359] Modules linked in: udp_diag tcp_diag inet_diag ip6table_filter ip6_tables pci_stub
vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) tun xt_multiport ebt_snat ebt_dnat e
btable_nat ebtables xt_nat nf_nat_sip nf_nat_irc nf_nat_amanda nf_nat_ftp nf_nat_proto_sctp libcrc32c nf_nat_proto_udplite
nf_nat_tftp nf_nat_snmp_basic nf_nat_h323 iptable_nat nf_nat_pptp nf_nat_proto_gre nf_nat_
ipv4 nf_nat act_nat nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_tftp nf_conntrack_proto_udplite nf_conntrack_h323
xt_conntrack nf_conntrack_proto_sctp nf_conntrack_netbios_ns nf_conntrack_ftp nf_conntrac
k_sip nf_conntrack_irc nf_conntrack_snmp nf_conntrack_broadcast nf_conntrack_netlink nfnetlink ts_kmp nf_conntrack_amanda
nf_conntrack_ipv4 nf_defrag_ipv4 nvidia(PO) uvcvideo snd_usb_audio videobuf2_vmalloc snd_us
bmidi_lib videobuf2_memops snd_rawmidi videobuf2_core joydev kvm_intel kvm serio_raw acpi_cpufreq ppdev parport xts gf128mul ecb
algif_skcipher af_alg dm_mirror dm_region_hash dm_log drm uas crc32c_intel [last unl
oaded: vmnet]
Jul 17 21:19:04 dana kernel: [ 1296.090439] CPU: 2 PID: 0 Comm: swapper/2 Tainted: P O 3.16.7-ckt9 #4
Jul 17 21:19:04 dana kernel: [ 1296.090443] Hardware name: System manufacturer System Product Name/P7P55D, BIOS 2003 12/14/2010
Jul 17 21:19:04 dana kernel: [ 1296.090450] 0000000000000009 ffffffff81579361 ffff88052fc83e28 ffffffff810446dd
Jul 17 21:19:04 dana kernel: [ 1296.090456] 0000000000000000 ffff88052fc83e78 0000000000000001 0000000000000002
Jul 17 21:19:04 dana kernel: [ 1296.090461] ffff880516f48000 ffffffff81044747 ffffffff81781210 0000000000000030
Jul 17 21:19:04 dana kernel: [ 1296.090466] Call Trace:
Jul 17 21:19:04 dana kernel: [ 1296.090469] <IRQ> [<ffffffff81579361>] ? dump_stack+0x41/0x51
Jul 17 21:19:04 dana kernel: [ 1296.090483] [<ffffffff810446dd>] ? warn_slowpath_common+0x6d/0x90
Jul 17 21:19:04 dana kernel: [ 1296.090488] [<ffffffff81044747>] ? warn_slowpath_fmt+0x47/0x50
Jul 17 21:19:04 dana kernel: [ 1296.090495] [<ffffffff81092dbc>] ? ktime_get+0x3c/0xe0
Jul 17 21:19:04 dana kernel: [ 1296.090501] [<ffffffff814b7eaf>] ? dev_watchdog+0x22f/0x240
Jul 17 21:19:04 dana kernel: [ 1296.090507] [<ffffffff814b7c80>] ? dev_graft_qdisc+0x70/0x70
Jul 17 21:19:04 dana kernel: [ 1296.090512] [<ffffffff814b7c80>] ? dev_graft_qdisc+0x70/0x70
Jul 17 21:19:04 dana kernel: [ 1296.090518] [<ffffffff8104e4f2>] ? call_timer_fn.isra.30+0x12/0x80
Jul 17 21:19:04 dana kernel: [ 1296.090524] [<ffffffff8104e728>] ? run_timer_softirq+0x1c8/0x270
Jul 17 21:19:04 dana kernel: [ 1296.090531] [<ffffffff8104893b>] ? __do_softirq+0x10b/0x220
Jul 17 21:19:04 dana kernel: [ 1296.090533] [<ffffffff81048b95>] ? irq_exit+0x95/0xa0
Jul 17 21:19:04 dana kernel: [ 1296.090536] [<ffffffff8100477c>] ? do_IRQ+0x4c/0xe0
Jul 17 21:19:04 dana kernel: [ 1296.090539] [<ffffffff8157f96a>] ? common_interrupt+0x6a/0x6a
Jul 17 21:19:04 dana kernel: [ 1296.090540] <EOI> [<ffffffff814039d1>] ? cpuidle_enter_state+0x41/0xb0
Jul 17 21:19:04 dana kernel: [ 1296.090544] [<ffffffff814039cd>] ? cpuidle_enter_state+0x3d/0xb0
Jul 17 21:19:04 dana kernel: [ 1296.090548] [<ffffffff8107afee>] ? cpu_startup_entry+0x27e/0x2b0
Jul 17 21:19:04 dana kernel: [ 1296.090550] ---[ end trace aaebcbeb49c4e033 ]---

> Читали https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt?
>
Не читал. Вроде там немного. Посмотрю, но вообще отлаживать hibernation нет большого желания.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55BFC813...@yandex.ru

[Vasiliy P. Melnik]

Указывать системе, какой своп юзать (помню, была в fstab опция, позволяющая распределить нагрузку), а hibernate указать UID раздела?

Всё же не совсем приятно, что своп будет в файле: там получится три уровня под ним

вы столько это обговариваете, что уже можно было пойти купить 16 гигов оперативки и забить на своп 

["Артём Н."]

On 02.08.2015 20:12, Aleksandr Sytar wrote:
> Если ядро собрано с поддержкой slab/slub - то кто конкретно держит память можно посмотреть через cat /proc/slabinfo Теоретически
> там не должно быть записей относительно процессов которые уже выгружены.

Собрано с поддержкой, только вот как их этого получить то, что мне надо:

root@dana:/home# cat /proc/slabinfo
slabinfo - version: 2.1
# name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> :
slabdata <active_slabs> <num_slabs> <sharedavail>
nf_conntrack_ffff8803e50b6780 0 0 312 26 2 : tunables 0 0 0 : slabdata 0 0 0
nvidia_stack_t 130 140 12288 2 8 : tunables 0 0 0 : slabdata 70 70 0
kvm_async_pf 0 0 136 30 1 : tunables 0 0 0 : slabdata 0 0 0
kvm_vcpu 0 0 16256 2 8 : tunables 0 0 0 : slabdata 0 0 0
kvm_mmu_page_header 0 0 168 24 1 : tunables 0 0 0 : slabdata 0 0 0
ext4_groupinfo_4k 8832 8876 144 28 1 : tunables 0 0 0 : slabdata 317 317 0
UDPLITEv6 0 0 1088 30 8 : tunables 0 0 0 : slabdata 0 0 0
UDPv6 120 120 1088 30 8 : tunables 0 0 0 : slabdata 4 4 0
tw_sock_TCPv6 0 21 192 21 1 : tunables 0 0 0 : slabdata 1 1 0
TCPv6 68 68 1920 17 8 : tunables 0 0 0 : slabdata 4 4 0
nf_conntrack_ffffffff8186c740 368 442 312 26 2 : tunables 0 0 0 : slabdata 17 17 0
kcopyd_job 0 0 3312 9 8 : tunables 0 0 0 : slabdata 0 0 0
dm_uevent 0 0 2632 12 8 : tunables 0 0 0 : slabdata 0 0 0
dm_rq_target_io 0 0 408 20 2 : tunables 0 0 0 : slabdata 0 0 0
scsi_cmd_cache 110 126 384 21 2 : tunables 0 0 0 : slabdata 6 6 0
bsg_cmd 0 0 312 26 2 : tunables 0 0 0 : slabdata 0 0 0
mqueue_inode_cache 36 36 896 36 8 : tunables 0 0 0 : slabdata 1 1 0
fuse_request 156 156 416 39 4 : tunables 0 0 0 : slabdata 4 4 0
fuse_inode 359 483 768 21 4 : tunables 0 0 0 : slabdata 23 23 0
hugetlbfs_inode_cache 29 56 576 28 4 : tunables 0 0 0 : slabdata 2 2 0
jbd2_journal_handle 340 340 48 85 1 : tunables 0 0 0 : slabdata 4 4 0
jbd2_journal_head 972 972 112 36 1 : tunables 0 0 0 : slabdata 27 27 0
jbd2_revoke_table_s 262 768 16 256 1 : tunables 0 0 0 : slabdata 3 3 0
jbd2_revoke_record_s 768 1024 32 128 1 : tunables 0 0 0 : slabdata 8 8 0
ext4_inode_cache 5495 29536 1000 32 8 : tunables 0 0 0 : slabdata 923 923 0
ext4_free_data 1152 1152 64 64 1 : tunables 0 0 0 : slabdata 18 18 0
ext4_allocation_context 128 128 128 32 1 : tunables 0 0 0 : slabdata 4 4 0
ext4_io_end 728 728 72 56 1 : tunables 0 0 0 : slabdata 13 13 0
ext4_extent_status 4794 4794 40 102 1 : tunables 0 0 0 : slabdata 47 47 0
configfs_dir_cache 0 46 88 46 1 : tunables 0 0 0 : slabdata 1 1 0
dquot 448 448 256 32 2 : tunables 0 0 0 : slabdata 14 14 0
pid_namespace 15 15 2184 15 8 : tunables 0 0 0 : slabdata 1 1 0
posix_timers_cache 0 0 248 33 2 : tunables 0 0 0 : slabdata 0 0 0
UDP-Lite 0 0 896 36 8 : tunables 0 0 0 : slabdata 0 0 0
flow_cache 0 0 104 39 1 : tunables 0 0 0 : slabdata 0 0 0
xfrm_dst_cache 0 0 448 36 4 : tunables 0 0 0 : slabdata 0 0 0
ip_fib_trie 88 292 56 73 1 : tunables 0 0 0 : slabdata 4 4 0
UDP 144 144 896 36 8 : tunables 0 0 0 : slabdata 4 4 0
tw_sock_TCP 147 147 192 21 1 : tunables 0 0 0 : slabdata 7 7 0
TCP 168 234 1792 18 8 : tunables 0 0 0 : slabdata 13 13 0
fscache_cookie_jar 0 0 80 51 1 : tunables 0 0 0 : slabdata 0 0 0
scsi_data_buffer 0 0 24 170 1 : tunables 0 0 0 : slabdata 0 0 0
blkdev_queue 30 64 1976 16 8 : tunables 0 0 0 : slabdata 4 4 0
blkdev_requests 374 374 368 22 2 : tunables 0 0 0 : slabdata 18 18 0
user_namespace 0 0 232 35 2 : tunables 0 0 0 : slabdata 0 0 0
sock_inode_cache 1754 1975 640 25 4 : tunables 0 0 0 : slabdata 79 79 0
net_namespace 7 7 4416 7 8 : tunables 0 0 0 : slabdata 1 1 0
shmem_inode_cache 2839 3025 648 25 4 : tunables 0 0 0 : slabdata 121 121 0
task_delay_info 2267 2376 112 36 1 : tunables 0 0 0 : slabdata 66 66 0
taskstats 168 168 328 24 2 : tunables 0 0 0 : slabdata 7 7 0
proc_inode_cache 1825 1825 640 25 4 : tunables 0 0 0 : slabdata 73 73 0
sigqueue 125 150 160 25 1 : tunables 0 0 0 : slabdata 6 6 0
bdev_cache 59 156 832 39 8 : tunables 0 0 0 : slabdata 4 4 0
kernfs_node_cache 23086 23086 120 34 1 : tunables 0 0 0 : slabdata 679 679 0
mnt_cache 275 275 320 25 2 : tunables 0 0 0 : slabdata 11 11 0
inode_cache 1621 2856 576 28 4 : tunables 0 0 0 : slabdata 102 102 0
dentry 10804 41538 192 21 1 : tunables 0 0 0 : slabdata 1978 1978 0
buffer_head 8418 11700 104 39 1 : tunables 0 0 0 : slabdata 300 300 0
vm_area_struct 90563 94490 184 22 1 : tunables 0 0 0 : slabdata 4295 4295 0
mm_struct 2109 2232 896 36 8 : tunables 0 0 0 : slabdata 62 62 0
files_cache 554 675 640 25 4 : tunables 0 0 0 : slabdata 27 27 0
signal_cache 762 960 1088 30 8 : tunables 0 0 0 : slabdata 32 32 0
sighand_cache 491 525 2112 15 8 : tunables 0 0 0 : slabdata 35 35 0
task_struct 1109 1312 2016 16 8 : tunables 0 0 0 : slabdata 82 82 0
Acpi-ParseExt 23281 23856 72 56 1 : tunables 0 0 0 : slabdata 426 426 0
Acpi-Parse 4075 6715 48 85 1 : tunables 0 0 0 : slabdata 79 79 0
Acpi-State 102 204 80 51 1 : tunables 0 0 0 : slabdata 4 4 0
Acpi-Namespace 6120 6120 40 102 1 : tunables 0 0 0 : slabdata 60 60 0
anon_vma 35252 37904 88 46 1 : tunables 0 0 0 : slabdata 824 824 0
radix_tree_node 23928 62748 584 28 4 : tunables 0 0 0 : slabdata 2241 2241 0
idr_layer_cache 411 420 2096 15 8 : tunables 0 0 0 : slabdata 28 28 0
dma-kmalloc-8192 0 0 8192 4 8 : tunables 0 0 0 : slabdata 0 0 0
dma-kmalloc-4096 0 0 4096 8 8 : tunables 0 0 0 : slabdata 0 0 0
dma-kmalloc-2048 0 0 2048 16 8 : tunables 0 0 0 : slabdata 0 0 0
dma-kmalloc-1024 0 0 1024 32 8 : tunables 0 0 0 : slabdata 0 0 0
dma-kmalloc-512 0 32 512 32 4 : tunables 0 0 0 : slabdata 1 1 0
dma-kmalloc-256 0 0 256 32 2 : tunables 0 0 0 : slabdata 0 0 0
dma-kmalloc-128 0 0 128 32 1 : tunables 0 0 0 : slabdata 0 0 0
dma-kmalloc-64 0 0 64 64 1 : tunables 0 0 0 : slabdata 0 0 0
dma-kmalloc-32 0 0 32 128 1 : tunables 0 0 0 : slabdata 0 0 0
dma-kmalloc-16 0 0 16 256 1 : tunables 0 0 0 : slabdata 0 0 0
dma-kmalloc-8 0 0 8 512 1 : tunables 0 0 0 : slabdata 0 0 0
dma-kmalloc-192 0 0 192 21 1 : tunables 0 0 0 : slabdata 0 0 0
dma-kmalloc-96 0 0 96 42 1 : tunables 0 0 0 : slabdata 0 0 0
kmalloc-8192 477 484 8192 4 8 : tunables 0 0 0 : slabdata 121 121 0
kmalloc-4096 734 752 4096 8 8 : tunables 0 0 0 : slabdata 94 94 0
kmalloc-2048 699 736 2048 16 8 : tunables 0 0 0 : slabdata 46 46 0
kmalloc-1024 1904 2112 1024 32 8 : tunables 0 0 0 : slabdata 66 66 0
kmalloc-512 2838 3544 512 32 4 : tunables 0 0 0 : slabdata 119 119 0
kmalloc-256 24889 28064 256 32 2 : tunables 0 0 0 : slabdata 886 886 0
kmalloc-192 9672 12978 192 21 1 : tunables 0 0 0 : slabdata 618 618 0
kmalloc-128 4049 6336 128 32 1 : tunables 0 0 0 : slabdata 198 198 0
kmalloc-96 5265 10542 96 42 1 : tunables 0 0 0 : slabdata 251 251 0
kmalloc-64 76400 132544 64 64 1 : tunables 0 0 0 : slabdata 2071 2071 0
kmalloc-32 9012 27264 32 128 1 : tunables 0 0 0 : slabdata 213 213 0
kmalloc-16 4416 4608 16 256 1 : tunables 0 0 0 : slabdata 18 18 0
kmalloc-8 32517 37888 8 512 1 : tunables 0 0 0 : slabdata 74 74 0
kmem_cache_node 141 320 64 64 1 : tunables 0 0 0 : slabdata 5 5 0
kmem_cache 118 168 192 21 1 : tunables 0 0 0 : slabdata 8 8 0

?

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55BFC5BB...@yandex.ru

["Артём Н."]

On 03.08.2015 22:44, Alex Kicelew wrote:
> On 08/03/15 22:36, "Артём Н." wrote:
>>> а не пробовали vm.swappiness (sysctl) менять? по умолчанию вроде 60 ,
>>> поставьте в диапазоне 1-5
>> Я пробовал.
>> # sysctl vm.swappiness
>> vm.swappiness = 2
>> Естественно, что при 20 Гб RAM, 60% - это слишком.
>
> Я не помню точную семантику этого числа, но это однозначно не проценты.
> В отличие от процентов, которых не может быть больше 100, это число не
> ограничено сверху (точнее, ограничено размерностью инта).
>
>

А, кстати в офф доке ничего не говорится про то, в каких это единицах:
"swappiness

This control is used to define how aggressive the kernel will swap
memory pages. Higher values will increase agressiveness, 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.

The default value is 60."

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55BFC8E2...@yandex.ru

["Артём Н."]

Вы, кажется, не совсем в курсе проблемы.
20 Гб оперативки и так есть. И я так думаю, добавление ещё 16-ти не решит проблемы с засыпанием.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55BFC87A...@yandex.ru

["Артём Н."]

> Я не помню точную семантику этого числа, но это однозначно не проценты.
> В отличие от процентов, которых не может быть больше 100, это число не
> ограничено сверху (точнее, ограничено размерностью инта).

Хотя... В страницах?

"amount of free and file-backed pages is less
than the high water mark in a zone"

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55BFC939...@yandex.ru

[dimas]

а /sys на момент попытки записи в него еще смонтирован?


2015-215 09:24 Илья <mir...@yandex.ru> wrote:
> Пн. авг.  3 00:17:38 MSK 2015: performing hibernate
> test0
> test1
> sh: echo: I/O error <==== sudo mcedit /usr/lib/pm-utils/pm-functions: echo -n
> "disk" > /sys/power/state

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/20150804104...@Ulf.tvoe.tv

[Andrey Melnikoff]

"Артём Н." <arti...@yandex.ru> wrote:
> On 03.08.2015 00:08, Илья wrote:
> >>> я думаю это ругается /usr/lib/pm-utils/pm-functions:
> >> При выборе режима сна? С чего бы?
> >

[]

> > Нужно смотреть на момент когда возникает ошибка или зависание /var/log/kern.log. Там все есть.
> Ошибки пока не было, но проскакивает что-то нездоровое:

С этого и надо было начинать. nvidia, virtualbox - наличие out-of-tree модулей
может давать разнообразные симптомы.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/9ji69c-...@woofie.cef.spbstu.ru

["Артём Н."]

On 04.08.2015 10:43, dimas wrote:
> а /sys на момент попытки записи в него еще смонтирован?
>

Не знаю, не проверял. Но могу предположить, что да, т.к. системный (не самописный) обработчик pm-utils пытается туда что-то писать
в это время.

>
> 2015-215 09:24 Илья <mir...@yandex.ru> wrote:
>> Пн. авг. 3 00:17:38 MSK 2015: performing hibernate
>> test0
>> test1
>> sh: echo: I/O error <==== sudo mcedit /usr/lib/pm-utils/pm-functions: echo -n
>> "disk" > /sys/power/state
>
>


--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55C10D12...@yandex.ru

["Артём Н."]

On 04.08.2015 14:00, Andrey Melnikoff wrote:
> "Артём Н." <arti...@yandex.ru> wrote:
>> On 03.08.2015 00:08, Илья wrote:
>>>>> я думаю это ругается /usr/lib/pm-utils/pm-functions:
>>>> При выборе режима сна? С чего бы?
>>>
>
> []
>
>>> Нужно смотреть на момент когда возникает ошибка или зависание /var/log/kern.log. Там все есть.
>> Ошибки пока не было, но проскакивает что-то нездоровое:
>
> С этого и надо было начинать. nvidia, virtualbox - наличие out-of-tree модулей
> может давать разнообразные симптомы.

Да вроде не было такого раньше, хотя nvidia всегда vbox и vmware тоже...

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55C10CC8...@yandex.ru

[Илья]

>> Я смог вызвать эту ошибку двумя способами (выдает именно это сообщение sh: echo: I/O error):
>>
>> 1) swapoff -a
>> но тут понятно - система даже "ругается".
>
> Интересно - почему? Откуда I/O error?
> Мне не понятно.

Почему не понятно? Устройство отключено, а в него пытаются использовать.

> Вот, например сейчас (да, запишет наверное, но долго это будет идти, да и заметьте, что забито 5 Гб (!) свопа):
> artiom@dana ~ $ free
>
> total used free shared buffers cached
> Mem: 19G 19G 254M 188M 711M 3,7G
> -/+ buffers/cache: 14G 4,7G
> Swap: 29G 5,3G 24G
>
> Сделал, как рекомендовали, немного поменялось (сбросил дисковые буфера):

Мне не понятно, зачем это делать? Мне кажется кэши и буфера не влияют на процесс, а из свопа вы данные все равно не вытащили.

> root@dana:/home# for i in $(seq 1 4); do echo $i > /proc/sys/vm/drop_caches; done
> root@dana:/home# free
> total used free shared buffers cached
> Mem: 19G 14G 5,3G 188M 8,4M 584M
> -/+ buffers/cache: 13G 5,9G
> Swap: 29G 5,3G 24G

>> 2) система "зависает" на таком объеме, можно оценить сколько ресурсов будет "съедено" при сжатии и записи всей памяти на диск.
> Вот только как это понять.
> Опять же, как правило, проблема проявляется со временем, на большом аптайме.

Можно понаблюдать за процессом в динамике, хотя бы sar, vmstat.

Я конечно не специалист, но обратил бы внимание на следующее (тут вам самим надо разбираться):


> Aug 3 19:01:11 dana kernel: [202669.471882] kthreadd: page allocation failure: order:2, mode:0x2000d0 <======= google? Слишком много задач или фрагментация памяти?

> Aug 3 19:01:11 dana kernel: [202669.471886] CPU: 0 PID: 2 Comm: kthreadd Tainted: P O 3.16.7-ckt9 #4

> Aug 3 19:01:11 dana kernel: [202669.471887] Hardware name: System manufacturer System Product Name/P7P55D, BIOS 2003 12/14/2010 <======= обновить BIOS?

> Aug 3 19:01:12 dana kernel: [202669.523214] PM: Allocated 11 049 008 kbytes in 69.98 seconds (157.88 MB/s) <=== просто "фантастическая" скорость ;)

Например, у меня как то так
grep 'PM: Allocated' /var/log/kern.log
Allocated 2 378 652 kbytes in 0.29 seconds (8202.24 MB/s)
Allocated 1 465 804 kbytes in 0.13 seconds (11275.41 MB/s)
Allocated 1 338 792 kbytes in 0.09 seconds (14875.46 MB/s)


--
С уважением, Илья.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/20108614...@web7g.yandex.ru

["Артём Н."]

On 04.08.2015 22:15, Илья wrote:
>>> Я смог вызвать эту ошибку двумя способами (выдает именно это сообщение sh: echo: I/O error):
>>>
>>> 1) swapoff -a
>>> но тут понятно - система даже "ругается".
>>
>> Интересно - почему? Откуда I/O error?
>> Мне не понятно.
>
> Почему не понятно? Устройство отключено, а в него пытаются использовать.

swap? А, так вы отключили вручную и попытались сделать hibernate? Тогда ясно.

>> Вот, например сейчас (да, запишет наверное, но долго это будет идти, да и заметьте, что забито 5 Гб (!) свопа):
>> artiom@dana ~ $ free
>>
>> total used free shared buffers cached
>> Mem: 19G 19G 254M 188M 711M 3,7G
>> -/+ buffers/cache: 14G 4,7G
>> Swap: 29G 5,3G 24G
>>
>> Сделал, как рекомендовали, немного поменялось (сбросил дисковые буфера):
>
> Мне не понятно, зачем это делать? Мне кажется кэши и буфера не влияют на процесс, а из свопа вы данные все равно не вытащили.

На всякий случай. Чтобы не занимали память. И на их сброс, в процесс засыпания тоже уйдёт время.

>>> 2) система "зависает" на таком объеме, можно оценить сколько ресурсов будет "съедено" при сжатии и записи всей памяти на диск.
>> Вот только как это понять.
>> Опять же, как правило, проблема проявляется со временем, на большом аптайме.
>
> Можно понаблюдать за процессом в динамике, хотя бы sar

У меня пакет sysstat даже не стоял, и про sar я ранее не слышал. Поставил.

> vmstat.
root@dana:/home# vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
2 0 5043844 9482676 225660 5039404 8 24 154 177 27 41 35 13 52 1 0

Что мне это даёт?

> Я конечно не специалист, но обратил бы внимание на следующее (тут вам самим надо разбираться):
>
>
>> Aug 3 19:01:11 dana kernel: [202669.471882] kthreadd: page allocation failure: order:2, mode:0x2000d0 <======= google? Слишком много задач или фрагментация памяти?
>> Aug 3 19:01:11 dana kernel: [202669.471886] CPU: 0 PID: 2 Comm: kthreadd Tainted: P O 3.16.7-ckt9 #4
>
>> Aug 3 19:01:11 dana kernel: [202669.471887] Hardware name: System manufacturer System Product Name/P7P55D, BIOS 2003 12/14/2010 <======= обновить BIOS?
>

Thnx. Да, посмотрел: 2012-й последний.
Особенно с учётом:
1. Improve memory compatibility
2. Improve system stability
3. Update CPU Level up function


Неприятно конечно, но обновлю на выходных.

>> Aug 3 19:01:12 dana kernel: [202669.523214] PM: Allocated 11 049 008 kbytes in 69.98 seconds (157.88 MB/s) <=== просто "фантастическая" скорость ;)
>
> Например, у меня как то так
> grep 'PM: Allocated' /var/log/kern.log
> Allocated 2 378 652 kbytes in 0.29 seconds (8202.24 MB/s)
> Allocated 1 465 804 kbytes in 0.13 seconds (11275.41 MB/s)
> Allocated 1 338 792 kbytes in 0.09 seconds (14875.46 MB/s)

Да вижу... Только почему?

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55C116...@yandex.ru

["Артём Н."]

Обновил BIOS, перезагрузился.

>> Aug 3 19:01:12 dana kernel: [202669.523214] PM: Allocated 11 049 008 kbytes in 69.98 seconds (157.88 MB/s) <=== просто "фантастическая" скорость ;)
>
> Например, у меня как то так
> grep 'PM: Allocated' /var/log/kern.log
> Allocated 2 378 652 kbytes in 0.29 seconds (8202.24 MB/s)
> Allocated 1 465 804 kbytes in 0.13 seconds (11275.41 MB/s)
> Allocated 1 338 792 kbytes in 0.09 seconds (14875.46 MB/s)
>
>

Aug 4 21:52:25 dana kernel: [217697.695350] PM: Allocated 6961104 kbytes in 0.55 seconds (12656.55 MB/s)

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/55C11D62...@yandex.ru

["Артём Н."]

Нашёл любопытную статью на Хабре про оптимизацию серверов "одноглазников.ру":
http://habrahabr.ru/company/odnoklassniki/blog/266005

Выдержка:
"Дефрагментация запускается только тогда, когда свободная память опускается ниже
определённой отметки (zone watermark), и в нашем случае это происходило слишком
поздно. Единственный способ заставить её запускаться раньше — это повысить
min_free_kbytes через sysctl. Данный параметр говорит ядру стараться держать часть
памяти свободной, а чтобы удовлетворить это требование, ему приходится запускать
дефрагментацию раньше. В нашем случае хватило значения в 1 Гбайт."

[Aleksandr Sytar]

28 сентября 2015 г., 10:22 пользователь "Артём Н." <arti...@yandex.ru> написал:

Странный совет - в случае когда приложение попытается аллоцировать памяти с залезанием в зону min_free_kbytes, то придет злобный oom-killer и накажет кого попало.

["Артём Н."]

> Странный совет - в случае когда приложение попытается аллоцировать памяти с
> залезанием в зону min_free_kbytes, то придет злобный oom-killer и накажет кого попало.
>

Стоит заметить, что у них 45 Гб оперативки и, в основном, как я понимаю, всё
тратится на кэш в виде tmpfs.
Приложение же вероятно (это уже мой домысел) ограничивается по верхнему объёму памяти.