Использование ввода-вывода для перенаправления / dev / null?

Я всегда использую nohup для запуска своей системы. Однако вывод nohup настолько велик, что я думаю перенаправить его на /dev/null . Моя проблема заключается в том, что перенаправление на /dev/null также приведет к некоторым операциям ввода-вывода, например записи в обычный файл?

Или я должен перейти на уровень кода и удалить всю информацию о регистрации? (Но мне они могут понадобиться).

Моя единственная проблема – использование и объем ввода-вывода и размер файла.

  • Как я могу настроить рабочий стол Linux на более отзывчивый?
  • Linux: Почему init и systemd используют так много операций ввода-вывода?
  • Почему я не могу сделать ls -a 1> & -?
  • Вывести вывод сценария bash в строку, которая называется сценарием bash
  • 100.0% sy с плохой производительностью диска
  • Как условия гонки влияют на чтение и запись (которые происходят одновременно)
  • Как найти то, что забивает мой ввод-вывод?
  • SysBench выделяет невероятную производительность записи на диск на белом поле против сервера Tier1
  • 3 Solutions collect form web for “Использование ввода-вывода для перенаправления / dev / null?”

    Данные, записанные в /dev/null , никуда не денутся. Поскольку файл не записывается ни в один файл, размер файла не влияет на него.

    Если программа записывает /dev/null , происходит системный вызов. Но системный вызов возвращается почти сразу, не записывая данные нигде. Таким образом, с точки зрения приложения есть ввод-вывод, но не с точки зрения аппаратного обеспечения.

    Никто, кроме вас, не знает, слишком ли дорого стоит письменная запись /dev/null . Если вы обеспокоены, контрольный показатель.

    Это немного похоже на проблему XY . То, что вы действительно должны делать, это добавить возможность контролировать уровень ведения журнала из файла конфигурации или командной строки, используя все большее число -v 's, ala. -vvv как и многие инструменты командной строки.

    Затем вы все равно можете вызывать свой сервер с помощью nohup и добавлять / удалять -vv.. переключение и добавлять его только при необходимости.

    Кроме того, посмотрите на использование реального средства ведения журнала , такого как log4j , log4perl , log4X, где X – это любой ваш язык. Затем вы можете контролировать уровень ведения журнала из файла log4X .conf, а также указывать такие вещи, как поворот журнала и т. Д.

    Очевидно, что вы можете перенаправить ведение журнала, поскольку оно соответствует /dev/null но это другие параметры, которые вы также должны рассматривать как разработчик.

    Запись на / dev / null несет ненулевую стоимость, но если она влияет на производительность вашей системы, автор программного обеспечения сделал что-то очень не так. Вызов sys_write () сильно оптимизирован. Написание данных, которые вы отправляете на него, пробивается через различные библиотеки и системы ядра, пока не ударит нулевой драйвер. Этот путь очень эффективен.

    Да, программа, вероятно, должна иметь флаг, который отключает вывод, но если это не так, и запись в / dev / null является проблемой производительности, у вас есть одна странная система.

    Помните, что «преждевременная оптимизация – это корень всего зла». Редактирование кода для исправления является пустой тратой времени, если вы не можете сначала написать контрольный показатель, который показывает, что это действительно самое узкое место в производительности.

    Историческая справка:

    В оригинальных версиях Linux был очень медленный / dev / null. Он сделал много обработки, чтобы выбросить данные в конце. Был неловкий бенчмарк (я не могу найти ссылку, извините!), Показывающий, что Linux / dev / null был намного медленнее, чем FreeBSD и Solaris (популярные Unix-подобные системы тогда). Следующий выпуск Linux имел намного более быстрый / dev / null. Аналогично, loopback NIC в Linux был очень медленным, потому что он полностью обработал пакет, проверил ошибки CRC (что не могло ошибиться) и проделать другую ненужную работу. Были опубликованы несколько неловко плохих тестов, и вскоре все было исправлено.

    Linux и Unix - лучшая ОС в мире.