Использование O_DIRECT на Linux

Просто символьная ссылка тот каталог к /dev/null

rm -rf ~/.logs
ln -s /dev/null ~/.logs

/dev/null, не должен быть каталог. Если программа пытается писать в ~/.logs/log1.dump, это все еще идет прямо в /dev/null.
Я делаю это для кэша Google Chrome, потому что через некоторое время это становится столь большим, что Chrome займет минуты для запуска.

24
26.10.2015, 23:28
6 ответов

Хорошо, Вы просите события, это делает вопрос немного субъективным и спорным, но проходимым.

Linus сказал, что обращение к использованию, которое люди обычно приписывают O_DIRECT, и для того использования, IMO, Linus главным образом корректен. Даже при направлении ввода-вывода Вы не можете передать данные устройствам непосредственно к Вашим положениям программы, Вам нужен буфер, который заполнен (программой или устройством) и переданный через системный вызов другого конца. Кроме того, для создания этого эффективным Вы не захотите перечитывать что-то, что Вы просто уже читаете, в случае, если Вам нужен он снова. Таким образом, Вам нужен своего рода кэш... и точно, что ядро обеспечивает без O_DIRECT, кэша страницы! Почему бы не использовать это? Это также идет с преимуществами, если бы больше процессов хочет получить доступ к тому же файлу одновременно, это была бы авария с O_DIRECT.

Однако O_DIRECT имеет свое использование: Если по некоторым причинам необходимо получить данные непосредственно из блочного устройства. Это не имеет никакого отношения к производительности.

Люди, использующие O_DIRECT для производительности обычно, происходят из систем с плохими алгоритмами кэширования страницы, или без механизмов совета POSIX или даже людей, бессмысленно повторяющихся, что сказали другие люди. Для предотвращения этих проблем O_DIRECT был решением. Linux, OTOH, имеет философию, что необходимо решить реальную базовую проблему, и базовой проблемой было OSs, которое сделало безнадежное дело с кэшированием страницы.

Я использовал O_DIRECT для простой реализации кошки для нахождения ошибки памяти в моей машине. Это - одно допустимое использование для O_DIRECT. Та производительность, к которой не имеют никакого отношения.

17
27.01.2020, 19:41
  • 1
    Спасибо за информацию это ценится. Я обновил свой вопрос с особыми условиями приложения, которое запросило этот вопрос. Если бы у Вас есть больше деталей о механизмах совета POSIX для записи файлов, которые ценились бы, также. –  casualunixer 28.01.2011, 07:42
  • 2
    o_direct мог бы также быть полезным в системе, где разработчик хочет обеспечить, механизм кэширования на прикладном уровне (думайте базы данных). –  Jmoney38 03.02.2014, 19:14

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

6
27.01.2020, 19:41
  • 1
    Отчет об ошибках на самом деле обсуждает использование файловых систем с journal=data опцией на. Эта опция непосредственно противоположна в действительности к флагу O_DIRECT. Большая часть ext3 и ext4 файловые системы не имеют этого набора флага и если они сделают, то выключение его разрешит открывать файл с O_DIRECT. –  casualunixer 29.01.2011, 19:57

На самом деле, O_DIRECT необходим для предотвращения любого из

  • загрязнение кэша — иногда Вы знаете, что нет никакого смысла в издержках с кэшированием, для, например, при контакте с действительно большими файлами скажите 64 гибибайта, когда существует только 2 гибибайта RAM. Файл потока 32 гибибайт, которые пользователь решил проверить, кажется, не хороший кандидат на кэширование. Это - просто дополнительное действие со своими собственными издержками. И это может заставить некоторые действительно полезные данные быть сокращенными от кэша.
  • дважды кэширование — для, например, некоторый RDBMSes (MySQL для упоминания) допускает определение его собственного кэша. Базы данных, предположительно, знают лучше, как кэшироваться и что, чем Виртуальная память ядра, которая не знает вещь о SQL, планирующем и так далее.

— который бесполезен, как это кажется. И O_DIRECT не означает быть быстрее, часто это не.

14
27.01.2020, 19:41
  • 1
    posix_fadvise может заботиться о проблеме загрязнения кэша. –  psusi 14.06.2012, 17:36
  • 2
    я не думаю Виртуальная память, имеет какое-либо отношение к ней, она просто отображает адрес памяти. Кэш-буфер / Кэш Страницы - то, что Вы имеете в виду. –  ArekBulski 26.10.2015, 23:51
  • 3
    является частью подсистемы VM в UNIX, насколько я могу сказать, вот почему я использовал этот термин. Спасибо за редактирование. :) –  poige 27.10.2015, 01:58

Касаясь того, что уже сказал @Juliano.

Контроль posix_fadvise если настоящей проблемой является недостойное поведение алгоритма кэширования базовой файловой системы, можно ли попробовать, дают ему совет, как Вы собираетесь использовать файловую систему. В течение приятно реализованной фс это должно дать повышение производительности. (Вот ссылка на другую тему, касающуюся подобных соображений https://stackoverflow.com/a/3755818/544721),

3
27.01.2020, 19:41
  • 1
    Похоже, что posix_fadvise изменяет readahead алгоритмы, используемые ядром. Критическим фактором с кодом в вопросе является производительность записи. Проблема, это выписывающее буфер заполняет кэши Linux сначала, которые затем должно вывести ядро, когда это исчерпывает память. Это - трата усилия, вывод в этом случае должен быть минимально буферизован на пути к диску. –  casualunixer 28.10.2015, 04:05

Это во многом связано с производительностью.

Интересный пример - mongodb, использующий движок mmap. O_DIRECT лучше всего использовать, как утверждали другие, где данные вряд ли будут прочитаны в течение некоторого времени. В mongodb журнал базы данных записывается с использованием O_DIRECT, в то время как записи данных и индексов обрабатываются механизмом кеширования страниц (pdflush), потому что, хотя O_DIRECT предлагает меньшую пропускную способность, это также означает меньшую задержку и, следовательно, снижает потерю данных в случае неожиданный сбой (паника ядра, сбой диска или питания). Обратите внимание, что до того, как запись O_DIRECT будет зафиксирована в энергонезависимой памяти, буферизация все еще существует, это просто снижает потери данных.

Другой важной особенностью O_DIRECT является то, что он обеспечивает больший контроль над последовательностью записи. Опять же, это не гарантирует порядок записи (если у вас нет энергонезависимого кэширующего контроллера диска и не используется планировщик fifo, но у них есть свои сложности). Следовательно, хотя mysql использует O_DIRECT для своих данных / индексов, а также для ведения журнала, можно ожидать, что последнее обычно будет выполнено первым.

Но важно помнить, что O_DIRECT нарушает справедливость распределения ресурсов. Одна из причин, по которой ваше приложение ускоряется, заключается в том, что оно замедляет другие вещи.

3
27.01.2020, 19:41

В основном я администратор баз данных/системных администраторов/сетевых администраторов, но также я программист на C/C++. Я написал собственное приложение для массового копирования/перемещения файлов с помощью O _DIRECT и встроенного в Linux aio. Результатом является разумное увеличение пропускной способности, при этом не беспокоя приложения, которым требуется кеш.
Как администратор баз данных я предпочитаю использовать прямой ввод-вывод, когда это возможно. Многие РСУБД предлагают поддержку O _DIRECT, но ни одна из них не предлагает использование собственных вызовов posix/linux для освобождения кэша после его использования.
В конце концов, мне кажется, что позиция Линуса имеет смысл с точки зрения его разработчика ядра, но она не очень практична для разработчика СУБД, который также должен поддерживать другие ОС.
Вернемся к моему приложению. Использование O _DIRECT с буферами 8 или 16 МБ существенно повышает производительность. И приложение практически не использует процессор.

2
11.05.2020, 14:46

Теги

Похожие вопросы