Почему делают программы (включая Xorg) закрываются, когда из RAM, но Подкачка почти пуста?

У меня есть некоторая настроенная подкачка, и я верю активированный...

Filename                Type        Size    Used    Priority
/dev/sda5                               partition   7811068 1124912 200
/mnt/data02/swapfile                    file        134217724   37032   100
/home/swapfile                          file        134217724   36600   -1

Но, когда системный монитор показывает память, достигающую 100%, система имеет тенденцию отвечать путем закрытия/катастрофического отказа программ. Xorg отказал таким образом, как имеет драйвер беспроводного устройства. В то время как это происходит шоу системного монитора мало использования (на менее чем 5 гибибайт) Подкачки. Я подтвердил, что swappiness не установлен на экстремум (и изменяется в этом параметре, казалось, не имели никакого эффекта на проблему).

~$  cat /proc/sys/vm/swappiness
70

Система имеет огромную сумму RAM...

~$ free -h
             total       used       free     shared    buffers     cached
Mem:          125G        20G       105G       161M        54M       1.1G
-/+ buffers/cache:        19G       106G
Swap:         263G       1.1G       262G

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

Что я могу сделать для решения этого вопроса?

Править

~$ cat /etc/fstab
    # <file system> <mount point>   <type>  <options>       <dump>  <pass>
    # / was on /dev/sda3 during installation
    UUID=8dfbed62-9957-4f06-b4e1-a42020adec91 /               ext4    errors=remount-ro 0       1
    # /home was on /dev/sda6 during installation
    UUID=b6f33408-1d8b-4302-9983-5c778ef64f47 /home           ext4    defaults        0       2
    # swap was on /dev/sda5 during installation
    # ae0304dd-e63e-4d3a-99da-9c9d7a034c6e is the swap file
    UUID=fd4c00c9-49bf-4562-adea-1c817fc57ce9 none            swap    sw,pri=200              0       0
    UUID=3A323DCA323D8BBF /mnt/data01 ntfs-3g defaults,windows_names,locale=en_US.utf8  0 0
    UUID=4cc8a19d-5991-4186-8f65-7062805b66a6 /mnt/data02 ext4 defaults 0 0
    /mnt/data02/swapfile   none    swap    sw,pri=100    0   0
    /home/swapfile  none  swap  sw  0,pri=150 0

ОТРЕДАКТИРУЙТЕ 2 В ответ на комментарий ниже, я наблюдал, что моя система выполнила операцию, которую я знал, будет использовать всю доступную RAM, но не всю доступную подкачку и затем проверенный dmesg в течение и после отказа. Система подкачала и стала периодически небыстро реагирующей (хорошо поведение). Затем, в то время как подкачка была меньше чем на 10% способности, разрушенный Chrome (Sorry, the program "chrome" closed unexpectedly. Your computer does not have enough free memory to automatically analyze the problem and send a report to the developers). Попытка возвратиться к выводу dmesg, который я наблюдал, я получил сообщение об ошибке, которое указало This window is not responding. Do you want to force the application to exit, or wait for it to respond. Я выбрал, 'ожидают'. Рабочий стол вновь появился, и системный монитор гнома вошел и из отображения серым несколько раз, в то время как система подкачала. Когда я перепроверил в, я был в экране входа в систему Ubuntu. Я вошел в систему как нормальный... все мои более ранние рабочие процессы закончились, и меня встретили сообщением об ошибке, идентичным тому о Chrome в отношении Xorg. Проверка dmesg показывает только следующие два сообщения:

[131267.206774] Watchdog[3433]: segfault at 0 ip 00007fe38faf9756 sp 00007fe37f393770 error 6 in chrome[7fe38be0a000+510c000]
[133329.875212] nvidia 0000:03:00.0: irq 106 for MSI/MSI-X

ОТРЕДАКТИРУЙТЕ 3 Других возможных соответствующих темы:

Редактирование 4 Дополнительных сообщения об ошибках:

[92315.165728] Watchdog[1319]: segfault at 0 ip 00007f7d0a417756 sp 00007f7cf9cb1770 error 6 in chrome[7f7d06728000+510c000]
[92656.478271] INFO: task Chrome_IOThread:1292 blocked for more than 120 seconds.
[92656.478275]       Tainted: P           OX 3.13.0-45-generic #74-Ubuntu
[92656.478276] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[92656.478278] Chrome_IOThread D ffff88207fc534c0     0  1292  32756 0x00000000
[92656.478282]  ffff881fa9d15dd8 0000000000000086 ffff881fad2ab000 ffff881fa9d15fd8
[92656.478285]  00000000000134c0 00000000000134c0 ffff881fad2ab000 ffff881fad2ab000
[92656.478288]  ffff881f5fce6260 ffff881f5fce6268 ffffffff00000000 ffff881f5fce6270
[92656.478290] Call Trace:
[92656.478299]  [<ffffffff817252d9>] schedule+0x29/0x70
[92656.478302]  [<ffffffff81727f55>] rwsem_down_write_failed+0x115/0x230
[92656.478307]  [<ffffffff81371d63>] call_rwsem_down_write_failed+0x13/0x20
[92656.478311]  [<ffffffff81314c90>] ? apparmor_file_mprotect+0x30/0x30
[92656.478313]  [<ffffffff8172796d>] ? down_write+0x2d/0x30
[92656.478318]  [<ffffffff8116ba7c>] vm_mmap_pgoff+0x6c/0xc0
[92656.478322]  [<ffffffff8117f916>] SyS_mmap_pgoff+0x116/0x270
[92656.478325]  [<ffffffff81018802>] SyS_mmap+0x22/0x30
[92656.478328]  [<ffffffff8173196d>] system_call_fastpath+0x1a/0x1f
1
задан 15 February 2015 в 08:52

2 ответа

В зависимости от того, что они делают, Компьютеры с большими объемами памяти, такой как Ваш, могут войти в трудности, когда сумма свободной памяти (резидентный объект в противоположность подкачке) становится очень низкой. Иногда (не уверенный для Вашей ситуации) вещи могут быть улучшены путем увеличения минимального количества памяти, сохраненной свободной, или/proc/sys/vm/min_free_kbytes. Думайте о нем, поскольку сохраняющий больше комнаты освобождают таким образом, что вещи легче переместить и перегруппировать и дефрагментироваться и такой. Попробуйте очень большое количество сначала, скажите 20G, и если это помогает попытаться уменьшить его. Вы могли бы также помочь себе путем наблюдения "свободный" тщательно в попытке коррелировать проблемы с некоторой минимальной доступной памятью.

Метод 1 (сценарий, выполненный как sudo):

#! /bin/bash
cat /proc/sys/vm/min_free_kbytes

echo "20000000" > /proc/sys/vm/min_free_kbytes

cat /proc/sys/vm/min_free_kbytes

Метод 2 (прямая команда):

echo "20000000" | sudo tee /proc/sys/vm/min_free_kbytes
3
ответ дан 10 November 2019 в 08:42

Чтобы узнать, были ли Ваши процессы уничтожены уничтожителем OOM, можно осмотреть результат этой команды:

sudo egrep -ri 'killed process' /var/log/ | grep -v auth.log

, Если это верно, Вы могли бы хотеть посмотреть на статью о taiming Уничтожитель OOM. http://lwn.net/Articles/317814/

1
ответ дан 10 November 2019 в 08:42

Другие вопросы по тегам:

Похожие вопросы: