Назад | Перейти на главную страницу

Практика установки сервера Linux / UNIX для / tmp

Основываясь на том, что вы все видите, какова рекомендуемая конфигурация / tmp в серверной системе и почему. Я обсуждал эти вопросы на протяжении многих лет, иногда с принципиальными разногласиями.

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

Специально для / tmp:

  1. Следует ли ln -s / var / tmp / tmp?

  2. Следует ли сохранять / tmp между перезагрузками или нет?

  3. Должен ли / tmp находиться в реальной области диска или разрешен в основном в области подкачки (или tmpfs)?

  4. Должен ли / tmp находиться на другом диске, чем / (корневой)?

  5. Вы бы разместили / tmp на другом контроллере диска, отличном от / (корневого) диска?

  6. Какие-нибудь практические правила для размера / tmp?

  7. Как бы вы управляли пространством / tmp, когда система работает? Удалить все файлы> определенного возраста? Оставить область в покое, пока она не достигнет% возраста от макс.

  8. Следует ли вводить какие-либо процедурные положения для регулирования этой области?

Специально для / tmp:

  • Следует ли ln -s / var / tmp / tmp?

В случае полного образа диска в памяти (подумайте о «live boot CD») это могло бы быть приемлемо, так как каждый байт RAM должен быть сжат. В противном случае, если вам не нужно много места на диске, нет. / var имеет свои особенности, и смешивание / tmp с / var / tmp может иметь непредвиденные последствия при выполнении обслуживания системы. Он также добавляет дополнительную зависимость, заключающуюся в том, что / tmp должен быть смонтирован для правильной работы / var / tmp; не все нуждается в / tmp, и у вас может возникнуть ситуация, когда вы хотите перенести его на другой раздел или диск, но не можете, потому что вы не хотите отключать / var.

  • Следует ли сохранять / tmp между перезагрузками или нет?

Нет. Если вы полагаетесь на это как на последовательное поведение, то рано или поздно вы столкнетесь с проблемами.

  • Должен ли / tmp находиться в реальной области диска или разрешен в основном в области подкачки (или tmpfs)?

Когда он интенсивно используется, возникает соблазн - «мы поместим / tmp на RAM-диск, это ускорит доступ, а когда система перезагружается / выключается, убирать нечего». Однако, если вы думаете о реализации временного пространства как RAM-диска, который будет заменяться местами, я бы рассмотрел последствия использования пространства подкачки вашей системы другими программами. Если своп используется как форма «аварийного переполнения», когда система находится в тяжелом положении и нуждается в нем, последнее, что вам нужно, это чтобы пространство подкачки использовалось неконтролируемым процессом, заполняющим / tmp, потребляющим память, вызывая давление на Подсистема ВМ для подкачки на диск. Между действиями подкачки и дополнительной потоковой передачей ввода-вывода на RAM-диск (что, в свою очередь, может привести к дополнительным подкачкам для удовлетворения seek ()) ваша система быстро станет связанной с вводом-выводом.

  • Должен ли / tmp находиться на другом диске, чем / (корневой)?

Желательно да, хотя в этом нет необходимости. Если вы интенсивно пользуетесь им или у вас есть постоянная рабочая нагрузка, которая требует этого, то определенно да. Гипотетический пример: база данных, которая выгружает временные файлы в / tmp, получит небольшое ускорение, если ввести / tmp на отдельный шпиндель (т. Е. На диск).

  • Вы бы разместили / tmp на другом контроллере диска, отличном от / (корневого) диска?

Если у вас есть требования к восстанавливаемости или скорости, то это следует учитывать.

  • Какие-нибудь практические правила для размера / tmp?

Он должен в 2 раза превышать ожидаемую рабочую нагрузку. Под этим я подразумеваю, что если у вас есть локальные пользователи, регулярно использующие это пространство, рано или поздно кто-то сделает что-нибудь глупое и попытается заполнить его. Небольшой избыток позволит вам избежать странных "проблем" с программами, которые останавливаются из-за того, что их временные файлы заполнили оставшееся пространство.

Если это установка с «общими службами», когда сервер предоставляет одну или несколько сетевых служб, но не обслуживает пользователей, то это, вероятно, будет низким. Если это многопользовательская установка, это будет на высоком уровне (да, есть еще места, где размещаются реальные пользователи и не только их сетевые сервисы).

  • Как бы вы управляли пространством / tmp, когда система работает? Удалить все файлы> определенного возраста? Оставить область в покое, пока она не достигнет% возраста от макс.

Посмотрите в tmpwatch команда, я думаю, вы обнаружите, что она хорошо подходит для этой части вашего вопроса (ов). Команда просто удаляет все файлы старше определенного возраста в часах. В зависимости от того, как быстро он заполняется, вы можете работать 30, 45, 90 дней и т. Д.

  • Следует ли вводить какие-либо процедурные положения для регулирования этой области?

Я бы порекомендовал следующее:

  1. Все файлы являются временными, и их сохранение после перезагрузки не гарантируется.
  2. Устаревшие файлы старше% age будут удаляться каждую ночь в полночь по местному времени с помощью задания cron, которое запускает команду tmpwatch.

Остальное зависит от ваших конкретных потребностей.

По опыту я рекомендую не смешивать каталоги / var / tmp и / tmp.

Причина в том, что в / var (надеюсь) будут находиться все ваши журналы, кеш и служебные данные (например, базы данных). Как правило, рекомендуется разместить / var в отдельном разделе, чтобы в случае значительного события данных (например, большого количества записей в журнале или записи в базу данных) в корневом разделе и разделах / tmp по-прежнему оставалось свободное место для надежной работы.

Например, я буквально только что вернулся с сайта, где эта практика не соблюдалась (т.е. все находилось на одном разделе), и в результате создания журнала вся система оказалась на коленях. Если бы соблюдался разумный макет разделения, на разделе / ​​var не хватило бы места, но сервер остался бы реагировать.

Очень многое зависит от конкретной нагрузки вашего приложения. Некоторые серверы приложений (SunONE, старый материал netscape) записывают от нескольких сотен до нескольких тысяч файлов в / tmp - в этой ситуации вы действительно не хотите, чтобы это был смонтированный RAM-диск, и нет причин сохранять его между перезагрузками.

Серверы становятся менее общими и становятся более специализированными - этот тип вопросов (и аналогичный вопрос «как мне разделить мою систему») действительно зависит от вашей загрузки.

Недавно у меня был один сервер, который был перезагружен в первый раз через 4 года или около того - он застрял на полпути при загрузке, удалив все файлы в / tmp - там было так много мусора, что потребовался хороший час, чтобы его очистить . Определенно неплохо периодически чистить его, если ваш компьютер не перезагружается очень часто.

Только отвечая на некоторые вопросы ...

Я бы поместил / tmp в другой раздел, чем /, просто чтобы я мог монтировать / ro во время нормальной работы. Отдельный диск? Это зависит от того, насколько часто используются / tmp и / get и мешают ли они друг другу.

Что касается частей 1 и 2, на моем компьютере (Mac OS X) / var / tmp очищается не ежедневно, а / tmp, поэтому они имеют разные политики и, следовательно, не должны быть связаны друг с другом символическими ссылками. Я не уверен, что ежедневная очистка / var / tmp ничего не сломает, и хотел бы изучить это, прежде чем стать более громким - на данный момент это всего 172k.

В связи с вашим последним вопросом я бы рассмотрел один пункт - сделать / tmp noexec, nosuid, то есть никакие исполняемые файлы не смогут запускаться из / tmp, и никакие двоичные файлы suid не смогут переключать идентификатор пользователя. Однако это может повлиять на некоторые программы, поэтому протестируйте его, прежде чем полностью полагаться на него - я думаю, что ssh был даже одним из них, но я забыл.

Это мера безопасности, которая повысит вашу безопасность в отношении / tmp.

Еще одна вещь: многие пользователи будут пытаться использовать / tmp в качестве постоянного временного хранилища: любая принудительная очистка / tmp должна выполняться вместе с обучением пользователей: напомните им, что / tmp - это временный и все, что там находится, может исчезнуть в любой момент.

Должен ли / tmp находиться в реальной области диска или разрешен в основном в области подкачки (или tmpfs)?

Вы обдумывали, что происходит, когда / tmp заполняется в этой ситуации? Это не то, что нужно делать дважды. Я сделал это однажды (на Solaris / tmp съест всю доступную оперативную память и своп), и это поставило сервер на колени.