Oom-killer на сервере (Убивает мой единственный процесс)

[Toshka]

Здравствуйте!
Я держу выделенный сервер (16Gb озу).
У меня стоит mysql сервер на этой машине и единственный мне нужный процесс, под который я выделяю 6 Gb , но его каждые пару часов убивает oom-killer.
Вот скрипт с запуском на java:
------------------------
while : ;
do
sleep 5 && java -server -Xmx6G -XX:+UseConcMarkSweepGC -jar /root/root/server/spigot.jar
done
------------------------
А вот файл /var/log/messages с логом oom-killer'a, как видно всё началось с 6 апреля.
--->>> http://pastebin.com/bNuV2vV2
Извините, если написал не в ту тему. Прошу помощи!
----------------------------------
я так понимаю, что проблема в кэше? или где тогда.. я даже не знаю куда может деваться оперативная память
P.S.- запускал без скрипта - то же самое, процесс убивается линуксом

MemTotal: 16129212 kB
MemFree: 391856 kB
MemAvailable: 424992 kB
Buffers: 4092 kB
Cached: 11312736 kB
SwapCached: 0 kB
Active: 4012104 kB
Inactive: 11234976 kB
Active(anon): 4001900 kB
Inactive(anon): 11205728 kB
Active(file): 10204 kB
Inactive(file): 29248 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 3930272 kB
Mapped: 32816 kB
Shmem: 11277376 kB
Slab: 387004 kB
SReclaimable: 182352 kB
SUnreclaim: 204652 kB
KernelStack: 2888 kB
PageTables: 15368 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 8064604 kB
Committed_AS: 16032180 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 71432 kB
VmallocChunk: 34359623752 kB
AnonHugePages: 3618816 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 14372 kB
DirectMap2M: 16441344 kB
---------------------------------
Я ребутнул сервер и всё стало нормально, и памяти свободной было много, а в кэше мало.
Но вот нашёл я приключений на свою голову и решил распаковать увесистый архив в 2 гб. В итоге кэш забился, и мой процесс опять убивается...
Причём команда "sync; echo 3 > /proc/sys/vm/drop_caches" освобождает максимум 20 мб
И ещё. когда я использую команду "free" , то показывает,ч то у меня swap по нулям. Это нормально? Может из-за этого у меня происходит это всё.
Жду советов!)

[Bizdelnick]

Ну сделайте swap гига на 32-64, если у Вас такие прожорливые процессы.

[Toshka]

Ну сделайте swap гига на 32-64, если у Вас такие прожорливые процессы.

А это поможет, или это вообще не влияет на мою проблему?
Просто я сколько пытался вникнуть в суть swap , так и не понял то это или нет.

Ну сделайте swap гига на 32-64, если у Вас такие прожорливые процессы.

вот сейчас наблюдал, при мне free память дошла до 200 с лишним мб и процесс киллнулся.. То есть почему-то кэш не высвобождается для нужд процессов...

[Toshka]

Ну сделайте swap гига на 32-64, если у Вас такие прожорливые процессы.

Начал создавать файл подкачки, в итоге в кэш ушло ещё 4 гб, и процесс теперь вообще не запускается

[Bizdelnick]

С кешем странно - у Вас диски перегружены, что ли?
Файл можно сделать так: truncate -s 32G /path/to/file. Обнуляться он не будет, соответственно и кеш не потребуется. Но теоретически если на той же ФС хранились какие-то сверхсекретные данные, это потенциальный сбособ их слить.

[MrClon]

То есть почему-то кэш не высвобождается для нужд процессов...

Вот это странно. В приведённом /proc/meminfo 11 Гб неактивных анонимных кэшей. По идее эти кэши можно дропнуть в любой момент (или вроде того).
Только не могу вспомнить что попадает в анонимный кэш, может кто напомнит?

С кешем странно - у Вас диски перегружены, что ли?

Судя по meminfo в первом посте файловых кэшей вообще кот наплакал, кэши забиты чем-то другим.

[neol]

У вас почти 11 Гб в Shared Memory, а виноваты опять кеши. Этот мир так несправедлив =(
Посмотреть кто нагадил по идее можно в выводе ipcs -m