Xserver перестает отвечать на запросы из-за агрессивного обмена

Question

cat /proc/sys/vm/swappiness
1

free -h
              total        used        free      shared  buff/cache   available
Mem:           3.7G        579M        1.6G        1.1G        1.6G        1.8G
Swap:          1.0G        144K        1.0G

У меня есть ошибка Firefox, запущенная amok - XServer перестает отвечать на запросы более 10 секунд, иногда требуя жесткого отключения рабочего стола - вот использование vmstat, когда я запускаю его, а затем, наконец, удается завершить процесс:

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- -----timestamp-----
 r  b   swpd   free  inact active   si   so    bi    bo   in   cs us sy id wa st                 EDT
 0  0      0 193940 2540804 1002716    0    0     0     0  827 2947  2  1 97  0  0 2015-05-16 16:13:30
 0  0      0 193940 2540804 1002740    0    0     0     0  785 3747  3  2 96  0  0 2015-05-16 16:13:31
 0  0      0 196064 2540804 1000400    0    0     0     0  865 4064  6  1 93  0  0 2015-05-16 16:13:32
 0  0      0 195692 2540804 1000524    0    0     0     0  790 4699  4  2 94  0  0 2015-05-16 16:13:33
 0  0      0 195532 2540804 1000644    0    0     0   857  866 4770  5  1 94  0  0 2015-05-16 16:13:34
 0  0      0 195284 2540804 1000660    0    0     0    48  743 3755  2  1 97  0  0 2015-05-16 16:13:35
 0  0      0 195284 2540804 1000700    0    0     0     0  758 4037  3  1 96  0  0 2015-05-16 16:13:36
 1  0    148 119156 2745740 893480    0  148  3356   148 10443 7868 33 15 51  1  0 2015-05-16 16:13:37
 0  2 225360 126552 2764572 867432    0 225212 24260 225252 15027 2811  4  7 49 40  0 2015-05-16 16:13:38
 0  3 427808 121044 2756804 875764    0 202448 20084 202812 1825 1717  9  7 52 32  0 2015-05-16 16:13:39
 0  2 549012 136656 2740740 876064    0 121204  5060 121204 1327 1573 10  4 60 27  0 2015-05-16 16:13:40
 0  0 613996 139208 2741352 878332    0 64984 15284 65048 1169 1586  2  2 81 15  0 2015-05-16 16:13:41
 0  2 765516 131056 2743152 878224    0 151520   644 151520  517  981  9  4 77 10  0 2015-05-16 16:13:42
 1  0 908672 184712 2691932 877260    0 143156  3676 143156  638 1094  3  3 62 32  0 2015-05-16 16:13:43
 1  1 906072 164200 2717744 873548 2160    0  9124     0 1137 2246  8  2 81 10  0 2015-05-16 16:13:44
 1  0 1028568 217116 2662856 877792 5632 128156 15956 128212 1344 2189  8  3 61 28  0 2015-05-16 16:13:45
 0  0 1028568 214064 2663532 879556    0    0   344     0  789  899  1  1 98  0  0 2015-05-16 16:13:46
 0  0 1028564 207536 2667876 881500    0    0  6456    12  962 2349  3  1 95  1  0 2015-05-16 16:13:47
 0  0 1028564 202708 2669568 884756    0    0  2284     0  733  874  2  1 97  1  0 2015-05-16 16:13:48
 0  0 1028564 199732 2672484 885092    0    0  3084     0  286  937  1  0 98  1  0 2015-05-16 16:13:49
 0  0 1028564 197004 2674716 885376    0    0  2440     0  259 1080  1  0 98  0  0 2015-05-16 16:13:50
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- -----timestamp-----
 r  b   swpd   free  inact active   si   so    bi    bo   in   cs us sy id wa st                 EDT
 1  0 1028564 196756 2674860 885660    0    0    20     0  235  904  1  1 98  0  0 2015-05-16 16:13:51
 0  0 1028564 196740 2674876 885668    0    0     0     0  318 1012  1  1 98  0  0 2015-05-16 16:13:52
 0  0 1028564 196740 2674880 885680    0    0   100    44  656 1003  1  0 98  1  0 2015-05-16 16:13:53
 0  0 1028564 195356 2675532 886456    0    0  1488     0  766 2099  2  2 96  0  0 2015-05-16 16:13:54
 1  0 1028460 168444 2682144 904076   96    0  7588     0 1334 5119  9  3 87  1  0 2015-05-16 16:13:55
 0  0 1028460 152100 2704240 899988    0    0  3216     0  937 2737  6  2 92  1  0 2015-05-16 16:13:56
 0  0 1028460 139956 2709516 905816    0    0   580     0  732 3588  4  1 94  0  0 2015-05-16 16:13:57
 0  0 1028460 139708 2709780 906108    0    0   128     0  814 3768  3  2 95  0  0 2015-05-16 16:13:58
 0  0 1028460 138456 2711344 906320    0    0    12    52  835 4109  3  1 96  0  0 2015-05-16 16:13:59
 0  0 1028460 139588 2711440 904452    0    0     0     0  856 3445  3  1 95  0  0 2015-05-16 16:14:00
 0  0 1028460 142440 2711440 901300    0    0     4   424  887 5238  3  1 96  0  0 2015-05-16 16:14:01
 1  0 1028460 115192 2730492 910708    0    0 18948     8 2228 4712  6  3 87  4  0 2015-05-16 16:14:02
 0  0 1028460 114080 2731276 911640    0    0   396     0  976 4185  6  2 92  0  0 2015-05-16 16:14:03
 1  7 1048572  84512 2776408 900196    0 20112 162296 21044 26462 8939 25 10 33 33  0 2015-05-16 16:14:04
 0 10 1048572 206548 2803588 751176    0    0 1305648   120 77614 206123  0  4 74 22  0 2015-05-16 16:14:23
 0  1 1048572  85332 2865180 812416  528  476 120320  2296 22658 7102 14  8 48 30  0 2015-05-16 16:14:24
 3  0   9944 3423940 143324 203924  340    0 171776   764 6222 17487  2 17 32 49  0 2015-05-16 16:14:25
 0  0   9944 3493676 103216 177288    0    0  3436 15072 1124 1624  5  1 88  6  0 2015-05-16 16:14:26
 0  0   9944 3493676 103280 177316    0    0    68     0  575  684  0  1 99  0  0 2015-05-16 16:14:27
 0  0   9944 3492900 103724 177316    0    0   604     0  596  765  1  0 99  0  0 2015-05-16 16:14:28
 0  0   9944 3492684 104184 177316    0    0   348     0  622  751  0  1 99  0  0 2015-05-16 16:14:29

Вы можете увидеть 0 swap до того, как ошибка сработает, и Firefox решит сделать что-то странное с памятью - вскоре после этого X-сервер перестает отвечать на запросы, когда он, наконец, отвечает на единственное связывание клавиш для kill -9 (ps -aux|grep [f]irefox | awk '{print $2}') вы можете увидеть, что своп возвращается к 0.

Я не думаю, что это проблема OOMKiller, но что-то не так с тем, как это обрабатывается ядром.

Answer 1

Я бы изучил конфигурацию OOM-killer в вашем ядре (читайте: "как ваш дистрибутив явно сломал ее": P)

Как немедленное практическое решение, которое, я уверен, поможет ощутимо ... добавить больше свопов. В самом деле.

У меня ... слишком большой опыт работы с системами с недостаточным объемом оперативной памяти. :П

Когда у Linux заканчивается ОЗУ, перед тем, как запустить OOM-убийцу, он ДЕЙСТВИТЕЛЬНО старается "справиться", постоянно удаляя различные кеши эффективности, которые он хранит в памяти. Вы можете видеть, что это происходит, когда вся система практически зависает, а диск сходит с ума - ядро постоянно убивает кэш диска.

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

Обратите внимание, что области подкачки могут быть физическими файлами; просто создать новый файл в / или некоторый угол он не будет трогать (так как rm'ing файл = Insta-паника ядра) с dd mkswap его, а затем swapon его. Добавьте файл в / etc / fstab ПОСЛЕ строки, которая монтирует файловую систему, в которой он находится, для его автоматического монтирования.

Вы можете также захотеть исследовать увлекательность, которая является zram -as-swap.

Также, возможно, используйте случайную целевую практику с FTP Mozilla и попробуйте случайные старые версии FF (двоичные файлы Linux запускаются напрямую без установки, FYI), чтобы определить, не являются ли старые версии глупыми. (РЕДАКТИРОВАТЬ: чтобы увидеть, если это из-за регрессии.)

(Дух / здравый смысл /, вероятно, уже сделано). Также рассмотрите возможность удаления расширений и отслеживания того, на каких сайтах вы находились, когда это происходит.