дисковый кэш

насчёт жрёт много памяти.... что система успевает её так же быстро очистить(выжраную), следуя нижеуказанному выводу, я бы так не сказал...

vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 4  1      0 5470216 931384 4594244    0    0   556    16 7872 4495 19  8 71  2
 1  1      0 5445648 931396 4623220    0    0   224     8 6081 3370 18  4 77  1
 3  2      0 5382988 931408 4594652    0    0   432  1304 4649 4461 25  5 69  1
 2  1      0 5542164 891864 4477392    0    0  1084   416 6254 5744 36 11 46  7
 1  1      0 8195720 891872 2183552    0    0   996     0 4269  750  9 15 65 10
 3  1      0 9795004 891900 758016    0    0  1280    32 4534 2343 10 12 67 11
 0  1      0 9826416 891944 729168    0    0  1916     8 3914 1977 13  8 59 19
 0  2      0 9824068 891988 730764    0    0  2200   600 4640 4412 12  4 73 11
 0  1      0 9824924 891996 731760    0    0   724   332 3284 1506  1  2 83 14
 5  1      0 9823296 892008 733816    0    0  1132     0 3238 1224  2  1 86 11
 0  1      0 9828344 892012 735148    0    0  1972    80 4709 2551 14  4 71 11  

Мое предположение было не о "изощренных вредителях", а о осознанных действиях, сделанных при настройке какого-то приложения (может и забытых впоследствии).

Резкое изменение в масштабе секунды. Или это не быстро?

Я думаю, у вас файловая система зачем-то перемонтируется. Сейчас проверил - кеш сбрасывается моментально если сделать umount.

Переименуйте для начала программы mount/umount, нафига они вам такие нужны (только перегружаться не надо пока программа mount недоступна). Может быть что-то подозрительное в dmesg можно найти.

audit может мониторить конкретные syscall и вам нужно понаблюдать за вызовами mount.

сколько всего дисков и как они разбиты?

Весь? :)

Как воспроизвести подобный скачок, подскажите пожалуйста. Что отмонтировать посоветуете - /var? Раздел базы данных?

А главное, как этой порнографии умудриться не заметить? 🍿

netwind, самое подозрительное в dmesg это

[370184.220663] ispmgr[26792]: segfault at 7fbcbe1f5ff8 ip 7fbcbcafea65 sp 7fffe3d8e740 error 4 in libc-2.7.so[7fbcbca89000+14a000]

но папку с манагером я переименовывал, и проверяло что он не запущен, уверен на все 100, что это не ispm

mount разве не в initrd происходит? переименовать пока не могу

дисков два, в mdraid, сейчас один диск выдернули, вырос Reallocated_Sector_Ct за 500 , разбиты стандартно /boot swap / , пока диск ещё работал сервер перезагружал, дабы убрать возможные изменения sysctl и порчее, сбрасывание не прекратилось

потом

явно не соответствует umount/mount

---------- Добавлено в 21:27 ---------- Предыдущее сообщение было в 21:25 ----------

наверное всё таки речь идёт о /proc что в принципе тоже тяжко размонтировать корректно

вот уж не знаю как. по крайней мере, umount точно сбрасывает кеш и очень быстро. речь действительно о /var.

Периодически? Как-то коррелирует со сбросами?

Чудо. Как тебе проще объяснить? - Это совершенно обычная работа ядра с файлами в /proc/. Переживать стоило бы, если б аудит указал там пид пользовательского процесса.

Только не о проц :) Начиная с того, что его так запросто не отмонтируешь ;)

А теперь сделайте мне это периодически и так, чтобы админ не заметил. (условия задачи)

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

раз уж других идей нет и никто точно не трогает файл в /proc, то и эта версия сойдет.

mount -o remout кеш не сбрасывает. по крайней мере у меня.

тоесть что-то быстро делает umount/mount / ? идя конечно..

никак

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

п.с. можно ещё подумать в свете выход одного диска из строя что что-то явно не в порядке с дисковой подсистемой

---------- Добавлено в 21:53 ---------- Предыдущее сообщение было в 21:49 ----------

я приводил кусочек топа мускуль меньше 100% редко ест, судя по его TIME+ а сечас он 3671:05 мускуль явно не перезагружается после "сброса" (новая разновидность бага)

Это я классифицировал бы похлеще чем "вероятность низкая". К примеру: "вероятность - глупая" 🍿

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