Исходное сообщение
"Эксперимент по повышению эффективности работы утилиты cat" Отправлено Аноним, 19-Июл-22 21:39
Боюсь, что нужно быть конкретнее... Чудовищный оверхед от переключения контекстов с последующей деградацией производительности без полной утилизации я по опыту наблюдал в Linux сильно чаще, чем в других ОС, но нельзя же вот так сразу говорить, что виновато именно ядро. В моем случае чаще всего виновником было либо ПО, которое имеет "специфику" реализации, вышестоящая инфраструктура виртуализации, которая с одной стороны наложила дополнительный оверхед, а с другой стороны, какой-то злодей положил на хост с высоким оверкоммитом CPU много маленьких виртуальных машин и одну большую, при этом она неверно отражает аппаратную топологию хоста виртуализации. Давайте еще вспомним, что Linux такие вещи сам в себе не настраивает, нужно учитывать аппаратные особенности сервера (SMP/NUMA), параметры premmption, tick frequency и всякие CONFIG_NO_HZ_IDLE / CONFIG_NO_HZ_FULL. Все зависит от того как вам сконфигурировали ядро в дистрибутиве (обычно плохо, понавключав энергосберегательных режимов). Начните читать тут: https://docs.kernel.org/timers/no_hz.html И вообще каждый случай уникален, но есть еще одна общая черта... Не включайте HyperThreading или как там назвали ваше SMT в процессоре на серверах, где у вас ПО, которое приводит к паразитной нагрузке за счет переключения контекстов. Если планировщики процессов Windows еще умеют хитро шаманить так, чтобы оно не деградировало от наличия SMT, то в Linux эту дрянь лучше сразу выключить.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> Боюсь, что нужно быть конкретнее... > Чудовищный оверхед от переключения контекстов с последующей деградацией производительности > без полной утилизации я по опыту наблюдал в Linux сильно чаще, > чем в других ОС, но нельзя же вот так сразу говорить, > что виновато именно ядро. > В моем случае чаще всего виновником было либо ПО, которое имеет "специфику" > реализации, вышестоящая инфраструктура виртуализации, которая с одной стороны наложила > дополнительный оверхед, а с другой стороны, какой-то злодей положил на хост > с высоким оверкоммитом CPU много маленьких виртуальных машин и одну большую, > при этом она неверно отражает аппаратную топологию хоста виртуализации. > Давайте еще вспомним, что Linux такие вещи сам в себе не настраивает, > нужно учитывать аппаратные особенности сервера (SMP/NUMA), параметры premmption, tick > frequency и всякие CONFIG_NO_HZ_IDLE / CONFIG_NO_HZ_FULL. > Все зависит от того как вам сконфигурировали ядро в дистрибутиве (обычно плохо, > понавключав энергосберегательных режимов). > Начните читать тут: https://docs.kernel.org/timers/no_hz.html > И вообще каждый случай уникален, но есть еще одна общая черта... Не > включайте HyperThreading или как там назвали ваше SMT в процессоре на > серверах, где у вас ПО, которое приводит к паразитной нагрузке за > счет переключения контекстов. Если планировщики процессов Windows еще умеют хитро шаманить > так, чтобы оно не деградировало от наличия SMT, то в Linux > эту дрянь лучше сразу выключить.
	Введите код, изображенный на картинке: