LINUX.ORG.RU
ФорумAdmin

Mysqld жрет swap при свободной RAM

 , , , ,


0

1

Привет, камрады.

Имеется проблема: subj

Что заметили - проблема проявляется при использовании использовании binlog.

При этом несколько серваков попадает под раздачу, с разной топологией:

 M -- M -- S

 M -- S
 |
 |
 S

и так далее. Это всегда slave. Были мысли, что в один момент Mysqld не хватает памяти и идет в своп, но нет - метрики говорят, что использование памяти всегда постоянно (выхлоп ниже).

Рестарт mysqld помогает ненадолго и снова имеем такую же картину.

База работает на одно приложение, размер базы маленький - 30 Гб. LA околонулевые, iostat предоставлен ниже

[me ~]$ cat /etc/redhat-release 
CentOS Linux release 7.6.1810 (Core) 

Версия мускуля:

5.7.25

Выхлоп free:

[me ~]$ free -h
              total        used        free      shared  buff/cache   available
Mem:            31G        6.8G        243M        1.5G         24G         22G
Swap:          8.0G        3.0G        5.0G

Выхлоп процессов потреблению свопа:

[me ~]$ for file in /proc/*/status ; do awk '/VmSwap|Name/{printf $2 " " $3}END{ print ""}' $file; done | sort -k 2 -n -r | head -5
mysqld 2976632 kB
tuned 10556 kB
polkitd 5100 kB
VGAuthService 1588 kB
NetworkManager 1384 kB
параметры ядра по памяти:
sudo sysctl -a | grep -i vm
vm.admin_reserve_kbytes = 8192
vm.block_dump = 0
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 3000
vm.dirty_ratio = 30
vm.dirty_writeback_centisecs = 500
vm.drop_caches = 0
vm.extfrag_threshold = 500
vm.hugepages_treat_as_movable = 0
vm.hugetlb_shm_group = 0
vm.laptop_mode = 0
vm.legacy_va_layout = 0
vm.lowmem_reserve_ratio = 256   256     32
vm.max_map_count = 65530
vm.memory_failure_early_kill = 0
vm.memory_failure_recovery = 1
vm.min_free_kbytes = 67584
vm.min_slab_ratio = 5
vm.min_unmapped_ratio = 1
vm.mmap_min_addr = 4096
vm.mmap_rnd_bits = 28
vm.mmap_rnd_compat_bits = 8
vm.nr_hugepages = 0
vm.nr_hugepages_mempolicy = 0
vm.nr_overcommit_hugepages = 0
vm.nr_pdflush_threads = 0
vm.numa_zonelist_order = default
vm.oom_dump_tasks = 1
vm.oom_kill_allocating_task = 0
vm.overcommit_kbytes = 0
vm.overcommit_memory = 0
vm.overcommit_ratio = 50
vm.page-cluster = 3
vm.panic_on_oom = 0
vm.percpu_pagelist_fraction = 0
vm.stat_interval = 1
vm.swappiness = 30
vm.user_reserve_kbytes = 131072
vm.vfs_cache_pressure = 100
vm.zone_reclaim_mode = 0
my.cnf
[me ~]$ grep -vE "^$|^#"  /data/mysql/my.cnf 
[mysqld]
server-id = 14116
log-bin = hostname-bin
log-error=/data/mysql/hostname
basedir=/usr
datadir = /data/mysql
tmpdir  = /data/mysql/tmp/
innodb_data_home_dir = /data/mysql/
socket = /data/mysql/mysql.sock
sql_mode=NO_ENGINE_SUBSTITUTION
explicit_defaults_for_timestamp = 1
query_cache_type = 0
thread_cache_size = 500
tmp_table_size = 5G
delayed_queue_size = 200
net_buffer_length = 32K
read_rnd_buffer_size = 64M
bulk_insert_buffer_size = 512M
join_buffer_size = 512M
read_buffer_size = 512M
sort_buffer_size = 512M
innodb_buffer_pool_size=25G
innodb_data_file_path = ibdata1:12M:autoextend
innodb_file_per_table = 1
innodb_log_files_in_group = 2
innodb_log_file_size = 4G
innodb_flush_log_at_trx_commit = 2
innodb_log_buffer_size = 512M
innodb_flush_method = O_DIRECT
innodb_thread_concurrency = 48
innodb_strict_mode=off
max_connections = 2400
expire_logs_days = 3
max_allowed_packet = 1024M
max_error_count = 64
max_heap_table_size = 1024M
open_files_limit = 4096
long_query_time = 30
wait_timeout = 1800
max-binlog-size = 1024M
range_optimizer_max_mem_size = 0
binlog-format = mixed
slave_parallel_workers=40
slave_parallel_type = LOGICAL_CLOCK
net_read_timeout=120
net_write_timeout=180
[me~]$ iostat 
Linux 3.10.0-957.el7.x86_64 (hostname)       01/13/2020      _x86_64_        (4 CPU)
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.96    0.05    0.32    0.18    0.00   98.49
Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda              10.23         1.07       474.06    9583704 4236848304
dm-0              0.10         0.01         0.39      73093    3495820
dm-1              0.13         0.08         0.43     751960    3840532
dm-2              0.04         0.54         0.02    4802280     200592
dm-3             22.66         0.38       469.33    3363537 4194622224
dm-4              0.96         0.06         3.88     562013   34689060

Подозреваю, что еще нужен выхлоп переменных рантайма, но там их очень уж дофига.

Если есть толковые DBA - помогите, пожалста, ничего в голову не приходит.

★★★★

можно через загрузочную строку включить cgroup2

а в юните базы прописать ограничение или выкл своппинга.

MemorySwapMax=1G в юните базы

swapaccount=1 systemd.unified_cgroup_hierarchy=1 в boot cmdline

anonymous ()
Ответ на: комментарий от chaos_dremel

Хочется понять, почему одни серваки идут в своп, а другие - нет.

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

Да, на железных серваках отключаем, на вируталках оставляем.

Если апликуха действительно сожрёт всю память, то пусть лучше в своп идёт, чем ляжет.

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

watermrk scale factor можно поправить. В своп идёт та память, которая активно не используется. На разных серваках это разные объемы памяти, естесно.

Deleted ()
Ответ на: комментарий от PunkoIvan

30 это довольно консервативное значение. У меня был подобный кейс. Приходил по крону антивирус, отжирал память, вытеснял мускуль в своп. Даже swappiness=5 не спасал от такого поведения.

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

ЕМНИП, даже при swappiness 0, но при присутствующем свапе, туда будет складываться чуть-чуть всякого.

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

Прикол в том, что графана показывает ровное использование памяти физической.

Если б так было, то вопрос не было.

У нас случай, что память свободная есть постоянно, и постоянно лезем в своп.

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

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

swappiness - рекомендательный параметр и влияет на агрессивность свопа не сильно.

vm.watermark_boost_factor = 15000
vm.watermark_scale_factor = 100

Тебя интересует вот это.

https://www.kernel.org/doc/Documentation/sysctl/vm.txt

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

У нас случай, что память свободная есть постоянно, и постоянно лезем в своп.

штатное поведение системы.

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

Спасибо, надо копать и разбираться на более низком уровне, интересно.

Если вообще этих параметров нет, можно из задать без боли через sysctl?

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

Почему на одних серверах это проявляется, а на других - нет?

сравнивали параметры ядра, сравнивали конфиг мускуля - всё идентично. Единственное место, где может быть разница - соотношение r/w операций и число соединений.

Глупый вопрос - при недостаточном ресурсе дисковой подсистемы может ли это влиять на память (РАМ) ?

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

Смотрел вот так:

[me~]$ sudo cat /proc/8124/numa_maps | grep -i swap
01cdd000 default file=/usr/sbin/mysqld anon=62 dirty=50 mapped=112 swapcache=12 active=92 N0=112 kernelpagesize_kB=4
02819000 default heap anon=46594 dirty=46539 swapcache=55 active=46162 N0=46594 kernelpagesize_kB=4
7ff41daae000 default anon=13313 dirty=13312 swapcache=1 N0=13313 kernelpagesize_kB=4
7ff431a66000 default anon=22581 dirty=22528 swapcache=53 active=20532 N0=22581 kernelpagesize_kB=4
7ff4586d4000 default anon=1434628 dirty=1392044 swapcache=42584 active=1302469 N0=1434628 kernelpagesize_kB=4
7ffb25572000 default file=/usr/lib64/libgcc_s-4.8.5-20150702.so.1 anon=1 swapcache=1 N0=1 kernelpagesize_kB=4
7ffb25874000 default file=/usr/lib64/libm-2.17.so anon=1 swapcache=1 N0=1 kernelpagesize_kB=4
7ffb25b5e000 default file=/usr/lib64/libstdc++.so.6.0.19 anon=4 dirty=1 swapcache=3 N0=4 kernelpagesize_kB=4
7ffb25b68000 default anon=4 dirty=1 swapcache=3 N0=4 kernelpagesize_kB=4
7ffb263ca000 default file=/usr/lib64/libnuma.so.1 anon=1 swapcache=1 N0=1 kernelpagesize_kB=4
7ffb269fa000 default anon=5 dirty=1 swapcache=4 N0=5 kernelpagesize_kB=4
7ffb26a0a000 default anon=1 swapcache=1 N0=1 kernelpagesize_kB=4
7ffb26a0c000 default file=/usr/lib64/ld-2.17.so anon=1 swapcache=1 N0=1 kernelpagesize_kB=4

Но мало что понял :)

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

Если вообще этих параметров нет, можно из задать без боли через sysctl?

Их не может не быть. sysctl -a | grep watermark

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

Единственное место, где может быть разница - соотношение r/w операций и число соединений.

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

Глупый вопрос - при недостаточном ресурсе дисковой подсистемы может ли это влиять на память (РАМ) ?

Не понял вопроса. Диск используется, как подкачка для памяти, но не наоборот.

Deleted ()

Не смог решить такую же проблему (репликации не было) - в процессе работы mysql понемногу подъедал swap, через несколько недель приходилось перезапускать, мигрировал на postgres

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

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

avb ()
Ответ на: комментарий от Deleted

Лол. Ты предлагаешь смириться с тем что происходит и называешь это нормальным. Предложить по делу ничего не можешь и написал тупняк, так же как и я.

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

Да вы тут все странеые, включая ТС. Причем смешнее всего, что тс привел достаточно инфы, чтобы понять что происходит, но всем неважно, читать сложно, думать - вообще запрещено.

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

vm.dirty_background_ratio = 1
У меня решает проблему выползания в свап при копировании файла большого размера.
Но вот свою проблему с vzdump я так и не смог решить нормально. Просто включил zswap c lzo сжатием и добавил в крон swapoff -a && swapon -a раз в сутки. Zswap здорово снижает нагрузку на диск.

Deleted ()
Ответ на: комментарий от Deleted
[me ~]$ sudo sysctl -a | grep water
[ipunko@prod-icinga-vdb-m2 ~]$ 
[ipunko@prod-icinga-vdb-m2 ~]$ ls /proc/sys/vm/
admin_reserve_kbytes    dirty_background_ratio  dirty_writeback_centisecs   hugetlb_shm_group     max_map_count              min_slab_ratio      mmap_rnd_compat_bits     nr_pdflush_threads        overcommit_kbytes  panic_on_oom              user_reserve_kbytes
block_dump              dirty_bytes             drop_caches                 laptop_mode           memory_failure_early_kill  min_unmapped_ratio  nr_hugepages             numa_zonelist_order       overcommit_memory  percpu_pagelist_fraction  vfs_cache_pressure
compact_memory          dirty_expire_centisecs  extfrag_threshold           legacy_va_layout      memory_failure_recovery    mmap_min_addr       nr_hugepages_mempolicy   oom_dump_tasks            overcommit_ratio   stat_interval             zone_reclaim_mode
dirty_background_bytes  dirty_ratio             hugepages_treat_as_movable  lowmem_reserve_ratio  min_free_kbytes            mmap_rnd_bits       nr_overcommit_hugepages  oom_kill_allocating_task  page-cluster       swappiness
PunkoIvan ★★★★ ()
Ответ на: комментарий от avb

Если ты глянешь ОП, то там есть вывод програм, которые используют своп. не обязательно использовать программу специальную, если можно накостылять на баше.

for file in /proc/*/status ; do awk '/VmSwap|Name/{printf $2 " " $3}END{ print ""}' $file; done | sort -k 2 -n -r | head -5

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

У меня в ядре это есть. Наверно у тебя совсем древность ?
Кстати тюнинг watermark мне ничем не помог.

Deleted ()
Ответ на: комментарий от Anoxemian

Долго думал и не один я, честно. Не хватает опыта разобраться с памятью, поэтому обратился на форум.

Мудрили с overcommit`ом, но не вышло толко ничего.

Подскажи, если решение лежит на поверхности.

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

Да, и еще момент. QPS на серверах с проблемой - больше, чем на серверах без проблемы? Тот же вопрос про размер БД?

Deleted ()
Ответ на: комментарий от PunkoIvan

Виртуалки это с мускулом? Или мускул на хосте стоит? Если виртуалки с мускулом, то на ноде память в своп уходит?

Deleted ()

Попробуй уменьшить innodb_buffer_pool_size или innodb_log_file_size по мне так у тебя слишком задрано, эти два параметра уже разрешают пухнуть до 30G не считая остальных параметров. БД сколько дай памяти, всё сожрёт

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

Ты такой умный. А ничего, что у него под vfs 24 гига ушло?

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

Виртуалка c мускулем это. В свопе висит только мускуль, остальные апликухи жрут 0.01%

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

Документацию читал по этому параметру. На хосте 32гб рам, теоретически всё должно работать.

Попробовать можно уменьшить, конечно.

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

И зачем вообще нужен этот swap?! Отключайте.

И вообще зачем нужны таблетки от диареи?! Заколотите жопу.

Deleted ()
Ответ на: комментарий от PunkoIvan

ну так ты и смотри swapin и swapout vmstat’ом.

anonymous ()

Посмотри глазами, что за данные в свопе валяются. Например, less’ом открой своп как файл. Может, узнаешь в данных какую-нибудь большую таблицу и это натолкнет на какие-то мысли.

bigbit ★★★★★ ()
Последнее исправление: bigbit (всего исправлений: 1)
Ответ на: комментарий от Tanger
  1. Вы серьёзно считаете, что программа упадёт потому, что подкачка страниц отключена? И если упадёт, то по какой причине?

  2. Зачем использовать устаревшую технологию эмуляции оперативной памяти через жёсткий диск, когда можно просто докупить планку памяти?

mabu ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.