Tmp в tmpfs.

Не последний человек в Canonical Дастин Киркленд (Dustin Kirkland) давно продвигает такую интересную, ускоряющую I/O тему как перенос /tmp в память, но он делает это грамотно, показывая аналитику по многочисленным серверам от Canonical.

Далее текст пойдёт от лица Дастина.

Tl;dr

(too long didn't read - многа букаф, ниасилил).

• Перенос /tmp через tmpfs в ОЗУ улучшает I/O Linux систем, уменьшает потребление электроэнергии за счёт замены диска на быструю ОЗУ, увеличивает срок службы батареи, продлевает срок службы SSD и чуток улучшает безопасность за счёт 100% пропажи временных файлов.
• По факту мы должны сделать /tmp через tmpfs поведением по умолчанию в Ubuntu для серверов и в облачных образах.
• Анализ 502 физических и виртуальных серверов в Canonical показывает, что у 96,6% из них /tmp укладывается в половину свободной памяти (free memory) и у 99,2% - в свободную память + своп (free memory + free swap).

Попробуйте

Самим попробовать вынести /tmp в ОЗУ на своей Ubuntu машине можно так

echo "tmpfs /tmp tmpfs rw,nosuid,nodev 0 0" | sudo tee -a /etc/fstab
sudo reboot


Предпосылка

В апреле 2009 года я предложил поместить /tmp в tmpfs (файловая система в ОЗУ) в Ubuntu серверах по умолчанию при определённых условиях, к примеру при большом количестве ОЗУ. Предложение получило тег approved, но по различным причинам вопрос повис в воздухе. Снова в 2016 году я предлагаю это улучшение в качестве обсуждения-бага в почтовых рассылках ubuntu-cloud и ubuntu-devel.

Плюсы /tmp в tmpfs:

• Производительность. Чтение, запись и не нужность позиционировать головки над данными. Быстрота на скоростях ОЗУ.
• Безопасность. Утечки данных предотвращены, особенно если ещё отключен swap. Так как /tmp обладает точкой монтирования ему добавлены параметры nosuid и nodev (админы могут добавить и noexec).
• Энергоэффективность. Операции с диском более энергозатратны. Работа с ОЗУ менее энергозатратна.
• Надёжность. Уменьшается запись в ячейки SSD.

Для честного разбора стоит отметить недостатки:

• Может быть мало места (space) в ОЗУ, чем в корне /, где традиционно живёт /tmp.
• Запись в tmpfs может вытеснить другую информацию.

Более подробно в Linux Kernel documentation tmpfs.txt.

Не совсем неизведанная территория

Проект Fedora несколько лет назад перешёл в релизе 18 на использование /tmp в tmpfs. Solaris это использует по умолчанию с 1994 года. Я поставил Fedora 23 в виртуальную машину, чтобы убедиться в использовании по умолчанию /tmp в ОЗУ. ArchLinux поступает так же. Debian обсуждает данный вопрос в ветке Moving /tmp to tmpfs makes it useless и желательно прочесть его весь, чтобы переварить плюсы и минусы, так как начало ветки целиком посвящено "не делать /tmp в ОЗУ".

Реальные данные

По факту все дискуссии ЗА и ПРОТИВ во множестве Linux дистрибутивов полны предположений, гипотез, догадок и допущений. Но давайте глянем реальные данные!

Вот анализ (не исчерпывающий) 502 серверов в production, что держат Ubuntu.com, Launchpad.net, сотни сервисов, в том числе OpenStack, дюжина сайтов, хостинг кода, базы данных и т.д. Выборка серверов предвзята в том смысле, что количество физических серверов превалирует над виртуальными машинами, но оба типа присутствуют в выборке. Так же взят широкий спектр серверов по параметру беспрерывной работы (uptime) - от суток до 1306 дней uptime у сервера, который обновляется методом live patched kernels.

Вы можете взять эти данные с разделением столбцов через tab по адресу people.canonical.com/~kirkland/tmpfs.txt

Заголовки столбцов:

• Столбец 1: имя хоста в виде числа для анонимизации.
• Столбец 2: du -s /tmp на дату 17.01.2016.
• Столбец 3-8: free про ОЗУ в Кб.
• Столбец 9-11: free про swap в Кб.
• Столбец 12: число inode в /tmp

Для цифр что тут будут мелькать 1 Мб = 1000 Кб, 1 Гб = 1000 Мб. Про кибиты-КиБ и мибиты-МиБ давайте спорить не здесь, ок?

Mean - среднее арифметическое. Median - среднее значение в отсортированном списке. Mode - число встречается чаще всего. Все расчёты идут с точностью до 2 значащих цифр.

Суммарные данные по использованию /tmp:

• Max: 101 Гб
• Min: 4 Кб
• Mean: 453 Мб
• Median: 16 Кб
• Mode: 4 Кб

Глядя на данные от 502 серверов, можно увидеть два крайне экстремальных значения. Один сервер имеет 101 Гб в /tmp, а другой 42 Гб в виде django.log. Есть ещё 4 сервера с 10-12 Гб в /tmp. Остальные из 496 серверов (98,8%) используют менее 4,8 Гб. По факту 483 сервера (96,2%) используют менее 1 Гб в /tmp. 454 сервера (90,4%) меньше 100 Мб. 414 сервера (82,5%) менее 10 Мб в /tmp. 370 сервера (73,7%) меньше 1 Мб.

Суммарные данные по количеству доступной памяти (total memory):

• Max: 255 Гб
• Min: 1 Гб
• Mean: 24 Гб
• Median: 10,2 Гб
• Mode: 4,1 Гб

Все 100% машин имеют по крайней мере 1 Гб ОЗУ.
495 машин (98,6%) >= 2 Гб.
437 (87%) >= 4 Гб.
255 (50,8%) >= 10 Гб.
157 (31,3%) >= 24 Гб.
74 (14,7%) >= 64 Гб.

Суммарные данные своп (total swap):

• Max: 201 Гб
• Min: 0 Кб
• Mean: 13 Гб
• Median: 6,3 Гб
• Mode: 2,96 Гб

485 машин (96,6%) имеют включённый swap, в то время как у 17 (3,4%) серверов подкачка отключена. Одна из таких машин имеет 415 Мб в /tmp и обладает 32 Гб ОЗУ. Все остальные сервера-без-swap имеют в /tmp от 4 до 52 Кб данных и обладают от 2 до 28 Гб ОЗУ. 5 серверов (1%) обладают 100 Гб swap разделом.

Суммарные данные по использованию swap:

• Max: 19 Гб
• Min: 0 Кб
• Mean: 657 Мб
• Median: 18 Мб
• Mode: 0 Кб

476 машин (94,8%) используют менее 4 Гб swap. 463 (92.2%) менее 1 Гб. 366 (72,9%) менее 100 Мб. 18 (3,6%) обладают swap более 10 Гб.

Моделирование использования /tmp в tmpfs

Я взял total memory каждой машины и разделил пополам, так как столько по умолчанию даётся для tmpfs, затем вычел "использование /tmp", чтобы понять может ли tmpfs машины вместить в памяти БЕЗ ЗАДЕЙСТВОВАНИЯ swap и БЕЗ вытеснения чего-либо из памяти. 485 машин (96,6%) смогли бы разместить свой /tmp в tmpfs в свободной памяти.

Теперь для каждой машины посчитаем сумму Free memory + Free swap и посмотрим, какие из них смогут разместить /tmp, благодаря free memory + swap. 498 (99,2%)! 4 машины с экстремальным использованием /tmp не смогут этого сделать - 101, 42, 13, 10 Гб.

Производительность tmpfs против ext4-on-SSD

Давайте глянем на несколько грубые числа чтения и записи с помощью dd. Перед каждой командой делайте sync; echo 3 | sudo tee /proc/sys/vm/drop_caches

Мой /tmp в tmpfs:
cd /tmp; df -h .
Filesystem Size Used Avail Use% Mounted on
tmpfs 7.7G 2.6M 7.7G 1% /tmp

Запишем 2 Гб данных:
cd /tmp; dd if=/dev/zero of=/tmp/zero bs=2G count=1
2147479552 bytes (2.1 GB) copied, 1.56469 s, 1.4 GB/s

Запишем данные синхронно:
cd /tmp; dd if=/dev/zero of=/tmp/zero bs=2G count=1 oflag=dsync
2147479552 bytes (2.1 GB) copied, 2.47235 s, 869 MB/s

Мой Intel SSD:
df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/dm-0 217G 106G 100G 52% /

Запишем 2 Гб данных на SSD (предполагая /var/tmp на SSD):
cd /var/tmp; dd if=/dev/zero of=/var/tmp/zero bs=2G count=1
2147479552 bytes (2.1 GB) copied, 7.52918 s, 285 MB/s

Запишем данные на SSD синхронно:
dd if=/dev/zero of=/var/tmp/zero bs=2G count=1 oflag=dsync
2147479552 bytes (2.1 GB) copied, 11.9599 s, 180 MB/s

Вернёмся к tmpfs и начнём читать:
dd if=/tmp/zero of=/dev/null bs=2G count=1
2147479552 bytes (2.1 GB) copied, 1.94799 s, 1.1 GB/s

Читаем SSD:
dd if=/var/tmp/zero of=/dev/null bs=2G count=1
2147479552 bytes (2.1 GB) copied, 2.55302 s, 841 MB/s

Создадим 10,000 маленьких файлов (1 Кб) в tmpfs:
cd /tmp; time for i in $(seq 1 10000); do dd if=/dev/zero of=$i bs=1K count=1 oflag=dsync ; done
real 0m15.518s
user 0m1.592s
sys 0m7.596s

Создадим 10,000 маленьких файлов (1 Кб) на SSD:
cd /var/tmp/; time for i in $(seq 1 10000); do dd if=/dev/zero of=$i bs=1K count=1 oflag=dsync ; done
real 0m26.713s
user 0m2.928s
sys 0m7.540s

К сожалению, у меня нет обычных HDD с вращающимися пластинами и головками, которым нужно время на позиционирование над данными. Но точно результаты будут хуже SSD. Итак этот грубый тест с помощью dd дал:
869 Мб/с - 1,4 Гб/с запись для tmpfs
180 Мб/с - 285 Мб/с запись для SSD

Конечно, есть более грамотные тесты для измерения I/O, но tmpfs находится в ОЗУ и победа будет над любыми быстрыми дисками и хранилищами.

Итого:

• Использование /tmp
  • 98,8% серверов используют менее 4,8 Гб в /tmp.
  • 96,2% меньше 1 Гб.
  • 73,7% меньше 1 Мб.
  • mean/median/mode = 453 Мб / 16 Кб / 4 Кб.
• Доступно total memory
  • 98,6% серверов обладают не менее 2 Гб ОЗУ.
  • 88% не менее 4 Гб.
  • 57,4% не менее 8 Гб.
  • mean/median/mode = 24 Гб / 10 Гб / 4 Гб.
• Доступен swap
  • 96,6% серверов обладают swap.
  • mean/median/mode = 13 Гб / 6.3 Гб / 3 Гб.
• Swap используется
  • 94,8% серверов используют менее 4 Гб swap.
  • 92,2% менее 1 Гб.
  • 72,9% менее 100 Мб.
  • mean/median/mode = 657 Мб / 18 Мб / 0 Кб.
• Моделирование использования /tmp в tmpfs
  • 96,6% машин могли бы разместить свой /tmp в свободной памяти.
  • 99,2% могли бы разместить свой /tmp во free memory + free swap
  • 4 из 502 машин (0,8%) требуют специальной обработки своих конфигураций.

Выводы

• /tmp в tmpfs можно делать всем?
  • Нет, мы выявили 4 из 502 машин (0,8%) чьи огромные данные в /tmp не дадут сделать требуемое.
  • Но это реально исключение, а не правило. 96,6% машин умещают свои tmp в половине свободной ОЗУ.
• /tmp в tmpfs впервые вы предлагаете сделать по умолчанию?
  • Нет. Solaris это применяет уже 22 года и Fedora с ArchLinux уже 4 года.
• tmpfs реально быстрее, эффективней и безопасней?
  • Каждый должен попробовать сам.

Дата последней правки: 2023-12-27 17:23:24