subject:"Утекает память"


Обновил 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-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55c11d62.6010...@yandex.ru

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


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   sobibo   in   cs us sy id wa st
 2  0 5043844 9482676 225660 50394048   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-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55c11617@yandex.ru

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


On 04.08.2015 14:00, Andrey Melnikoff wrote:

"Артём Н."  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-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55c10cc8.2070...@yandex.ru

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

2015-08-04 Пенетрантность Andrey Melnikoff


On 04.08.2015 10:43, dimas wrote:

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

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




2015-215 09:24 Илья  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-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55c10d12.1020...@yandex.ru

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

"Артём Н."  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-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/9ji69c-9c1@woofie.cef.spbstu.ru

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

2015-08-04 Пенетрантность dimas

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


2015-215 09:24 Илья  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-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150804104300.1b191...@ulf.tvoe.tv

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


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

Хотя... В страницах?
"amount of free and file-backed pages is less
than the high water mark in a zone"


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55bfc939.4090...@yandex.ru

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


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-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55bfc8e2.1060...@yandex.ru

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


On 03.08.2015 22:50, Vasiliy P. Melnik wrote:

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



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



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

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


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55bfc87a.7040...@yandex.ru

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

2015-08-03 Пенетрантность Vasiliy P. Melnik


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 sharedbuffers cached
Mem:   19G19G   254M   188M   711M   3,7G
-/+ buffers/cache:14G   4,7G
Swap:  29G   5,3G24G

Сделал, как рекомендовали, немного поменялось (сбросил дисковые буфера):
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 sharedbuffers cached
Mem:   19G14G   5,3G   188M   8,4M   584M
-/+ buffers/cache:13G   5,9G
Swap:  29G   5,3G24G



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

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


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

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


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

Ошибки пока не было, но проскакивает что-то нездоровое:
Aug  2 23:01:58 dana kernel: [202584.677536] ata3.01: exception Emask 0x10 SAct 
0x0 SErr 0x400 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 200312/14/2010
Aug  3 19:01:11 dana kernel: [202669.471888]  88052e9abc70 81579361 
002000d0 810d32a9
Aug  3 19:01:11 dana kernel: [202669.471890]  0002 002000d0 
0002 810df991
Aug  3 19:01:11 dana kernel: [202669.471892]  000590b3  
0020 
Aug  3 19:01:11 dana kernel: [202669.471893] Call Trace:
Aug  3 19:01:11 dana kernel: [202669.471899]  [] ? 
dump_stack+0x41/0x51
Aug  3 19:01:11 dana kernel: [202669.471903]  [] ? 
warn_alloc_failed+0xd9/0x130
Aug  3 19:01:11 dana kernel: [202669.471906]  [] ? 
try_to_free_pages+0x91/0xa0
Aug  3 19:01:11 dana kernel: [202669.471908]  [] ? 
__alloc_pages_nodemask+0x588/0xc10
Aug  3 19:01:11 dana kernel: [202669.471911]  [] ? 
copy_process.part.38+0x11d/0x1a10
Aug  3 19:01:11 dana kernel: [202669.471913]  [] ? 
kthread_create_on_node+0x170/0x170
Aug  3 19:01:11 dana kernel: [202669.471914]  [] ? 
do_fork+0xd4/0x380
Aug  3 19:01:11 dana kernel: [202669.471916]  [] ? 
__schedule+0x272/0x7a0
Aug  3 19:01:11 dana kernel: [202669.471918]  [] ? 
kernel_thread+0x1d/0x20
Aug  3 19:01:11 dana kernel: [202669.471919]  [] ? 
kthreadd+0x150/0x1a0
Aug  3 19:01:11 dana kernel: [202669.471921]  [] ? 
kthread_create_on_cpu+0x40/0x40
Aug  3 19:01:11 dana kernel: [202669.471923]  [] ? 
ret_from_fork+0x58/0x90
Aug  3 19:01:11 d

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

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


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

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


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 : tunables: 
slabdata   

nf_conntrack_8803e50b6780  0  0312   262 : tunables0
00 : slabdata  0  0  0
nvidia_stack_t   130140  1228828 : tunables000 : 
slabdata 70 70  0
kvm_async_pf   0  0136   301 : tunables000 : 
slabdata  0  0  0
kvm_vcpu   0  0  1625628 : tunables000 : 
slabdata  0  0  0
kvm_mmu_page_header  0  0168   241 : tunables000 : 
slabdata  0  0  0
ext4_groupinfo_4k   8832   8876144   281 : tunables000 : 
slabdata317317  0
UDPLITEv6  0  0   1088   308 : tunables000 : 
slabdata  0  0  0
UDPv6120120   1088   308 : tunables000 : 
slabdata  4  4  0
tw_sock_TCPv6  0 21192   211 : tunables000 : 
slabdata  1  1  0
TCPv6 68 68   1920   178 : tunables000 : 
slabdata  4  4  0
nf_conntrack_8186c740368442312   262 : tunables0
00 : slabdata 17 17  0
kcopyd_job 0  0   331298 : tunables000 : 
slabdata  0  0  0
dm_uevent  0  0   2632   128 : tunables000 : 
slabdata  0  0  0
dm_rq_target_io0  0408   202 : tunables000 : 
slabdata  0  0  0
scsi_cmd_cache   110126384   212 : tunables000 : 
slabdata  6  6  0
bsg_cmd0  0312   262 : tunables000 : 
slabdata  0  0  0
mqueue_inode_cache 36 36896   368 : tunables000 : 
slabdata  1  1  0
fuse_request 156156416   394 : tunables000 : 
slabdata  4  4  0
fuse_inode   359483768   214 : tunables000 : 
slabdata 23 23  0
hugetlbfs_inode_cache 29 56576   284 : tunables000 
: slabdata  2  2  0
jbd2_journal_handle340340 48   851 : tunables000 : 
slabdata  4  4  0
jbd2_journal_head972972112   361 : tunables000 : 
slabdata 27 27  0
jbd2_revoke_table_s262768 16  2561 : tunables000 : 
slabdata  3  3  0
jbd2_revoke_record_s768   1024 32  1281 : tunables000 : 
slabdata  8  8  0
ext4_inode_cache5495  29536   1000   328 : tunables000 : 
slabdata923923  0
ext4_free_data  1152   1152 64   641 : tunables000 : 
slabdata 18 18  0
ext4_allocation_context128128128   321 : tunables00
0 : slabdata  4  4  0
ext4_io_end  728728 72   561 : tunables000 : 
slabdata 13 13  0
ext4_extent_status   4794   4794 40  1021 : tunables000 : 
slabdata 47 47  0
configfs_dir_cache  0 46 88   461 : tunables000 : 
slabdata  1  1  0
dquot448448256   322 : tunables000 : 
slabdata 14 14  0
pid_namespace 15 15   2184   158 : tunables000 : 
slabdata  1  1  0
posix_timers_cache  0  0248   332 : tunables000 : 
slabdata  0  0  0
UDP-Lite   0  0896   368 : tunables000 : 
slabdata  0  0  0
flow_cache 0  0104   391 : tunables000 : 
slabdata  0  0  0
xfrm_dst_cache 0  0448   364 : tunables000 : 
slabdata  0  0  0
ip_fib_trie   88292 56   731 : tunables000 : 
slabdata  4  4  0
UDP  144144896   368 : tunables000 : 
slabdata  4  4  0
tw_sock_TCP  147147192   211 : tunables000 : 
slabdata  7  7  0
TCP  168234   1792   188 : tunables000 : 
slabdata 13 13  0
fscache_cookie_jar  0  0 80   511 : tunables000 : 
slabdata  0  0  0
scsi_data_buffer   0  0 24  1701 : tunables000 : 
slabdat

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


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-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55bfc404.4050...@yandex.ru

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

2015-08-03 Пенетрантность 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-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55bfc48f.3060...@gmail.com

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


On 03.08.2015 14:12, Илья wrote:

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

Да.


Я считаю, что на больших объемах ОЗУ можно вообще отказаться от свопа

Да, я думал над этим, но тогда RAM потребуется ещё больше.
Тем не менее, своп у меня, в основном требуется для hibernate.


а для hibernate использовать либо свой pm hook (swapon,swapoff)

А вот это идея. Насчёт хуков я не подумал.
Только вот какие побочные эффекты могут быть?


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

Почитаю в конце недели эту документацию, в том числе и про overcommit_*: пока 
времени нет.


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55bfc380.8020...@yandex.ru

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

2015-08-03 Пенетрантность Anatoly Pugachev


On 03.08.2015 11:45, Anatoly Pugachev wrote:

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


  total   used   free sharedbuffers cached
Память:2063884 8268921236992   1064  17720  85756
-/+ буферы/кэш: 7234161340468
Подкачка:22425562240568   1988
...



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

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

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


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55bfc2ab.3070...@yandex.ru

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

2015-08-03 Пенетрантность Tim Sattarov

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

В конкретно этой ситуации можно сделать системный своп в файл
а hibernate/resume  направить на свап партицию.



smime.p7s
Description: S/MIME Cryptographic Signature

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

2015-08-03 Пенетрантность Илья

Я делал синтетические тесты - в реальности у меня таких проблем не возникает.Будет свободное время попробую, но... Как я понял этот параметр действует по направлению ram -> swap, а не обратно.Я считаю, что на больших объемах ОЗУ можно вообще отказаться от свопа ,а для hibernate использовать либо свой pm hook (swapon,swapoff), либо какой тоспецифический параметр виртуальной памяти, что то типа overcommit_ratio.  -- С уважением, Илья.03.08.2015, 11:45, "Anatoly Pugachev" :2015-08-03 9:24 GMT+03:00 Илья : total   used   free shared    buffers cachedПамять:    2063884 826892    1236992   1064  17720  85756-/+ буферы/кэш: 723416    1340468Подкачка:    2242556    2240568   1988...а не пробовали vm.swappiness (sysctl) менять? по умолчанию вроде 60 , поставьте в диапазоне 1-5

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

2015-08-03 9:24 GMT+03:00 Илья :

>
>  total   used   free sharedbuffers cached
> Память:2063884 8268921236992   1064  17720  85756
> -/+ буферы/кэш: 7234161340468
> Подкачка:22425562240568   1988
> ...
>


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

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

2015-08-02 Пенетрантность Илья

Случайно выяснилось (при освобождении памяти), что такая ошибка возникает в 3 случае.pm-suspend.log:Initial commandline parameters: Пн. авг.  3 00:17:36 MSK 2015: Running hooks for hibernate.Running hook /usr/lib/pm-utils/sleep.d/000kernel-change hibernate hibernate:... total   used   free shared    buffers cachedПамять:    2063884 826892    1236992   1064  17720  85756-/+ буферы/кэш: 723416    1340468Подкачка:    2242556    2240568   1988...Пн. авг.  3 00:17:38 MSK 2015: performing hibernatetest0test1sh: echo: I/O error < sudo mcedit /usr/lib/pm-utils/pm-functions: echo -n "disk" > /sys/power/statetest2Пн. авг.  3 00:17:44 MSK 2015: Awake.Пн. авг.  3 00:17:44 MSK 2015: Running hooks for thaw.. /var/log/kern.log:Aug  3 00:17:42 lapf5v kernel: [ 5909.475478] PM: Syncing filesystems ... done.Aug  3 00:17:42 lapf5v kernel: [ 5909.659265] PM: Marking nosave pages: [mem 0x0009f000-0x000f]Aug  3 00:17:42 lapf5v kernel: [ 5909.659270] PM: Basic memory bitmaps createdAug  3 00:17:42 lapf5v kernel: [ 5909.659324] PM: Preallocating image memory... done (allocated 284499 pages)Aug  3 00:17:42 lapf5v kernel: [ 5910.158895] PM: Allocated 1137996 kbytes in 0.49 seconds (2322.44 MB/s) Aug  3 00:17:42 lapf5v kernel: [ 5910.900045] PM: freeze of devices complete after 478.746 msecsAug  3 00:17:42 lapf5v kernel: [ 5910.900330] PM: late freeze of devices complete after 0.281 msecsAug  3 00:17:42 lapf5v kernel: [ 5910.900722] PM: noirq freeze of devices complete after 0.389 msecsAug  3 00:17:42 lapf5v kernel: [ 5911.004195] PM: Saving platform NVS memoryAug  3 00:17:42 lapf5v kernel: [ 5911.004830] PM: Creating hibernation image:Aug  3 00:17:42 lapf5v kernel: [ 5911.008006] PM: Need to copy 189571 pagesAug  3 00:17:42 lapf5v kernel: [ 5911.008006] PM: Normal pages needed: 43044 + 1024, available pages: 185168Aug  3 00:17:42 lapf5v kernel: [ 5911.008006] PM: Hibernation image created (189571 pages copied) <== Образ для записи созданAug  3 00:17:42 lapf5v kernel: [ 5911.008006] PM: noirq thaw of devices complete after 0.166 msecsAug  3 00:17:42 lapf5v kernel: [ 5911.008006] PM: early thaw of devices complete after 0.080 msecsAug  3 00:17:42 lapf5v kernel: [ 5912.177656] PM: thaw of devices complete after 1169.799 msecsAug  3 00:17:42 lapf5v kernel: [ 5912.177929] PM: writing image.Aug  3 00:17:42 lapf5v kernel: [ 5912.177955] PM: Cannot get swap writer <= Ошибка и выход из режимаAug  3 00:17:42 lapf5v kernel: [ 5912.244205] PM: Basic memory bitmaps freed Это вобще странно, памяти свободной по хоть забалуйся, но нет места в свопе. Почему из свопа не выгружается? Так, что сам себе ответил на ранее поставленый вопрос (о забитом свопе).Лечится "очисткой" свапа (swapoff -a && swapon -a).  -- С уважением, Илья.03.08.2015, 00:18, "Илья" : я думаю это ругается /usr/lib/pm-utils/pm-functions: При выборе режима сна? С чего бы?Я смог вызвать эту ошибку двумя способами (выдает именно это сообщение sh: echo: I/O error):1) swapoff -a но тут понятно - система даже "ругается".2) забивал всю память, добиваясь заполнения свопа . Тут странно. Если полностьюзаполнить всю память - в "сон" не уходит и в системных логах нет никаких следов: Если, места чуть есть (но не достаточно)то выводит прогресс сжатия/записи образа и прервывется с сообщением сколько времени ушло на операцию и какова скорость записи.

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

2015-08-02 Пенетрантность Aleksandr Sytar

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

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

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

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

2015-08-02 Пенетрантность Артём Н.

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-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55be2d22.2010...@yandex.ru

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

2015-08-02 Пенетрантность Артём Н.


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-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55be2bf9.10...@yandex.ru

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

2015-07-31 Пенетрантность ivan demakov

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

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


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

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

-- 
ivan

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

2015-07-30 Пенетрантность Tim Sattarov

On 2015-07-30 14:12, Илья wrote:
> Это 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."
>
>
>
Три ошибки:

1) sync  не вызывает  sh:  и echo: ...
2) ответ с неиспользованием  In-Reply-To: заголовка (ломается тред)
3) ответ напрямую отсылателю письма и в рассылку


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




smime.p7s
Description: S/MIME Cryptographic Signature

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


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-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55ba62d1.2040...@yandex.ru

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

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 вообще кривой, в принципе...

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


On 30.07.2015 16:27, Ста Деюс wrote:

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


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


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

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


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55ba60cb.3000...@yandex.ru

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


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

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

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

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


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


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

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


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55ba602c.2010...@yandex.ru

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


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



--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55ba5f7f.7020...@yandex.ru

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

2015-07-30 Пенетрантность Tim Sattarov

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.

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

smime.p7s
Description: S/MIME Cryptographic Signature

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

On 30.07.2015 17:36, Andrey Melnikoff wrote:

"Артём Н." wrote:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2015-07-30 Пенетрантность Anatoly Pugachev

On 30.07.2015 16:38, Ста Деюс wrote:

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

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

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

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

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

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

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

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

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

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

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

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

2015-07-30 Пенетрантность Ста Деюс

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

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

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

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

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


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


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


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150730200813.4f1c7314@STNset

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

2015-07-30 Пенетрантность Ста Деюс

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

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

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


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


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


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150730195704.7a0e456e@STNset

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

2015-07-30 Пенетрантность Ста Деюс

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


В 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-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150730195422.268c2608@STNset

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

2015-07-29 20:18 GMT+03:00 "Артём Н." :

> 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 sharedbuffers cached
Mem:   40564683454004 602464  0 3475922210568
-/+ buffers/cache: 8958443160624
Swap:  6160376  06160376

 total   used   free sharedbuffers cached
Mem:   4056468 7624843293984  0484  39840
-/+ buffers/cache: 7221603334308
Swap:  6160376  06160376

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

2015-07-29 Пенетрантность Mikhail A Antonov


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-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55b932d1.4010...@yandex.ru

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

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


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



signature.asc
Description: OpenPGP digital signature

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

Самое главное - сумма занятой памяти совпадает ? :)

Сложно сказать: много процессов.

Я бы задумался если нет, попробовал бы проапгрейдить систему ... те же
util-linux.
проверить debsums и прочее.
Подобные данные ввели бы меня в параноидальное состояние и полную
проверку системы, пока не найду что происходит.

Большое потребление памяти прикладными процессами у меня - это нормально.
Одни браузеры занимают кучу памяти, KDE, периодически виртуалки...
На винде на работе тоже firefox жрёт память.

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

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

В основном, там разграничение на уровне ФС: куда разрешено, а куда нет.

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

2015-07-29 Пенетрантность Tim Sattarov

On 2015-07-29 13:34, "Артём Н." wrote:
>> Получается, что те 6.2 гига которые остаются неизменными и есть реально
>> занятая память.
>> надо смотреть кто их занимает.
> 1. XUL паршивый - это то, что жрёт память в огромных масштабах на всех
> платформах.
>Firefox+icedove.
> 2. Chromium.
> 3. Okular.
> 4. Java.
> 5. Mysqld.
> 6. Amarok.
> 7. Прочее.
>

Самое главное - сумма занятой памяти совпадает ? :)
Я бы задумался если нет, попробовал бы проапгрейдить систему ... те же
util-linux.
проверить debsums  и прочее.
Подобные данные ввели бы меня в параноидальное состояние и полную
проверку системы, пока не найду что происходит.

>> У тебя случайно не настроены хитрые приблуды. которые скрывают процессы
>> или как то разделяют права доступа к процессам ?
> Например?
>
ты упоминал  AppArmor,  я с ним не разбирался, но подозреваю там есть
подобные механизмы.

smime.p7s
Description: S/MIME Cryptographic Signature

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


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

1. XUL паршивый - это то, что жрёт память в огромных масштабах на всех 
платформах.
   Firefox+icedove.
2. Chromium.
3. Okular.
4. Java.
5. Mysqld.
6. Amarok.
7. Прочее.


У тебя случайно не настроены хитрые приблуды. которые скрывают процессы
или как то разделяют права доступа к процессам ?

Например?


попробуй прогнать  rkhunter ...

Гоняется автоматом. Кстати, да, вспомнил. Есть preload.
Rkhunter всё-таки ещё раз прогнал: ничего криминального. Лог приложил.


rkhunter.log.gz
Description: application/gzip

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

2015-07-29 Пенетрантность Tim Sattarov

On 2015-07-29 13:16, "Артём Н." wrote:
> Да, сбрасывает.
> Долго пишет.
>
Получается, что те 6.2 гига которые остаются неизменными и есть реально
занятая память.
надо смотреть кто их занимает.
У тебя случайно не настроены хитрые приблуды. которые скрывают процессы
или как то разделяют права доступа к процессам ?
попробуй прогнать  rkhunter ...




smime.p7s
Description: S/MIME Cryptographic Signature

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

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

On 29.07.2015 18:15, aleksey wrote:

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

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

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

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


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


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

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

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


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55b90aea.80...@yandex.ru

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


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


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


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


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

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


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55b90937.6020...@yandex.ru

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

2015-07-29 Пенетрантность Alexander Sitnik


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

root@danroot@dana:/home# free  ; dd if=/dev/zero of=test.dump bs=1024 
count=16353480 ; rm -f test.dump
 total   used   free sharedbuffers cached
Mem:   19G   7,7G11G   335M   666M   1,3G
-/+ buffers/cache:   5,8G13G
Swap:  29G   352M29G
16353480+0 записей получено
16353480+0 записей отправлено
 скопировано 16745963520 байт (17 GB), 181,822 c, 92,1 MB/c
удалён «test.dump»
root@dana:/home# free
 total   used   free sharedbuffers cached
Mem:   19G   6,2G13G   335M   4,0M   465M
-/+ buffers/cache:   5,7G13G
Swap:  29G   350M29G
a:/home# free  ; dd if=/dev/zero of=test.dump bs=1024 count=16353480 ; rm -f 
test.dump
 total   used   free sharedbuffers cached
Mem:   19G   7,7G11G   335M   666M   1,3G
-/+ buffers/cache:   5,8G13G
Swap:  29G   352M29G
16353480+0 записей получено
16353480+0 записей отправлено
 скопировано 16745963520 байт (17 GB), 181,822 c, 92,1 MB/c
удалён «test.dump»
root@dana:/home# free
 total   used   free sharedbuffers cached
Mem:   19G   6,2G13G   335M   4,0M   465M
-/+ buffers/cache:   5,7G13G
Swap:  29G   350M29G


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
   totalusedfree  shared  buff/cache
available
Mem:15G1.0G156M 40M
14G 14G
Swap:   15G  0B 15G
16353280 blocks (15970Mb) written.
16353480+0 records in
16353480+0 records out
   totalusedfree  shared  buff/cache
available
Mem:15G1.0G 13G 40M
1.5G 14G
Swap:   15G  4K 15G


по сути ты создаешь файл размером с память и удаляешь его, это должно
сбросить буфер и освободить память.
Как видно выше у меня кэш сбросился с 14 до 1.5 гигабайта и свободная
память увеличилась с 156М до 13Г.

проверь сбрасываются ли буферы в твоем случае.






--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55b90a8a.8090...@yandex.ru

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

29 июля 2015 г., 18:15 пользователь aleksey  написал:

> 29.07.2015 08:24, "Артём Н." пишет:
> > Т.е., вы хотите сказать, что перед этим кэш сбрасывается на диск и всё
> > ok?
> > В любом случае, запись 10 Гб (да, проблемы с hibernate начинаются
> > после долгой работы),
> > не быстрая процедура. Собственно, мне такого не надо.
> Система периодически сбрасывает незаписанные данные из кэша на диск. И я
> сильно сомневаюсь, что у вас данные для записи постоянно накапливаются.
> Иначе я бы постоянно терял свои данные на своих дисках, т.к. у меня
> регулярно случаются проблемы с электропитанием. Так что длительная
> запись данных перед выключением вам не грозит.
>
>
> Как правильно отметил Алексей, большая часть данных в этом кеше -- уже
сброшены на диск, система это делает постоянно.
Для принудительного сброса кеша вполне стандартный способ:
sudo sh -c 'echo 1 > /proc/sys/vm/drop_caches'.
После этого посмотри вывод free и попробуй запустить гибернацию.


-- 
Alexander Sitnik

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

2015-07-29 Пенетрантность aleksey

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


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55B8EDFE.3090406@localhost

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

2015-07-29 Пенетрантность Andrey Melnikoff

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

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

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

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




-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/0c6n8c-lrl@woofie.cef.spbstu.ru

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

2015-07-29 Пенетрантность Tim Sattarov

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
  totalusedfree  shared  buff/cache  
available
Mem:15G1.0G156M 40M
14G 14G
Swap:   15G  0B 15G
16353280 blocks (15970Mb) written.
16353480+0 records in
16353480+0 records out
  totalusedfree  shared  buff/cache  
available
Mem:15G1.0G 13G 40M   
1.5G 14G
Swap:   15G  4K 15G

по сути ты создаешь файл размером с память и удаляешь его, это должно
сбросить буфер и освободить память.
Как видно выше у меня кэш сбросился с 14 до 1.5 гигабайта и свободная
память увеличилась с 156М до 13Г.

проверь сбрасываются ли буферы в твоем случае.

smime.p7s
Description: S/MIME Cryptographic Signature

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


Да, забыл сказать.
Последнее время я использую не pm-hibernate, а пункт меню "Спящий режим" в KDE.
В логи, вероятно, при этом ничего не пишется (но проблема уже давно):
-rw-r--r-- 1 root root0 июн 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 root0 июн 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-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55b8684b.2080...@yandex.ru

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


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

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


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

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

А по ограничению кэша я пока ничего не нашёл (вечером ещё посмотрю, что сделать 
возможно).

-- Посмотрите журналы

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


Ошибки есть, но ничего криминального я не нашёл. Приложил логи, на всякий 
случай.
Initial commandline parameters: 
Ср июн 24 20:09:31 MSK 2015: Running hooks for hibernate.
Running hook /usr/lib/pm-utils/sleep.d/000kernel-change hibernate hibernate:
/usr/lib/pm-utils/sleep.d/000kernel-change hibernate hibernate: success.

Running hook /usr/lib/pm-utils/sleep.d/00logging hibernate hibernate:
Linux dana 3.16.7-ckt9 #4 SMP Sat May 9 08:21:21 MSK 2015 x86_64 GNU/Linux
Module  Size  Used by
xts 2831  1 
gf128mul5490  1 xts
st 34185  0 
parport_pc 18948  0 
udp_diag2189  0 
tcp_diag1000  0 
inet_diag   9668  2 tcp_diag,udp_diag
ip6table_filter 1348  0 
ip6_tables 16385  1 ip6table_filter
pci_stub1301  1 
vboxpci13523  0 
vboxnetadp 18035  0 
vboxnetflt 16100  0 
vboxdrv   331509  3 vboxnetadp,vboxnetflt,vboxpci
tun19173  0 
xt_multiport1646  6 
ebt_snat1212  0 
ebt_dnat1084  0 
ebtable_nat 1772  0 
ebtables   22802  1 ebtable_nat
xt_nat  1793  0 
nf_nat_sip  8357  0 
nf_nat_irc  1390  0 
nf_nat_amanda   1168  0 
nf_nat_ftp  1652  0 
nf_nat_proto_sctp   1187  0 
libcrc32c922  1 nf_nat_proto_sctp
nf_nat_proto_udplite 1113  0 
nf_nat_tftp  910  0 
nf_nat_snmp_basic   7320  0 
nf_nat_h323 5999  0 
iptable_nat 2670  0 
nf_nat_pptp 2138  0 
nf_nat_proto_gre1269  1 nf_nat_pptp
nf_nat_ipv4 3328  1 iptable_nat
nf_nat 11282  13 
nf_nat_ftp,nf_nat_irc,nf_nat_sip,nf_nat_amanda,nf_nat_proto_udplite,nf_nat_proto_gre,nf_nat_h323,nf_nat_ipv4,nf_nat_pptp,nf_nat_tftp,xt_nat,nf_nat_proto_sctp,iptable_nat
act_nat 3421  0 
nf_conntrack_pptp   3874  1 nf_nat_pptp
nf_conntrack_proto_gre 3844  1 nf_conntrack_pptp
nf_conntrack_tftp   3841  1 nf_nat_tftp
nf_conntrack_proto_udplite 3551  0 
nf_conntrack_h323  43411  1 nf_nat_h323
xt_conntrack3153  17 
nf_conntrack_proto_sctp 7958  0 
nf_conntrack_netbios_ns 1061  0 
nf_conntrack_ftp6735  1 nf_nat_ftp
nf_conntrack_sip   20981  1 nf_nat_sip
nf_conntrack_irc3675  1 nf_nat_irc
nf_conntrack_snmp   1195  1 nf_nat_snmp_basic
nf_conntrack_broadcast 1109  2 nf_conntrack_netbios_ns,nf_conntrack_snmp
nf_conntrack_netlink22850  0 
nfnetlink   4861  1 nf_conntrack_netlink
ts_kmp  1791  5 
nf_conntrack_amanda 2461  1 nf_nat_amanda
nf_conntrack_ipv4  12154  18 
nf_defrag_ipv4  1291  1 nf_conntrack_ipv4
nvidia  10496043  49 
uvcvideo   71382  0 
snd_usb_audio 119942  1 
videobuf2_vmalloc   2648  1 uvcvideo
snd_usbmidi_lib18596  1 snd_usb_audio
videobuf2_memops1647  1 videobuf2_vmalloc
snd_rawmidi17910  1 snd_usbmidi_lib
videobuf2_core 22815  1 uvcvideo
cdc_acm18274  0 
joydev  9903  0 
kvm_intel 126789  0 
kvm   278904  1 kvm_intel
serio_raw   4289  0 
acpi_cpufreq6634  0 
ppdev   5534  0 
parport29301  2 ppdev,parport_pc
ecb 1865  0 
algif_skcipher  5859  0 
af_alg  4748  1 algif_skcipher
dm_mirror  12595  0 
dm_region_hash  6559  1 dm_mirror
dm_log  8083  2 dm_region_hash,dm_mirror
drm   229879  3 nvidia
uas16882  0 
crc32c_intel   13817  1 
 total   used   free sharedbuffers cached
Mem:  20516700   154416885075012 429416 4216526526504
-/+ buffers/cache:8493532   12023168
Swap: 31264596  0   31264596
/usr/lib/pm-utils/sleep.d/00logging hibernate hibernate: success.

Running hook /etc/pm/sleep.d/00plymouth hibernate hibernate:
/etc/pm/sleep.d/00plymouth hibernate hibernate: not executable.

Running hook /usr/lib/pm-utils/sleep.d/00powersave hibernate hibernate:
/usr/lib/pm-utils/sleep.d/00powersave hibernate hib

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


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-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55b86565.8090...@yandex.ru

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

2015-07-27 Пенетрантность Mikhail A Antonov


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

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


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

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


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55b86183.30...@yandex.ru

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

2015-07-27 Пенетрантность Ста Деюс

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


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

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

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

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


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


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


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150728131319.6ba2db26@STNset

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

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 "Артём Н." > >:
>>
>> Почему-то система использует 15 Гб памяти.
>>
>> root@dana:~# free
>>   total   used   free sharedbuffers 
>> cached
>> Mem:   19G15G   4,5G   328M   931M   8,8G
>
>


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



signature.asc
Description: OpenPGP digital signature

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

2015-07-27 Пенетрантность Tim Sattarov



On 2015-07-27 15:41, "Артём Н." wrote:
> On 27.07.2015 21:38, Max Dmitrichenko wrote:
>> в последней колонке cached  8,8G
>>
> Ну, так подо что cached?
>
http://www.linuxatemyram.com/
>> 2015-07-27 21:14 GMT+03:00 "Артём Н." > >:
>>
>> Почему-то система использует 15 Гб памяти.
>>
>> root@dana:~# free
>>   total   used   free shared   
>> buffers cached
>> Mem:   19G15G   4,5G   328M  
>> 931M   8,8G
>
>



smime.p7s
Description: S/MIME Cryptographic Signature

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


On 27.07.2015 21:38, Max Dmitrichenko wrote:

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


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


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

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

root@dana:~# free
  total   used   free sharedbuffers cached
Mem:   19G15G   4,5G   328M   931M   8,8G



--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55b68974.7010...@yandex.ru

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


On 27.07.2015 21:51, Tim Sattarov wrote:

On 2015-07-27 14:38, Max Dmitrichenko wrote:

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


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


И..?


# free -h
   totalusedfree  shared  buff/cache
available
Mem:15G899M2.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-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55b68949.6090...@yandex.ru

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


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-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55b68a47.5060...@yandex.ru

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

2015-07-27 Пенетрантность Max Dmitrichenko


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

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


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55b688c3.2030...@yandex.ru

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

2015-07-27 Пенетрантность Tim Sattarov

On 2015-07-27 14:38, Max Dmitrichenko wrote:
> в последней колонке cached  8,8G
>
Это был мой первый ответ.
но потом я посмотрел на вывод своего free:

# free -h
  totalusedfree  shared  buff/cache  
available
Mem:15G899M2.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




smime.p7s
Description: S/MIME Cryptographic Signature

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

2015-07-27 Пенетрантность dimas

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


2015-208 21:14 Артём Н.  wrote:
> Почему-то система использует 15 Гб памяти.
> 
> root@dana:~# free
>   total   used   free sharedbuffers cached
> Mem:   19G15G   4,5G   328M   931M   8,8G
> -/+ buffers/cache:   5,4G14G
> Swap:  29G 0B29G
> 
> После убийства процессов, требовательных к памяти (firefox, chromium,
> icedove), остаются использованными 14-10 Гб. Куда она утекает? Под
> какой-нибудь кэш? Как это понять?
> Проблема в том, что hibernate, при таком использовании сбоит.
> 
> root@dana:~# for i in $(mount|grep tmp|cut -f3 -d' '); do df $i; done
> Файловая система Тип  Размер Использовано  Дост Использовано%
> Cмонтировано в udev devtmpfs10M0   10M
> 0% /dev Файловая система Тип   Размер Использовано  Дост Использовано%
> Cмонтировано в tmpfstmpfs   4,0G  11M  4,0G
> 1% /run Файловая система Тип   Размер Использовано  Дост Использовано%
> Cмонтировано в tmpfstmpfs   9,8G 2,5M  9,8G
> 1% /dev/shm Файловая система Тип   Размер Использовано  Дост Использовано%
> Cмонтировано в tmpfstmpfs   5,0M 8,0K  5,0M
> 1% /run/lock Файловая система Тип   Размер Использовано  Дост Использовано%
> Cмонтировано в tmpfstmpfs   9,8G0  9,8G
> 0% /sys/fs/cgroup Файловая система Тип   Размер Использовано  Дост
> Использовано% Cмонтировано в tmpfstmpfs   9,8G 524K
> 9,8G1% /tmp Файловая система Тип   Размер Использовано  Дост
> Использовано% Cмонтировано в tmpfstmpfs   2,0G 8,0K
> 2,0G1% /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  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
> 23207 artiom20   0 1288736 514472  86708 S   6,5  2,5   1:33.34 firefox
> 22312 artiom20   0  875040 325572  78016 S   0,0  1,6   0:08.76 icedove
> 10634 artiom20   0 3457612 260240  89112 S   0,0  1,3   2:46.30 kwin
> 10643 artiom20   0 3848900 230240  96120 S   0,0  1,1   3:17.86
> plasma-desktop 10644 artiom20   0 1705204 153260  85784 S   0,0  0,7
> 0:04.85 krunner 12416 artiom20   0  649636 147952  56164 S   0,0  0,7
> 0:01.80 okular 12414 artiom20   0  632840 145124  54504 S   0,0  0,7
> 0:02.06 okular 12391 artiom20   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 artiom20   0  652940 140332  56860 S   0,0  0,7
> 0:03.14 okular 12387 artiom20   0  616188 137692  54480 S   0,0  0,7
> 0:01.68 okular 12402 artiom20   0  649284 137128  56416 S   0,0  0,7
> 0:02.31 okular 12403 artiom20   0  650740 136324  56416 S   0,0  0,7
> 0:02.32 okular 12377 artiom20   0  614464 136136  54508 S   0,0  0,7
> 0:02.18 okular
> 
> 


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150727213819.24654...@ulf.tvoe.tv

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

2015-07-27 Пенетрантность Tim Sattarov


On 2015-07-27 14:14, "Артём Н." wrote:
> Почему-то система использует 15 Гб памяти.
>
> root@dana:~# free
>  total   used   free sharedbuffers cached
> Mem:   19G15G   4,5G   328M   931M   8,8G
> -/+ buffers/cache:   5,4G14G
> Swap:  29G 0B29G
посмотри какой процесс пользует память ...
ps axo %mem,cmd k -%mem | grep -v "0.0"




smime.p7s
Description: S/MIME Cryptographic Signature

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

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

2015-07-27 21:14 GMT+03:00 "Артём Н." :

> Почему-то система использует 15 Гб памяти.
>
> root@dana:~# free
>  total   used   free sharedbuffers cached
> Mem:   19G15G   4,5G   328M   931M   8,8G
> -/+ buffers/cache:   5,4G14G
> Swap:  29G 0B29G
>
> После убийства процессов, требовательных к памяти (firefox, chromium,
> icedove), остаются использованными 14-10 Гб.
> Куда она утекает? Под какой-нибудь кэш?
> Как это понять?
> Проблема в том, что hibernate, при таком использовании сбоит.
>
> root@dana:~# for i in $(mount|grep tmp|cut -f3 -d' '); do df $i; done
> Файловая система Тип  Размер Использовано  Дост Использовано%
> Cмонтировано в
> udev devtmpfs10M0   10M0% /dev
> Файловая система Тип   Размер Использовано  Дост Использовано%
> Cмонтировано в
> tmpfstmpfs   4,0G  11M  4,0G1% /run
> Файловая система Тип   Размер Использовано  Дост Использовано%
> Cмонтировано в
> tmpfstmpfs   9,8G 2,5M  9,8G1% /dev/shm
> Файловая система Тип   Размер Использовано  Дост Использовано%
> Cмонтировано в
> tmpfstmpfs   5,0M 8,0K  5,0M1% /run/lock
> Файловая система Тип   Размер Использовано  Дост Использовано%
> Cмонтировано в
> tmpfstmpfs   9,8G0  9,8G0%
> /sys/fs/cgroup
> Файловая система Тип   Размер Использовано  Дост Использовано%
> Cмонтировано в
> tmpfstmpfs   9,8G 524K  9,8G1% /tmp
> Файловая система Тип   Размер Использовано  Дост Использовано%
> Cмонтировано в
> tmpfstmpfs   2,0G 8,0K  2,0G1%
> /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  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
> 23207 artiom20   0 1288736 514472  86708 S   6,5  2,5   1:33.34 firefox
> 22312 artiom20   0  875040 325572  78016 S   0,0  1,6   0:08.76 icedove
> 10634 artiom20   0 3457612 260240  89112 S   0,0  1,3   2:46.30 kwin
> 10643 artiom20   0 3848900 230240  96120 S   0,0  1,1   3:17.86
> plasma-desktop
> 10644 artiom20   0 1705204 153260  85784 S   0,0  0,7   0:04.85 krunner
> 12416 artiom20   0  649636 147952  56164 S   0,0  0,7   0:01.80 okular
> 12414 artiom20   0  632840 145124  54504 S   0,0  0,7   0:02.06 okular
> 12391 artiom20   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 artiom20   0  652940 140332  56860 S   0,0  0,7   0:03.14 okular
> 12387 artiom20   0  616188 137692  54480 S   0,0  0,7   0:01.68 okular
> 12402 artiom20   0  649284 137128  56416 S   0,0  0,7   0:02.31 okular
> 12403 artiom20   0  650740 136324  56416 S   0,0  0,7   0:02.32 okular
> 12377 artiom20   0  614464 136136  54508 S   0,0  0,7   0:02.18 okular
>
>
> --
> To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/55b6750f.4070...@yandex.ru
>
>


-- 
--
With best regards
  Max Dmitrichenko

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