Re: Утекает память
On 2015-08-03 07:12, Илья wrote: Я считаю, что на больших объемах ОЗУ можно вообще отказаться от свопа , а для hibernate использовать либо свой pm hook (swapon,swapoff), либо какой то специфический параметр виртуальной памяти, что то типа overcommit_ratio. В конкретно этой ситуации можно сделать системный своп в файл а hibernate/resume направить на свап партицию. smime.p7s Description: S/MIME Cryptographic Signature
[DONE] wml://security/2015/dsa-332{3,4,5}.wml
Cheers! Lev Lamberov --- english/security/2015/dsa-3323.wml 2015-08-03 02:13:09.0 +0500 +++ russian/security/2015/dsa-3323.wml 2015-08-03 13:57:54.946927317 +0500 @@ -1,54 +1,56 @@ -define-tag descriptionsecurity update/define-tag +#use wml::debian::translation-check translation=1.1 maintainer=Lev Lamberov +define-tag descriptionобновление безопасности/define-tag define-tag moreinfo -pSeveral vulnerabilities were discovered in the International Components -for Unicode (ICU) library./p +pВ библиотеке международных компонентов для Юникода (ICU) +было обнаружено несколько уязвимостей./p ul lia href=https://security-tracker.debian.org/tracker/CVE-2014-8146;CVE-2014-8146/a -pThe Unicode Bidirectional Algorithm implementation does not properly -track directionally isolated pieces of text, which allows remote -attackers to cause a denial of service (heap-based buffer overflow) -or possibly execute arbitrary code via crafted text./p/li +pДвунаправленный алгоритм Юникода неправильно отслеживает +изолированные в плане направления части текста, что позволяет удалённым +злоумышленникам вызвать отказ в обслуживании (переполнение динамической памяти) +или выполнить произвольный код с помощью специально сформированного текста./p/li lia href=https://security-tracker.debian.org/tracker/CVE-2014-8147;CVE-2014-8147/a -pThe Unicode Bidirectional Algorithm implementation uses an integer -data type that is inconsistent with a header file, which allows -remote attackers to cause a denial of service (incorrect malloc -followed by invalid free) or possibly execute arbitrary code via -crafted text./p/li +pРеализация двунаправленного алгоритма Юникода используется целочисленный тип +данных, что несовместимо с заголовочным файлом, это позволяет +удалённым злоумышленникам вызывать отказ в обслуживании (некорректное выделение +памяти, следующее за неправильным освобождением памяти) или выполнить произвольный код с помощью +специально сформированного текста./p/li lia href=https://security-tracker.debian.org/tracker/CVE-2015-4760;CVE-2015-4760/a -pThe Layout Engine was missing multiple boundary checks. These could -lead to buffer overflows and memory corruption. A specially crafted -file could cause an application using ICU to parse untrusted font -files to crash and, possibly, execute arbitrary code./p/li +pВ движке разметки отсутствуют многочисленные проверки границ массивов. Это может +приводить к переполнению буфера и порче содержимого памяти. С помощью специально +сформированного файла, переданного приложению, использующему ICU для выполнения грамматического разбора недоверенных файлов +шрифтов, можно аварийно завершить работу этого приложения и выполнить произвольный код./p/li /ul -pAdditionally, it was discovered that the patch applied to ICU in DSA-3187-1 -for a href=https://security-tracker.debian.org/tracker/CVE-2014-6585;CVE-2014-6585/a was incomplete, possibly leading to an invalid memory -access. This could allow remote attackers to disclose portion of private -memory via crafted font files./p +pКроме того, было обнаружено, что заплата, применённая к ICU в DSA-3187-1 +для исправления a href=https://security-tracker.debian.org/tracker/CVE-2014-6585;CVE-2014-6585/a, была недостаточной, что может приводить к неправильному +доступу к содержимому памяти. Это может позволить удалённым злоумышленникам раскрыть часть закрытой +памяти при помощи специально сформированных файлов шрифтов./p -pFor the oldstable distribution (wheezy), these problems have been fixed -in version 4.8.1.1-12+deb7u3./p +pВ предыдущем стабильном выпуске (wheezy) эти проблемы были исправлены +в версии 4.8.1.1-12+deb7u3./p -pFor the stable distribution (jessie), these problems have been fixed in -version 52.1-8+deb8u2./p +pВ стабильном выпуске (jessie) эти проблемы были исправлены в +версии 52.1-8+deb8u2./p -pFor the testing distribution (stretch), these problems have been fixed -in version 52.1-10./p +pВ тестируемом выпуске (stretch) эти проблемы были исправлены +в версии 52.1-10./p -pFor the unstable distribution (sid), these problems have been fixed in -version 52.1-10./p +pВ нестабильном выпуске (sid) эти проблемы были исправлены в +версии 52.1-10./p -pWe recommend that you upgrade your icu packages./p +pРекомендуется обновить пакеты icu./p /define-tag # do not modify the following line #include $(ENGLISHDIR)/security/2015/dsa-3323.data # $Id: dsa-3323.wml,v 1.1 2015/08/02 21:13:09 gusnan Exp $ + --- english/security/2015/dsa-3324.wml 2015-08-03 02:14:55.0 +0500 +++ russian/security/2015/dsa-3324.wml 2015-08-03 14:01:24.103883104 +0500 @@ -1,24 +1,26 @@ -define-tag descriptionsecurity update/define-tag +#use wml::debian::translation-check translation=1.1 maintainer=Lev Lamberov +define-tag descriptionобновление безопасности/define-tag define-tag moreinfo -pMultiple security issues have been found in
Re: [DONE] wml://security/2015/dsa-332{3,4,5}.wml
On Mon, Aug 03, 2015 at 02:14:45PM +0500, Lev Lamberov wrote: Cheers! Lev Lamberov --- english/security/2015/dsa-3323.wml2015-08-03 02:13:09.0 +0500 +++ russian/security/2015/dsa-3323.wml2015-08-03 13:57:54.946927317 +0500 @@ -1,54 +1,56 @@ -define-tag descriptionsecurity update/define-tag +#use wml::debian::translation-check translation=1.1 maintainer=Lev Lamberov +define-tag descriptionобновление безопасности/define-tag define-tag moreinfo -pSeveral vulnerabilities were discovered in the International Components -for Unicode (ICU) library./p +pВ библиотеке международных компонентов для Юникода (ICU) +было обнаружено несколько уязвимостей./p ul lia href=https://security-tracker.debian.org/tracker/CVE-2014-8146;CVE-2014-8146/a -pThe Unicode Bidirectional Algorithm implementation does not properly -track directionally isolated pieces of text, which allows remote -attackers to cause a denial of service (heap-based buffer overflow) -or possibly execute arbitrary code via crafted text./p/li +pДвунаправленный алгоритм Юникода неправильно отслеживает +изолированные в плане направления части текста, что позволяет удалённым +злоумышленникам вызвать отказ в обслуживании (переполнение динамической памяти) +или выполнить произвольный код с помощью специально сформированного текста./p/li lia href=https://security-tracker.debian.org/tracker/CVE-2014-8147;CVE-2014-8147/a -pThe Unicode Bidirectional Algorithm implementation uses an integer -data type that is inconsistent with a header file, which allows -remote attackers to cause a denial of service (incorrect malloc -followed by invalid free) or possibly execute arbitrary code via -crafted text./p/li +pРеализация двунаправленного алгоритма Юникода используется целочисленный тип +данных, что несовместимо с заголовочным файлом, это позволяет +удалённым злоумышленникам вызывать отказ в обслуживании (некорректное выделение +памяти, следующее за неправильным освобождением памяти) или выполнить произвольный код с помощью +специально сформированного текста./p/li lia href=https://security-tracker.debian.org/tracker/CVE-2015-4760;CVE-2015-4760/a -pThe Layout Engine was missing multiple boundary checks. These could -lead to buffer overflows and memory corruption. A specially crafted -file could cause an application using ICU to parse untrusted font -files to crash and, possibly, execute arbitrary code./p/li +pВ движке разметки отсутствуют многочисленные проверки границ массивов. Это может +приводить к переполнению буфера и порче содержимого памяти. С помощью специально +сформированного файла, переданного приложению, использующему ICU для выполнения грамматического разбора недоверенных файлов +шрифтов, можно аварийно завершить работу этого приложения и выполнить произвольный код./p/li /ul -pAdditionally, it was discovered that the patch applied to ICU in DSA-3187-1 -for a href=https://security-tracker.debian.org/tracker/CVE-2014-6585;CVE-2014-6585/a was incomplete, possibly leading to an invalid memory -access. This could allow remote attackers to disclose portion of private -memory via crafted font files./p +pКроме того, было обнаружено, что заплата, применённая к ICU в DSA-3187-1 +для исправления a href=https://security-tracker.debian.org/tracker/CVE-2014-6585;CVE-2014-6585/a, была недостаточной, что может приводить к неправильному +доступу к содержимому памяти. Это может позволить удалённым злоумышленникам раскрыть часть закрытой +памяти при помощи специально сформированных файлов шрифтов./p -pFor the oldstable distribution (wheezy), these problems have been fixed -in version 4.8.1.1-12+deb7u3./p +pВ предыдущем стабильном выпуске (wheezy) эти проблемы были исправлены +в версии 4.8.1.1-12+deb7u3./p -pFor the stable distribution (jessie), these problems have been fixed in -version 52.1-8+deb8u2./p +pВ стабильном выпуске (jessie) эти проблемы были исправлены в +версии 52.1-8+deb8u2./p -pFor the testing distribution (stretch), these problems have been fixed -in version 52.1-10./p +pВ тестируемом выпуске (stretch) эти проблемы были исправлены +в версии 52.1-10./p -pFor the unstable distribution (sid), these problems have been fixed in -version 52.1-10./p +pВ нестабильном выпуске (sid) эти проблемы были исправлены в +версии 52.1-10./p -pWe recommend that you upgrade your icu packages./p +pРекомендуется обновить пакеты icu./p /define-tag # do not modify the following line #include $(ENGLISHDIR)/security/2015/dsa-3323.data # $Id: dsa-3323.wml,v 1.1 2015/08/02 21:13:09 gusnan Exp $ + --- english/security/2015/dsa-3324.wml2015-08-03 02:14:55.0 +0500 +++ russian/security/2015/dsa-3324.wml2015-08-03 14:01:24.103883104 +0500 @@ -1,24 +1,26 @@ -define-tag
Re: Утекает память
Случайно выяснилось (при освобождении памяти), что такая ошибка возникает в 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, "Илья" mir...@yandex.ru: я думаю это ругается /usr/lib/pm-utils/pm-functions: При выборе режима сна? С чего бы?Я смог вызвать эту ошибку двумя способами (выдает именно это сообщение sh: echo: I/O error):1) swapoff -a но тут понятно - система даже "ругается".2) забивал всю память, добиваясь заполнения свопа . Тут странно. Если полностьюзаполнить всю память - в "сон" не уходит и в системных логах нет никаких следов: Если, места чуть есть (но не достаточно)то выводит прогресс сжатия/записи образа и прервывется с сообщением сколько времени ушло на операцию и какова скорость записи.
Re: Утекает память
2015-08-03 9:24 GMT+03:00 Илья mir...@yandex.ru: total used free sharedbuffers cached Память:2063884 8268921236992 1064 17720 85756 -/+ буферы/кэш: 7234161340468 Подкачка:22425562240568 1988 ... а не пробовали vm.swappiness (sysctl) менять? по умолчанию вроде 60 , поставьте в диапазоне 1-5
Re: Утекает память
Я делал синтетические тесты - в реальности у меня таких проблем не возникает.Будет свободное время попробую, но... Как я понял этот параметр действует по направлению ram - swap, а не обратно.Я считаю, что на больших объемах ОЗУ можно вообще отказаться от свопа ,а для hibernate использовать либо свой pm hook (swapon,swapoff), либо какой тоспецифический параметр виртуальной памяти, что то типа overcommit_ratio. -- С уважением, Илья.03.08.2015, 11:45, "Anatoly Pugachev" mator...@gmail.com: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
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: Утекает память
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 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: Утекает память
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: Утекает память
On 02.08.2015 20:12, Aleksandr Sytar wrote: Если ядро собрано с поддержкой slab/slub - то кто конкретно держит память можно посмотреть через cat /proc/slabinfo Теоретически там не должно быть записей относительно процессов которые уже выгружены. Собрано с поддержкой, только вот как их этого получить то, что мне надо: root@dana:/home# cat /proc/slabinfo slabinfo - version: 2.1 # nameactive_objs num_objs objsize objperslab pagesperslab : tunables limit batchcount sharedfactor : slabdata active_slabs num_slabs sharedavail 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 :
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 11:45, Anatoly Pugachev wrote: 2015-08-03 9:24 GMT+03:00 Илья mir...@yandex.ru 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: Утекает память
Указывать системе, какой своп юзать (помню, была в fstab опция, позволяющая распределить нагрузку), а hibernate указать UID раздела? Всё же не совсем приятно, что своп будет в файле: там получится три уровня под ним вы столько это обговариваете, что уже можно было пойти купить 16 гигов оперативки и забить на своп
Re: Утекает память
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] [81579361] ?
dump_stack+0x41/0x51
Aug 3 19:01:11 dana kernel: [202669.471903] [810d32a9] ?
warn_alloc_failed+0xd9/0x130
Aug 3 19:01:11 dana kernel: [202669.471906] [810df991] ?
try_to_free_pages+0x91/0xa0
Aug 3 19:01:11 dana kernel: [202669.471908] [810d6f68] ?
__alloc_pages_nodemask+0x588/0xc10
Aug 3 19:01:11 dana kernel: [202669.471911] [81041ebd] ?
copy_process.part.38+0x11d/0x1a10
Aug 3 19:01:11 dana kernel: [202669.471913] [81060e60] ?
kthread_create_on_node+0x170/0x170
Aug 3 19:01:11 dana kernel: [202669.471914] [81043954] ?
do_fork+0xd4/0x380
Aug 3 19:01:11 dana kernel: [202669.471916] [8157aba2] ?
__schedule+0x272/0x7a0
Aug 3 19:01:11 dana kernel: [202669.471918] [81043c1d] ?
kernel_thread+0x1d/0x20
Aug 3 19:01:11 dana kernel: [202669.471919] [810616c0] ?
kthreadd+0x150/0x1a0
Aug 3 19:01:11 dana
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
