Можно ли выносить временную папку mysql на ramdisk в памяти

Обновлено: 09.01.2025

На днях писал заметку про мониторинг SSD дисков в связи с повышенным расходом ресурса записи. Решил повнимательнее посмотреть на сервер, чтобы понять, кто там так много пишет. Оказалось, что это PostgreSQL и конкретно временные данные статистки, живущие в директории pg_stat_tmp.

Хочешь научиться автоматически разворачивать и поддерживать высоконагруженные проекты? Тогда рекомендую познакомиться с онлайн курсом " Infrastructure as a code." в OTUS. Актуально для системных администраторов и devops инженеров. Подробности по .

Выдержка из документации по поводу этого параметра:

Задаёт каталог, в котором будут храниться временные данные статистики. Этот путь может быть абсолютным или задаваться относительно каталога данных. Значение по умолчанию — pg_stat_tmp. Если разместить целевой каталог в файловой системе в ОЗУ, это снизит нагрузку на физическое дисковое хранилище и может увеличить быстродействие. Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера.

В документации указано, что эту директорию можно вынести в ram диск, что я и сделал в итоге. По дефолту она занимает всего 25 мегабайт, так что я решил с запасом сделать диск размером 1G.

Теперь добавляем в fstab (не забудьте в конце переход на новую строку поставить):

Монтируем диск в систему:

Меняем параметр в postgresql.conf:

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

Как можно было догадаться из названия сервиса postgresql, настраивалось все это для сервера 1С. Так что если вам предстоит переезд на postgresql, заметку сохраните. Наверняка пригодится.

Если есть вопросы по поводу переезда или подбора сервера под 1С, задавайте. Статья может получится на эту тему, а может и нет. Не знаю, как со временем будет. Там должны быть бэкапы, запасной сервер для разворачивания и тестирования бэкапов баз, автоматическая выгрузка баз в dt, мониторинг. В общем все, что надо для промышленной эксплуатации.

Курс предназначен для организаций, предоставляющих услуги хостинга и желающих получить компетенцию Рекомендуемый хостинг.

В курсе рассматриваются требования платформы Bitrix Framework к хостингу, вопросы установки, настройки продукта а также вопросы инструментов и методов оптимизации серверов и баз данных для работы с системой

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

Рекомендуется ознакомиться с опытом настройки и тестирования серверов в блогах Александра Демидова и Дениса Шаромова, а так же с отзывами клиентов о хостингах в группе Черный и белый список хостингов социальной сети компании "1С-Битрикс".

Если ваш хостинг на Windows, то вам может быть полезна группа 1С-Битрикс на платформе Windows Server 2008 в социальной сети сайта "1С-Битрикс". В ней пользователи делятся опытом работы системы на IIS 7.

После изучения курса вам будет предложено пройти тесты на сертификацию. При успешной сдаче линейки тестов на странице Моё обучение можно просмотреть результат обучения и загрузить сертификат в формате PDF.

У нас часто спрашивают, сколько нужно заплатить

Курс полностью бесплатен. Изучение курса, прохождение итоговых тестов и получение сертификатов - ничего из этого оплачивать не нужно.

Ещё у нас есть Академия 1С-Битрикс, где можно обучиться на платной основе на курсах нашей компании либо наших партнёров.

Баллы опыта

В конце каждого урока есть кнопка Прочитано! . При клике на неё в Вашу итоговую таблицу опыта добавляется то количество баллов, которое указано в прочитанном После нажатия кнопки Прочитано! появится
окно подтверждения:

уроке.

Периодически мы заново оцениваем сложность уроков, увеличивая/уменьшая число баллов, поэтому итоговое количество набранных Вами баллов может отличаться от максимально возможного. Не переживайте! Отличный результат - это если общее число набранных Вами баллов отличается от максимального на 1-2%.

iPhone:
FBReader
CoolReader
iBook
Bookmate

Windows:
Calibre
FBReader
Icecream Ebook Reader
Плагины для браузеров:
EpuBReader – для Firefox
Readium – для Google Chrome

iOS
Marvin for iOS
ShortBook
обновляются периодически, поэтому возможно некоторое отставание их от онлайновой версии курса. Версия файла от 28.04.2021.

В работе периодически сталкиваюсь с медленными Drupal сайтами, и тормоза очень часто вызваны медленным выполнением запросов к Mysql. Причины бывают разные, но зачастую медленное выполнение запросов вызвано тем, что при выполнении запроса MySQL вынуждено использовать временные таблицы на диске. Для этого используется каталог заданный в переменной tmpdir файла конфигурации my.cnf.
На мой взгляд, правильным решением в таких ситуациях является оптимизация базы данных (использование типов полей наиболее подходящих под содержимое, правильная настройка идексов, и построение корректных запросов к базе, учитывающих индексы в базе). Но также мы можем помочь MySQL если переместим эти временные таблицы в оперативную память (такое решение подходит для серверов с большим количеством оперативной памяти), что позволит более быстро выполнять операции связанные с использованием временных таблиц, за счет экономии на операциях записи и чтения с диска, так как всё будет делаться в оперативной памяти.
Для переноса папки tmpdir в оперативную память мы подключим к папке /var/lib/mysql/tmp раздел tmpfs размером 4 Gb выполнив следующие шаги:

Создаем папку для хранения временных файлов, например: /var/lib/mysql/tmp
Изменяем владельца папки и группу на mysql
Выясняем идентификатор пользователя (uid) и группы (gid) mysql
В файл fstab добавляем запись
Монтируем новый tmpfs раздел
Редактируем файл конфигурации MySQL /etc/mysql/my.cnf
Перезапускаем MySQL

пн, 12/03/2012 - 09:11

Никогда не думал, что это настолько просто. Спасибо, Роман, за полезную статью.

пн, 12/03/2012 - 09:13

Рад, что оказалось полезно. Если честно я сам немного не ожидал. Хотел по-другому делать.

Роман (не проверено)

ср, 07/17/2013 - 06:53

6. Редактируем файл конфигурации MySQL /etc/mysql/my.cnf
tmpdir=/var/lib/mysqltmp опечатка? tmpdir=/var/lib/mysql/tmp

пт, 07/19/2013 - 06:38

Ответ на 6. Редактируем файл от Роман (не проверено)

Да, опечатался. спасибо, исправил

Serge (не проверено)

пт, 05/29/2015 - 14:24

Спасибо за удачный хинт, но есть сомнения.
Попробовал эту идею на CentOS 7.1 с Percona MySQL 5.5, использовал /mysqltmp вместо /var/lib/mysql/tmp как в Вашем примере
Запустил РНР скрипт обработки данных с массовым инсертом в MySQL
Одновременно смотрю по команде
df -h
tmpfs 4.0G 0 4.0G 0% /mysqltmp
То есть не попадает ничего в раздел. а по всей логике - должно ?
Буду признателен за комментарий и мнение.

пт, 05/29/2015 - 14:29

Ответ на Спасибо за удачный хинт, но от Serge (не проверено)

Мне кажется, что корректней было бы сделать массовый select, сомневаюсь что для insert mysql будет использовать tmp.

Serge (не проверено)

пт, 05/29/2015 - 18:11

Возможно Вы правы и для insert это не влияет. просто для меня оптимизация именно массового insert была приоритетом.
Но нет у меня массового select :) чтобы проверить.
Однако несколько Joomla сайтов будут на это завязаны - а там по практике будет частый select.
Обязательно отпишу как увижу на продакшене.
Спасибо за коммент !

Аким (не проверено)

чт, 09/17/2015 - 13:58

Спасибо.
Перенос mysql директории tmpdir в оперативную память позволяет решить проблему с kjournald, когда журналирование файловой системы вешает эту же саму файловую систему.
Как выяснилось, высокую нагрузку на kjournald порождает как раз mysql большим количеством чтений и записи в директорию tmpdir

Дмитрий (не проверено)

вт, 10/11/2016 - 08:14

А подскажите почему сразу же после создания эти файлы удаляются, можно ли как то это отключить?

Андрей (не проверено)

чт, 02/16/2017 - 08:54

а как можно закешировать больше памяти? у меня кешируется только 4 килобит

сб, 02/25/2017 - 11:52

Ответ на а как можно закешировать… от Андрей (не проверено)

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

Paula (не проверено)

ср, 05/31/2017 - 16:44

Здравствуйте,
чуть выше Serge уже поднимал этот вопрос, но все-таки - как убедиться в том, что все работает как положено?
df -h показывает, что место в смонтированном разделе не используется (занято 0), в свою очередь,
mysqltuner показывает, что временные таблицы создаются.

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

Зачем использовать оперативную память

RAM (оперативное запоминающее устройство) намного быстрее для чтения и записи, чем для других типов хранилищ на компьютере, таких как жесткий диск / ssd, где MySQL по умолчанию хранит базу данных. Перемещение базы данных в оперативную память может значительно увеличить скорость ввода и вывода операций с базой данных.

Недостатки работы с MySQL используя RAM-диск

Перенос баз данных в оперативную память

Теперь, когда вы знаете преимущества и недостатки перемещения баз данных MySQL на RAM-диск, я расскажу вам, как этого добиться.

Сначала сделайте резервную копию всех баз данных. Скопируем его в /var/lib/mysql.bak

sudo cp -pRL /var/lib/mysql /var/lib/mysql.bak

Создайте каталог для RAM-диска.

sudo mkdir /tmp/ramdisk

Установите его. Я назначил рамдиску размер 2ГБ. Вам решать, сколько места вы хотите, просто убедитесь, что оно может вместить все данные, которые вы будете записывать в базу данных.

sudo mount -t tmpfs -o size=2G tmpfs /tmp/ramdisk/

Переместите базы данных MySQL на RAM-диск.

sudo mv /var/lib/mysql /tmp/ramdisk/mysql

Создайте символическую ссылку на RAM-диск.

sudo ln -s /tmp/ramdisk/mysql /var/lib/mysql

Измените принадлежность на MySQL, чтобы разрешить доступ.

sudo chown mysql:mysql /tmp/ramdisk/mysql

Перезапустите MySQL, чтобы изменения вступили в силу.

sudo /etc/init.d/mysql restart

Теперь мы закончили! После перемещения баз данных на RAM-диск выполнение миграции и сеялки заняло всего минуту по сравнению с почти часом при использовании жесткого диска.

Восстановление баз данных

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

Удалите ранее созданную символическую ссылку на mysql ramdisk.

sudo rm -rf /var/lib/mysql

Скопируйте и восстановите базы данных из резервной копии.

sudo cp -pRL /var/lib/mysql.bak /var/lib/mysql

Скрипты для удобства

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

Вот сценарий восстановления базы данных

Вот сценарий для переноса базы данных в оперативную память

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

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

При использовании RAM-диска у нас всегда будет возникать одна проблема - что будет, если размер tempDB выйдет за пределы RAM-диска?

Эта проблема решается весьма просто - MSSQL позволяет создавать дополнительные файлы данных и логов, в том числе для tempDB.
Таким образом общие рекомендации сводятся к следующему:

Первый файл данных tempDB - на RAM-диске, фиксированного размера (я ставлю 75%) от размера RAM-диске. Отключен autogrowth.
Первый файл логов tempDB - на RAM-диске, фиксированного размера (я ставлю 25%) от размера RAM-диске. Отключен autogrowth.
Второй файл данных tempDB - на обычном диске, начальный размер 8 Mb. Включен autogrowth.
Второй файл логов tempDB - на обычном диске, начальный размер 8 Mb. Включен autogrowth.

Таким образом, при росте размера tempDB и выходе его "из берегов" RAM-диска он просто расширится на медленные диски.

Чтобы сжать дополнительные файлы БД, если tempDB выросла в их размеры, настраивается простенький план обслуживания на ночь:

P.S. Лишь внедрением RAM TempDB мы смогли ускорить закрытие месяца в ERP в два раза.

Специальные предложения

Эх! А я-то думал, что в статье будет описано, как именно сделать на сервере RAM-диск.
Какой понадёжнее, какой подешевле и т.п. Brawler; VKuser318125097; mpeg1989; sansys; Tavalik; alest; + 6 – Ответить (1) Ниже написал, каким диском пользуюсь.
Вопросы установки и настройки нужно рассмотреть? (5) Да не. Разобраться с установкой там легко.
Просто пишу свой отзыв о статье.
Я рассчитывал на сравнительный анализ ПО для RAM-дисков, а статья оказалась о другом. :) Ответьте, пожалуйста, с помощью какой программы вы делали RAM-диск? (8) а теперь 2 тыщи домашняя версия и чуть больше 3к - коммерческая. Для организации копейки, так-то. (4) Интерес скорее вызывает не столько цена, сколько опыт эксплуатации.
У вас это на рабочей базе/базах?
И нормально работает? Плюсанул за разнесение по файлам для решения проблемы переполнения.
Вроде банальная штука, но почему-то никогда в голову не приходила. Правда и вопрос этот всерьез не рассматривал. (9) Хм. И за счет чего ожидается прирост, если файлики рядом лежат?
Да и выставлять степень параллелизма в единицу - тоже спорный совет. Это радикально замедляет формирование тяжелых отчетов.
ЗЫ. Почитал про разбиение tempdb - это скорее прикрытие возможного узкого места (при большом количестве конфликтов при мультипоточном доступе к файлу), чем кнопка "турбо". Т.е. может и не иметь никакого эффекта. (15) Правильно ли я понял Ваш вопрос - за счёт чего возникает прирост производительности после перемещения tempDB в RAM. Верно? (16) Нет. Вопрос касался разделения tempdb на несколько файлов на одном и том же диске. Вопрос был не к вам.
Но если знаете точный ответ - буду благодарен. И актуальна ли эта рекомендация для RAID 5 и выше. (9) Конечно знаю. Но в данной ситуации рекомендация разбивать неприменима. Нужно ли объяснить, почему? (9) Не правильно давать ссылку на "перепосты", а не на первоисточник.
Плохо, что для 1С-ников истина по SQL на сайте 1С, а не на MSDN (((( MS SQL сам кэширует в памяти все что нужно без всяких RAM-дисков. Без тестов производительности статья ни о чем. Разбивать TempDB на несколько файлов - описано в настройках MS SQL от 1С, вероятно закрытие месяца от этого и ускорилось. (12) Я не являюсь экспертом по SQL, но насколько мне известно есть куча настроек (хеширование, статистика), которые отвечают за скорость работы с данными, ХРАНЯЩИМИСЯ НЕПОСРЕДСТВЕННО в базе (файле MDF). Но эти настройки (ИМХО) не ускоряют работы с файлами TempDB, которые (источник этой информации указать не могу) не планировались в роли оперативного хранилище здоровенных массивов информации, как сейчас их использует платформа 1С.
MS SQL сам кэширует в памяти все что нужно без всяких RAM-дисков.

MS SQL при построении плана запроса рассчитывает необходимое количество памяти и, если ошибается, то начинает задействовать tempdb. Это легко увидеть, если в профайлере получить планы запросов. Там, где стоит желтый восклицательный знак, там внутри как раз и пишет, что был задействован tempdb. Часто такое происходит на процедурах сортировки.

Было такое, как по изначальной статье, даже базы выносили, но потом все равно на ssd перешли.
Тем более в новых скулях есть настройки Buffer Pool Extension.
Как вы после перезагрузки сервера действуете или MSSQL в отложенном запуске?

Да, конечно от статьи ждал большего. Хотелось бы анализа причин, прироста производительности. Ну, простите меня, не ведующего, ну не могу я понять, почему если от SQL сервера откусить несколько десятков гигабайт памяти и сделать на них RAM-диск, то операции на этом сервере станут выполнять ЗАМЕТНО быстрее (и уж тем более в общем случае, а не как у автора - в частном случае закрытия месяца).

Ведь, насколько я знаю, все операции над temdb SQL сервер и так делает над таблицами (условно будем считать всё, что хранится в tembdb таблицами) с установленным внутренним приоритетом хранения в оперативной памяти (если её конечно достаточно)! То есть, временная таблица не будет выгружаться на диск, если для неё достаточно свободного места в оперативной памяти. Понятно, что если будут обрабатываться достаточно большие таблицы - они будут выгружаться на диск (при этом будет дублирование - часть данных наборов страниц будет в оперативном кеше и на диске). Но насколько же это будет в общем случае критично? Чтобы лишать SQL сервер гибко управлять всей своей свободной памятью, ради того, чтобы достаточно большая часть была всегда выделена под RAM диск с temdb - которая, скорее всего, в 90% не будет использована и на половину (а что будет использовано ещё и будет частично повторно кешировано в буфере SQL Server - неэффективно расходуя оперативную память на свои копии данных)! Так как SQL Server и всё-равно будет стараться держать временные таблицы в оставшейся у него оперативной памяти и выгружать их RMA-tempdb (причём выполняя объёмную пересылку данных между блоками памяти самым не производительным способом - через кучу посредников и между изолированными доменами приложений) в одну и в другую сторону только по мере необходимости (нехватки памяти, которая как раз и будет вызвана тем, что её попросту недодали SQL Server'у).

На мой взгляд RAM-диск для базы - это больше экстремальное экспериментирование, чем реальное предложение по ускорению! Вы вот так насоветуете админам - а они на своих серверах с 64Gb оперативной памяти, при базе(ах) объёмом боле 1Tb (с самой большой базой около 100Gb) и temdb, который у них при закрытии месяца пухнет свыше 100Gb возьму и выделять под RAM-tempdb минимум 16Gb (а кто-то и все 32Gb) и тем самым у них просядет обычная работа с данными рабочих баз на 25% (условно) в обычном режиме (а в пике ещё больше), а скорость работы с temdb (в часы макс нагрузки) увеличится ну максимум на 20% (и это в пике) - будет ли это реальной панацеей? Большой вопрос! Очень большой!

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

И главное, в чём будет реальный экономический выигрыш - от того, что сервер будет требовать больше очень недешёвой серверной оперативной памяти, нежели - как альтернатива - просто разместить temdb на хорошем (тоже не дешёвом, но это пока с памятью не сравнить) серверном SSD диске - с высоким IOPS (лучше всего модели для PCI-ex, а не SAS/SATA; ну или хотя бы в слот M.2 - но это только на современных матерях) , и низким коэффициентом снижения производительности от числа полной перезаписи. Тут важна скорость - надёжность не так важна - это же не для хранения рабочей базы данных.

Вот тогда от статьи был бы толк.

Ну а если помещать в RAM tempdb - то я был начал только с лога temdb - который только пишется (и перезаписывается) в simple rec. mode, ему не требуется хранить большие объёмы дублирующихся данных. А данные временных таблиц - пусть SQL Server сам размещает в доступной ему буферной памяти, и выгружает на физ диск (лучше SSD), когда памяти уж совсем не хватает (а если это часто -то лучше 100 раз задуматься о том, чтобы её нарастить - ведь если её не хватает, от её перераспределения её больше не станет).

Вообще, прежде чем переходить на RAM - лучше сначала освоить перенос temdb на другой диск - если Ваш tempdb находится в том же RAID массиве что и диски рабочей базы - то задумайтесь сначала об этом, крайне негативном факторе - вынесите tempdb на отдельный RAID массив, да хотя бы просто на отдельный диск (два диска : данные и лог) и Вы сразу почувствуете прирост скорости, особенно в пиковой нагрузке! А уж если вы выберите для temdb PСI-ex SSD диски - то, наверняка, дальнейшее желание переносить их на RAM у Вас уже пропадёт!

Читайте также: