Странно. Попробуй sysctl -w vm.swappiness=0, хотя это вряд-ли поможет. Может в момент срабатывания OOM-killer было резкое повышения использования памяти?

>Попробуй
Свопа же нет.

Может в момент срабатывания OOM-killer было резкое повышения использования памяти?

«Резкое», это как?

`free -m` после сброса кеша что говорит? В логах что есть?

свопа добавь... посмотри, что будет ;) где-то проскакивало о не особо адекватном поведении, когда свопа нет вообще. ..

>`free -m` после сброса кеша что говорит?

Вверху же детализация. Говорит что Cached: 368836 kB

В логах что есть?

Ничего.

>свопа добавь... посмотри, что будет ;)

Интерес представляет выяснение причин а не маскирование симптомов.

P.S. Пардон, просто не обращайте внимание на вывод free. Перед следующей командой были дропнуты кеши из другого терминала, это вводит в заблуждение, будто часть куда-то испарилась.

Вообще надо начать с того, что drop_caches не срабатывает. Скорее всего проблема в какой-нибудь tmpfs смонтированой на которой и лежат эти 369Мб.

Вот пример:

~ # free -m
             total       used       free     shared    buffers     cached
Mem:          7985        522       7463          0          1         15
-/+ buffers/cache:        505       7480
Swap:         8191          0       8191

~ # dd if=/dev/zero of=/dev/shm/test bs=1M count=500
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 0.190143 s, 2.8 GB/s

~ # free -m
             total       used       free     shared    buffers     cached
Mem:          7985       1033       6951          0          1        515
-/+ buffers/cache:        516       7468
Swap:         8191          0       8191

~ # echo 3 > /proc/sys/vm/drop_caches
~ # free -m
             total       used       free     shared    buffers     cached
Mem:          7985        981       7004          0          0        514
-/+ buffers/cache:        465       7519
Swap:         8191          0       8191

Линукс, такой линукс. Я уже с udev-ом намучился жить без оптического привода. При любом изменении (например, вставлении флэшки) начинает опрашивать несуществующий привод, при этом загружая одно ядро на 100% секунд на 20. Теперь оказывается и без свопа линукс не торт.

4.2 же.без свопа года два жил всё отлично.чяднт?и с udev всё норм.какое ядро и дистр то?

Вообще надо начать с того, что drop_caches не срабатывает.

Срабатывает, но оставляет очень большой «несгораемый остаток»

Скорее всего проблема в какой-нибудь tmpfs

tmpfs присутствует, но там только 16M занято:

root@aidaho-laptop:/home/aidaho# df -h
Файловая система      Разм  Исп  Дост  Исп% смонтирована на
/dev/sda3             3,7G  3,4G  128M  97% /
tmpfs                1009M  8,0K 1009M   1% /lib/init/rw
udev                 1005M  248K 1005M   1% /dev
tmpfs                1009M     0 1009M   0% /dev/shm
/dev/sda1              45M   14M   29M  32% /boot
/dev/sdb1             7,4G  4,4G  3,1G  59% /home
tmpfs                 200M   16M  185M   8% /tmp
tmpfs                 1,0M     0  1,0M   0% /var/lock
tmpfs                 5,0M  112K  4,9M   3% /var/run
/dev/sdc1             7,4G  1,7G  5,4G  24% /media/SD.card

Ядро 2.6.38.6. Дистр Arch x86_64, но похожие проблему гугляться и на Ubuntu, и на Арче, возможно и еще где-то. Решил проблему с udev-ом только блэклистом модуля cdrom.

Я тоже жил отлично, так как комп двухядерный, а за загрузкой цпу я все время не слежу. Поэтому о проблеме как таковой узнал совсем недавно. С памятью аналогичная ситуация, ее у меня 4 Гб, поэтому считать жалкие мегабайты никогда не пробовал.

ну вот то же самое)памяти достаточно и не играю в перфекционистов

торренты прибить не пробовал?

echo 3 > /proc/sys/vm/drop_caches

This is a non-destructive operation and will only free things that are [b]completely unused[/b]

Попробуй отключить oom-killer вообще. Проблема старая, можно начать её исследование, например, отсюда: https://bugzilla.redhat.com/show_bug.cgi?id=193542

>торренты прибить не пробовал?

Нету.

This is a non-destructive operation and will only free things that are [b]completely unused[/b]

Грязных страниц тоже нет, см. выше.

Спасибо, изучу. Вариант с отключением oom без свопа опасен — можно панику словить, но буду иметь ввиду.

Могу ошибаться, но возможно там хранятся какие-то важные данные (кеш метаданных фс например), раз оно не спешит их особождать.
А вообще надо бы спросить у разработчиков ядра.

Погуглил я там-сям по интернетам: действительно, не я первый, не я и последний. Проблем, с подобной друг-другу симптоматикой как минимум две (подозреваю, что три). В первом случае заканчивается lowmem, пути решения очевидны. Ко второму относится и мой. Намеков на причины в интернетах найти не удалось. Своя версия: oom стартует уместно, потому что освободить память не представляется возможным. А вот почему — вопрос сложный. Нужно рыть документацию и багзиллу ядра, а желания нет.

Выключать oom, кстати, можно только на ядрах с rhel'овскими патчами. Почётную роль костыля доверил демону swapspace.

Боюсь, что скорее нужно рыть исходники ядра. Иначе вобще не понять каким образом получить MemTotal из остальных полей в файле /proc/meminfo. И не понятно, какие данные могут быть в Cached.

Я на разных работающих системах попробовал «echo 3 > /proc/sys/vm/drop_caches» и в лучшем случае получил Cached порядка 30 Мбайт (при 1 Гб ОЗУ и полном простое системы).

Бампну старый тред полезной информацией:
Проблема оказалась в ntfs-3g. При наличии невыясненных пока условий он жрёт память не освобождая занятое под кеши. Сейчас кажется даже странно, почему я сразу не заподозрил модули фс.

Получается, что юзеры, имеющие доступ к /dev/fuse могут легко завалить машину сея хаос с помощью oom, или, если на машине есть свап — загнать её в такой iowait, что проще ткнуть резет.

Не так просто: ntfs-3g был в ответе за часть недропаемых кешей, остальное оказалось на совести видеодрайвера intel.