Здравствуйте.

Есть около 10 серверов, на части установлена CloudLinux 6 (это OS на базе CentOS 6), на части CentOS 6. Столкнулся с проблемой выделения и освобождения памяти.

Изначально заметил, что серверы MySQL (стоят версии MariaDB 10.2.17 и Percona 5.6.39 в зависимости от сервера) потребляют больше памяти, чем им выделено. Например, mysqltuner.pl может иметь следующий вывод (это тестовый сервер, буферы установлены на минимум):

-------- Storage Engine Statistics --------------------------------------- --------------------------
[-] Data in MyISAM tables: 284.6M (Tables: 8400)
[-] Data in InnoDB tables: 2.1G (Tables: 9416)
[-] Data in MEMORY tables: 0B (Tables: 62)
-------- Performance Metrics ---------------------------------------- -------------------------------
[-] Up for: 2m 34s (7K q [47.175 qps], 696 conn, TX: 23M, RX: 18M)
[-] Physical Memory: 7.7G
[-] Max MySQL memory: 562.8M
[-] Other process memory: 2.2G
[-] Total buffers: 184.0M global + 2.9M per thread (100 max threads)

А сервер базы данных может при этом съесть 2 гигабайта (именно RES, не VIRT памяти) спустя пару дней работы (либо можно просто запустить mysqltuner.pl несколько раз и обычно потребление уже выше заданного лимита). flush tables, caches не освобождают память.

Есть два решения данной проблемы - это установка MALLOC_ARENA_MAX в значение от 1 до 4 (изначально данное значение для сервера с 8 ядрами имеет значение 64), в данной ситуации MySQL начинает потреблять память корректно. Также можно ставить malloc_check_=3 (тоже помогает, данная переменная переводит glibc в старый режим работы с потоками). В системах стоит glibc 2.12.2 версии, зачем-то RHEL собирают его с параметром --enable-experimental-malloc, который и создает данные проблемы (изменение malloc_check_ как раз отключает данный режим). Второе решение, использование jemalloc (прописывается malloc-lib файла my.cnf).

В сети находил подобные проблемы, но часто там описывается неконтролируемый рост VIRT памяти на glibc 2.12, но никак не RES. Единственная похожая запись проблемы есть здесь https://jira.mariadb.org/browse/MDEV-15344, а также находил на сайте bugs.mysql.com, но ссылку не сохранил. Если смотреть pmap -x, то видно много выделенных anon блоков по 10 и 64 мб. Интересный момент еще в том, что при запуске сервера через утилиту valgrind --leak-check=full --leak-resolution=med потребление памяти нормальное.

Данная проблема не только с сервером базы данных, интересный момент есть и с веб сервером nginx. При запуске он потребляет 1.4 гигабайта (RES) памяти, если выполнить мягкую перезагрузку (graceful), то после «перерождения» процессов новые начинают потреблять 3 гигабайта (RES) памяти.

Для диагностики я установил два новых сервера с идентичным объемом ресурсов и операционными системами, скопировал серверы базы данных и веб сервера, проблему воспроизвести не удалось. Я стал сравнивать все параметры sysctl, ядра, различий не было. Сделал проверку файлов всех пакетов через rpm-Va, а после и вовсе сделал yum reinstall * (что переустановило все пакеты), но проблема не исчезла на тестовом сервере и не появилась на двух специально установленных серверах. Пробовал отказывать и обновлять glibc, результата также нет.

Что это может быть, куда копать? Почему одно и тоже программное обеспечение ведет себя по разному?

Здравствуйте.

Есть 4 сервера с операционной системой CentOS 7, на всех серверах стоит по 2 HDD диска и по 2 SSD накопителя. Создано 2 программных RAID-1 массива (один на HDD, другой на SSD).

Из указанных дисков HDD создано хранилище на базе LVM с кешированием на SSD дисках в режиме writeback.

После обновления пакетов lvm до версии 2.02.171-8 (последняя доступная версия в официальном репозитории), чтение с SSD дисков возросло в 2-3 раза и одновременно с этим возросла запись на HDD диски (пропорционально чтению с SSD дисков).

Хранилище используется под виртуальные машины на базе QEMU-KVM, нагрузка с их стороны не менялась. Одновременно с обновлением пакетов lvm производилось обновление всей системы (то есть ядро, qemu также были обновлены).

Ради эксперимента, на одном из серверов с низкой нагрузкой я переключил режим кеширования с writeback на writethrough, чтение с SSD и запись на HDD сразу снизились.

По ссылке https://yadi.sk/d/0a7fULcv3SrmrM можете посмотреть графики записи и чтения с дисков. На сервере 1 виден скачок чтения и записи после обновления и перезагрузки системы, на сервере 2 видно резкое снижение чтения и записи после переключения кеширования в режим writethrough.

Я пробовал искать подобные проблемы в сети, но ничего найти не смог. Также изучал https://bugzilla.redhat.com/buglist.cgi?quicksearch=lvm2 и https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=lvm2;dist=unstable , ничего похожего не нашел.

Откатился с ядра 3.10.0-693.21.1.el7.x86_64 обратно на 3.10.0-514.26.2.el7.x86_64, проблема осталась. Пробовал поставить 4.4.120-1.el7.elrepo.x86_64, проблема также сохраняется. Откатил LVM вместе с зависимостями от 2.02.171-8 к 2.02.166-1, проблема также сохранилась.

Что это может быть? Ошибка статистики или же система действительно по каким-то причинам пишет больше, чем должна? Куда копать в данном случае?