LINUX.ORG.RU

Система уходит в своп

 ,


0

2

С обновлением на Xubuntu 15.04 (ядро 3.19) я стал наблюдать очень неприятный эффект: система начинает свопиться и дико тормозить каждый день по утрам.

У меня в рабочем компе 8 Гб памяти, компьютер круглосуточно работает, из жирных программ запущены только Firefox и Thunderbird, которые вместе отжирают максимум 2 Гб. По утрам по крону запускается скрипт /usr/bin/updatedb.findutils, который вызывает find для всего диска. В процессе работы скрипта занятая память начинает расти, при этом buffers+cached тоже растут, но не так интенсивно. Через некоторое время занятая память достигает 8 Гб и данные начинают потихоньку складываться в своп, при этом buffers+cached держатся в районе 2 Гб. После выходных в свопе уже больше 1 Гб, и когда утром опять запускается этот скрипт, то становится просто невозможно работать: всё дико тормозит, buffers+cached уже всего несколько сот Мб.

Свопится даже при vm.swappiness=1. При vm.swappiness=0 ещё не проверял.

Зато если выполнить 'echo 3 > /proc/sys/vm/drop_caches', а затем 'swapoff -a && swapon -a', то системе сразу становится хорошо: 2 Гб использовано, 6 Гб свободно.

До обновления у меня было установлено ядро 3.13. По утрам бывали небольшие подтормаживания после разблокированя экрана, но таких диких тормозов не бывало никогда.

Кто-нибудь сталкивался с этим?

★★★★★

Последнее исправление: Sorcerer (всего исправлений: 1)

15.04

Жалуйтесь производителю. Кого здесь интересует дистр. с 9 мес. поддержкой, да еще и основанному на пакетной базе Debian Unstable?

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

Надеюсь, кого-нибудь и интересует.

Sorcerer ★★★★★
() автор топика

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

anonymous
()

vm.swappiness=1

А почему не vm.swappiness=10, тобишь своп будет работать, когда ОЗУ забьется на 90%, вот еще почитай. У меня настроено в этом духе, ос просто летает.

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

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

Проверил сейчас с vm.swappiness=0: тоже свопится. Игры с vm.vfs_cache_pressure тоже ничего не дают. Вот текущие данные (find всё ещё работает):

КиБ Mem:   8106308 total,  7243952 used,   862356 free,    51076 buffers
КиБ Swap:  8317948 total,   735928 used,  7582020 free.   100656 cached Mem

Смог запостить это, только выполнив в очередной раз 'echo 3 > /proc/sys/vm/drop_caches', после чего

КиБ Mem:   8106308 total,  1210952 used,  6895356 free,     4512 buffers
КиБ Swap:  8317948 total,   821124 used,  7496824 free.   118204 cached Mem

Sorcerer ★★★★★
() автор топика
Последнее исправление: Sorcerer (всего исправлений: 1)
Ответ на: комментарий от garik_keghen

А почему не vm.swappiness=10

Я написал, что даже при vm.swappiness=1 свопится. При vm.swappiness=10 - тоже. Вообще не влияет этот параметр в моём случае.

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

вот еще почитай

Я по-разному пытался настраивать. Та статья немного устарела, сейчас не рекомендуется устанавливать vm.dirty_background_ratio, особенно для 64-битных систем. Вместо этого Линус рекомендует vm.dirty_background_bytes & vm.dirty_bytes. У меня так:

vm.dirty_background_bytes  = 94371840
vm.dirty_bytes = 188743680

Sorcerer ★★★★★
() автор топика
Последнее исправление: Sorcerer (всего исправлений: 1)
Ответ на: комментарий от Sorcerer

Может и так, только есть уверенность, что в своп уходит что-то очень нужное, а в памяти остаётся что-то очень не нужное. И необходимость нахождения в памяти определяется совсем от балды.

anonymous
()

От root:

for PROCESS in /proc/*/; do
  swapused=$(awk 'BEGIN { total = 0 } /^Swap:[[:blank:]]*[1-9]/ { total = total + $2 } END { print total }' ${PROCESS}/smaps 2>/dev/null || echo 0)
  if [ $swapused -gt 0 ]; then
    /bin/echo -e "${swapused}k\t$(cat ${PROCESS}/cmdline)"
  fi
done | sort -rn
coldheadcleanhands
()
Ответ на: комментарий от aplay

Что это за ненужно?

Это скрипт из пакета locate. Хотя /usr/bin/locate ссылается на /usr/bin/mlocate из пакета mlocate, и на свежеустановленной убунте 15.04 устанавливается именно mlocate. Видимо, рудимент от старых версий. Удалю, но вопроса это, наверное, всё равно не отменяет.

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

top показывает занятость swap (с сортировкой)

top - 10:18:27 up 17 days, 19:40,  5 users,  load average: 0.01, 0.02, 0.05
Tasks: 277 total,   1 running, 276 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.3 us,  0.3 sy,  0.0 ni, 99.3 id,  0.1 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:   6050232 total,  5847864 used,   202368 free,    15748 buffers
KiB Swap: 10485756 total,    70100 used, 10415656 free.  4830568 cached Mem

  PID USER        VIRT    RES    SHR   SWAP S     TIME+  %CPU COMMAND                                                        
 1494 colord    346952   8632   4216  36488 S   0:33.61   0.0 colord                                                         
 2023 libvirt+ 2003400 251148   6492  27256 S  35:21.49   0.0 qemu-system-x86                                                
 1951 mediato+ 1346208  67000  10268   1984 S   8:00.13   0.0 mediatomb                                                      
 1068 root      919912   5272   2840   1948 S   0:00.99   0.0 libvirtd                                                       
 1996 lightdm    62224   2576      0    524 S   0:00.00   0.0 (sd-pam)                                                       
  981 root      336440   3684   2544    304 S   0:01.89   0.0 ModemManager                                                   
  982 root      433256   7020   5044    156 S   0:06.46   0.0 NetworkManager                                                 
 1885 root       17712   2068   1900    132 S   5:14.02   0.0 dovecot                                                        
 1870 uucp       43860   2060   1744    120 S   0:05.76   0.0 faxgetty                                                       
 1903 root        9364   1656   1464    116 S   0:01.98   0.0 log                                                            
 1902 dovecot     9236   1400   1312     60 S   0:01.79   0.0 anvil                                                          
 1857 uucp       41324   2284   1964     52 S   0:00.78   0.0 faxq                                                           
 1134 root      352324   4668   3696     48 S 200:56.59   0.0 lightdm                                                        
 1861 uucp       43728   1976   1636     36 S   0:00.02   0.0 hfaxd                                                          
 1489 root     1057328   4348   3088     20 S   0:08.93   0.0 console-kit-dae                                                
  395 root      249088   1124    684      4 S   0:00.07   0.0 lvmetad                                                        
  875 root       37168   2396   1940      4 S   0:02.60   0.0 rpcbind         
anonymous
()
Ответ на: комментарий от coldheadcleanhands

Я запускал аналогичный скрипт. Он показывал, что в свопе лежит часть программ. Кроме firefox и thunderbind лежали множество xterm и bash, а также другое нужное добро.

Сейчас я вообще отключил своп. Думал, что OOM Killer начнёт своё грязное дело, но нет: всё работает, система где-то находит память, хотя я ещё виртуалку запустил в virtualbox.

КиБ Mem:   8106308 total,  7969020 used,   137288 free,  1895368 buffers
КиБ Swap:        0 total,        0 used,        0 free.   266936 cached Mem

Sorcerer ★★★★★
() автор топика

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

Бинго! Моя любимая игра. А что там кричат, когда выигрывают?

sambist ★★
()

А Вам точно нужен своп при 8 ГиГ оперативы? Если не хотите/боитесь своп отключать (прям как я :)) - то можно сделать zRam на пару сотен мегов

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

А что там кричат, когда выигрывают?

В пятницу я проиграл: сдался, жмакнул на reset. Сегодня с начала прохожу.

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

А Вам точно нужен своп при 8 ГиГ оперативы?

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

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

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

Иногда лучше жевать. Только анонимные страницы могут попасть в своп.

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

Иногда лучше смотреть фактам в лицо - линукс отвратительно определяет, что надо выгружать на диск. Тебе только что человек показал, что нужные вещи в свопе, а память забита чёрт знает чем.

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

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

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

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

Варианты выхода из ситуации такие же простые, как и вход:
- не выполнять эту задачу
- купить под неё более адекватное железо (ещё памяти насовать)
- купить ssd, чтобы по утрам ядро доставало страницы с накопителя в 10-100 раз быстрее

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

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

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

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

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

Неувязочка в вашей стройной логике, не находите?

Нет. Страницы с известными источниками будут выброшены вне зависимости, есть своп или нет. Позже будут перечитаны из источников.

Отключить своп = запретить сброс анонимных страниц. К счастью, мнение юзера по поводу выброса неанонимных страниц никто не спрашивает. А то к тредам о свопе прибавилось бы столько же «а почему у меня всё валится с ENOMEM».

aidaho ★★★★★
()

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

grep -r test / > /dev/null 2>&1

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

Нет, а должно волновать? Меня больше волнует, как сделать, чтобы эта очевидная команда работала при подключенном свопе. Это не какой-то там экзотический кейс, - аналогичные действия проделываются по умолчанию на всех десктопах для индексации данных.

Sorcerer ★★★★★
() автор топика

После повторения проблемы посмотри grep -i slab /proc/meminfo. Ну и вообще в meminfo много интересного

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

всякий мусор загоняют в кэш, а потом этот кэш сбрасывают в своп

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

router ★★★★★
()
Последнее исправление: router (всего исправлений: 1)
Ответ на: комментарий от anonymous

это ты, ламер, выдумал, а не «отцы»

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

шинда(по крайней мере 7-8) ведёт себя хуже при свопе, вплоть до падения видеодрайвера, оболочки и пр, хотя и с перезапуском, и начинает свопится раньше, тк тратит память на бесполезные сервисы, даже если большинство из них отключить

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

Вот сейчас, 2 Гб в свопе:

MemTotal:        8106308 kB
MemFree:          133476 kB
MemAvailable:    2990548 kB
Buffers:            8672 kB
Cached:          2997856 kB
SwapCached:       199140 kB
Active:          4220520 kB
Inactive:        3482464 kB
Active(anon):    4187624 kB
Inactive(anon):   519680 kB
Active(file):      32896 kB
Inactive(file):  2962784 kB
Unevictable:          32 kB
Mlocked:              32 kB
SwapTotal:       8317948 kB
SwapFree:        6373252 kB
Dirty:                28 kB
Writeback:             0 kB
AnonPages:       4537204 kB
Mapped:           100964 kB
Shmem:              9508 kB
Slab:             111544 kB
SReclaimable:      60656 kB
SUnreclaim:        50888 kB
KernelStack:       12128 kB
PageTables:        53164 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    12371100 kB
Committed_AS:   13819068 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      128324 kB
VmallocChunk:   34359601660 kB
HardwareCorrupted:     0 kB
AnonHugePages:    155648 kB
CmaTotal:              0 kB
CmaFree:               0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:      476696 kB
DirectMap2M:     7843840 kB
Убил грепалку:
MemTotal:        8106308 kB
MemFree:         4343684 kB
MemAvailable:    7145936 kB
Buffers:            9460 kB
Cached:          2936080 kB
SwapCached:       200484 kB
Active:           232084 kB
Inactive:        3259880 kB
Active(anon):     161088 kB
Inactive(anon):   394820 kB
Active(file):      70996 kB
Inactive(file):  2865060 kB
Unevictable:          32 kB
Mlocked:              32 kB
SwapTotal:       8317948 kB
SwapFree:        6421448 kB
Dirty:                72 kB
Writeback:             0 kB
AnonPages:        401200 kB
Mapped:           107372 kB
Shmem:              9508 kB
Slab:             121144 kB
SReclaimable:      70260 kB
SUnreclaim:        50884 kB
KernelStack:       12112 kB
PageTables:        44912 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    12371100 kB
Committed_AS:    5423536 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      128324 kB
VmallocChunk:   34359601660 kB
HardwareCorrupted:     0 kB
AnonHugePages:     96256 kB
CmaTotal:              0 kB
CmaFree:               0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:      476696 kB
DirectMap2M:     7843840 kB
После 'echo 3 > /proc/sys/vm/drop_caches':
MemTotal:        8106308 kB
MemFree:         7101520 kB
MemAvailable:    7097992 kB
Buffers:            1220 kB
Cached:           107680 kB
SwapCached:       228528 kB
Active:           225032 kB
Inactive:         516984 kB
Active(anon):     162140 kB
Inactive(anon):   480628 kB
Active(file):      62892 kB
Inactive(file):    36356 kB
Unevictable:          32 kB
Mlocked:              32 kB
SwapTotal:       8317948 kB
SwapFree:        6480672 kB
Dirty:                60 kB
Writeback:             0 kB
AnonPages:        465140 kB
Mapped:           115456 kB
Shmem:              9512 kB
Slab:             113484 kB
SReclaimable:      62632 kB
SUnreclaim:        50852 kB
KernelStack:       12240 kB
PageTables:        44916 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    12371100 kB
Committed_AS:    5462948 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      128324 kB
VmallocChunk:   34359601660 kB
HardwareCorrupted:     0 kB
AnonHugePages:     96256 kB
CmaTotal:              0 kB
CmaFree:               0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:      476696 kB
DirectMap2M:     7843840 kB
После swapoff -a:
MemTotal:        8106308 kB
MemFree:         5590848 kB
MemAvailable:    5593660 kB
Buffers:            4440 kB
Cached:           159940 kB
SwapCached:            0 kB
Active:           296532 kB
Inactive:        1961220 kB
Active(anon):     227392 kB
Inactive(anon):  1917112 kB
Active(file):      69140 kB
Inactive(file):    44108 kB
Unevictable:          32 kB
Mlocked:              32 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                96 kB
Writeback:             0 kB
AnonPages:       2093560 kB
Mapped:           120100 kB
Shmem:             51004 kB
Slab:             112208 kB
SReclaimable:      61312 kB
SUnreclaim:        50896 kB
KernelStack:       12112 kB
PageTables:        44912 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     4053152 kB
Committed_AS:    5427564 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      126028 kB
VmallocChunk:   34359601660 kB
HardwareCorrupted:     0 kB
AnonHugePages:     96256 kB
CmaTotal:              0 kB
CmaFree:               0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:      476696 kB
DirectMap2M:     7843840 kB

Sorcerer ★★★★★
() автор топика

У меня в рабочем компе 8 Гб памяти

Печально, а я тут ною что с моими 4 гигами свопится постоянно.

Копай что именно жрет оперативу, говносайт какой-нибудь или 100500 писем в тандырбёрде

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

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

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

Анонимус выше был прав насчёт /dev, нужно его исключить, иначе с /dev/zero и пр. будет нехорошо. :) Правда, у меня сам grep память не успевал поесть, раньше всё свопиться начинало (до /dev). Попозже другой тест попробую.

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

Пока только такой тест придумал, но своп растёт не так шустро:

find / -type f -print0 2>/dev/null | xargs -0 -n 10 head -c 8192 > /dev/null 2>&1

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

а у меня регулярно, хотя в диспетчере задач 300-500Мб свободных. с железом проблем нет, проверено

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

попробуй выставить swappiness в 100 и vfs_cache_pressure в 100000

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

Хорошо, знаток матчасти, на каком основании в своп выгружается DE, а остаётся в памяти мусор от поиска файлов? Какой ламер это придумал? Какой толк от работающего тарахтящего диском ядра?

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

А что советовали купить до появления SSD и планок по 16 гигов памяти?

anonymous
()

Всем спасибо!

В итоге установил такие параметры:

vm.swappiness = 0
vm.vfs_cache_pressure = 100000
С такими настройками скрипт updatedb.findutils, о котором шла речь в начале, приводит к свопу примерно на 300 Мб, но при этом никаких диких тормозов не возникает. А когда скрипт не выполняется, то тоже всё замечательно работает, диском зря не шуршит.

Теперь со спокойной душой удаляю этот дурацкий скрипт вместе с пакетом locate. :)

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

странно. можешь ещё попробовать собрать ядро c отключенными всеми опциями связанными с huge pages и compaction

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