LINUX.ORG.RU
решено ФорумAdmin

Забивается SWAP. Centos 6.10. Ресурсов (считаю) хватает. Подскажите, куда копать?

 


1

3

Всем приветы.

Сервер Centos 6.10

Его задача - обычный сервак, на котором крутится пару десятков ненагруженых сайтов типа «интернет сайт компании по починке лопат». Сервер - работающий, боевой, несколько лет и перезагружать его «совсем проблематично». Крайний раз перезапускался пару лет назад.

За всё это время на нем изначально установлены Apache, MySQL, Nginx, почта ну и всякое ещё по мелочи - описывать долго, да и наверное сразу нет смысла. Потом, по ходу задач - что-то доустанавливалось, переконфигурировалось и т.д.

Конфиг : 22 проца. 130 ГБ оперативки. Основной раздел - примерно 600 Гб. Раздел SWAP 10 ГБ. В общем, считаю что для своей задачи - хватает ему железных ресурсов «за глаза».. Почему именно такой сервер? Да просто в своё время - думал «на будущее пригодится»..

Что ещё написать подробнее - не знаю, если спрОсите - отвечу.

Стандартная загрузка ЦПУ - 5-10%. Оперативной памяти все запущенные процессы занимают гигов 40-50 макс. Места на харде «занято наполовинку».

Проблема: растёт SWAP.

В какой то момент ( рандомно ) SWAP начинает просто забиваться. И так до момента «забито Все 10 Гигов»… При этом оперативка - наполовину свободная.

Потом OOM-Killer что нибудь убивает, перезапускает, машинка начинает тормозить. SWAP - чищу, если что то не запустилось само - перезапускаю ручками.. Всё оживает. И работает нормально. И вот так «по кругу». Раз в недельку ((

Смотрел, кто лезет в swap, может кому-то мало памяти и т.д.. Смотрел-экспериментировал с конфигами апача, мускула.. В бубен бил, танцевал, Ктулху звал.. Не помогает (((…

Чищу примерно так: Пока нашёл костыльное решение - написал скриптик, который "в кроне раз в 10 минут смотрит достиг ли swap размера в 100 MB ( или в 1 ГБ, 5 ГБ ) - и командами ( пробовал разные варианты ) примерно такими чищу его:

sync && sleep 5 && echo 3 > /proc/sys/vm/drop_caches
sleep 5
sync && sleep 5 && echo 0 > /proc/sys/vm/drop_caches
sleep 5
/sbin/swapoff -a && sleep 1 && /sbin/swapon -a

Искал-использовал различные скрипты, которые «показывают кто занимает swap, что-то анализирут и т.д.» - эффекта нету. Показывают «нули», когда свап - уже растёт (..

/proc/sys/vm/swappiness 5 /proc/sys/vm/vfs_cache_pressure 1000

Уровень моих знаний - оценил бы как «средний». Сервер - собирал железки и накатывал сам. То есть по манам руководствам - всё поставить смогу. Но до уровня «сисадмин» - не дорос.

Помогите, куда ткнуться? как найти виновника??…

PS - нашёл, что Апач.. Но это уже другая задача..

Перемещено hobbit из general



Последнее исправление: dessdess (всего исправлений: 1)

Ну а зачем ты такой мелкий свап сделал? Сделай как память 130ГБ и исчезнут проблемы.

И так до момента «забито Все 10 Гигов»… При этом оперативка - наполовину свободная.

Посмотри на это с другой стороны: у тебя занято целых 60ГБ оперативки, и всего 16% от этого объёма ядро посчитано нужным выгрузить на диск по причине редкого использования. Всё адекватно.

Да, многие репортят что у них всё работает или с мелким свапом или вообще без него, но тем не менее основной режим работы ядра - это когда свапа не меньше чем памяти, и лучше не злоупотреблять тем что «кажется и так всё работает».

firkax ★★★★★
()

Искал-использовал различные скрипты, которые «показывают кто занимает swap, что-то анализирут и т.д.» - эффекта нету.

Есть скрипт oom-sort, из пакета nohang, Linux ate my RAM - 2 (комментарий). Не знаю правда, насколько он эффективен для твоего случая. Да и сам не пользовался.


oom-sort --sort VmSwap -l0

krasnh ★★★
()
Последнее исправление: krasnh (всего исправлений: 4)
Ответ на: комментарий от krasnh

Своп это не «запасная оперативка на случай заканчивания основной». Он нужен для корректной работы ядерного менеджера страниц, вне зависимости от того сколько оперативки занято. Да, у некоторых даже некорректно работающий аллокатор в итоге не вызывает проблем, но не надо думать что так всегда будет.

firkax ★★★★★
()

В какой то момент ( рандомно ) SWAP начинает просто забиваться.

Потом OOM-Killer что нибудь убивает

Да, то что я выше написал, это подход не с того бока, все же явная ‘течь’ какого-то процесса. Но смутило, что своп забился, а память нет, и при этом oom-killer срабатывает.

Как-то все это непривычно работает на старых ПО. Хотя, просто так oom-killer настроен, наверно.

krasnh ★★★
()
Последнее исправление: krasnh (всего исправлений: 2)

SWAP может забиваться и при нормальной работе, потому что ядро выгружает неиспользуемые страницы памяти, даже если память свободна вся.

При этом оперативка - наполовину свободная.

Потом OOM-Killer что нибудь убивает

А вот так не бывает. OOM-Killer убивает, когда памяти не хватает.

Вообще, выглядит так, как будто у тебя стоит руткит, забивающий память и скрывающий себя от утилит контроля системы. Учитывая что это старый дистрибутив и боевой сервер, вероятность высока. Есть ли возможность для начала просканить на руткиты?

Aceler ★★★★★
()
Последнее исправление: Aceler (всего исправлений: 1)
Ответ на: комментарий от Aceler

Спасибо всем, кто подключился к беседе!

Попробую в этом сообщении ответить на те вопросы-дополнения, которые выше данного сообщения.

  1. установи ядро > 6.1, 2. включи zswap

Как я и писал выше - «установка переустановка = серп по яццам».. Никак не можно ((( Что такоt zswap - не слышал раньше. Иду читать-понимать!)

grep -i swap /proc/*/status

/proc/6711/status:VmSwap: 0 KB

Аналогично и все остальные процессы. Всё «по нулям»(..

Есть ли возможность для начала просканить на руткиты?

Есть, я - «рут» в системе). Вроде никто ничего не ломал никогда.. Но вдруг?… Буду смотреть как сие сделать и вдруг что то найдётся..

..Есть скрипт oom-sort..

Заранее спасибо! Про него ничего не слышал. Опять таки иду его искать и читать что он и как делает.

df -h

Filesystem Size Used Avail Use% Mounted on

/dev/mapper/vg_vmc610-lv_root 679G 555G 90G 87%

/tmpfs 10G 976M 9,1G 10% /dev/shm

/dev/sda1 477M 285M 167M 64% /boot

tmpfs - это ram диск на 10 ГБ.

Извиняюсь, если форматирование неверное. У меня на форуме постов очень мало. Я тут больше как читатель бываю..

dessdess
() автор топика
Ответ на: комментарий от rupert

Да конечно могу. Попробую выложить кусочек лога kernel.log. Весь выкладывать - наверное мусор и бесмысленно.

Как я понимаю - надо смотреть что вызывает oom-killer. Смотрю.. И это разные процессы. ( httpd73 - к примеру - это просто у меня так запущен демон апача с пхп 7.3. Только не спрашивайте почему так. Это «совсем другая история» ))

Apr 3 23:55:21 vmc610 kernel: httpd73 invoked oom-killer:

Apr 3 23:55:21 vmc610 kernel: Out of memory: Kill process 28852 (mysqld) score 691 or sacrifice child

Apr 3 23:55:21 vmc610 kernel: Killed process 28852, UID 27, (mysqld)

Apr 3 23:55:21 vmc610 kernel: memcached-0 invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0

Apr 3 23:55:21 vmc610 kernel: Out of memory: Kill process 21930 (memcached) score 63 or sacrifice child

Apr 13 03:50:15 vmc610 kernel: searchd[15212]: segfault at 2d0 ip 00007f2846323ea1 sp 00007ffc04a461c0 error 4 in libpthread-2.17.so[7f284631b000+16000]

Apr 17 21:44:56 vmc610 kernel: searchd invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0

Apr 17 21:44:56 vmc610 kernel: searchd cpuset=/ mems_allowed=0-1

dessdess
() автор топика
Ответ на: комментарий от dessdess

Извиняюсь, если форматирование неверное

Здесь все про форматирование на ЛОРе, https://www.linux.org.ru/help/markdown.md.
Пример разметки для кода:

```

Код

```

Если текста много, например какой-то длинный лог, то выкладывать на pastebin.com.

krasnh ★★★
()
Ответ на: комментарий от krasnh

все же явная ‘течь’ какого-то процесса. Но смутило, что своп забился, а память нет, и при этом oom-killer срабатывает.

Такое понятие слышал, что в инете есть - почитал на эту тему. Но примеривая этот случай на себя - просто не могу ( знаний-опыта не хватает видимо ) понять - как найти то, что течёт? Нашёл бы - то да и перекомпилил бы или переустановил и установки-конфиги бы прочитал много раз и т.д..

А условия такие - что основной софт был поставлен-( или скомпилирован)-сконфигурирован мною же «лет три-пять назад». И находился ( да и находится ) в состоянии «работает-не-трожь». Так как я считал, что если я в своё время «вот так сделал» - значит это было нужно, проверено и работает :)

Проблема началась пару месяцев назад.. Вместе с тем - смотрю на это со стороны - прямо как в кино - типа «дяденька, а я тут никаких выключателей не трогал, а оно погасло!» ))

dessdess
() автор топика

Проблема: растёт SWAP.

Настоящая проблема - невозможность выделения памяти, что в итоге приводит к убийству процессов.

https://github.com/hakavlad/nohang/blob/master/src/oom-sort

$ oom-sort -s VmSwap -l0
oom_score oom_score_adj   UID     PID Name            VmRSS   VmSwap
--------- ------------- ----- ------- --------------- ------- --------
      813           167  1000   42160 Isolated Web Co  2677 M    443 M 
      681             0  1000   26343 firefox-esr       931 M    366 M 
      791           167  1000   30872 Isolated Web Co   901 M    272 M 
      787           167  1000   30054 Isolated Web Co   646 M    194 M 
      786           167  1000   30934 Isolated Web Co   545 M    185 M 
      670             0  1000   50894 firefox-esr       281 M    112 M 
      781           167  1000   51112 Isolated Web Co   244 M     77 M 
      781           167  1000   51335 Isolated Web Co   271 M     76 M 
      666             0  1000    2330 mate-system-mon    21 M     34 M 
      778           167  1000   51154 Isolated Web Co    53 M     33 M 
      734           100  1000   26563 Isolated Web Co    75 M     32 M 
      734           100  1000   26581 Isolated Web Co    62 M     31 M 
      734           100  1000   26794 WebExtensions     108 M     26 M 

Как искать винговника? Запускать oom-sort -s VmSwap -l0 от рута, наблюдать в динамике.

При этом оперативка - наполовину свободная

Именно free много?

И какая версия ядра, кстати? 2.6?

Смотрел, кто лезет в swap

В своп лезет не тот, кому мало памяти. В своп улетают неактивные страницы, а не страницы процесса, который внезапно начал протекать.

hakavlad ★★★
()
Ответ на: удаленный комментарий

А почему в логе апрель?

Кусочек с ( видимо прошлого года )

Версия ядра 2.6.32-754.35.1.el6.x86_64

Нет ли в dmesg I/O errors?

Посмотрел. Нету. Дата файла - 10.2022. Видимо это дата крайней перезагрузки. С точки зрения железа - всё в порядке. То есть Харды, Мать, Память, ЦПУ - живые полностью.

Именно free много?


#free -m
             total       used       free     shared    buffers     cached
Mem:        120981     116277       4704      61779       3010      65300
-/+ buffers/cache:      47966      73015
Swap:         9999          0       9999

#df -h : 

Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_vmc610-lv_root  679G  234G  411G  37% /
tmpfs                          10G  981M  9,1G  10% /dev/shm
/dev/sda1                      477M  285M  167M  64% /boot

Стандартное состояние сервера если смотреть htop, сортировка по % памяти:


  1  [||||||||||||||||||||||||||||||||||||||                                  48.1%]     12 [|||||||||||||||||                                                       20.9%]
  2  [|||||||||||||||||||||||||||||||||||||||||||||||||||||                   67.4%]     13 [|||||||||||||||||||                                                     23.7%]
  3  [||||||||||                                                              12.1%]     14 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 91.1%]
  4  [|||||||||||||||||||||||||||                                             34.3%]     15 [||||                                                                     3.8%]
  5  [||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||98.1%]     16 [||||||||||||||||                                                        19.7%]
  6  [||||||||||||||||||||||||||||||||||||||||||||||||||||||||                71.5%]     17 [                                                                         0.0%]
  7  [||||                                                                     3.3%]     18 [||||||                                                                   7.1%]
  8  [|||||||||||||||||||||||||||||||||||||                                   46.5%]     19 [|||                                                                      2.8%]
  9  [|||||||||||||||||||||||||||||||||||||                                   46.5%]     20 [                                                                         0.0%]
  10 [                                                                         0.0%]     21 [|                                                                        0.5%]
  11 [                                                                         0.0%]     22 [|||||||||                                                               10.8%]
                                                                                         Tasks: 227; 7 running
  Mem[|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||48281/120981MB]     Load average: 6.95 7.89 9.10
  Swp[|                                                                    5/9999MB]     Uptime: 479 days(!), 12:32:46
                                                                                         Time: 13:31:31

  PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
24799 mysql      20   0 88.1G 37.9G  4912 S 157. 32.1     186h /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --user=mysql --
21365 memcached  20   0 3987M 3264M   764 S  0.9  2.7  0:10.21 memcached -d -p 11211 -u memcached -m 8192 -c 2048 -P /var/run/memcached/memcached.pid -t 8 -n 64 -f 1.05 -l 127
21132 apache     20   0  735M  169M 35132 S  0.0  0.1  0:02.70 /usr/sbin/httpd
21171 apache     20   0  727M  158M 30936 S  0.0  0.1  0:01.47 /usr/sbin/httpd
20967 apache     20   0  612M  132M 59168 S  0.0  0.1  1:14.31 /usr/sbin/httpd73 -f /usr/local/httpd2234/conf/httpd73.conf
20949 apache     20   0  601M  127M 63164 S  0.0  0.1  0:38.60 /usr/sbin/httpd73 -f /usr/local/httpd2234/conf/httpd73.conf
27788 apache     20   0  601M  120M 67736 S  0.0  0.1  0:50.46 /usr/sbin/httpd73 -f /usr/local/httpd2234/conf/httpd73.conf
20954 apache     20   0  599M  120M 60184 R 61.7  0.1  1:03.48 /usr/sbin/httpd73 -f /usr/local/httpd2234/conf/httpd73.conf
20982 apache     20   0  597M  120M 72940 S 63.6  0.1  0:47.89 /usr/sbin/httpd73 -f /usr/local/httpd2234/conf/httpd73.conf
20997 apache     20   0  589M  119M 67432 S  0.0  0.1  0:45.21 /usr/sbin/httpd73 -f /usr/local/httpd2234/conf/httpd73.conf
20947 apache     20   0  589M  116M 78012 S  4.7  0.1  0:53.25 /usr/sbin/httpd73 -f /usr/local/httpd2234/conf/httpd73.conf
20965 apache     20   0  597M  116M 67232 S  0.0  0.1  0:24.66 /usr/sbin/httpd73 -f /usr/local/httpd2234/conf/httpd73.conf

Чуть времени проходить ( чуть = типа пять минут и.. SWAP опять растёт!((((

Постарался не накосячить с разметкой… Как смог.

dessdess
() автор топика
Ответ на: комментарий от dessdess

Общая моя политика примерно такая:

mysql - может занимать до 70 ГБ оперативки ( из 120-ти физических). (innodb_buffer_pool_size = 70G )

Остальное отдавать Апачу-Нжинксу.

Я писАл выше - основная задача сервера - нести на себе пару десятков сайтов ненагруженых. с посещалками до 2000 людей в сутки.. Личные сайты, сайты маленьких компаний..

Конечно смотрел логи и апача и нжинкса.

Стоит fail2ban - который режет всех, кто пытается куда-то залезть или много раз сделать одно и тоже - типа «спарсить всё за пять секунд».

Стоит модуль geoip на Нжинксе, который фильтрует китайцев-индусов-и-иже-с-ними.

Про настройки этого всего опять таки - наверное не эта тема. Делал как мог, на что мог обратить внимание..

dessdess
() автор топика