Этот сервер меняет местами на 100% (диск подкачки 15 ГБ), в то время как у него еще есть 30 ГБ свободного места, я искал, но не могу понять, почему это происходит, я понял, что не использовать подкачку, если память все еще доступна.
# cat /proc/meminfo MemTotal: 131937984 kB MemFree: 29649644 kB Buffers: 347424 kB Cached: 55013896 kB SwapCached: 2180808 kB Active: 42065900 kB Inactive: 15782332 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 131937984 kB LowFree: 29649644 kB SwapTotal: 16779884 kB SwapFree: 2165300 kB Dirty: 1908 kB Writeback: 0 kB AnonPages: 323104 kB Mapped: 31100628 kB Slab: 408604 kB PageTables: 1737344 kB NFS_Unstable: 0 kB Bounce: 0 kB CommitLimit: 61777356 kB Committed_AS: 52238240 kB VmallocTotal: 34359738367 kB VmallocUsed: 382524 kB VmallocChunk: 34359355491 kB HugePages_Total: 20480 HugePages_Free: 20480 HugePages_Rsvd: 0 Hugepagesize: 2048 kB # top top - 14:33:16 up 27 days, 21:25, 7 users, load average: 3.47, 4.39, 4.34 Tasks: 669 total, 2 running, 661 sleeping, 0 stopped, 6 zombie Cpu(s): 7.6%us, 1.5%sy, 0.0%ni, 90.2%id, 0.6%wa, 0.0%hi, 0.1%si, 0.0%st Mem: 131937984k total, 101503048k used, 30434936k free, 347544k buffers Swap: 16779884k total, 14608832k used, 2171052k free, 54216540k cached # vmstat 1 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 14608504 30438520 347560 54216984 1 1 503 262 0 0 8 2 90 1 0 3 0 14608504 30439016 347560 54217024 0 0 88 403 1434 4884 0 0 99 0 0 2 0 14608468 30439760 347560 54217060 0 0 10 588 2381 5297 7 1 93 0 0 0 0 14608468 30439884 347560 54217060 0 0 0 76 1429 4768 5 0 94 0 0 1 0 14608448 30440180 347560 54217048 32 0 66 230 3371 4872 4 1 95 0 0 6 0 14608420 30440668 347560 54217076 32 0 42 320 2439 4860 6 1 93 0 0 3 0 14608412 30441384 347560 54217116 0 0 58 520 2128 4899 6 1 93 0 0 4 0 14608412 30441504 347560 54217116 0 0 0 58 1355 4477 11 1 88 0 0 3 0 14608392 30441844 347560 54217012 128 0 158 16 1491 4374 13 1 86 0 0 5 1 14608352 30441512 347560 54216924 160 0 296 640 2748 5279 15 2 83 0 0 4 0 14608324 30442132 347564 54217112 32 0 90 502 2493 4878 13 1 86 0 0 8 0 14608296 30437288 347568 54217204 0 0 8 724 2243 5185 12 1 86 0 0 # cat /proc/sys/vm/swappiness 60 bash-3.2# grep ^[a-z] /etc/sysctl.conf net.ipv4.ip_forward = 0 net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.default.accept_source_route = 0 kernel.sysrq = 0 kernel.core_uses_pid = 1 net.ipv4.tcp_syncookies = 1 kernel.msgmnb = 65536 kernel.msgmax = 65536 kernel.shmmax = 68719476736 kernel.shmall = 4294967296 net.ipv4.icmp_echo_ignore_broadcasts = 1 net.ipv4.icmp_ignore_bogus_error_responses = 1 net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.default.send_redirects = 0 net.ipv4.conf.all.log_martians = 0 net.ipv4.conf.default.log_martians = 0 kernel.panic_on_oops = 1 kernel.panic = 5 fs.aio-max-nr = 399360 kernel.exec-shield = 0 kernel.randomize_va_space = 0 vm.nr_hugepages = 20480 net.ipv4.tcp_keepalive_time 300
Возможным вариантом может быть изменение подкачки с 60 на меньшее число.
У меня есть сервер Sybase с CentOS 5, который не вызывает подкачки. Хитрость заключается в том, чтобы установить для swappiness значение 0 и оставить достаточно памяти для ОС. На сервере 16 ГБ (10 ГБ для Sybase и 6 ГБ для ОС и других сервисов). Начните с меньшего размера кэша Sybase и постепенно увеличивайте его.
[root@db2 ~]# tail -2 /etc/sysctl.conf
# Set Swappiness
vm.swappiness = 0
У друга была точно такая же проблема. Я предполагаю, что у вас многоядерная система. В этом случае Linux делит общую физическую оперативную память на процессор (т. Е. Если у вас 4 ядра и 16 ГБ оперативной памяти, он резервирует 4 ГБ на ядро). Когда вся доступная оперативная память израсходована для конкретного процессора, он переходит к использованию пространства подкачки вместо того, чтобы забирать свободную оперативную память у других процессоров.
Позвольте мне связаться с ним, чтобы узнать, какое именно решение он получил, может быть, этот ответ пока укажет правильное направление.
Вы, вероятно, используете программное обеспечение, которое поддерживает большие кеши в памяти процесса. Такие страницы будут выгружены при запуске другой задачи, требующей большого количества памяти. Память не будет переключаться обратно до тех пор, пока это не потребуется, поэтому, когда другая задача, требующая большого количества памяти, будет выполнена, будет много свободной памяти, которая не будет заполнена до тех пор, пока это необходимо.
Если у вас есть единственный процесс, который выделил огромный объем памяти в системе NUMA, возможно, он позволяет ему иметь память, принадлежащую только одному узлу NUMA или чему-то еще.
Прочтите это:
http://jcole.us/blog/archives/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/
Суть в том, что если вы можете использовать всю память, это может быть лучше.
Однако указание вашей базе данных использовать 32 ГБ из 32 ГБ кажется оптимистичным, поскольку это приведет к значительным накладным расходам. В частности, на x86_64 таблицы страниц будут занимать много места (возможно, 0,5 Гб?), А другим частям системы потребуется некоторое пространство. Я думаю, что около 75% было бы лучше.