“Пропуская отдельный debuginfo для …” при выполнении gcore

(для подведения итогов моих комментариев к OP)

Трехстороннее квитирование, к которому они обращаются, является частью установления соединения TCP, рассматриваемая опция не имеет отношение конкретно к этому. Также обратите внимание, что обмен данными не является частью трехэтапного квитирования, это просто создает соединение TCP в открытом/установленном состоянии.

Относительно существования этой опции это не традиционное поведение сокета, обычно поток обработчика сокетов разбужен, когда соединение принято (который является все еще после того, как трехэтапное квитирование завершается), и для некоторых протоколов действие запускается здесь (например, сервер SMTP отправляет 220 строк приветствия), но для HTTP первое сообщение в разговоре является веб-браузером, отправляющим ПОЛУЧАТЬ/POST/И Т.Д. строку, и пока этого не происходит, сервер HTTP не имеет никакого интереса к соединению (кроме таймаута его), таким образом будя Процесс HTTP, когда сокет принимает, завершается, расточительное действие, поскольку процесс сразу заснет, снова ожидая необходимых данных.

В то время как существует, конечно, аргумент, что пробуждение неактивных процессов может сделать их 'готовыми' к последующей обработке (я конкретно не забываю будить терминалы входа в систему на очень старых машинах и иметь их пыхтение в от подкачки), но можно также утверждать, что любая машина, которая выгрузила упомянутый процесс, уже требует у своих ресурсов и делает дальнейшие ненужные требования, мог бы в целом уменьшить производительность системы - даже если очевидная производительность отдельного потока улучшается (который это также не может, чрезвычайно занятая машина иметь узкими местами на диске IO, который замедлил бы другие вещи, если бы Вы загрузили, и если его настолько занятый, непосредственный сон мог бы подкачать его назад). Это, кажется, азартная игра, и в конечном счете 'жадная' азартная игра не обязательно окупается на занятой машине и конечно вызывает дополнительную ненужную работу над машиной, которой уже загрузили процесс - Ваш подход оптимизирует для машины с набором памяти большой емкости процессов, которые главным образом бездействуют, и свопинг одной дремоты для другого не является никаким грандиозным предприятием, однако машина с набором памяти большой емкости активных процессов пострадает от дополнительного IO, и любая машина, которая не является ограниченной памятью, страдает, любая зависящая от ЦП машина окажется в худшем положении.

Мои общие рекомендации относительно того уровня настройки производительности не состояли бы в том, чтобы принять программные решения относительно того, что является лучшим так или иначе, но позволить системному администратору и операционной системе сотрудничать, чтобы заниматься проблемами управления ресурсами - который является их заданием, и они намного лучше подходят для понимания рабочих нагрузок всей системы и вне. Дайте выбор конфигурации и опции.

Для специфического ответа на вопрос опция выгодна на всех конфигурациях, не к уровню, кроме которого Вы когда-либо, вероятно, замечали бы под экстремальной нагрузкой Трафика HTTP, но это - теоретически "правильный" способ сделать это. Это - опция, потому что не весь Unix (даже весь Linux) ароматы имеют ту возможность, и таким образом для мобильности это может быть настроено, чтобы не быть inclided.