Блин, вот как воевать со свопом?

swappines = 1

swappines = 0 не?

drop_caches по крону, конечно!

Глупый вопрос, а лимит на память случайно не стоит? Ну и есть ещё такой вариант https://dev.mysql.com/doc/refman/5.7/en/server-options.html#option_mysqld_mem...

swappines = 0 не?

Это выключит его совсем. Я же писал, своп нужен.

лимит на память случайно не стоит?

Не-а. Ни в limits, ни в опциях mysql.

swappines = 0.5

Как вы узнали, что данные достаются именно из свопа? Это вообще ненормальная ситуация. Правильно настроенный mysql не должен класть в своп то, что можно подтянуть с базы на диске.

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

Как вы узнали, что данные достаются именно из свопа?

А откуда ещё, если VIRT=25G, RSS=16G а суммарный объём таблиц = 32G? :)

Правильно настроенный mysql не должен класть в своп то, что можно подтянуть с базы на диске

Однако, 25G-16G = 9G у него лежит в свопе. При том, что свободно обычно 1-2G и в кеше/буферах — 9-10G. Он мог бы целиком всё держать в оперативке. Но вместо этого при относительно редких больших запросах начинает шарить по диску.

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

Innodb. И куда уж больше давать, когда VIRT итак 26G :)

Так же, полезно посмотреть на каких запросах происходят тормоза - и пытаться их оптимизировать

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

Это выключит его совсем

Вроде как можно отдельно для cgroups это делать.

Вроде как можно отдельно для cgroups это делать.

И у LXC, и у Docker слишком большой оверхед получается на сетевых соединениях. Поэтому БД (и другие высоко загруженные компоненты) всегда держу на хосте :-/

И у LXC, и у Docker

Дык они для сэндбокса используют нэймспейсы, а не cgroups.

А откуда ещё, если VIRT=25G, RSS=16G а суммарный объём таблиц = 32G? :)

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

Попробуйте запустить top, он там вверху показывает строчку KiB Swap, смотреть сколько used. И так же можно нажать f и включить колонку SWAP.

Innodb. И куда уж больше давать, когда VIRT итак 26G :)

сначала надо понять в чем проблема. Гипотеза была такая: mysql просит больше, чем есть физически, поэтому операционка что-то выбрасывает в своп. В этом случае, дать надо не больше памяти а меньше - чтобы не просила лишнего. Просто я подразумевал - дать больше таблицам одного типа за счет того, что забрать у других. Но, честно говоря, гипотеза маловероятна. Свопить оно начинает только когда памяти не хватает - а у вас 10гиг в кэше/буферах. Разве что, кто-то поджимает память процессу. Но основное подозрение - это не своп.

И сразу чтоб 2 раза на вставать. Если по инструкциям описанным выше, все же окажется, что свопит - есть подозрение, что кто-то зажимает память, которая отведена mysql. В этом случае я прежде всего попробовал бы уже настройками mysql зажать память до этих 16гиг. Должно перестать свопить - и производительность увеличится (т.к. своп это запись+чтение, а без свопа - только чтение). И если так и произойдет, то я бы дал 97% что это кто-то поджимает память для mysql.

Вообще, я тут подумал... имхо, MySQL не должен свопить впринципе никогда.

MySQL занимает 25Гб VIRT. Из них только 16Гб в RSS. При этом 9.6Гб в буферах и кешах + 2Гб свободно. Большие MySQL-запросы по базе безбожно тормозят с уходом в IO по причине доставания данных из свопа.

не очень шарю в терминах, но в своп то сколько памяти мускула ушло? может с ionice пошуровать?

А откуда ещё, если VIRT=25G, RSS=16G а суммарный объём таблиц = 32G? :)

Однако, 25G-16G = 9G у него лежит в свопе.

Так это же не своп. Это «выделено» минус «реально занято», и данная цифра вообще никакой реальной значимости не имеет.

Кстати да, ман overcommit.

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

Ну, там один только innodb_buffer_pool_size = 20G. Так что при занятых 16G RSS, только innodb пул занимает 4Гб в свопе.

Я ещё одно время, увеличивая innodb_buffer_pool_size, отмечал размер RSS:

9G -> 10G RSS
12G -> 13G
15G -> 15G
20G -> 16G

А ещё из крупных величин:

key_buffer      = 2G
myisam_sort_buffer_size     = 500M

имхо, MySQL не должен свопить впринципе никогда.

Ну, пусть не свопит, пусть просто хранит максимально возможную часть БД в оперативке, а не лезет за ней на диск, когда память пустует :)

А zswap не вариант, или мертвому припарки? Оно хотя бы на диск не пишется до упора.

А zswap не вариант, или мертвому припарки?

Зачем zswap, когда обычная оперативка ещё свободная? :)

Так что при занятых 16G RSS, только innodb пул занимает 4Гб в свопе.

Вы поймите, это математика и гипотеза. А я спрашиваю про практику. Выполнить top - и посмотреть вверху в шапке, сколько свопа занято. Если не показывает - жмакнуть m.

Если не ноль, то нажать f, включить колонку SWAP (выделяет пробелом) и жмакнуть по этой же колонке s (типа, по ней хотим сортировать), дальше жмем q и видим, что добавилась эта колонка. Обычно она крайняя слева. И дальше смотрим, какой процесс сколько отсвопил.

Ну, пусть не свопит, пусть просто хранит максимально возможную часть БД в оперативке,

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

КиБ Mem:   2056052 total,  1355088 used,   700964 free,   439316 buffers
КиБ Swap:  2095100 total,   104276 used,  1990824 free.   150204 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND         SWAP   CODE    DATA   USED 
 2486 mysql     20   0 1157140 171160   6540 S   0,4  8,3  13:28.60 mysqld         34188  12512 1138100 205348 

обратите внимание: разница межу VIRT и RES составляет ~985мб, при этом отсвоплено всего 104мб на все процессы, из них сам mysql отсвопил 34мб. Почему он у меня это сделал - я еще буду выяснять(непорядок это), но суть в том, что разница VIRT-RSS - это не SWAP.

Кстати, а у вас там в запросах CREATE TEMPORARY TABLE делается? Имейте в виду, эти таблицы создаются как минимум частично диске. Диск подгружают прилично.

В Debian недавно прилетело вот это: https://packages.debian.org/sid/pagein (http://kernel.ubuntu.com/~cking/pagein/). Судя по описанию, это утилита, которая достаёт данные из свопа обратно в память.

Еще можно sudo smem -tkns swap, но это надо smem ставить и питон, если нет.

И дальше смотрим, какой процесс сколько отсвопил.

mysqld — 6.6G

В принципе, разница между 16RSS + 6.6SWAP = 22.6G не так велика с нынешними 25G VIRT, по которым я оценивал.

В буферах/кеше сейчас 11G, своп занят на 100% (16G).

Кстати, а у вас там в запросах CREATE TEMPORARY TABLE делается?

Нет.

Еще можно sudo smem -tkns swap

  PID User     Command                         Swap      USS      PSS      RSS 
...
30805 106      /usr/sbin/mysqld --basedir=     6.6G    16.1G    16.1G    16.1G 
-------------------------------------------------------------------------------
  609 36                                      15.1G    20.8G    21.2G    23.9G

В Debian недавно прилетело вот это

Что-то мне оно нисколько не помогло :)

./pagein -p 30805
Pages touched:         5183
Free memory decrease:  948K (237 pages)
Swap memory decrease:  -96K (-24 pages)
Page faults major:     5
Page faults minor:     351
Swaps:                 0

1. swappines = 0 не отключает своп, так как вероятность свопинья данных расчитывается как сумма трёх величин, одна из которых (если мне не изменяет память) жестко вшита как константа в ядро.

2. Сколько dirty кеша при этом в моменты затупов? Dirty кеш занимает память пока не сбросится на диск, соответственно оперативка занята. (можно в atop посмотреть размер)

3. В новых ядрах есть интересный параметр watermark_scale_factor. Раньше эта величина рассчитывалась как 25% от min_free_kbytes, что было неудобно, так как приходилось выставлять высокие значения min_free_kbytes.

vfs_cache_pressure

Ладно, mysql 6гиг сбросило в кэш. Можно считать - доказали. Вопрос в том, в какой момент времени это произошло.

У вас какие-нибудь жирные проги кроме самого mysql запускаются? Прога, которая коннектится к базе и шлет запросы - она запущена на этом же компе или на другом? Если есть возможность попробовать запустить ее на другом - можно попробовать. Гипотеза такая: в вашей проге есть запросы, которые вытягивают много данных(именно по обьему, необязательно по кол-ву строк). Многие mysql-коннекторы по умолчанию никаких потоковых передач не делают: весь результат запроса вытягивается на клиента, там раскладывается в структуры данных и потом вы с ними работаете. Если такая прога да еще в несколько потоков запросит что-то - это раздувает объем памяти, занимаемый прогой, оперативы начинает нехватать, идет своп. При этом explain может вполне выдавать вменяемые результаты. Если есть такие запросы, то надо их как-то или резать и обрабатывать по частям, или использовать режим row-by-row.

Вопрос в том, в какой момент времени это произошло.

Оно _всегда_ так происходит :) MySQL очень быстро «отстаивается» в своп после рестарта.

У вас какие-нибудь жирные проги кроме самого mysql запускаются?

Следующие за ним по объёму жрут фиксированно по 500-600Мб (rslsync и sphix searchd) RSS. Дальше — меньше. 370Мб redis, 200Мб ещё один MySQL из LXC-контейнера, 150Мб php-fpm и т.д.

Собственно, вот, видно, что buffers и cache почти всегда на одном уровне: http://gateway.ipfs.io/ipfs/QmXj7mrUXxgsdaRAayLnMDBVFRbyf85n1edN9rTy2VxenS/fi...

Гипотеза такая: в вашей проге есть запросы, которые вытягивают много данных(именно по обьему, необязательно по кол-ву строк).

Нет, все запросы выдёргивают короткие результаты. Это чистый Web.

Ладно, тогда такое соображение. Надо понять почему оно свопит. Причин может быть 2: 1. mysql думает, что у него в распоряжении больше памяти, чем вы думаете. 2. запускается какая-то внешняя прога, а линукс вместо того, чтобы дропать буфера - отправляет какие-то страницы памяти в своп.

Собственно, в зависимости от этого, и искать надо в разных местах. Если это mysql - то как ни подкручивай ОС, а свопится все равно будет, потому что процесс запрашивает больше, чем есть. И никакие swapiness не помогут в этом случае. И похоже, что у вас случай 1, потому что VSS.

это выяcнить легко: sudo pmap <pid>

И когда виновник подтвержден, то мы идем читать документацию mysql на всякие ключики. Разумеется, попутно сбросив сюда вывод команд: select version(); show engines; — это больше для верности, что кто-то что-то увидит. Вряд ли они мне помогут. Видимо там что-то недоподкручено у вас. Если навскидку не находится, то просто делаем show variables - и читаем про каждый ключик и смотрим чему он у нас равен. Еще можно взять вывод mysql который не свопит - и сравнить с вашим. В идеале если б найти mysql который настроен на 32 гига - это могло бы существенно облегчить задачу.

А откуда ещё, если VIRT=25G, RSS=16G ... Однако, 25G-16G = 9G у него лежит в свопе ...

swappines = 0 не?

Это выключит его совсем. Я же писал, своп нужен.

Какоето у вас неправильное представление о организации виртуального адресного пространства в ОС линукс

Отключить временно swap, посмотреть на результат. Правильно уже заметили - для БД своп не должен использоваться. В идеале вся база должна быть в памяти. Также покажи вывод из mysql:

show status like '%pool%';
show status like '%cache%';

Отключить временно swap

Невозможно, т.к. оперативки меньше, чем занятой памяти.

Также покажи вывод из mysql

MariaDB [(none)]> show status like '%pool%';
+-----------------------------------------+--------------------------------------------------+
| Variable_name                           | Value                                            |
+-----------------------------------------+--------------------------------------------------+
| Innodb_buffer_pool_bytes_data           | 17123049472                                      |
| Innodb_buffer_pool_bytes_dirty          | 1114112                                          |
| Innodb_buffer_pool_dump_status          | not started                                      |
| Innodb_buffer_pool_load_status          | Buffer pool(s) load completed at 170301  5:55:45 |
| Innodb_buffer_pool_pages_data           | 1045108                                          |
| Innodb_buffer_pool_pages_dirty          | 68                                               |
| Innodb_buffer_pool_pages_flushed        | 12869004                                         |
| Innodb_buffer_pool_pages_free           | 232659                                           |
| Innodb_buffer_pool_pages_lru_flushed    | 0                                                |
| Innodb_buffer_pool_pages_made_not_young | 7036604                                          |
| Innodb_buffer_pool_pages_made_young     | 8674785                                          |
| Innodb_buffer_pool_pages_misc           | 32945                                            |
| Innodb_buffer_pool_pages_old            | 385628                                           |
| Innodb_buffer_pool_pages_total          | 1310712                                          |
| Innodb_buffer_pool_read_ahead           | 77405                                            |
| Innodb_buffer_pool_read_ahead_evicted   | 0                                                |
| Innodb_buffer_pool_read_ahead_rnd       | 0                                                |
| Innodb_buffer_pool_read_requests        | 141623065634                                     |
| Innodb_buffer_pool_reads                | 734881                                           |
| Innodb_buffer_pool_wait_free            | 0                                                |
| Innodb_buffer_pool_write_requests       | 264022568                                        |
| Threadpool_idle_threads                 | 0                                                |
| Threadpool_threads                      | 0                                                |
+-----------------------------------------+--------------------------------------------------+
23 rows in set (0.17 sec)

MariaDB [(none)]> show status like '%cache%';
+-----------------------------------+------------+
| Variable_name                     | Value      |
+-----------------------------------+------------+
| Aria_pagecache_blocks_not_flushed | 0          |
| Aria_pagecache_blocks_unused      | 15736      |
| Aria_pagecache_blocks_used        | 14219      |
| Aria_pagecache_read_requests      | 5306622651 |
| Aria_pagecache_reads              | 1782364    |
| Aria_pagecache_write_requests     | 166766263  |
| Aria_pagecache_writes             | 28361990   |
| Binlog_cache_disk_use             | 0          |
| Binlog_cache_use                  | 0          |
| Binlog_stmt_cache_disk_use        | 0          |
| Binlog_stmt_cache_use             | 0          |
| Com_assign_to_keycache            | 0          |
| Qcache_free_blocks                | 27938      |
| Qcache_free_memory                | 145091480  |
| Qcache_hits                       | 123226852  |
| Qcache_inserts                    | 47171191   |
| Qcache_lowmem_prunes              | 6783002    |
| Qcache_not_cached                 | 5232630    |
| Qcache_queries_in_cache           | 48426      |
| Qcache_total_blocks               | 127008     |
| Ssl_callback_cache_hits           | 0          |
| Ssl_session_cache_hits            | 0          |
| Ssl_session_cache_misses          | 0          |
| Ssl_session_cache_mode            | NONE       |
| Ssl_session_cache_overflows       | 0          |
| Ssl_session_cache_size            | 0          |
| Ssl_session_cache_timeouts        | 0          |
| Ssl_used_session_cache_entries    | 0          |
| Subquery_cache_hit                | 0          |
| Subquery_cache_miss               | 20465      |
| Threads_cached                    | 30         |
+-----------------------------------+------------+
31 rows in set (0.00 sec)

Это выключит его совсем. Я же писал, своп нужен.

Какоето у вас неправильное представление о организации виртуального адресного пространства в ОС линукс

Ну, х.з. Много раз читал именно такое представление. Собственно, даже вот это смущает: «vm.swappiness = 1: Kernel version 3.5 and over, as well as Red Hat kernel version 2.6.32-303 and over: Minimum amount of swapping without disabling it entirely».

Хотя про 0, действительно, сказано: «The kernel will swap only to avoid an out of memory condition».

Но второе противоречит первому, получается.

это выяcнить легко: sudo pmap <pid>

Мне этот выхлоп ни о чём не говорит :-/

как ни подкручивай ОС, а свопится все равно будет, потому что процесс запрашивает больше, чем есть

В кеше и буферах _всегда_ свободно 9-11Гб. Всегда.

то мы идем читать документацию mysql на всякие ключики

Уж кручено всё перекручено :) Да и нет там таких ключиков, которые бы mysql в своп загоняли.

select version(); show engines;

MariaDB [(none)]>  select version(); show engines;
+----------------------------------+
| version()                        |
+----------------------------------+
| 10.0.29-MariaDB-0ubuntu0.16.04.1 |
+----------------------------------+
1 row in set (0.02 sec)

+--------------------+---------+----------------------------------------------------------------------------+--------------+------+------------+
| Engine             | Support | Comment                                                                    | Transactions | XA   | Savepoints |
+--------------------+---------+----------------------------------------------------------------------------+--------------+------+------------+
| MEMORY             | YES     | Hash based, stored in memory, useful for temporary tables                  | NO           | NO   | NO         |
| MRG_MyISAM         | YES     | Collection of identical MyISAM tables                                      | NO           | NO   | NO         |
| CSV                | YES     | CSV storage engine                                                         | NO           | NO   | NO         |
| BLACKHOLE          | YES     | /dev/null storage engine (anything you write to it disappears)             | NO           | NO   | NO         |
| MyISAM             | YES     | MyISAM storage engine                                                      | NO           | NO   | NO         |
| FEDERATED          | YES     | FederatedX pluggable storage engine                                        | YES          | NO   | YES        |
| ARCHIVE            | YES     | Archive storage engine                                                     | NO           | NO   | NO         |
| PERFORMANCE_SCHEMA | YES     | Performance Schema                                                         | NO           | NO   | NO         |
| InnoDB             | DEFAULT | Percona-XtraDB, Supports transactions, row-level locking, and foreign keys | YES          | YES  | YES        |
| Aria               | YES     | Crash-safe tables with MyISAM heritage                                     | NO           | NO   | NO         |
+--------------------+---------+----------------------------------------------------------------------------+--------------+------+------------+
10 rows in set (0.01 sec)

делаем show variables - и читаем про каждый ключик и смотрим чему он у нас равен

Читано и перечитано многократно...

swappiness - отвечает за агресивность КЕШИРОВАНИЯ страниц в свопе. Тоесть вот есть у меня 8G RAM и 8G SWAP, и например всякий пользовательский софт занял 6G памяти. OS может скопировать некоторые страници из RAM в своп (именно не вигрузить а скопировать, и страница останится в RAM а ее точная копия будет в SWAP).

Плюс данного кеша заключается в том что если вдруг я запущу некий софт который запросит еще 6G SWAP системе предется побыстрому выгрузить 4G из RAM в SWAP, а это довольно меделенно, но если у системы уже есть прикешированые 4G в свопе то выгружать ничего не нужно, можно просто освободить закешированые страницы.

Минусом данного подхода является то что если софт меняет данные в закешированых страницах системе приходится обновлять их в свопе и машина начинает свопится даже если RAM достаточно (похоже на ваш случай).

Так вот если установить swappiness=1 система будет пытатся кешировать страници в свопе по максимуму, а если swappiness=0 то кеширование нету вообще (своп используется только тогда когда физически заканчивается RAM)

И параметры VIRT и RSS никак вообще не связаны со свопом, VIRT может быть намного больше чем RSS где вообще нет свопа (физически), или даже ядро собрано без потдержки SWAP

И да советую убедится что именно нагружает винт SWAP илиже сам MySQL/MirinaDB - можно просто в процессе нагрузки запустить atop и/или iostat и посмотреть на какой раздел (и в каком направлении) идет ввод/вывод, на том где таблички лежат, временные файлы или SWAP.

а если swappiness=0 то кеширование нету вообще (своп используется только тогда когда физически заканчивается RAM)

- Записал 0.
- Перезапустил выжравший кучу свопа rslsync.
- В свопе свободно 3.7G.
- В кеше/буферах, как обычно, 10+G.
- mysqld в свое занимает 6.0G.
- Прошло полчаса и mysqld в свопе занимает уже 6.2G.

Так что что-то не вяжется :) Памяти свободной достаточно, но mysqld продолжает занимать своп.

И да советую убедится что именно нагружает винт SWAP илиже сам MySQL/MirinaDB

Это другой вопрос. Сейчас в любом случае стоит задача не дать mysqld сползать в своп.

можно просто в процессе нагрузки запустить atop

И SWP, и PAG при таких запросах «красненькие».

SWP | tot    16.0G | free    3.6G  |              |              |              |               |              |              |  vmcom  43.6G | vmlim  31.6G |
PAG | scan    7692 |               | stall      0 |              |              |               |              | swin     403 |               | swout    392 |

Вам надо навести порядок с кешами mysql, так ли надо столько памяти ему ? Можно принудительно память разбросать через именованные кеши http://sqlinfo.ru/articles/info/3.html

так ли надо столько памяти ему ?

Периодически возникают задачи полного сканирования таблиц. Например, по '%smthng%'. Пока таблицы целиком в памяти, это не отражается на работе системы в целом, даже если запрос и медленный. Когда таблица оказывается в свопе, то при обходе таких данных весь сервер начинает затыкаться.

inner join на больших и разнородных данных со сложной сортировкой тоже требует большого обшаривания таблиц.

- Записал 0.
- Перезапустил выжравший кучу свопа rslsync.
- В свопе свободно 3.7G.
- В кеше/буферах, как обычно, 10+G.
- mysqld в свое занимает 6.0G.
- Прошло полчаса и mysqld в свопе занимает уже 6.2G.

Во первых если страницы уже выгрузились в своп то изменения swappiness тут уже не поможет, по хорошему swappiness нужно настраивать до запуска mysql.

Во вторых откуда вы знаете сколько страниц mysql находится в свапе ? Повторю в сотый раз - из значений VIRT и RSS никак нельзя узнать сколько страниц засвоплено, самый простой / надежный способ это «cat /proc/<pid>/status» и там смотреть «VmSwap»

Иногда причиной активного IO свопа является не нехватка памяти а большой IO на tmpfs, например раньше MySQL для сложных селектов часто создавал временные файлы в которые закидовал промежуточные результаты для повторного прохода. Также у вас может быть банально сильно занят какойто tmpfs (/tmp) как следствие потеря доступной RAM/SWAP для приложений.

Иногда система может принять решение что лутчше выгрузить чтото в кеш и отдать больше места буферам ввода/вывода.

перейти на Postgre уже советовали?

Судя по выхлопу 'show status' хватает всего. Из своего опыта администрирования больших БД MySQL (более 200ГБ памяти под Innodb буфер) могу лишь отметить что все серверы (кроме mysqld ничего больше не крутилось, ну может только mysql-proxy еще) были без свопа. Тормоза начинались только когда заканчивался буфер выделенной памяти (в show status - Innodb_buffer_pool_pages_free становился в «0»). Также могу отметить что везде использовался сбока MySQL с mysql.com, на таких больших базах нигде не ставил MariaDB, так что если есть возможность попробуй сборку с mysql.com, а не MariaDB, понимаю что оно взаимозаменяемо, но всё же. Также возможно стоит создать индексы если этого не сделано - производительность вырастает, но это к теме разговора про своп значения имеет мало.

Иногда причиной активного IO свопа является не нехватка памяти а большой IO на tmpfs, например раньше MySQL для сложных селектов часто создавал временные файлы в которые закидовал промежуточные результаты для повторного прохода. Также у вас может быть банально сильно занят какойто tmpfs (/tmp) как следствие потеря доступной RAM/SWAP для приложений.

Кстати да, при определенных селектах mysql создает временный файл, который по умолчанию создается на время запроса в /tmp, по окончании запроса удаляется. Сейчас модно монтировать /tmp в tmpfs, то есть в память, по этому временный файл отъедает часть памяти.

Во первых если страницы уже выгрузились в своп то изменения swappiness тут уже не поможет

Ага. Вот только если к ним уже были обращения, потом что, снова будут с своп выгружаться? :)

Во вторых откуда вы знаете сколько страниц mysql находится в свапе ?

Блин, вот как воевать со свопом? (комментарий)

Блин, вот как воевать со свопом? (комментарий)

Иногда причиной активного IO свопа является не нехватка памяти а большой IO на tmpfs

/tmp в ram и маленький

Также у вас может быть банально сильно занят какойто tmpfs (/tmp)

used 66M

Анонимус дело говорит

Арифметика очень наивная, своп не так считают, т.к. virt совсем другое

Приложение запросило у ОСи 25 Гб памяти. ОСь говорит - «да не вопрос». И приложение получает в своём виртуальном пространстве в heap ещё 25 ГБ памяти как allocated. При этом физическая память не выделяется. Мало ли что приложение хочет.

Дальше начинается работа механизма виртуальной памяти. Если приложение обратится к странице, которая уже allocated, но которая не примаплена к физической памяти, возникает page fault ( это гораздо «дешевле», чем выдавать сразу всё или чем проверять вручную, т.к. проверка маппинга и генерация page fault переложены на аппаратный контроллер памяти )

Соответственно, page fault бывает двух видов - major и minor

minor page fault - эта страница вообще никуда не примаплена. Соответственно, ОСь при обработке minor page fault просто выделяет физическую страницу памяти и мапит на виртуальную. Дешево

major page fault - возникает, если страница уже примаплена, но не к RAM. Например, к свопу или к блоку ФС. Вот тут уже приходится дёргать данные с диска. Дорого.

Т.е. считать своп как virt - rss категорически некорректно. В virt ещё входят страницы, которые процесс уже запросил у ОСи ( alloc ), но к которым ещё не обращался

Советую посмотреть systat, он собирает много полезных данных. В т.ч. о page fault

Отключить временно swap

возможно, т.к. оперативки меньше, чем занятой памяти.

«Семён Семёныч!». Сам же всё понимаешь. Своппинг происходит потому, что памяти не хватает. Не нужно кивать на размер кэша и прочее. Памяти не хватает, механизм своппинга решил, что выгрузить нужно именно страницы mysql