Вопрос касательно tmp_table_size. Дано: тяжелый сервер Битрикс24. Процент временных таблиц потребовавших создание

на диске стабильно больше 40% (Created_tmp_disk_tables / (Created_tmp_tables + Created_tmp_disk_tables))
tmp_table_size = max_heap_table_size = 256 МБ

Есть два противоречивых мнения:
1. Увеличивать показатели и надеяться что базе данных хватит оперативы на все.
2. Уменьшать показатели, перенести tmpdir в оперативную память (и если упадет, то упадет только конкретный запрос)


Менять запросы не вариант - почти все они генерируются проприетарным ПО по каким-то внутренним правилам.

Вопрос: какой из двух вариантов выбрать и есть ли третий?

А СУБД какая ?

MySQL 5.7.37-40

что такое тогда "перенести tmpdir в оперативную память " ?

1. Увеличивать показатели /2. Уменьшать показатели, — тоже как бы не ясно

Создать виртуальный диск на linux (tmpfs), примонтировать его в какую-нибудь директорию и изменить конфигурацию MySQL (tmpdir) чтобы он создавал временные таблицы в этой директории (которая де-факто находится не на диске, а в памяти).

с чего она будет в памяти-то ?

Сейчас tmp_table_size = 256МБ, ее можно увеличить до 512 например.

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

В любом случае лучше поставить SSD

Уже - Samsung EVO 960

Ну так и успокойся с памятью тогда, память лучше под кэш БД отдать. innodb buffer pool

Ваше мнение услышал. Большое спасибо. Подожду еще альтернатив (если будут).

Временные таблицы же на SSD у тебя сконфигурены ?

Да. Там все на SSD - и база и временные таблицы и ось

OS бы обошлась...

А третий вариант - индексы создавать надо. Это полезнее всех этих прыжков

А проблема-то сейчас в чём? Ну спиллятся времянки на диск, чуть медленнее запросы работают, но работают. А от манипуляций с tmpfs будешь регулярно получать очень быстрые краши вместо медленных результатов)

Я тоже не понял какой показатель вы хотите там увеличивать или уменьшать

У клиента "тормозит" ПО и он хочет "ускориться". Примерно 40% от скорости занимает время выполнение запросов (запросы не легкие с join'ами и кучей where). Одна из рабочих гипотез - что создание этих временных таблиц дает тормоза. "Специалисты" заказчика тыкают пальцами на этот процент и хотят чтобы его уменьшили (то бишь увеличили параметры), уверяя что это как-то увеличит производительность. Некоторые сисадмины (наши) уверяют что показатель наоборот надо уменьшать и переносить в оперативную память. Я не спец в этом и не считаю что это как-то сделает погоду, но если вдруг у кого-то есть какие-либо аргументы за/против - мне бы хотелось разобраться.

Ну то есть вам нужен нормальный mysql DBA, но нанять его нет денег

Так какой показатель ты хочешь менять?

Если бы была какая-то ежедневная/ежемесячная ситуация - думаю так и поступили бы, но вот такой вот "разовый" прыжок во мнениях произошел. Я бы и сам нырнул куда-нибудь да почитал, вот только в доках про mysql не пишут про трюки с tmpfs.

tmp_table_size И max_heap_table_size - там же написано (вроде как по докам лучше чтобы они были одинаковые).

Ну это можно сделать ЕСЛИ хватает оперативной памяти для самой базы данных, для её кэша

Зависит от того, сколько сессий параллельно работает (может у вас там 200 бухгалтеров разом тяжёлые отчёты грузят) и сколько едят эти запросы (может там спиллы на десяток гигов) Выкручивание tmp_table_size, скорее всего, даст очень ограниченный эффект Перенос на tmpfs - дорогая затея, не самый эффективный способ использования RAM. Ну и риски OOM повышаются резко - понравится ли это клиенту больше, чем тормоза? Лучше просто планок RAM закупить тогда уж. Начинать надо бы с редизайна схем, докручивания индексов, статистики по таблицам, партиционирования, а потом уже за конфигурацию кластера браться

Не надо всякий tmpfs, Если у тебя есть SSD, то это как бы его заменяет

Последний абзац ему недоступен он об этом сразу сказал

Параметр Max Hip Table size тебе трогать не нужно, это не про это, это про максимальный размер таблиц для Engine Memory которые создаются пользователем, то есть явно кодом SQL. Я подозреваю что у тебя-то таких таблиц нет вообще. Но с другой стороны если ты его увеличишь и таких таблиц всё равно нет то ничего страшного тоже не будет

Насколько я понял она играет роль для запросов ALTER TABLE на других таблицах - а такие запросы бывают (но очень редко).

Скорее всего это ты что-то не так понял

Не отрицаю :)