В принципе, я не понимаю, почему запись в строгий кольцевой -буфер может вызывать проблемы с фрагментацией. Кажется, это будет просто. Цитата звучит для меня так, как будто она основана на совете от более общих рабочих нагрузок записи. Но, глядя на связанный вопрос SO, я вижу, что у вас есть реальная проблема...
Поскольку вас беспокоит фрагментация, подумайте, как ее измерить! e4defrag
существует. У него всего два варианта. -c
показывает только текущее состояние и не выполняет дефрагментацию. -v
показывает статистику по -файлам. Действительны все комбинации опций (, включая отсутствие опций ). Хотя он не предоставляет какого-либо явного метода ограничения влияния на производительность работающей системы, e4defrag
поддерживает запуск отдельных файлов, поэтому вы можете оценить -самостоятельно.
(В XFS также есть инструмент дефрагментации, хотя я им не пользовался.)
e2freefrag
может показать фрагментацию свободного пространства. Если вы используете планировщик ввода-вывода CFQ, то вы можете запустить его с пониженным приоритетом ввода-вывода, используя ionice
.
Цитата угадывается неверно, ответ Стивена Китта верен. ext4 не выполняет никакой автоматической дефрагментации. Он не пытается «перетасовать» данные, которые уже были записаны.
Отбросив это странное заблуждение, не остается причин предлагать "ext2/ext3". Кроме всего прочего, код ext3 не существует в текущих ядрах. Код ext4 используется для монтирования ext3. ext3 является подмножеством ext4. В частности, когда вы создаете относительно большие файлы, просто глупо не использовать экстенты, и это особенность ext4 -.
Мне кажется, что «повешение» чаще всего ассоциируется с журналом. См., например. комментарии из (в файловой системе -progress)bcachefs-
Tail latency has been the bane of ext4 users for many years - dependencies in the journalling code and elsewhere can lead to 30+ second latencies on simple operations (e.g. unlinks) on multithreaded workloads. No one seems to know how to fix them.
In bcachefs, the only reason a thread blocks on IO is because it explicitly asked to (an uncached read or an fsync operation), or resource exhaustion - full stop. Locks that would block foreground operations are never held while doing IO. While bcachefs isn't a realtime filesystem today (it lacks e.g. realtime scheduling for IO), it very conceivably could be one day.
Не просите меня интерпретировать, в какой степени использование XFS позволяет избежать описанной выше проблемы. Я не знаю. Но если вы планируете протестировать альтернативную настройку файловой системы,XFS - это первое, что я бы попробовал.
Я изо всех сил пытаюсь найти много информации о влиянии отключения ведения журнала на ext4. По крайней мере, это не похоже на один из распространенных вариантов, рассматриваемых при настройке производительности.
Я не понимаю, почему вы используете sys _sync (). Обычно этого лучше избегать (, см., например,. здесь). Я не уверен, что это действительно объясняет вашу проблему, но мне кажется, что при попытке сузить это досадно.
Термин для этого Привязка ЦП . Вы можете использовать команду taskset
, чтобы установить его для отдельных процессов.
Для запуска <command>
только на первых 6 ядрах (ядрах #0 -#5 ):
taskset -c 0-5 <command> [arguments for command]
Если процесс уже запущен, вы можете установить его привязку по PID:
taskset -c 0-5 -p <PID of an existing process>
Если вам нужно ограничение, которое будет применяться к конкретному процессу и всем его дочерним процессам , вам понадобятся контрольные группы, как упоминал Стивен Китт в комментариях. Если рассматриваемый процесс работает как служба systemd
, то вы можете просто добавить CPUAffinity=0-5
в раздел [Service]
соответствующего файла .service
(или создать файл переопределения ).
Но если вам нужно ограничить количество ядер, используемых для целей лицензирования , вам необходимо выяснить, какие методы принимаются соответствующим поставщиком программного обеспечения. Скорее всего, им потребуется метод, который не так просто отменить, или им может потребоваться механизм, например, для. ежедневные отчеты о том, сколько ядер (максимум )использовалось для этого программного обеспечения каждый день.
Да, в системах RedHat пользователь обычно используетnumactl
Хотя он не может гарантировать привязку процесса к определенному ЦП (, поскольку разрешает привязку к другому ЦП, если требуемый ЦП недоступен, он настраивает запуск задания таким образом, чтобы приложить все усилия для привязки и (, если процесс спит )перепривязать к нужным процессорам.
Обратите внимание, что в данном случае ЦП означает «вещь, которая может запускать программу», а не физический элемент. Это означает, что (для этого разговора )реальное ядро — это один ЦП, гиперпоток — другой, и часто в физическом корпусе много ЦП. Чтобы получить список этих процессоров:
cat /proc/cpuinfo
numactl --hardware
показывает аппаратную компоновку. Каждый узел представляет собой «границу памяти», что означает, что это изолированный бит ОЗУ, который доступен для некоторых ЦП быстрее, чем для других ЦП. Причина обычно в том, что он напрямую доступен для набора ЦП, а другие ЦП должны делать запросы через эти границы, чтобы получить доступ к этому биту ОЗУ. Это важно, потому что вы также можете указать numactl
использовать только определенные границы памяти. Рекомендуется указать границу памяти, локальную для ЦП, если вы указываете конкретные ЦП.
numactl --physcpubind=0-7 <command>
запустит все, что вы обычно запускаете с <command>
на ядрах с 0 по 7.
numactl --physcpubind=0,7 <command>
запустит <command>
на ядре 0 или 7.
Конечно,оба они могут «отсутствовать по ядру», когда ОС решает, что ядро будет недоступно, и запускает программу на не указанном -ядре, а не откладывает запуск. Параметр numactl
--localalloc
будет пытаться использовать память, локальную для ядра, тогда как --membind=...
разрешает более явную привязку расположения памяти.
numastat
показывает numa_hits
и numa_misses
в статистической форме для numactl
запущенных процессов. Чтобы увидеть, сработал или пропустил какой-либо конкретный процесс, вам нужно прочитать подробности из файловой системы /proc
до того, как процесс завершится.