не будет постоянно меняющаяся привязка, присвоенная потокам ядром Linux, имеет отрицательный эффект на общую производительность?
У меня сложилось впечатление, что вы ищете такой инструмент, как GNU Stow.
GNU Stow - это менеджер ферм symlink, который берет отдельные пакеты программ и/или данных, расположенные в отдельных каталогах файловой системы, и делает вид, что они установлены в одном и том же месте. Например,
/usr/local/binможет содержать симлинки к файлам в пределах/usr/local/stow/emacs/bin,/usr/local/stow/perl/binи др, а также рекурсивно для любых других подкаталогов, таких как.../share,.../man, и так далее.
Проверьте, совпадает ли она со случаем использования.
Если вы собираетесь запускать все потоки на одном ядре, купите более дешевое оборудование с одним ядром.
Планировщик пытается максимально использовать все ядра. Это означает отправку потоков на любое ядро, у которого есть свободное время. Перемещение потока с одного ядра на другое имеет небольшую стоимость, поэтому планировщик старается этого избежать. Но вы, как правило, этого не замечаете, поскольку преимущество того, что ядро не простаивает, гораздо больше, чем затраты на перемещение потока. Это особенно верно, если потоки используют больше памяти, чем вы имеете локальный кэш ядра: если память, используемая потоком, не находится в локальном кэше ядра, то при переносе ее на другое ядро можно потерять очень мало.
Второстепенное предположение о том, что планировщик промышленного класса, такой как Linux, обычно ухудшает производительность.
Графики, которые вы показываете, показывают, что нагрузка на различные ядра не является полной и слегка переменной, предположительно потому, что ваша система в целом ограничена вводом/выводом для задач, которые она выполняет прямо сейчас, а не питанием процессора. Здесь так или иначе ничего не сказано о том, как часто потоки перемещаются с одного ядра на другое.
Во-первых, почему? В документах для s _ клиента указано, что openssl по умолчанию использует рукопожатие, которое определяет правильный протокол для вас. Это вся основа атаки POODLE. Проблема в том, что в 0.9.8 это рукопожатие начинается с SSL_V23 и в какой-то более поздний пункт попытается TLSv1. Многим серверам не нравится, когда клиенты подключаются с помощью SSL_V23, потому что это красный флаг, что клиент делает что-то небезопасное, отсюда и ваша проблема.
Как это исправить? Ну, я не смог найти какой-либо вариант openssl.cnf, который бы позволил вам сказать «Эй, по умолчанию просто использовать» TLSv1. В этот поток предполагает, что это возможно в версии 1.0.0 +. После часа поиска в Google, я решил, что ваша лучшая ставка - это перекомпилировать openssl и отключить SSLv2 и SSLv3 . Если вы перекомпилируете openssl, это, вероятно, будет намного проще использовать 0.9.8, пытаясь обновить openssl до 1.x + в что-то вроде RHEL может быть полный кошмар.
-121--111714- Если я правильно понимаю, о чем вы спрашиваете, то в smb.conf , расположенном здесь:
/etc/samba/smb.conf
Добавьте следующие параметры в раздел [global] :
force user = rolf
force group = coders
Предоставленный здесь снимок зависит от типа (версии) ядра. Старые ядра с версией 2.4 имели слабое сродство, что вызывало большое количество движения ping-понга потоков, влияющих на производительность системы. Версии ядра от 2.5 имеют относительно лучшее сродство.
В многоядерной системе установка соответствия может повысить производительность, избегая недействительности кэша при перемещении потока по ядрам.
В случае многоядерной системы на базе Linux поведение сходства планировщика (естественное сходство) может быть переопределено в зависимости от типа приложения/требования с помощью sched_setaffinity/taskset для процесса и pthread_setaffinity_np для потока.
kernelshark , по-видимому, обеспечивает лучшее визуальное представление многоядерной системы и сходства.
Также обратите внимание, что htop обеспечивает визуальную поддержку для установки сходства (для переопределения планировщика).