Вопросы Теги

Как изменить длину временных рядов, используемых Linux CPU scheduler?

Вы можете передать это через tr, sort, uniq, например, в командной строке вы можете проверить это:

 $ var1='50003 50003 50003 50001 50003'

Далее,

 $ echo $var1 | tr ' ' '\n' | sort | uniq
50001
50003

Как вы можете видеть, это выводит уникальные слова и сортирует их, если вы хотите сделать что-то с ними позже, что требует сортированного ввода.

Обновление

На ваш дополнительный вопрос в комментариях, если вы хотите сохранить результаты в переменную, вы можете, в сценарии:

var2="$( echo $var1 | tr ' ' '\n' | sort | uniq )"
  • $( ...) - это подстановка команды bash, заменяющая содержимое $(.... ) на вывод команд

Поэтому позже в вашем скрипте, если вы хотите вывести $var2 на терминал, просто: 

echo "$var2"
  • заключите $var2 в кавычки, чтобы продолжать выводить его как одну строку на результат
  • иначе без кавычек, echo по умолчанию интерпретирует каждое "слово" в $var2 как отдельный аргумент, будет выводить их одно за другим, разделенные пробелом, так что в итоге вы получите одно длинное предложение.

Также помните, что вы можете сохранить вывод в файл, например ~/unique_results.txt:

echo $var1 | tr ' ' '\n' | sort | uniq  > ~/unique_results.txt
  • > - file redirection, перенаправляет стандартный вывод в указанный файл
5
02.12.2018, 18:37
3 ответа

Похоже, вам нужен пакетный -планировщик :, использующий schedtoolдля запуска процессов под разными планировщиками. например.schedtool -B «Command to be run in batch mode»

1
27.01.2020, 20:39

Для большинства серверов RHEL7 RedHat предлагает увеличить sched_min_granularity_nsдо 10 мс и sched_wakeup_granularity_nsдо 15 мс.(Источник . Технически эта ссылка говорит о 10 мкс, что было бы в 1000 раз меньше. Это ошибка ).

Мы можем попытаться понять это предположение более подробно.

Увеличение графика _мин. _детализация _нс

В современных ядрах Linux кванты времени процессора выделяются задачам с помощью CFS, полностью справедливого планировщика. CFS можно настроить с помощью нескольких настроек sysctl.

  • kernel.sched_min_granularity_ns
  • kernel.sched_latency_ns
  • kernel.sched_wakeup_granularity_ns

Вы можете установить sysctl временно до следующей перезагрузки или навсегда в файле конфигурации, который применяется при каждой загрузке. Чтобы узнать, как применять этот тип настройки,найдите «sysctl» или прочитайте краткое введение здесь .

sched_min_granularity_nsявляется наиболее заметным параметром. В исходном запланированном -дизайне -CFS.txt это было описано как единственная «настраиваемая» настройка, «для настройки планировщика с« рабочего стола »(с низкими задержками )на« server' (хорошая пакетная обработка )рабочих нагрузок».

Другими словами, мы можем изменить этот параметр, чтобы уменьшить накладные расходы на переключение контекста -и, следовательно, повысить пропускную способность за счет скорости отклика («задержки» ).

Я думаю, что эта настройка CFS имитирует настройку времени предыдущей сборки -, CONFIG _HZ . В первой версии кода CFS значение по умолчанию составляло 1 мс, что эквивалентно 1000 Гц для использования на рабочем столе. Другими поддерживаемыми значениями CONFIG _HZ были 250 Гц (по умолчанию )и 100 Гц для "серверной" стороны. 100 Гц также было полезно при запуске Linux на очень медленных процессорах, это была одна из причин, указанных , когда CONFIG _HZ впервые был добавлен в качестве параметра сборки на X86 .

Кажется разумным попробовать изменить это значение на 10 мс (, т. е. 100 Гц ), и измерить результаты. Помните, что sysctl измеряются в нс . 1 мс = 1 000 000 нс.

Мы можем видеть, что эта старая -настройка «сервера» все еще была очень актуальна в 2011 году для пропускной способности в некоторых высоконагруженных -тестах производительности :https://events.static.linuxfound.org/slides/2011/linuxcon/lcna2011_rajan.pdf

.

И, возможно, еще пара настроек

Значения по умолчанию для трех указанных выше параметров выглядят относительно близкими друг к другу. Это заставляет меня стремиться к простоте и умножать их все на один и тот же коэффициент :-). Но я попытался изучить это, и кажется, что может иметь значение и более конкретная настройка, поскольку вы настраиваете пропускную способность.

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

См. также «Отключение WAKEUP _PREEMPT» в этом справочнике IBM за 2010 год , в котором говорится, что «для некоторых рабочих нагрузок» эта функция по умолчанию -«может стоить несколько процентов загрузки ЦП». ".

У SUSE Linux есть документация, в которой предлагается установить для этого параметра значение, превышающее половину sched_latency_ns, чтобы эффективно отключить пробуждение -до предварительного -срабатывания, и тогда «задачи с коротким рабочим циклом не смогут эффективно конкурировать с процессором-свиньем». ".

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

https://www.suse.com/documentation/opensuse121/book_tuning/data/sec_tuning_taskscheduler_cfs.html

Если вы поэкспериментируете с любой из этих переменных планирования, я думаю, вы также должны знать, что все три масштабируются (умножаются )на 1+log _2 числа процессоров. Это масштабирование можно отключить с помощью kernel.sched_tunable_scaling. Я мог что-то упустить, но это кажется удивительным, например. если вы рассматриваете скорость отклика серверов, предоставляющих интерактивные приложения и работающих с полной или почти полной нагрузкой, и как эта скорость будет меняться в зависимости от количества процессоров на сервер.

Предложение, если ваша рабочая нагрузка имеет большое количество потоков/процессов

Я также наткнулся на предложение 2013 года относительно нескольких других параметров, которые могут значительно увеличить пропускную способность, если ваша рабочая нагрузка включает большое количество потоков. (Или, возможно, более точно, он -увеличивает пропускную способность, которую они получили на ядрах до -CFS ).

ИгнорироватьCONFIG_HZ

Я думаю, вам не нужно беспокоиться о том, что установлено CONFIG_HZ. Насколько я понимаю, это не относится к текущим ядрам, если у вас есть разумное оборудование таймера. См. также коммит 8f4d37ec073c, «sched :высокий -тик вытеснения разрешения» , найденный в этом комментарии в ветке об изменении:https://lwn.net/Articles/549754/.

(Если вы посмотрите на коммит, я бы не стал беспокоиться, что SCHED_HRTICKзависит от X86. Похоже, что это требование было снято в более позднем коммите ).

12
27.01.2020, 20:39

(это должен быть комментарий, но он немного длинный)

Less frequent context switches should be able to allow higher throughput

Только в том случае, если ядро ​​предварительно -удаляет задачи и помещает их обратно в очередь выполнения.

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

0
27.01.2020, 20:39

Теги

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