Что такое OOM и oom-killer Out of memomy, killer, oom-killer
Мы можем настроить систему таким образом, чтобы при OOM у нас был kernel panic и система автоматически перезагружалась.
Скопирую часть из документации с сайта kernel.org
This enables or disables panic on out-of-memory feature.
If this is set to 0, the kernel will kill some rogue process, called oom_killer. Usually, oom_killer can kill rogue processes and system will survive.
If this is set to 1, the kernel panics when out-of-memory happens. However, if a process limits using nodes by mempolicy/cpusets, and those nodes become memory exhaustion status, one process may be killed by oom-killer. No panic occurs in this case. Because other nodes’ memory may be free. This means system total status may be not fatal yet.
If this is set to 2, the kernel panics compulsorily even on the above-mentioned. Even oom happens under memory cgroup, the whole system panics.
The default value is 0. 1 and 2 are for failover of clustering. Please select either according to your policy of failover. panic_on_oom=2+kdump gives you very strong tool to investigate why oom happens. You can get snapshot.
Устанавливаем параметры для ядра через sysctl
# sysctl vm.panic_on_oom = 1 # sysctl kernel.panic = 30 # время ожидания в секундах до перезагрузки
Или чтобы настройки остались после перезагрузки вносим их в файл sysctl
echo "vm.panic_on_oom = 1" >> /etc/sysctl.conf echo "kernel.panic = 30" >> /etc/sysctl.conf
Тест panic_on_oom
Теперь осталось вызвать Пиковую даму OOM.
В этом вопросе меня выручил блог.
Надо собрать простую программу на С
#include #include #include #define MB 10485760 int main(int argc, char *argv[]) { void *b = NULL; int c = 0; while(1) { b = (void *) malloc(MB); if (!b) { break; } memset(b, 1, MB); printf("Allocating %d MB\n", (++c * 10)); } exit(0); }
Компилятор, сборка, запуск
# yum install gcc # gcc -O2 oom.c -o oom # ./oom Allocating 10 MB Allocating 20 MB . Allocating 7500 MB Allocating 7510 MB Killed
Система ушла в ребут.
Запись в syslog
Mar 12 16:51:25 shisp1 kernel: in:imjournal invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0 Mar 12 16:51:25 shisp1 kernel: [] oom_kill_process+0x254/0x3d0 Mar 12 16:51:25 shisp1 kernel: [] ? oom_unkillable_task+0xcd/0x120 Mar 12 16:51:25 shisp1 kernel: Out of memory: Kill process 7112 (oom) score 904 or sacrifice child Mar 12 16:51:25 shisp1 kernel: Killed process 7112 (oom) total-vm:7707656kB, anon-rss:7694760kB, file-rss:20kB, shmem-rss:0kB
Сайт rtfm.wiki использует cookies и трекинг посещений. Продолжая использовать этот сайт, вы соглашаетесь с сохранением файлов cookie на вашем компьютере. Если вы не согласны покиньте сайт или включите Adblock ОК Что такое cookies?
OOM-Killer
Как можно сделать так, чтобы программка, которую «убил» oom killer не трогала процесс и процессу выделялось столько памяти, сколько нужно? На сервере 2гб оперативной памяти. Программка кушает больше. Залезло в подкачку, как я думаю. и oom killer грохнул процесс. Как сделать так, чтобы процесс продолжал работу даже при условии загрузки памяти и выделялось столько подкачки, сколько нужно?
MaksDragon
06.02.22 15:29:55 MSK
- Ответить на это сообщение
- Ссылка
Поменять OOMScore а настройках юнита?
anonymous
( 06.02.22 15:36:46 MSK )
- Ответить на это сообщение
- Показать ответ
- Ссылка
скорее всего весь своп выжрало. ну либо процесс юзает memlock — можно попробовать заткнуть mlock* вызовы пустышками через LD_PRELOAD
NiTr0 ★★★★★
( 06.02.22 15:39:03 MSK )
- Ответить на это сообщение
- Показать ответ
- Ссылка
Ответ на: комментарий от anonymous 06.02.22 15:36:46 MSK
Можно как-нибудь попроще объяснить? Я только что на форуме зарегистрировался и вообще не силен во всех этих темах. У меня ситуация такая: У нас игровой сервер по игре. На виртуальной машине 2гб оперативки. Утром увидел что сервер игровой остановлен. Что процесс был убит. Погуглив немного я понял что это oom killer., даже команду находил чтобы посмотреть какой процесс был убит. И вот ищу решение
MaksDragon
( 06.02.22 15:43:13 MSK ) автор топика
- Ответить на это сообщение
- Ссылка
Ответ на: комментарий от NiTr0 06.02.22 15:39:03 MSK
Возомжно сделать как-то, чтобы своп увеличивался в размерах в зависимости от потребности программки?
MaksDragon
( 06.02.22 15:43:45 MSK ) автор топика
- Ответить на это сообщение
- Показать ответы
- Ссылка
Ответ на: комментарий от MaksDragon 06.02.22 15:43:45 MSK

Нет, нельзя. Если приложение игрового сервера течёт по памяти, то чините приложение, а до этого перезапускайте его по расписанию. Ну и запускайте свой игровой сервер из под systemd чтобы оный его перезапускал как только приложение будет убито
cobold ★★★★★
( 06.02.22 16:30:33 MSK )
- Ответить на это сообщение
- Показать ответ
- Ссылка
Ответ на: комментарий от cobold 06.02.22 16:30:33 MSK
«У меня ситуация такая: У нас игровой сервер по игре. На виртуальной машине 2гб оперативки. Утром увидел что сервер игровой остановлен. Что процесс был убит. Погуглив немного я понял что это oom killer., даже команду находил чтобы посмотреть какой процесс был убит» Так а нельзя просто сделать чтобы назначался файл подкачки? И увеличивался по мере того, сколько нужно игровому серверу?
MaksDragon
( 06.02.22 16:33:07 MSK ) автор топика
- Ответить на это сообщение
- Показать ответы
- Ссылка
Ответ на: комментарий от MaksDragon 06.02.22 16:33:07 MSK

cobold ★★★★★
( 06.02.22 16:34:46 MSK )
- Ответить на это сообщение
- Показать ответ
- Ссылка
Ответ на: комментарий от cobold 06.02.22 16:34:46 MSK
Так а если я прописал в sysctl выключение «киллера» vm.overcommit_memory = 2 vm.overcommit_ratio < 100 это ведь поможет
MaksDragon
( 06.02.22 16:38:29 MSK ) автор топика
- Ответить на это сообщение
- Показать ответ
- Ссылка
Ответ на: комментарий от MaksDragon 06.02.22 16:38:29 MSK

Нет, не поможет. Если приложение течёт по памяти, то оно всё равно будет запрашивать больше и больше памяти, а где система ее взять если суммарный объём памяти(рам + подкачка) ограничен?
cobold ★★★★★
( 06.02.22 16:41:04 MSK )
- Ответить на это сообщение
- Показать ответы
- Ссылка
Ответ на: комментарий от cobold 06.02.22 16:41:04 MSK
Я в этом всём не очень разбираюсь, прошу терпения. Но у нас не программка которая будет запрашивать бесконечное количество память. Конечно она ограничена. Там условно памяти кушает рам + чуть больше файла подкачки. Этими параметрами просто разрешу программе кушать сколько угодно но по итогу она не съест все ресурсы под ноль. Я это вижу вот так.
MaksDragon
( 06.02.22 16:50:22 MSK ) автор топика
- Ответить на это сообщение
- Показать ответы
- Ссылка
Ответ на: комментарий от MaksDragon 06.02.22 16:50:22 MSK
Раз количество ограничено (и известно) создай заранее swap с небольшим запасом, в чем проблема?
kardapoltsev ★★★★★
( 06.02.22 18:09:35 MSK )
- Ответить на это сообщение
- Ссылка
На сервере 2гб оперативной памяти.
Нутакое. Небось ещё и с DE.
pinus_nigra ★
( 06.02.22 18:22:35 MSK )
- Ответить на это сообщение
- Ссылка
Ответ на: комментарий от MaksDragon 06.02.22 16:50:22 MSK

Не знаю что за приложение у вас, но выглядит стремно. а) использование свопа интерактивным приложением обычно приводит к «тормозам» приложения до такой степени что им становится некомфортно пользоваться; б) если приложение лезет в своп и при этом нормально работает + тот момент про проснулся однажды утром и обнаружил что приложение прибито по ООМ выглядит как будто приложение течёт по памяти. Для этой проблемы в общем случая только одно решение — исправлять приложение. Есть ещё костыли в виде регулярного рестарта приложения пока оно не прибито аварийно. Если вам не хватает памяти и вы уверены что достаточно увеличить своп, то есть ещё больший костыль — можно добавить своп файл man mkswap, man swapon, но лучше увеличить своп раздел
cobold ★★★★★
( 06.02.22 19:34:02 MSK )
- Ответить на это сообщение
- Показать ответ
- Ссылка
Ответ на: комментарий от MaksDragon 06.02.22 15:43:45 MSK
как это «увеличивался в размерах»?
своп — это файл или раздел. куда сбрасываются данные, которые не влезают в оперативную память. зачем ему «увеличиваться в размерах» если размер можно однократно задать, избежав фрагментации?
NiTr0 ★★★★★
( 06.02.22 22:37:36 MSK )
- Ответить на это сообщение
- Ссылка
Sysadminium
В этой статье рассматривается стратегия освобождения памяти в Linux и то, как системный администратор может этим управлять.
Оглавление скрыть
Стратегия освобождения памяти в Linux
Из предыдущей статьи вы узнали что каждому процессу выделяется блок памяти (виртуальная память) и он эту память использует (физическая память). Суммарно физическая память состоит из оперативной памяти и подкачки (swap). Но подкачка может лишь хранить какие-то данные, которые не очень востребованы. Процессам же, чтобы избежать сильных тормозов, требуется работать с оперативной памятью.
При всём этом, суммарно, виртуальной памяти может быть выделено больше чем есть оперативной памяти. И может случится такое, что процессу нужна память, а взять её не откуда. В этом случае ядро может высвободить занятую память тремя способами:
- сбросить, по мнению ядра, самые ненужные данные из резидентной памяти в swap;
- сбросить некоторые файлы, которые хранятся в Page Cache, на диск;
- запустить специальный инструмент OOM Killer, который завершит самый ненужный и занимающий больше всего памяти процесс.
Есть несколько стратегий распределения памяти. Управлять этими стратегиями можно с помощью параметра sysctl — vm.overcommit_memory. Этот параметр может принимать значения 0, 1 или 2:
- vm.overcommit_memory = 2 — сумма виртуальной память всех процессов не будет превышать физическую память. При этом, каждому отдельному процессу будет выделено не больше vm.overcommit_ratio процентов от всей памяти.
- vm.overcommit_memory = 1 — виртуальной памяти может быть выделено больше чем есть физической. При этом, если приложение действительно попытается использовать эту память а физической памяти не хватит, то произойдет событие out of memory. По умолчанию, при событии out of memory, запустится OOM Killer и завершит какой-то процесс. При такой стратегии можно настроить еще некоторые параметры sysctl:
- vm.panic_on_oom = 1 — при out of memory будет происходить kernel.panic вместо запуска OOM Killer;
- kernel.panic = 10 — при kernel.panic через 10 секунд сервер пере-загрузится.
Работа OOM Killer
OOM Killer — это компонент ядра Linux, призванный решать проблему недостатка памяти за счет убийства одного из существующих процессов по определённому алгоритму. В случае нехватки памяти (out of memory) он убивает процесс с помощью сигнала SIGKILL и не даёт ему корректно завершиться.
Алгоритм работы OOM Killer следующий. Все процессы, во время своей работы, накапливают специальные балы — oom_score. И при нехватке памяти OOM Killer убивает процесс с наивысшим oom_score. Посмотреть значение oom_score для процесса можно так — cat /proc//oom_score, например:
$ cat /proc/1/oom_score 0 $ cat /proc/2383/oom_score 668
Как рассчитывается oom_score (взято от сюда):
- чем больше памяти занимает процесс, тем выше oom_score;
- чем больше у процесса дочерних процессов, тем выше oom_score;
- чем выше у процесса Nice, тем выше oom_score;
- чем раньше создан процесс, тем ниже oom_score;
- если процесс имеет прямой доступ к аппаратному обеспечению, то oom_score снижается;
- если процесс имеет root привилегии, то oom_score снижается.
Но значением oom_score можно управлять, чтобы например обезопасить некоторые процессы от OOM Killer. Для этого у процесса есть параметр oom_score_adj. Чем меньше у процесса oom_score_adj, тем меньше oom_score.
Вы можете задать параметр oom_score_adj для служб systemd, поправив файл юнита службы. Для этого в секции [Service] укажите параметр OOMScoreAdjust со значением от — 1000 до 1000. Если указать -1000, то OOM Killer никогда не убьёт процессы данной службы. А если указать 1000, то для OOM Killer процессы этой службы превратятся в главную цель.
Также, вы можете напрямую записать значение oom_score_adj для определённого процесса. Для этого нужно поправить файл /proc//oom_score_adj.
$ cat /proc/2383/oom_score_adj 0 $ cat /proc/2383/oom_score 668 $ echo 20 | sudo tee /proc/2383/oom_score_adj $ cat /proc/2383/oom_score 682
В примере видно что вначале oom_score_adj для процесса 2383 равнялся 0, а oom_score равнялся 668. Затем я поменял значение oom_score_adj на 20 и oom_score увеличился до 682.
Итог
Вы узнали про некоторые параметры sysctl, с помощью которых можно настроить стратегию высвобождения памяти:
- vm.overcommit_memory — тип стратегии;
- vm.overcommit_ratio — процент всей памяти, который можно выделить одному процессу;
- vm.panic_on_oom — при событии out of memory выполнить kernel.panic;
- kernel.panic — перезагрузить сервер через указанное число секунд в случае kernel.panic.
Также вы узнали про инструмент OOM Killer. И про значения oom_score и oom_score_adj на которые полагается OOM Killer в своей работе.
И вы узнали что ситуация нехватки памяти называется — out of memory.
Памяти много а oom-killer работает
Я памяти прибавляю а киррер всё равно убивает процессы. в логах out of socket memory. по socket я и в sysctl tcp_mem прибавил, но как вижу не помогло. почему так? вот полный лог:
0 0 mingetty
0 sshd
Dec 14 10:51:20 myserver kernel: [12082] 498 12082 12767 10997 2 0 0 nginx
Dec 14 10:51:20 myserver kernel: [12085] 498 12085 12271 10483 1 0 0 nginx
Dec 14 10:51:20 myserver kernel: [12087] 498 12087 10543 8822 0 0 0 nginx
Dec 14 10:51:20 myserver kernel: Out of memory: Kill process 12082 (nginx) s core 14 or sacrifice child
Dec 14 10:51:20 myserver kernel: Killed process 12082, UID 498, (nginx) tota l-vm:51068kB, anon-rss:43200kB, file-rss:788kB
Dec 14 10:51:22 myserver kernel: __ratelimit: 3 callbacks suppressed
Dec 14 10:51:24 myserver kernel: nginx invoked oom-killer: gfp_mask=0xd0, or der=0, oom_adj=0, oom_score_adj=0
Dec 14 10:51:24 myserver kernel: nginx cpuset=/ mems_allowed=0
Dec 14 10:51:24 myserver kernel: Pid: 12085, comm: nginx Not tainted 2.6.32- 431.1.2.0.1.el6.i686 #1
Dec 14 10:51:24 myserver kernel: Call Trace:
Dec 14 10:51:24 myserver kernel: [] ? dump_header+0x84/0x190
Dec 14 10:51:24 myserver kernel: [] ? oom_kill_process+0x68/0x280
Dec 14 10:51:24 myserver kernel: [] ? oom_badness+0x92/0xf0
Dec 14 10:51:24 myserver kernel: [] ? out_of_memory+0xc8/0x1e0
Dec 14 10:51:24 myserver kernel: [] ? __alloc_pages_nodemask+0x7fd /0x810
Dec 14 10:51:24 myserver kernel: [] ? tcp_sendmsg+0x635/0x970
Dec 14 10:51:24 myserver kernel: [] ? sock_aio_write+0x13e/0x190
Dec 14 10:51:24 myserver kernel: [] ? sock_aio_write+0x0/0x190
Dec 14 10:51:24 myserver kernel: [] ? do_sync_readv_writev+0xce/0x 110
Dec 14 10:51:24 myserver kernel: [] ? autoremove_wake_function+0x0 /0x40
Dec 14 10:51:24 myserver kernel: [] ? security_file_permission+0xc /0x10
Dec 14 10:51:24 myserver kernel: [] ? rw_verify_area+0x66/0xe0
Dec 14 10:51:24 myserver kernel: [] ? do_readv_writev+0xa6/0x1b0
Dec 14 10:51:24 myserver kernel: [] ? sock_aio_write+0x0/0x190
Dec 14 10:51:24 myserver kernel: [] ? sys_recv+0x37/0x40
Dec 14 10:51:24 myserver kernel: [] ? vfs_writev+0x3e/0x50
Dec 14 10:51:24 myserver kernel: [] ? sys_writev+0x41/0xa0
Dec 14 10:51:24 myserver kernel: [] ? sysenter_do_call+0x12/0x28
Dec 14 10:51:24 myserver kernel: Mem-Info:
Dec 14 10:51:24 myserver kernel: DMA per-cpu:
Dec 14 10:51:24 myserver kernel: CPU 0: hi: 0, btch: 1 usd: 0
Dec 14 10:51:24 myserver kernel: CPU 1: hi: 0, btch: 1 usd: 0
Dec 14 10:51:24 myserver kernel: CPU 2: hi: 0, btch: 1 usd: 0
Dec 14 10:51:24 myserver kernel: Normal per-cpu:
Dec 14 10:51:24 myserver kernel: CPU 0: hi: 186, btch: 31 usd: 179
Dec 14 10:51:24 myserver kernel: CPU 1: hi: 186, btch: 31 usd: 181
Dec 14 10:51:24 myserver kernel: CPU 2: hi: 186, btch: 31 usd: 180
Dec 14 10:51:24 myserver kernel: HighMem per-cpu:
Dec 14 10:51:24 myserver kernel: CPU 0: hi: 186, btch: 31 usd: 37
Dec 14 10:51:24 myserver kernel: CPU 1: hi: 186, btch: 31 usd: 26
Dec 14 10:51:24 myserver kernel: CPU 2: hi: 186, btch: 31 usd: 31
Dec 14 10:51:24 myserver kernel: active_anon:28222 inactive_anon:7959 isolat ed_anon:0
Dec 14 10:51:24 myserver kernel: active_file:6327 inactive_file:5842 isolate d_file:0
Dec 14 10:51:24 myserver kernel: unevictable:1506 dirty:6 writeback:0 unstab le:0
Dec 14 10:51:24 myserver kernel: free:510706 slab_reclaimable:1842 slab_unre claimable:157006
Dec 14 10:51:24 myserver kernel: mapped:2517 shmem:94 pagetables:405 bounce: 0
Dec 14 10:51:24 myserver kernel: DMA free:3524kB min:64kB low:80kB high:96kB active_anon:0kB inactive_anon:0kB active_file:4kB inactive_file:4kB unevictable :0kB isolated(anon):0kB isolated(file):0kB present:15856kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:152kB slab_unreclaimable:23 64kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB p ages_scanned:0 all_unreclaimable? no
Dec 14 10:51:24 myserver kernel: lowmem_reserve[]: 0 863 3032 3032
Dec 14 10:51:24 myserver kernel: Normal free:3556kB min:3724kB low:4652kB hi gh:5584kB active_anon:0kB inactive_anon:0kB active_file:68kB inactive_file:0kB u nevictable:0kB isolated(anon):0kB isolated(file):0kB present:883912kB mlocked:0k B dirty:0kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:7216kB slab_unre claimable:625660kB kernel_stack:896kB pagetables:0kB unstable:0kB bounce:0kB wri teback_tmp:0kB pages_scanned:0 all_unreclaimable? no
Dec 14 10:51:24 myserver kernel: lowmem_reserve[]: 0 0 17351 17351
Dec 14 10:51:24 myserver kernel: HighMem free:2035744kB min:512kB low:2852kB high:5192kB active_anon:112888kB inactive_anon:31836kB active_file:25236kB inac tive_file:23364kB unevictable:6024kB isolated(anon):0kB isolated(file):0kB prese nt:2220972kB mlocked:6024kB dirty:24kB writeback:0kB mapped:10064kB shmem:376kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:1620kB u nstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:1664 all_unreclaimable? n o
Dec 14 10:51:24 myserver kernel: lowmem_reserve[]: 0 0 0 0
Dec 14 10:51:24 myserver kernel: DMA: 5*4kB 44*8kB 19*16kB 13*32kB 4*64kB 1* 128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 3524kB
Dec 14 10:51:24 myserver kernel: Normal: 387*4kB 3*8kB 4*16kB 4*32kB 0*64kB 2*128kB 0*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 3556kB
Dec 14 10:51:24 myserver kernel: HighMem: 10*4kB 7*8kB 46*16kB 417*32kB 395* 64kB 194*128kB 133*256kB 12*512kB 8*1024kB 5*2048kB 467*4096kB = 2035744kB
Dec 14 10:51:24 myserver kernel: 12893 total pagecache pages
Dec 14 10:51:24 myserver kernel: 0 pages in swap cache
Dec 14 10:51:24 myserver kernel: Swap cache stats: add 0, delete 0, find 0/0
Dec 14 10:51:24 myserver kernel: Free swap = 65528kB
Dec 14 10:51:24 myserver kernel: Total swap = 65528kB
Dec 14 10:51:24 myserver kernel: 786428 pages RAM
Dec 14 10:51:24 myserver kernel: 559615 pages HighMem
Dec 14 10:51:24 myserver kernel: 41636 pages reserved
Dec 14 10:51:24 myserver kernel: 46018 pages shared
Dec 14 10:51:24 myserver kernel: 207900 pages non-shared
Dec 14 10:51:24 myserver kernel: [ pid ] uid tgid total_vm rss cpu o om_adj oom_score_adj name
0 mingettyDec 14 10:51:25 myserver init: tty (/dev/tty3) main process (1188) killed by TERM signal
Dec 14 10:51:25 myserver init: tty (/dev/tty4) main process (1190) killed by TERM signal
Dec 14 10:51:25 myserver init: tty (/dev/tty5) main process (1195) killed by TERM signal
Dec 14 10:51:25 myserver init: tty (/dev/tty6) main process (1197) killed by TERM signal
Dec 14 10:51:27 myserver kernel: TCP: time wait bucket table overflow
Dec 14 10:51:28 myserver named[1052]: received control channel command ‘stop ‘
Dec 14 10:51:28 myserver named[1052]: shutting down: flushing changes
Dec 14 10:51:28 myserver named[1052]: stopping command channel on 127.0.0.1# 953
Dec 14 10:51:28 myserver named[1052]: stopping command channel on ::1#953
Dec 14 10:51:28 myserver named[1052]: no longer listening on 127.0.0.1#53
Dec 14 10:51:28 myserver named[1052]: no longer listening on 5.45.75.69#53
Dec 14 10:51:28 myserver named[1052]: no longer listening on 5.45.76.187#53
Dec 14 10:51:28 myserver named[1052]: no longer listening on 5.45.74.67#53
Dec 14 10:51:28 myserver named[1052]: no longer listening on 5.45.77.200#53
Dec 14 10:51:28 myserver named[1052]: no longer listening on ::1#53
Dec 14 10:51:28 myserver named[1052]: exiting
Dec 14 10:51:30 myserver auditd[1007]: The audit daemon is exiting.
Dec 14 10:51:30 myserver kernel: type=1305 audit(1481730690.057:114096): aud it_pid=0 old=1007 auid=4294967295 ses=4294967295 subj=system_u:system_r:auditd_t :s0 res=1
Dec 14 10:51:30 myserver kernel: type=1305 audit(1481730690.162:114097): aud it_enabled=0 old=1 auid=4294967295 ses=4294967295 subj=system_u:system_r:auditct l_t:s0 res=1
Dec 14 10:51:30 myserver kernel: Kernel logging (proc) stopped.
Dec 14 10:51:30 myserver rsyslogd: [origin software=»rsyslogd» swVersion=»5. 8.10″ x-pid=»1032″ x-info=»http://www.rsyslog.com»] exiting on signal 15.
[root@myserver ~]#- eTarget 2011:Панельная дискуссия «Стратегия и планирование рекламной кампании в интернете»
- eTarget 2011: Круглый стол «Реклама в онлайн-видео»
- Могут ли «плохие» входящие ссылки привести к ухудшению ранжирования?
На сайте с 04.01.2012
15 декабря 2016, 23:44Попробуйте отключить на сервере IPv6
и в файл /etc/sysctl.conf
Добавить или привести строки к такому виду
По идее должно помочь
Если не поможет вот есть статья
попробуйте сделать по ней
NVMe VDS (https://well-web.net/nvme-vps) с поддержкой 24/7 — от 545 руб.! Безлимитный хостинг (https://well-web.net/ssd-hosting) — от 129 руб.! Домен в подарок! Перенос бесплатно! Заказывайте сейчас, и получите скидку 50%! Заходи! (https://well-web.net/limited-offers)
На сайте с 25.04.2008
17 декабря 2016, 15:26увеличил tcp_mem и max_orphans (как-то так называется) и ошибка про out of socket memory пропала, обрывов при загрузке сайтов не стало, но теперь иногда приходит полный крах — убивается nginx
worker process exited on signal 9
гугление мне ничего не даёт кроме увеличения ram, а он у меня занят на 30% и свап не используется.
куда ещё смотреть?
трафика много идёт, 600мбит
На сайте с 20.04.2005
17 декабря 2016, 16:20Сервер виртуальный? Если нет, то поведение странное.